Blog – A complete solution for maintaining deployed software on the Windows platform

Deploying Applications with AppLife Cloud

AppLife provides the ability to easily deploy and maintain many applications on your Windows clients and servers. By installing AppLife Manager on your deployed systems a channel is created with which one or more applications can be deployed and maintained using AppLife packages. This is the first of a series of posts that will discuss and demonstrate the use of AppLife tools to deploy software. This series will include:

Deploying an application with AppLife
Using mostly default settings, we’ll start from a brand new AppLife subscription and deploy a .NET WPF application through AppLife Manager.
Explore Manager Deployment Options
After looking at a default deployment in the first post, we’ll demonstrate the different configuration options available with AppLife Manager.
Explore the AppLife Engine
The deployment package in the first post added two files to the installation directory. In this post, we’ll look at other actions and demonstrate the features of the AppLife Update engine.
Using the Dashboard
The AppLife Dashboard provides the ability to control which of your deployed systems get applications and updates. It can help in troubleshoot defective packages, can identify which clients are running what version of your applications and more. The final post in the series will look at how the dashboard enhances your AppLife deployment model.

Connecting AppLife Manager to your Subscription

The AppLife Manager application gets installed on all of the systems that will run your software and connects your deployed clients to your AppLife subscription. AppLife Manager is downloaded from AppLife Update home page (www.applifeupdate.com). Once installed, you’ll connect Manager to your subscription through a registration process. To register AppLife Manager, you’ll need your Publisher Code. You’ll also need to define a Client Access Key. The Client Access Key will be a value that identifies an individual client, or perhaps a group of clients.

Your publisher code can be found on the Subscription view of your dashboard and can be replaced with a custom value.

Defining a Custom Publisher Code

You can set a custom publisher code for your subscription. One that is more meaningful and easier to remember, such as your domain name. A custom publisher code is set from the Subscription view on your dashboard.

With your publisher code entered, the default settings of your initial application will allow it to be discovered. It’ll be displayed within AppLife Manager. Nothing is actually installed on this deployed client yet, as there are no AppLife packages published for the application.

Deploying an Application

We have an application, called First Look that we want to deploy. We are going to effectively XCopy deploy our First Look application to our client machines through AppLife Manager. To accomplish this, we’ll create and publish an AppLife package that, when executed, will place our application on the deployed client. Once published, AppLife Manager will automatically discover and apply the package.

To create the package, we’ll use the AppLife Builder application. Like AppLife Manager, this can be downloaded from the AppLife Update home page. Once downloaded and installed, log into AppLife using your credentials. Select your subscription application. You’ll be prompted for the basic information about your application.

Application Name
Set this to your application’s name. In this case, First Look. Note that this will change the name displayed in AppLife Manager.
Executable Name
Set this to the name of the primary executable of your application. FirstLook.exe.
Local Working Directory
This is a local value that defines the local directory for your application and will be used for relative paths later. For custom software, this is usually a bin directory or an output directory of your build process.

AppLife Actions

An AppLife Package consists of a series of Actions that will take place when the package is executed on a deployed client. There are many actions available. This first package is going to include only one action. An Add & Replace Files action, which will copy two files to the designated Application Directory. When AppLife Manager discovers and applies this package, these two files will be copied.

By default, AppLife Manager applications will check for new versions every 24 hours. After having published this package, any connected clients will install First Look on their next check. AppLife Manager can also be refreshed manually, which will find the application immediately.

Deployments in the Dashboard

When a client applies an AppLife Package, the results are reported to your dashboard and can be reviewed there.

Summary

Using a new AppLife Subscription, we just built an AppLife Package that deploys our existing application through AppLife Manager. With the exception of setting a custom Publisher Code and changing the application name, we used entirely default settings. In the next post, we’ll explore the configuration options available through AppLife Manager that will let you customize the deployment and maintenance model to better fit different scenarios.

Use the WiX Toolset and AppLife Cloud to Install and Maintain Software Applications

