AppLife Manager

Controlling Access to AppLife Applications and Packages

AppLife Cloud provides an excellent channel to distribute custom software applications to Windows desktops and servers. For many subscribers, they publish their packages using the default anonymous access settings and it works great for them. But there are many scenarios where it becomes important to filter access to specific applications and packages. The most common scenario is for limiting new versions to testing and QA installations and then opening them up later for wider distribution. Whatever the scenario, when applications require limited access, AppLife Cloud provides a simple method that works well. Our method works like this…

A string token is assigned to each installation, called a Client Access Key (CAK). Client Access Keys do not have to be unique. Through your dashboard you can create lists of Client Access Keys. These lists are assigned to Applications and AppLife Packages which determine their visibility to installations checking for packages. It’s that simple. In this post, we’ll review how to work with Client Access Keys and Access Lists in AppLife Cloud.

Assigning Client Access Keys

Client Access Keys can be any string value and are specific to the applications domain. While individual installations don’t require unique Client Access Keys, we recommend creating unique keys for each application installation. This not only provides the most flexibility in controlling access to Applications and Packages, but it allows for better monitoring your install base throughout the life of your application within your AppLife online dashboard.

AppLife Manager

When using AppLife Manager on deployed clients, the Client Access Key is set when AppLife Manager is connected (registered) to your AppLife subscription. When installed independently on a computer, the Register Subscription command is used.

When AppLife Manager is installed through automation, a subscription is added through a Command Line Action.

AppLifeManagerInstallDir\AppLife Manager UI\RegisterNewServer.exe <SubscriptionId> <ClientAccessKey> [<disableAppApprovals>]

Setting Client Access Key through Command Line

AppLife Controller API

When the AppLife API is used through NuGet to integrate an update process directly into your application, the Client Access Key is set as a property value of the Update Controller object.

Using an Update Controller to set Client Access Key

Creating Access Lists

Access Lists are collections of Client Access Keys that can be assigned to Applications and AppLife packages to control visibility of these assets.

Individual Access Lists are “owned” by an application and the editor is opened through the dashboard Application view. When viewing any application in your dashboard, the Client Access view can be opened through the Application Menu.

From there you can control most of the features of Access Control. Clicking to Manage Access Lists displays all of the applications Access Lists. By selecting a list, you can edit that list, clone the list into a new one, delete it or copy the entries onto the clipboard. You can also add a new list from here.

When adding/editing a list, the list name is editable and a list of the Client Access Keys included in the list is displayed. When adding a Client Access Key, the list of existing keys that don’t match the current entry are hidden from view. This helps find an existing Client Access Key in a list and also prevents entering duplicates.

Bulk Add

To assist in adding an existing list of Client Access Keys, there is a Bulk Add option. Using Bulk Add, multiple Client Access Keys can be added at the same time, one per line. This supports using the clipboard to paste from spreadsheets or query results.

Client Access API

In situations where Client Access Keys are managed from a separate supervisory system, Access Lists can be manipulated through the Client Access API. This will allow lists to be created, removed and entries added and removed. To use the Client Access API, it must be enabled per application and a token must be generated. The different API actions are called through HTTP Post to the respective addresses. More information is available in the AppLife Cloud documentation.

Sharing Lists

Access Lists are created and maintained for individual applications, however lists can be shared across all applications within an AppLife Subscription. This allows a single set of lists to be maintained for subscribers with multiple applications that use some or all the same Access Lists. To share an Access List, the list must be selected as shared.

On applications where this shared list is to be used, toggle the option to Use Shared Lists. Any lists shared through any subscription application will be available for selection.

Assigning Access Lists

With Access Lists created and shared as necessary, they can be assigned to Applications and Individual AppLife packages to control exposure to clients. By default, new applications are configured for Anonymous access. To filter access based on Client Access Keys, disable the Allow Anonymous Access setting, and then check the appropriate access lists that should be able to see the application.

Assign Lists to Individual Packages

Access to individual AppLife packages can be set during publishing and can be modified afterwards through the dashboard or through the AppLife Builder application. A common use-case is to publish packages initially for testers, and then open it up for wider distribution through the dashboard later. When publishing, the Version Access Mode options are Application, Version, and None. When Version is selected, the Access List selections will override the application level selections.

Version Mode Access Entries can also be modified through AppLife Builder.

Modifying Version Access through AppLife Builder

Version Access Lists can also be assigned through the dashboard. Select to edit the individual AppLife package properties by clicking on the row in the Application Versions table.

Conclusion

Visibility of your Applications and AppLife packages published to your AppLife Cloud can be controlled by setting Client Access Keys on each installation and then assigning lists of your Client Access Keys to your Applications and packages.

The AppLife tooling provides the ability to easily integrate Access Control into your dev ops routine. This article provides instruction on how to accomplish access control using AppLife.

