Hub and Spoke Application Update Deployment
In an application operating environment, it’s a common scenario to see many physical
locations, each with many computers, all pulling application updates from a single
update location. For many of these locations, the network connection to the update
server is slow, compared to the speed of each of the local networks. With each local
system retrieving updates over the slower wide-area connection, bandwidth is expended
resulting in a slow updating user experience. Employing a Hub and Spoke update process,
which maintains a local application update server at selected remote sites, improves
bandwidth utilization as well as the end-user updating user experience.
For applications that operate in an environment like this, maintaining a local update
location at each location and utilizing the faster local network speed to distribute
application updates to local systems represent a much more efficient update distribution
configuration. Configured this way, application updates are downloaded only once
per physical location over the slow wide-area connection, with local computers retrieving
the update from a local update location.
To accomplish this with an application maintained by AppLife Update, we’ll use AppLife
Update itself to replicate the public update folder to a local folder. Once we have
the update folder replicating to a local server, the deployed application on local
systems need only be configured to check the local update folder instead of the
public update location during application updates.
Replicating the Public Update Location
An update location is simply a folder on a server that contains update packages,
as well as a Director.Xml file which describes all of the update packages in the
folder. Whenever an update package is created for your application, the publish
process adds (or replaces) an update package (maj.min.bld.rev.zip) and a modified
Director.Xml file to the designated publish location. To maintain a local
application update folder at separate deployed sites, we will use a new AppLife
Update project to create and publish updates that will maintain a local update
folder. As new update packages are built for your application, a second update
will also be published that will maintain update folders at deployed sites, and
this second update will place this newly created application update package and
modified Director.Xml into the local update folder.
Updating Local Application Update Folders
The update action list used to maintain the replicated update locations contain
two Add & Replace files actions. The first action will include the newest
update package built for the primary application. The second action includes the
We add the update package file first so that the package is present in the update
folder being maintained when the Director.Xml file that includes the package is
placed in the folder. The update folder is not taken off-line during the update,
so it is likely that clients at the site will check for updates as the folder is
being maintained. You’ll notice that the update package is explicitly listed in
this action list, which would require a manual modification to the action list with
each subsequent update version. Automation can be employed to remove this manual
modification requirement. When this update action is built, the action will add
the update package (22.214.171.124.zip) and the Director.Xml file to the Application Directory,
which during update execution will be the application updates folder on the designated
local site server.
The Local Update Process
With an update published that will replicate the latest update package, we need
a process running at the local site that will discover and apply the update. This
could be the primary application itself, however in this example we present a Windows
Service that is to be installed on any local server that is designated to host the
primary application updates. Use of the service is quite simple. Install the service
on the hosting server and configure two paths in the service’s config file. The
first path is the publically available update location where the replicated updates
are published. The second path is the local physical path to the folder that will
serve the application updates. This service will check for updates at the configured
time interval and apply any updates that it finds automatically. As the service
applies updates, the local update folder is maintained to include the latest primary
application updates. The primary application can then be configured to check for
application updates from the local server through UNC, http, or ftp protocols, whichever
the local server supports. The download for this solution lab includes a ready-to-use
service installer, as well as source code for this service which can be modified,
or ported to a different host process, such as a stand-alone executable or as a
function available through the host application itself.
Override Assembly Location
The update process implemented in the service is explained through source code comments.
We call attention to the use of the OverrideAssemblyLocation method of the
Update Controller. This call is used to set the Application Directory designated
in the update actions to the designated local update folder.
Setting the Current Version
When checking for updates, the update process must know the current local version.
For the replication process, the current version is identified through the
highest available update in the local update folder. The service reads this from
the Director.Xml file in the local update folder. Whenever a new update is applied,
the Director.Xml file is replaced during the update process, which updates the local
current version. After the update is executed, the next update check will use the
higher version number as the current local version.
The service writes when an update is applied to the Windows Event Log. Errors that
occur during the update process are also written to the Windows event log. The source
code is provided and can be extended to communicate update information errors to
support staff through channels available to you.
Using the Service
A ready-to-use service installer is available in the solution lab download. To utilize
- Run the Service installer, MyAppUpdateLocationSvcSetup.msi.
- Change the MasterUpdateLocationUrl value in the config file located in the service
install folder to the location that you will be publishing replication updates to.
- Change the LocalUpdateLocationUrl value to the local server folder that will hold
the primary application updates.
- Use the ServerUpdates.aup AppLife Update project file to build and publish replication
updates that contain your primary application updates.
For security reasons, we highly recommend creating your own AppLife Update project
file (.aup) and changing the Application ID and the Public Key to match the new
Application Updates can be easily replicated to any number of remote sites using
AppLife Update. By replicating your application updates to remote sites, client
systems can check for and apply updates from a server local to the client and avoid
using wide-area network connections for application maintenance.
Using a pre-build script, the manual modification to the update action required to insert the correct application update package can be removed. Read the blog post discussing pre-build automation for more information.
Download AppLife Update Here