App-V 4.6 SP1: Saga of the duplicate GUID (continued)

We held our first training class on Microsoft App-V 4.6 SP1 last week in Malmo, Sweden.  During the class, we ran into an “old friend” that entered the room using a new disguise.  Although we thought he died, our friend the duplicate GUID still lives on.  To explain…

When application packages are sequenced with App-V, a package GUID (Globally Unique IDentifier) is generated.  This package GUID can be seen in the XML files generated, but is also present in the SFT file and is really intended to be behind the scenes and away from the user.  In fact, App-V liberally uses GUIDs for all sorts of behind the scenes identifications.  But when it comes to the package GUID, the important thing to know is that the client requires each package GUID to really be unique. 

Thanks to a combination of using virtual machines where we revert to old snapshots, and incorrect logic in when to create and assign this GUID in the sequencer, we have seen situations in prior versions of App-V whereby someone using the sequencer could create two or more packages and end up with the same GUID.

First Visitation

Ever since we started using VMs (originally we used Norton Ghost) to sequence with SoftGrid, we found that you could create packages with duplicate GUIDs by taking the VM snapshot after starting the sequencer.  The sequencer would generate the GUID when you launched the sequencer executable, you took the snapshot, and every time you reverted the VM and generated a package it would end up with the same GUID.  So we trained people to take the snapshot with the sequencer not running (yes, it’s OK to take it with the VM booted up and you logged in.  Your security people will be calmed when you remind them that after reverting the VM you still need to log in to access it).

Second Visitation

In version 4.6, Microsoft changed the GUID generation, however we found our old friend show up in a different way.  With the 4.6 RTM, when you install the sequencer using the GUI installer, the final installer dialog has a checkbox that when selected will launch the sequencer.  Stupidly, this checkbox is on by default leading countless people to suddenly see the launch the sequencer, which they dutifully close and then take their snapshot like we told them.  Except that this scenario caused duplicate GUIDs to appear.  So we started training them to make sure they uncheck that box and not start the sequencer before taking the snapshot.

In 4.6 SP1, Microsoft solves this problem and even if you let the installer launch the sequencer, you can close it and take your snapshot without worry.  But having been burned twice, I retained the caution in our training guides about ever running the sequencer prior to taking the snapshot.   I didn’t have any reason for doing so, but until I hear Microsoft explain that they moved the GUID generation to the package save phase of the sequencer (which I don’t believe they have done), I have an uneasy acceptance that I won’t see duplicate GUIDs again.

Third Visitation

One of the new and neat features in 4.6 SP1 of the App-V Sequencer is the Template feature.  Many think of this as nothing more than the ability to save the sequencer configuration into an XML based file (which ends with the SPRT file extension), but at least in this release you can include almost all of the settings that you would like in the file.  A registry setting (which you can set in the options settings dialog of the sequencer) tells the sequencer to use this file.

If you start the sequencer and use the options dialog you can set many parameters, save off this file on the sequencer and register to use it.  Shutdown the sequencer, take your snapshot.  This process works reasonably well and does not seem to cause duplicate GUIDs.

But that process includes default settings for some things that you might want in the file.  So you either need to manually edit, or to create a dummy package in order to get to the “Sequence Editor” to set these options.  As we will see, this can lead to issues if you are not careful.

I believe that in the long run, you probably want a couple of these Template files for your environment.  You will have a standard one that you use for most of your applications, and an alternate one or two as you see the need.  Standardizing on a template is an important act.  It will (help to) ensure that multiple packagers follow the same basic settings.  If you outsource any sequencing, insisting that the outsourcer use your template will replace about 10 pages of documentation on how you want things packaged, and reduce errors where they don’t follow that documentation exactly.  You probably end up with more than one in the long run because not every app will be right for that template.  An obvious candidate will be a template that allows use of the Windows Update during sequencing.  Windows Live applications, for example, need Windows Update to install (yes, there are ways around this, but why bother?).  64-bit applications might be another candidate.

Any way, what I recommend is creating these template files and copying them to the desktop of the sequencer before taking the snapshot.  To be clear, what I recommend is making these template files and copying them off somewhere safe like a file share, reverting your VM with the sequencer, copying the files to the desktop and taking a snapshot.

We had someone in the class run the sequencer to create a dummy package (no installation, for example), to get to the sequence editor, set the final options he wanted, which included which target OSs, and save this off.  [Note: you can only specify these OS’s as a restriction, there remains no way for you to specify “any OS” using the template].  This person then saved the template file directly to the desktop and took a snapshot.  This was technically a dirty machine since a package was partially created, but it was a test lab and should be OK.

And I think it would have been OK, as long as he started the sequencer from the start menu.  But he did as I suggested, that is to start the sequencer by double clicking on the template file on the desktop.  This launches the sequencer and skips a dialog since it already knows he wants to sequence a new app using this template.

This person created a package (call it “Package A)” by double clicking the template and deployed it using SCCM.  OK so far.  He reverted his sequencer VM, created a different package (“Package B”) by launching from the start menu (because we were doing a middleware package for DSC), then deployed using SCCM.  Still OK.  He then revered his sequencer VM and created another package (“C”) by double clicking on the template file.  When he tried to deploy using SCCM, the SCCM advertisement failed. 

Whenever a problem like this crops up in one of our classes, we get everyone involved in the troubleshooting.  I believe this is one of the really great things about our classes.  To solve these issues, you really have to apply everything you learned about how things work in an unscripted way.  By thinking through deployment issues you really reinforce the techniques we teach and all of that background about what is happening behind the scenes.

The error code captured by SCCM wasn’t terribly helpful about why it failed.    So we looked to the SCCM log files – the first place to look when an SCCM deployment fails.  We could see that the sftmime command had been run and failed with an uninteresting failure code.  Checking the App-V Client log, we were surprised to find it contained no information about the sftmime failure at all.  We checked the SCCM cache to ascertain if all of the files had been correctly copied down by BITS, and found that they were.  So we copied the sftmime command from the SCCM log file and ran it by hand.

We received an error from SFTMIME that the registration failed and a usable App-V error code.   This error led most of the people involved to guess either that the App-V client was messed up and needed a reboot, or that the package was just bad.  I smelled the stench of an old friend.

We opened up the OSD of the package we wanted to deploy and located the package GUID (not to be confused with the package version GUID or the OSD GUID; this is the one on the CODEBASE line).  Next, we went to the client Windows Registry.  Looking at the local machine registry hive under the App-V client, there is a “Packages” key.  Under this key will be a key with the GUID of every packaged added to the client.  Here, we found a GUID that matched the package GUID that we were trying to add.  Under that GUID, we could see that the OriginalURL registry item was pointing to a different SFT file, the one from “Package A”.   We had managed to create a second package using the same GUID!

The cause appears not to be anything inside the SPRT file itself, but in what the sequencer is doing when we launch the sequencer using the template file.  Therefore the advice remains:  Do NOT launch the sequencer before taking your snapshot.

---

Update:

Fellow MVP Nicke Kallen hosted and helped to teach the mentioned class.  He reopened the VMs used and reconstructed the errors, which I did not have available to me back home.  You can find these on his blog here:   https://www.viridisit.se/eng/blog/?p=921