Maintaining a Previously Deployed Application with AppLife

We’ve written about deploying and maintaining new applications using AppLife, but what about picking up existing applications that have been deployed over the years? Maybe the application started small, has grown over time but never had a maintenance process built into it. Or maybe it had a maintenance process from the beginning but is no longer working very well. Maybe it’s deployed through XCopy deployment or maybe an MSI installed it. Regardless of circumstance, we’ll show you how to use AppLife to start maintaining that previously deployed application with absolutely no source code integration required.

The Big Picture

In a nutshell, we’re going to use AppLife Manager, which is a Windows Service application that has been or will be installed on your deployed systems, to orchestrate the discovery, delivery, and execution of AppLife packages that will maintain your installed application. For AppLife Manager to perform this maintenance duty, it needs to know where the application is installed and what version is locally present. When AppLife is used in an original deployment, your configuration settings define where and what version gets installed. When picking up an application that has already been deployed through some other method, AppLife just needs to figure out where the application of interest is installed and what version exists there. Once we accomplish this, maintaining the existing application is pretty much the same as any other AppLife maintained application.

We’re going to create an initial AppLife package that will search for the existing application installation and if it finds it, identify what version is present. In the example, we’re using the .Net Assembly version of the primary executable to identify the current version stamp. If the application is not present, we’ll set the version to a value that indicates that the application is not present. That’s all that this first package will do. Then we’ll create another package that installs the current version of the application. At this point, you’ll be able to publish AppLife packages that maintain your deployed application as future versions are created.

Implementing a New Maintenance Process

The first thing we’ll do is create an AppLife Cloud application and configure it as necessary to support the use of AppLife Manager for orchestrating the application maintenance process. You can create a new application through your AppLife Dashboard Subscription view. If you are a new subscriber to AppLife, an application is created for you. To set up the application for maintaining an existing application, we’ll set the Manager Settings like this:

The key setting is the * value for the Application Directory. This instructs AppLife Manager to ignore the server-based setting and rely on an update process to identify the appropriate application directory. We’ll set up that update process in the next step. Here, we’ll also check the box to apply updates automatically and fil in the appropriate process name and primary executable.

Create the Update Package that Searches for Existing Installations

When a new application is created, AppLife Manager sets its version to 0.0.0.0. The plan is to create an initial update package with a version stamp of 0.1 so that when AppLife Manager initiates this application, it will discover only this update package to 0.1. Future updates will target version 0.1 and greater. This 0.1 package will search for the installation that we expect to find and start maintaining. If the application is not found, we’ll assume its not present and we’ll set up a default installation directory that future updates will use to install the application. In any event, after the version 0.1 update package executes, AppLife Manager will know the location and version of the existing application installation and be able to maintain it going forward.

First Action – Set Application Directory

The first action we’ll use is the Set Application Directory action. This action will search the machine for a designated assembly that will identify the current installation directory. The action has some configuration options available and should be configured based on where the existing application is expected to be found. For this example we’ll assume that if we don’t find it in the program files directories it’s not present. We set the assembly’s name that we’re searching for. If the file is not found, we’ll set a default path to be used as this applications installation directory. We’ll use the %ProgramFiles% environment variable. Whatever directory is set will then be placed into a Shared Property that will be used in following actions.

Search for Existing Application Directory

Second Action – Read Version Number

Now that we know where the application is installed, the next step is to determine what application version is installed. This example will use the .Net assembly version, but its possible that determining the existing version might require something else. This action will read the assembly version of the defined assembly, and if the assembly can’t be found, we’ll set a default value of 0.1. The determined version will then be placed in a CurrentVersion Shared Property that will be used in the final action of this update.

Third Action – Set Update Version

The final action will use the CurrentVersion Shared Property to set the AppLife Manager version stamp for the application. Set the action to use an explicit version, and then use the shared property determined in the previous action. When this update gets executed, the version value written here should match the actual version number of the currently installed software.

Create the Update Package that will install the Current Version

For the machines that had the existing software installed, we’re ready to create update packages that will deploy future versions. But for the machines that didn’t have the existing application installed, the next update package should perform a full installation, and target version 0.1 and higher. We’ll create an update package to version 2.0 of My Existing Application. This package will simply package up the entire installation directory and place it in the designated installation directory. Non-trivial applications might require more actions, but just about anything is possible.

Note that the path to the folder to copy files from is relative to the local working directory that is set up when first creating the application builder profile. The working directory can be changed in the project settings dialog.

This action simply packages every file in the local directory and places them in the defined target client folder when the update is executed. This is the application directory discovered or set in the 0.1 update.

In Conclusion