Packaging software for Installation on the Windows platform is most commonly accomplished by using the Windows Installer. The WiX installer is one of the many tools available to create Windows Installer packages (.msi files). WiX Installer Xml is a popular and well documented toolset with a large library of online resources to help new integrators get started.

AppLife Cloud is a turn-key software distribution and updating online service that provides the functionality to publish, control and monitor the distribution of software, and future updates, over the internet. AppLife can be implemented using an installable client application that, when connected to an AppLife Subscription, can install and maintain one or more applications on a Windows computer, requiring no source code integration with any of the maintained applications. Alternatively, AppLife can be integrated into an application’s source code to deliver a tightly coupled maintenance process for installed software.

WiX, Major Upgrades, and AppLife

In this article, we’ll use the WiX Toolset to create a Windows Installer for our application that implements a Major Upgrade scheme. Then, we’ll use AppLife Cloud tools to create an online distribution channel for the application. To help support the use of AppLife, we’ll also implement an ARPINSTALLFOLDER Custom Action within the WiX project, which writes to the Windows registry the local directory that the application gets installed into, which AppLife tools use.

The AppLife Builder tool is used to package the application Msi file created by WiX and publish it to the AppLife cloud, where it can be discovered and executed using AppLife Manager. AppLife Manager is a small client software that lives in the Windows System Tray, capable of automatically deploying and maintaining many applications through the AppLife Cloud. As an alternative to using AppLife Manager, the AppLife API can be used to integrate update discover and execution functionality directly into the Windows application.

These examples are based on the standard templates used by Visual Studio 2022 and the Wix Toolset to create the .Net example application and the WiX created Windows Installer(.msi).

The Example Application

Our example application will be a .Net 7 Windows Forms application, created using the Visual Studio application template. We’ll add no functionality as we will be focusing on packaging the application for deployment and future continuous updates and maintenance.

Create the WiX Installer

WiX uses XML files to define how the Windows Installer is created. Compared to other GUI based Windows Installer build tools, WiX has a larger learning curve. After paying the early learning price to get started, our experience suggests literally every objective thereafter relating to Windows Installer functionality is easier accomplished with WiX than other tools.

To get started, install the WiX 3.11 toolset, and then in Visual Studio WiX, the WiX v3 Visual Studio 2022 Extension. To be clear, Visual Studio is not necessary to use WiX, but since we are using Visual Studio and .Net, we’ll use the extension as Visual Studio makes for an excellent XML editor and we can use Visual Studio environment variables to help with accessing sourcing the files and assemblies for inclusion.

Create a new Setup Project using Visual Studio

We’ll make a few immediate changes to the standard template.

1. Embed the CAB file. We want a single MSI file to deploy. To support this, we make a change to the Media Template element.

2. Add ARPINSTALLLOCATION custom action to the installer. This action writes the installation directory to the registry and allows AppLife to lookup the install location using the registry information.

3. Support Major Upgrades. The WiX template is already configured to support Major Upgrades. If starting from an existing WiX project, verify that the UpgradeCode attribute is set on the Project element, the Id attribute is set to *, and the MajorUpgrade element is present in the Product Element.

4. Add a reference to the .Net Application to the WiX msi project. This allows us to use environment variables to source the files we’ll add to the installer.

Add Files to the Installer

This is the output directory of the Visual Studio application. The Windows Installer must deploy the highlighted files. We’ll add the necessary WiX components.

And in the Wix Project….

Now we can build the Windows Installer project and generate an MSI that we will distribute and deploy with AppLife.

Deploy with AppLife Cloud

Create an AppLife Application. If you don’t already have an AppLife Subscription, here’s how to get started.

We’ll start with a newly created AppLife application. Since we’ll be using the Windows Installer, our action list will include only one action, which will execute the Windows Installer file we created with WiX.

Add a Run Windows Installer action to the action list. Select the Windows Installer to run, select the Quiet/Silent option, and finally the Set AppLife Manager Application Directory option.

Publish an AppLife Package

Create version 1.0.0.0 by clicking the Create an Update… button.

For Access Control, leave set to the default Application option. Access control lists can be configured to publish an update package for a specific group of users, but for this example we are using anonymous access and publishing for everyone.

