How important is it to launch your application in a AppV package while sequencing?

For a bit I was of the mindset that sequencing a AppV package should be as clean as humanely possible.  This would include finding all configuration tweaks to files/registry keys ahead of time and implementing them so any registry keys generated would be unique to the user.  I've seen some applications generate a unique GUID that vendor's would use to lock it so that the application was tied to one machine.  Since this key would be generated in HKLM so all users would be able to see the key, it prevented new launches.

But if you didn't launch the application while sequencing, the key wouldn't get generated until the user launched it in their bubble.  This effectively allowed multiple users to use the same application on one server.  With this new information in mind, and a new outlook on keeping the AppV registry hive to a bare minimum; forward I strode.  And hard into a wall I ran.

What I eventually ended up finding was applications that error'ed on first launch:

But would launch just fine the second time:

So what would cause it to fail the first time?  I imagine for most cases the error message is caused by missing file(s) or registry key(s) or values.  So how do you find these newly generated profile?  Well, the nice thing about AppV is it stores all these things in two places.  Your registry hive or your user profile.

Before launching the application I did a "dir /s /b C:\Users\Adtest91 >>Clean.txt" and saved that to a text file.  I then launched the program twice and ran this command "dir /s /b C:\Users\Adtest91 >> Working.txt"  I then compared the files and found the following new paths generated:

C:\Users\adtest91\AppData\Local\Microsoft\AppV\Client\VFS\ADB25534-3FE9-44BD-9FC8-D5AAD8C0E728
C:\Users\adtest91\DesktopFax

To see if these two paths caused my issue I deleted them and relaunched the application.  The application launched just fine.  I then backed up those two folders.  To rule out the file system with some more finality, I deleted my user profile then copied my two backup folders to their recorded paths and tried launching the program and got the error message again.  With that I felt confident I could rule out files/folders as the cause.

The beautiful thing about AppV registry changes is they are recorded to your user profile.  This is stored here:
HKEY_USERS\!GUID!_Classes\AppV\Client\Packages

Export this key prior to launching your application, launch your application, and export the key again and do a difference.  Any created or modified registry keys will reside in this location for you to examine.

For this issue, this was the key that was generated:

[HKEY_USERS\S-1-5-21-38857442-2693285798-3636612711-15053136_Classes\AppV\Client\Packages\ADB25534-3FE9-44BD-9FC8-D5AAD8C0E728\REGISTRY\MACHINE\SOFTWARE\Classes\TypeLib\{3B7C8863-D78F-101B-B9B5-04021C009402}\1.2\0\win32]
@="C:\\Windows\\system32\\Richtx32.ocx"

Deciphering the key results in the following missing value:
[HKLM\SOFTWARE\Classes\TypeLib\{3B7C8863-D78F-101B-B9B5-04021C009402}\1.2\0\win32]

Looking locally on the server, this is what I saw in the registry:

There was nothing in the Data field!  AppV5 'integrates' the Classes key in your AppV package when you publish it.  I resequenced and launched the application after the install and checked the key again:

Surprise, surprise.  And now the application launches without issue.  So it appears that some application installers don't completely register all files (OCX files are two instances of this issue happening that I noticed) until the application is launched.  So now, our policy will always to, at a minimum, launch the application while sequencing.

Awesome blog to follow

I'm learning a ton from reading http://www.remkoweijnen.nl/.  Very good blog with good step-by-step on how he executes his troubleshooting.  One thing I've learned from it is to love Ida Pro.