Getting Started with Sequencing

NOTE: This post is part of a series. You might want to start at the beginning:

1. “I’m new to App-V so how do I get started?”
2. What is App-V and how does it work?
3. How do I get App-V?
4. Getting Started with Sequencing (This post)
5. To Manage or not to Manage

What to Sequencing On

The App-V Sequencer is used on very clean OS images. The less that is on the image the better. I prefer just the OS and Service packs. Hotfixes are usually OK, but don’t usually matter given how you use this OS. We usually sequence on a virtual machine that we can create a snapshot/checkpoint, allowing us to revert back to a known state before sequencing an app. Here is a blog post I previously wrote documenting my lab sequencer build.

We usually sequence on desktop OS rather than an RDS Server, even if we plan to deploy on the server. We also select an OS version that is as old as the oldest client we might deploy apps to. So for many customers this means a Windows 7 with SP1 operating system. Sometimes there are apps that require the server OS, so we use that also when we have to. If I use the Server OS, my preference is to NOT add the RDS role.

If you have both 32 and 64 bit operating systems in use for clients, we’ll normally sequence on the 32-bit OS. The biggest exception here is due to shell extensions. If you need them, you must sequence on the OS bitness (Microsoft uses the confusing term “Architecture”) as the client. XenApp customers that don’t allow full access to the RDS desktop won’t care about the shell extensions.

When possible, the mantra is sequence only once, run everywhere.

Sequencing Theory

When you sequence, there is an installation and configuration stage where you install and configure the application. While in this phase, the sequencer monitors all file and registry accesses. New, updated, and removed items are recorded. This is why it is so important to work with a clean image — any standard redistributable or third party shared component that is part of the image that the application depends upon would not be captured (file reads are ignored for the list). And it is just plain wrong to assume that everything in your standard corporate image will be on every machine. It might be today, but not for a new machine created two years from now.

You should have exceptions to this. I prefer to treat the exceptions as a one-off basis. An example might be an app that depends upon a well known dependency, such as Office or a particular VC++ Runtime distribution. In those cases we would install the dependency prior to sequencing, and then document, document, document the dependency.

Customization of the app is important. You want to configure all shortcuts and settings, and especially you must either disable or remove problematic features. Application update features always must be defeated as the update will fail at the client anyway, usually producing an ugly looking error.

You can then configure how the streaming will work. Since you are just starting, I’ll offer the advice to just don’t worry about this yet. New customers tend to get so hung up on the streaming option, trying to get the best optional experience. Don’t be that person. Wait until you have your architected deployment figured out and a firm idea on what kinds of clients will be using App-V. Then make a decision. If you’re just setting up, simply use the default.

Scripting is also a big part of the sequencing process. It allows you to customize the package at the client for things like configuration to the correct back-end database or license key injection. It also allows you to install dependencies, such as device drivers. Where possible, you should aim to put those scripts into the internal AppXManifest.xml file (a more advanced technique than I’ll describe in this post).

The information above is just scratching the surface of what you will need to be successful with App-V. The next step for you would be to read the Microsoft Application Virtualization 5.0 Sequencing Guide.  Some things change over time and I might not agree with everything in there, but it is a great place to start.

Unit Testing

Once an App-V package is created, a quick unit test is performed, typically by the person that sequenced it. This work is done on a separate client OS image. This one could be nearly identical to the Sequencing VM, or could be based on the standard corporate image. The one thing we all agree upon, however, is that you add the free AppV_Manage tool (free download from the TMurgent website). This tool allows you to analyze, add/publish, test, and debug the new package without the need for any server deployment activity.  The package analysis is an important step to better understand the application and everything it interfaces with.  It also warns you about common issues that it can detect.

Other Tools

There are tools in addition to AppV_Manage you should use (or at least consider).

1. AVME is a free editor for editing the internal AppXManifest.xml file while in the sequencer.
2. ACE is a free editor for external Deployment and User Configuration files, and the internal AppXManifest.xml file for post sequencer editing.
3. AVE is a paid for third party App-V package editor with lots of features.