Enable AppLife Manager

To enable any client connected to your AppLife Subscription with AppLife Manager to discover and install this example Windows Forms application, we need to configure the application through the AppLife Cloud dashboard.

And we’ll also set the application access control to allow anonymous access.

With these actions taken, AppLife Manager can discover and deploy this new application. Future updates are then automatically discovered and installed.

Conclusion

AppLife Cloud and the WiX installer combines to create an excellent software package and distribution model for new and old applications that target the Windows platform. With WiX, you can create an MSI that can be installed on any PC, and when combined with AppLife Cloud, you have an instant global Software Distribution network that can be used to deploy and maintain all your applications across your user-base. This short example just scratches the surface on what can be accomplished with both tools. WiX enables everything that is possible with the Windows Installer technology and includes many tools and techniques that we did not touch on to manage large-scale installations. AppLife extends this with a solid distribution system, many actions that can be taken during a package execution far beyond executing an MSI, and access control that can all be accomplished without any source code integration to your applications. Please visit the following additional online resources on these technologies for more information.

The WiX Toolset

AppLife Cloud

AppLife Documentation

New Iterate List Action

A new Iterate List action introduced in version 6.0.0.98 allows for iterating a collection of items and calling a designated Action List once for each item in the collection.

The action will iterate any IList<object> collection. The collections to iterate can come from the results of other Actions, such as the Find Files and the Find Services actions. The Set Shared Property action has been extended to include a new Text List type of Shared Property, which can be iterated. And finally, the Iterate List action can be used in conjunction with the C#/VB.Net action, which exposes programmatic access to the entire Shared Properties dictionary, to perform complex repetitive operations during package execution.

Example Usage

To demonstrate the usage of this action, we’ll add 10 sub-directories to our Application Install Directory and add an image file to each one. We’ll start by creating the Action List that will add the files to the designated directory. Note the use of the item Shared Property.

Next, we’ll create the List to iterate. This list will contain the Directory Names for each of the new directories. The Action List will use the current value of the list item to define the directory name. The value is provided to the Action List in the form of a Shared Property (item), who’s key value is defined by the Iterate List action settings.

Finally, we’ll add the Iterate List action to the Primary Action List. Configure it to iterate our list created by the Set Shared Property action and call our specific CreateAndPopulate Action List once for each item.

While the example provided is quite trivial, the demonstrated usage of the Iterate List action will hopefully trigger thoughts on how the action can improve the installation and maintenance of your AppLife managed applications.

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.

Set a Custom Extraction (Working) Directory

When AppLife downloads and executes a maintenance package, a working directory is created in a designated location on a deployed client. Depending on the configuration, this is usually in a user’s temp directory. Sometimes it is necessary to define a specific working directory for a machine. AppLife provides a mechanism to accomplish this.

Add a key to the 64 bit registry. HKLM\SOFTWARE\KineticJump\AppLifeUpdate\ApplicationSettings\{Your Application ID GUID}

Add an UpdatePackageDirectoryRoot string value.

If a value exists for an application, the AppLife Engine and Launcher will utilize the specified directory. The Windows Identity of the host process will need to have both write and execute permissions to the directory.

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.

Application Master Passcode

When a deployed application discovers and downloads an AppLife package, the first action taken is a verification of the package using the Public Key value that is already present on the client and the update package signature that comes with the package. Digital signature validation using asynchronous cryptology. If the downloaded update package fails validation, it is never loaded or executed. There are many reasons why a downloaded update package might fail validation, but whatever the reason, a failed validation means that the update package is not identical to the package that was built and published by the author.

Validation ensures that the package that is about to be applied on a deployed client is the exact package that was created and published. The validity of the authentication process performed by AppLife is completely dependent on the sanctity of the project’s private key. This validation process ensures that it is not possible for a third party to create a package that could ever be applied through your software.

So if your AppLife Cloud account was compromised, would your application private keys be at risk? Yes they would, and this could potentially lead to a third party having the ability publish a privileged update package that your deployed clients would apply. Securing your AppLife Cloud account through strong passwords, two-factor authentication, and Publishing IP Address Filtering significantly reduces the probability of a compromised account. Beyond these, another action that can be taken to secure your deployed clients is to implement a Master Passcode on your individual applications.