This is the recommended method to start maintaining an application that is already deployed using AppLife. By using AppLife Manger we avoid any source code integration into the application being maintained. The flexibility that using AppLife packages provides in maintaining deployed software opens the opportunity to use AppLife for application that doesn’t currently have a maintenance process built into it. AppLife Manager needs only be deployed once on deployed clients and once deployed, can maintain many applications.

Explore Manager Deployment Options

The AppLife Cloud solution provides a turn-key custom software management system, enabling deployment and maintenance of your software that targets the Windows operating system. On your deployed clients, the AppLife Manager provides the significant task of orchestrating the discovery, download and execution of AppLife packages. In this post we’ll dive into AppLife Manager, looking at it’s options and features.

Visual Branding

AppLife Manager is a Windows Service that performs most of it’s work behind the scenes. Your users won’t often interact with Manager at all, but when they do we want them to know what they are interacting with. Namely your software and your company. AppLife Manager sits in the System Tray and pops up messages from time to time.

When the user does open the AppLife Manager user interface, there are options to adorn it with your company and your application visuals.

Publisher Settings

Your AppLife Subscription has settings that determine how your AppLife Manager header looks, as well as what is shown on the information form within AppLife Manager.

Organization
By-line
Publisher Image
First Name
Last Name
Phone
Email

By settings these values, your company information is displayed to the Applife Manager user.

Application Settings

For each application you can define a name and an image. We’ve already set the name of the application to First Look in the last post, where we created and published an installer for the application. You can also set an image setting that can be defined in the application properties view.

Putting this together, by changing a few properties in the AppLife Dashboard, we can transform the visual representation of our company and our applications within AppLife Manager.

Application Behavior

The behavior of AppLife Manager applications is customizable as well.

How often does an application check for new packages?
What happens when a new package is discovered. Apply automatically or prompt a user?
Restrict applying packages to off-peak times?

These behavior settings can be set globally for all clients, or you can allow these settings to be modified locally. Or, you can allow only specific clients to modify locally.

Check for Updates Frequency – Sets the number of minutes between checks. The default is 1440 (once a day), and can be set as low as every 5 minutes.

Apply Updates Automatically – When checked, updates will be applied automatically. If the application is running at the time of initiation, a prompt will be presented to any logged in user that is running the application. If any decline the update, it is postponed. If the application is not running, the update is applied immediately, unless an Off-Peak Time Windows is defined and the current time is not in the time window. In this case, the update is postponed until the start of the off-peak time window.

Disable Sending Failed Execution Logs – When an update fails, the execution log is posted back to the AppLife Cloud for troubleshooting and can be viewed in the dashboard. This post can be disabled.

Off-Peak Updating Time Window – It’s often advantageous to apply updates during off peak hours so as not to disturb daily operations. You can set a beginning time and number of hours to allow updates to be applied. When set, package installations will be be initiated in that time window. AppLife Manager will still check for, and download packages based on the frequency settings, but will not apply a package outside of your defined time window.

Allow Behavior Settings Locally – Checking this option allows local users to define their own application behaviors.

The example above shows a local setting that overrides the update frequency to check every 5 minutes and sets a daily off-peak time window from 02:00 AM to 06:00 AM.

Note the Disable Application Updating option available in the local settings window. When local settings are enabled, users can disable updating completely on their machine. Also note that local settings are application specific, so local settings can be allowed on one subscription application, but not others.

Allow Local Settings on Specific Clients

In circumstances where overriding application behavior isn’t desirable for every client, this setting can be toggled for specific clients through the AppLife Dashboard Client View.

Installation and Process Settings

Beyond behavior settings, there are settings that affect the installation and operation of an application within AppLife Manager.

Application Directory
Process Name
Primary Executable
This Application has an integrated Update API
Client Version Mode

Application Directory – Defines the directory on the local client that will be used as the application’s directory. Actions within AppLife Packages can target this directory for file placement. Windows environment path variables can be used in this setting. The default value is %ProgramFiles%\%ApplicationId%.

* – * is a special value in the application directory settings and can be used in coordination with an AppLife Action that will set the application directory during a package execution. The action will search specified directories for a designated executable and use the discovered directory, or use a defined directory if the executable is not found. In the scenario where an application is already deployed, but you would like to start using AppLife Manager to maintain existing installations, you can use an AppLife Action to set the Application Directory to the discovered existing installation directory.

Process Name – The defined process name is the process that AppLife Manager looks for to determine if the application is running. This value is usually in coordination with the Primary Executable, and is defaulted based on the defined Primary Executable, but it does not have to be. It can be set independently.

Primary Executable – The primary executable is used for multiple functions. It is used by the Start button in AppLife Manager. It can be used to determine the current version of the application that is installed, and it’s used to re-launch the application if it was running when the package installation started. One caveat is when Windows Services are being maintained. In this case Manager does not shutdown or restart directly. Instead you will need to use Update Actions in your package, which use the Windows Service Manager to stop and subsequently restart your Windows Service processes.

