Messing with a ThinApp's Registry for Fun and Profit!

When you install ThinApp, it includes several utilities that are very useful for manipulating and troubleshooting your ThinApp packages. One of them is vregtool, which I’m going to discuss today. Vregtool allows you to examine and manipulate the registry for a ThinApp. Why would you need this when you can simply embed Regedit inside your package and use a tool with which you’re already familiar? Well, vregtool can be used to examine .tvr files, like the registry change files that get stored in the sandbox.

What this means is that you can start up a ThinApp, change some setting and then examine exactly what registry change was made to reflect that setting change. That can make it very easy to cherry pick the application settings that you want to embed within your package, vs. those that you want to leave out. Perhaps the concrete example of my use case will help this to make sense.

A customer recently had me package Office 2007 for use in their VDI environment. Office 2007 is nothing special to ThinApp, but we wanted the initial launch to be as smooth as possible. We used the Office 2007 Admin Templates in Group Policy to enable auto configuration based on primary SMTP Address as well as a few other settings (pretty much like we do for Office 2010) and it was largely smooth sailing. However, because we have Windows Search disabled, Outlook ‘helpfully’ warns us that “The Windows Search Engine is currently disabled. Outlook will not be able to provide fast search results…” with a checkbox to suppress the message in the future. Ultimately, that’s not that big of an annoyance, but everything that we can do to improve that first user experience is worth examining, so I set about disabling that message.

Just disabling the message on my capture box before the post scan was problematic. That message doesn’t come up until Outlook configures an inbox. I really didn’t want to have lingering bits of my own inbox configuration in my ThinApp package, so I didn’t like the idea of doing it that way. I know that you can delete a mailbox from Outlook after the fact, but I’m not sure about what other bits might hang around and cause subtle issues down the line. Instead, I decided to use vregtool to look at what’s actually happening when I suppress that message and then push that change only.

First, I used my knowledge of ThinApp Sandbox Locations (first Self-Referential Link!) to get myself a clean sandbox location. I then started up Outlook and clicked “ok” on the message without checking the box to suppress future notifications. Then I shutdown Outlook. That gave me a good “control” registry differential file, so that all of the junk that Outlook sets on first run would be part of my baseline. I copied my Registry.rw.tvr file (and renamed it to Baseline-Registry.rw.tvr) to a persistent location so that I could analyze it later and then prepared my modified registry file. To do that, I just opened up Outlook again and this time I checked the box to suppress future notifications about the Windows Search functionality. I then closed Outlook and copied my new Registry.rw.tvr as Set-Registry.rw.tvr to that same persistent location. Now, it’s time to pull out some data.

I went to my packaging machine and then, to make everything easier at the command line, I copied both of my *-Registry.rw.tvr files into my “C:\Program Files\VMware\VMware ThinApp” directory. Vregtool needs to know some stuff about how these registry files were generated and so I also put a copy of my Package.ini file in there. With the stage prepped, I opened a command prompt and navigated to that same directory. Then, using the commands:

Vregtool.exe Baseline-Registry.rw.tvr PrintKeys –ShowValues –ShowData –ExpandMacros > Reg-Base.txt

And

Vregtool.exe Set-Registry.rw.tvr PrintKeys –ShowValues –ShowData –ExpandMacros > Reg-Set.txt

I exported my Registry differential files into text files. These files are not insignificant (each is over 100k of text), so searching through them by hand wasn’t really feasible. A bit of google-fu revealed the Windows equivalent of “diff” and so I used the following command to narrow my search:

Fc Reg-Base.txt Reg-Set.txt > Reg-Diff.txt

FC (File Compare) listed all of the differences between the two files and only came up with a 19k text file. That’s better, especially when you consider that FC outputs the lines from both files so that you can easily compare them, as well as the preceding and proceeding lines from each changed block. All told, my diff resulted in 23 changed blocks of text between the two files. With those changes identified, it came down to a bit of guess and check around which one(s) were responsible for the setting that I actually wanted changed. Fortunately, I was able to eliminate a lot of the changed blocks based on their names and where they were in the registry (the stuff from Installer and from ThinStall\RunTimeObjects, for example, didn’t seem like probable candidates for my target change). I came down to a handfull likely changes that I determined to test.

I once again cleared out my sandbox, and this time I opened up my embedded RegEdit (vregtool could have done this too, but RegEdit was just easier for this particular task) and I made the first of my probable changes and then started up Outlook. No dice, so I shut it down and implemented my next change. On the third probable change, I was no longer harassed by that notification. To determine if it was a combination of my changes or if it was just that third change, I cleared out my sandbox once again and then only made that third change – success!

Now, with my change identified, I decided to bake it into the main package. I just opened up my “HKEY_CURRENT_USER.txt” file in the Office 2007 build folder and added the following 3 lines (they shouldn't be numbered in the file, I just did that to avoid confusion from wrapped lines in the web browser) in order to make the change:

1. Isolation_full HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Options\General
2. Value=PONT_STRING
3. REG_SZ~53,#2300

And I was good to go! For those of you who haven’t spent a bunch of time poking around those text files, that’s basically adding a String value named “PONT_STRING” to the HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Options\General key and putting “53,” in its data. I’m not sure why there’s that comma after the 53, but hey, that’s what it did when I checked that box and so that’s what I’ve added to my package. After a quick rebuild, I ran the package and the message was correctly suppressed.