The new App-V AutoSequencer

Microsoft this week announced some changes in App-V 5 associated with the release of Windows 1703 “Creators Update”. While there is a minor client change to support cleaning up unpublished packages documented here, the real news comes when we see the updated Sequencer, which is the subject of this post.

As of the previous release, the Windows 10 based sequencer is now released as part of the Windows ADK. Because you can’t remove the App-V client on the new OSs, portions of the new sequencers depend upon the equivalent App-V Client being present (they share a lot of code). Thus, it only installs on the similar operating systems and won’t on Windows 7 where the 5.1 HF8 sequencer is preferred. The 1703 ADK is downloaded from here, and while I don’t have time while traveling to check the final code I have been testing some pre-release builds and now that Microsoft has disclosed the released it I guess that I can talk about it.

Details on the changed sequencer and instructions on autosequencing may be found in this blog post. What follows are from my experiences and should be treated as additional information beyond that provided in the links above.

The changes for sequencing involve two things:

  • Command line changes to the sequencer to better support command line sequencing (See blog link above for details).
  • Some PowerShell scripts to enable managing automated sequencing of multiple applications by using a Hyper-V VM with a snapshot.

The purpose of this is first to support ISVs that want an automated way to build their software into App-V packages just like they build the rest of their software.  Second, they want to make it easy for the enterprise to automate updates to all of their packages.

While I haven’t the time yet to play with the final code release for the sequencer, let me share with your my experiences with the pre-release, which should be pretty close to the final build. I have used this auto-sequencer to automate about 100 applications. The applications that I chose were selected specifically because I did not have any kind of silent installation prepared. Preparing the silent installation is by far the most time consuming portion of the project.

To be clear about this, Microsoft only wrote scripting management for Hyper-V. Clearly there is no reason that someone couldn’t do something similar for other HyperVisors, just don’t expect Microsoft to do it for you.

In my tests, the average time to sequence an application was a smidge over 5 minutes per package, or 11 per hour. This was achieved using some very unoptimized installation scripts on my part with sleeps in many places so that I could watch what was going on. The version of management automation scripts provided to me in pre-release form by Microsoft were also not as optimal as should be possible – it took a full two minutes to boot the VM and start the script copy process (while a manual boot to the same VM plus logon was about 15 seconds). Hopefully we’ll see this improve in the released version, but quite frankly this rate is probably good enough anyway.

The Microsoft Management scripts run from a Hyper-V host utilizing an XML file for input that allows you to specify a folder for the installer files, and the command to perform the sequence. It reverts the VM to the last snapshot (or creates a snapshot if none exists), boots the VM, copies the files to the VM, and then injects a remote command to perform the sequence. After that completes, it copies the package back off of the VM.

The remote command actually runs an injected PowerShell script which does some housework and then starts the autosequencer with your silent installation. I found it necessary (in the pre-release version) to modify this provided script when the command to run is not a file you copied but a system component like powershell.exe; this script assumed the install line would be just running a file in the locally copied folder. This edit to the provided script has to be done prior to building the VM image per the instructions as the script ends up embedded in that image. Again, with luck this fix will be in the final release by Microsoft but I really don’t know.

I have built my own general purpose PowerShell based scripting framework for use to perform the silent install that the sequencer will call. I simply copy the framework into a folder with the product installer(s) and make a few small modifications. I have automated about 100 packages this way and have made provisions for most all of the special things that you might need to do. It supports:

  • Aa command single script that can install the app on 32 or 64 bit systems.
  • Support automatic importation of discovered reg files, and allows for os-architecture versions of them.
  • MSI, MST, MSP, EXE, and other files may be used as installers to run.  Multiple installers may also be specified.
  • Can automatically remove desktop shortcuts or
  • Supports automatic execution of additional powershell scripts generated by the latest version of my AppV_Manage tool to improve the product installer (scripts to optimize .Net components or to make the package support Regsitered Application Capabilities.

Many of the package specific scripts built on this framework are a one or two line change. The intent is that I will release this PowerShell framework later this summer (probably as an open source project), and it can be used for any packaging project, not just for App-V.

One serious restriction that I found, at least in the pre-release version, was that there was no way to have an initial “prerequisites” script for pre-requisites that are not to be in the App-V package. Microsoft seemed to assume that we would include these in the VM. I requested that they provide for a second script for this purpose, but don’t know if they will act on this. I have scoped out what would be needed to edit their VM scripting management framework and such a change is surely possible — I simply chose to not make those mods at this point until I know if Microsoft is going to do that for us.

Stay tuned…