A master passcode is added to your application locally through AppLife Builder. Navigate to your project settings dialog and open the Security tab. When a master passcode is provided, AppLife Builder uses the code to encrypt the application keypair before transmitting application data to the AppLife Cloud. The master pass code is never transmitted and only stored locally if elected to be.

If a unique passcode is applied to your application, the passcode is never transmitted and an update for the application can never be created without it.

A master passcode provides maximum protection against a compromised AppLife Cloud account, as a final secret that is required but never shared. With this protection comes the reality that a master passcode can never be recovered if forgotten. If a master passcode is forgotten, your deployed clients are forever disconnected from the remote update capabilities provided by AppLife.

For maximum protection from your update process ever being used to compromise your deployed clients, choose and implement a unique strong master passcode.

Publishing IP Address Filtering

Using the AppLife Cloud solution makes it easy to deploy and maintain applications by creating a channel between you the application publisher, and all your deployed client systems. It’s very important to protect that channel and keep it secure. Steps to keep your deployed clients secure started with:

Setting a strong password on your account. We require 8 characters, a letter, a number and special character, but going beyond these minimums is recommended. Using a password tool such as Last Pass makes using long strong passwords very manageable.
Enabling Two-Factor authentication on your account. In addition to a strong password, requiring something you have in addition to something you know adds a significant level of protection.

The next step to consider taking is enabling Publishing IP Address Filtering on your AppLife subscription. This is a great idea if your application publishing always originates from static IP addresses. Once enabled, your application update packages must originate from an IP address in your defined list.

To enable IP Address Filtering, navigate to your Subscription Properties view within your dashboard. IP Filtering is subscription scoped, and covers all applications in your subscription with one list.

Once on the Subscription Properties view, you’ll find the IP Filtering list towards the bottom. When you click the enable checkbox, your current IP Address is automatically added to the list. You can add as many IP Addresses as you need. Save the list and you have successfully enabled IP Filtering.

Enable Two-Factor Authentication

Securing your AppLife Cloud accounts is vitally important. In version 6, we’ve implemented multiple features designed to keep your accounts safe. One of these features is two-factor authentication.

Two-Factor authentication works by requiring a user to follow up your standard username and password credentials (something you know), with an additional authentication step that requires you to provide something you have. This style of authentication removes the potential of compromised credentials (commonly acquired by simply guessing, sophisticated brute force, or duplicate credentials from a less secure site) alone allowing access to your cloud account. With two-factor enabled, the potential imposter would need more than just your credentials. How much more, is configurable. There are three options available.

A one-time passcode emailed to the account email address
A passcode generated by an Authenticator app on a mobile device
A hardware USB key

Email Option

The simplest option available is to enable the Email method. With this method enabled, whenever you sign on to AppLife Cloud on a new device, an email will be sent to the account email address. This email will contain a one-time pass code. Enter this code when prompted and you’ll be successfully authenticated.

Authenticator App Option

An authenticator app shares a private code during setup, and then generates rolling one-time passcodes that expire. Once setup, you will need the device with the app that you configured in your possession in order to log in and authenticate. The app that AppLife Cloud uses is Google Authenticator. Available for both Apple and Android mobile devices, it is a great option and more secure than Email, as it requires physical possession of your device during AppLife Cloud authentication.

USB Hardware Key Option

USB Hardware keys are the third and most secure option for validation. AppLife Cloud supports YubiKey brand keys. Once set up, the physical key must be present to login. The Series 5 key supports USB, USB-C and NFC. You can use your YubiKey for authentication on AppLife Cloud as well as many of the popular sites around the web, such as Google, Microsoft, Amazon, Apple and Twitter to name a few.

You can set up multiple keys on your AppLife Cloud account.

Pick one of the options and enable two-factor authentication on your AppLife Cloud account today. Doing so adds a significant level of protection for your AppLife enabled deployed applications.