Integrated API – When an update controller is integrated into the application being maintained by AppLife Manager, the inter-process communications that occur between controllers will initiate the shutdown of the application being maintained. Events are triggered that you can integrate with and use to perform customized tasks within your application code during the update process. Integration is not necessary for AppLife Manager to maintain your applications, but the integration hook is available for advanced or more technically challenging scenarios.

Client Version Mode – An important determination in the software maintenance process is identifying what version is actually installed on the deployed client. The simplest method to use is to let AppLife Manager maintain this value for you. This is the default method. The local version is based entirely on the version stamp of the last update package installed. No explicit action is necessary to use this versioning mode. You have additional options which might be better suited for your applications. You can use the configured primary executable’s assembly version or file version. This is advantageous when you start maintaining an application that was previously deployed. Another option is to use the MSI display version. This is best suited for applications that are using AppLife Manager solely for deploying and initiating Windows Installer packages. In this case, AppLife Manager can use the Windows Installer display version, which is maintained by the MSI process itself, to determine the locally installed version of the application.

Summary

Using AppLife you can easily deploy and maintain one or more applications over your fleet of Windows based client systems. In this post, we reviewed many of the options available to you, out of the box, when you use AppLife Manager on deployed systems. With no source code integration whatsoever, AppLife Manager can completely automate your maintenance processes. In the next post, we’ll explore what can be accomplished by the AppLife Engine during the execution of AppLife packages, whether discovered and initiated by AppLife Manager or through a direct integration with your application source code using the AppLife API.

Introducing AppLife Cloud Version 6!

We’re excited to announce the release of the next version of AppLife Cloud. It’s never been easier to publish and maintain deployed Windows software with AppLife! Along with a new look and feel, version 6 strengthens the integration of the cloud dashboard, builder tools and AppLife Manager software. On the backend, we’ve increased performance, reliability and extensibility of the platform, which will lead to a better experience and more frequent feature additions going forward.

Here’s a summary of what’s new…

Dashboard

New Identity/Authorization System
- Two Factor Authorization
  - Email
  - Authenticator App
  - Hardware Key
- More strict password requirements
- Email usernames

Responsive Layout
View Failed Client Execution Logs in Dashboard
Persisted Sorting, Paging, Filtering Navigation
Performance and Scalability improvements
IP Based Publishing Filter

AppLife Builder

Formerly called Make Update, AppLife Builder has been completely integrated with AppLife Cloud. You’ll notice the changes upon launching AppLife Builder, as your prompted to log on. All of your build configuration information is now centrally managed within AppLife Cloud. AppLife Builder makes it easier to build and publish update packages for your cloud applications.

Integrates directly with AppLife Dashboard
Simplified, per-user installation without licensing
Key Pair Encryption using local password
Edit published update Access Control configuration
New Install .Net 5 Action
New Install .Net 4.8 Action

AppLife Manager

We’ve added many features to AppLife Manager that makes it a compelling option over direct AppLife integration. Completely manage the distribution and maintenance of your applications without any source code integration. Your maintenance process can be as automated or manual as you prefer, based on simple dashboard configuration. In version 6, deploying applications with AppLife Manager has never been easier.

Organization Information in UI
More visual feedback during update process
Application Update History dialog
Publisher and Application Information dialog
Failed Update Execution Log Reporting to Cloud
Local Behavior Settings Options
- Globally for all deployed clients
- Enable for specific clients
Optionally require admin authorization for new applications
Custom Publisher Code option

API Changes

There is a new .NET 5 (Core) integration assembly. The .Net 4.x integration assemblies are now built on .NET 4.5 and include new TAP based asynchronous integration. The biggest change is that the AppLife integration API is now deployed through NuGet and integrated directly into your Visual Studio projects. You can find them here…

AppLife.Api

AppLife.Api is for .NET 5 applications and includes the primary AppLife Update controller and visual controls for the .NET 5 Windows Client extension (WinForms and WPF)

Kjs.AppLife.Update.Controller

This NuGet package is for applications targeting .NET 4.5 thru 4.8. It includes the primary AppLife Update controller and visual controls for WinForms.

Kjs.AppLife.Update.Wpf

This NuGet package extends and depends on the Kjs.AppLife.Update.Controller package and includes visual controls for .Net 4.5 thru 4.8 WPF applications.

In the Future…

We plan for frequent feature additions on the new platform. The next release is already in development and will add user management for subscription owners, allowing for adding and removing subscription users and modifying the application privilege’s of subscription users. We’re localizing AppLife Manager to German, Spanish, French, Italian, and Dutch with more languages to follow. Were adding more Update Actions too.

More to come…