A typical workflow for sequencing an application is something like this:
1) Take a snapshot of your sequencer (odds are it's a virtual machine [VM])
2) Power up your sequencer and sequence your application
3) Move your application to your system, test it, try and catalog all problems. Revert your VM snapshot and go to step 1.
In several environments that I have worked in, this is a bit of a hassle as most environments implement the 'Machine Account Password Expires after X days'. So after that time you either need to delete your snapshot, power on your VM and rejoin domain then start over. This gets really cumbersome with multiple sequencers to take care of. In addition, at my current environment, we require Windows Update be up-to-date and applied to all machines, including sequencers. Reverting a snapshot to before Windows Update will, sometimes, cause Windows Update to start upon the desktop when you login. There is a lot of overhead and hassle to maintaining snapshots, though it is better than the alternative of reinstalling the operating system each time you want a clean sequencer.
There is a very elegant solution to all of this I have found that also allows me to sequence super fast.
Citrix Provisioning Service (PVS).
Citrix PVS works by managing the Active Directory machine account password for me, so I never have to reset it again.
With Citrix PVS you can create several sequencers from one vDisk. This ensures consistency and avoids tech's having their own VM with their own nuances.
Citrix PVS allows you to create a version of the vDisk and apply Windows Update's. Automatically, all of your sequencers get the updates applied.
With 'Standard Image' mode, the VM now becomes 'non-persistent'. This means if you reboot your VM it will go back to the state it was when it was last powered on. PVS requires a 'persistent' supplemental disk attached to the VM for things like the event log, page file and the write cache files. We ensure the supplemental disk is large enough so we can locally store application installer files there (temporarily!) then the installer files go onto a fileshare that has regular backups, etc.
Starting with Citrix PVS 7.1 there is a new feature called 'Cache to device RAM with overflow on hard disk'. By utilizing a memory sizing for your sequencer VM that can run the operating system *and* contain the largest application in total megabyte size, your sequencing can go super duper fast! Sequencing to the operating system drive with this PVS feature will actually write to RAM, which is significantly faster than disk. This shortens sequencing times significantly. You will need to ensure your cache size is large enough for your largest application or else the overflow to disk will slow you down.
But won't this setup fail to work with AppV5's 'reboot' feature?
Starting with AppV5 you can now *reboot* an application in the middle of sequencing and the sequencer is supposed to be pickup after the reboot and continue to capture. So far, I have not had good luck continuing sequencing after rebooting with the AppV5 sequencer. I've found, with a 100% success rate *so far* that a reboot is not necessary. I'm aware that applications
like Chrome show that a reboot can make a package work successfully, but I prefer to figure out what it does post-reboot and
just implement that in the sequence instead.
By avoiding doing reboots we are not missing that feature at all. In cases where it is absolutely required
I have a workaround. I create another vDisk version in Maintenance mode
And set my Sequencer VM to Maintenance mode.
This turns the VM to a 'persistent' state for this duration. Once the sequence is completed I delete the version and set my VM back to production. The caveat here is only one VM may use the maintenance version at a time.
What should I put on my PVS Sequencer?
As per my previous topic, I believe you should try and minimize the visual C++ runtimes that are different from your sequencer to your VDI/XenApp server boxes. If possible, make them identical. This prevents AppV5 from usurping installed versions of this runtimes when pushed to your VDI/XenApp servers. They may still get usurped if an application has a different version installed then what you have on your box, but I strongly believe in minimizing it if possible. There may also be a (small) benefit by speeding up your application first launch experience by removing some minor registry staging.
Here is what I have on my sequencer and a clipping of some of the software we run on our XenApp servers:
 |
| All of the software on the Sequencer |
 |
| A small clipping of software on the XenApp servers |
With the PVS sequencer you have a static, persistent disk that you can use to locally store installer files, notes, AppV template file, whatever you need to help you get sequencing.
 |
| A little snapshot of my persistent disk |
How do I sequence with this thing?
For my sequences, I usually create a batch file that lets me do a silent install of the application and any shortcut configuration. I can then use this batch file to do a completely scripted sequence if required in the future. Otherwise, sequencing is identical to how you would do it previously, but you cannot restart the system! Restarting will result in a clean sequencer coming back up (after all, that's the point!)
.jpg)
