One aspect of App-V that we rarely discuss is then when you are sequencing, the sequencer not only detects added folders, files, registry keys, and registry items, but it also pays attention to things that the installer removes. By this I am not referring to a temporary file added and then removed, but something that was present prior to sequencing and actively removed by the installer.
It isn’t something that happens very often. We see it more in an application upgrade scenario than anything else.
In App-V prior to 5.0, the SFT format had a special provision that listed files and folders that were deleted during sequencing. Similarly, the osguard.cp file that contains the virtual registry had the ability to mark deleted registry items. These are both clearly documented in the file format document that Microsoft finally released a couple of years ago. This capability also was further carried out in the PKG format, where it is needed more. If the user deletes a folder/file/registry key/registry item, a marker for this this was stored in the PKG file.
The Sequencer did not show you these deleted entries, but tools like my free “PkgView” tool, or Kalle’s “Application Virtualization Explorer” tool would parse these formats and show them to you. All of this worked great in the pre 5.0 releases. So how does this work in 5.0?
“Different”.
During sequencing, the sequencer seems to detect and store deleted registry keys and items, but not folders/files. As in the older releases, you can’t see the deleted entries (files or registry) in the Sequence editor, but need a tool to break into the format to find them. Breaking into the AppV format is fairly simple, using standard OS tooling. You make a copy of the “.AppV” file and rename the extension to “.zip”. You can then open up the file for viewing only using the zip compression utility that comes with the OS, or a third party zip compression tool. Note: Don’t ever think of saving the file with one of these utilities and renaming back to “.AppV” — you end up with a broken package (hence the part of that initial statement that said “make a copy of …”).
Once you open the zip file, you will see a folder named Root, a bunch of XML files, and a file ending in “.DAT”. If you look under the Root folder, you will see all of the added or modified files. You will find no indication of any deleted files. Further investigating all of the XML files by opening in notepad or some xml editor or viewer, you will also find no indication of the deleted files. It appears that we have lost this capability to mark deleted files.
To view the Registry.Dat file, we can also use a standard OS utility – regedt32. The format appears to be only slightly different than a standard registry hive format. To view the file, you create a temporary key in regedit, and click on the key. Next, use File–>Import from the menu. You will need to change the allowable file types to all Registry file hives (*.*), then select the Dat file. This will import the virtual registry, in essence, mounting it under the active key.
In the image above, you can see an example of a deleted registry item. The marking is accomplished by using a unique, and unknown to regedit, registry type of 0x20000. This is how App-V is designating the item as deleted. I have not verified deleted registry keys, but presumably this would be captured similarly.
We probably need more investigation to see what happens with deletions in the stored user personalization. I expect that the registry items are handled similarly to how they are handled in the Registry.dat file. I also expect that file deletions are not handled.
These changes in App-V 5 have the potential to break an application. It would be rare, and I am unable to point to any production application that these changes would affect (tests to show the changes were done using a purpose-built app to show the effect). But it is the kind of thing that we all need to be aware of when we run into the odd application that just won’t work right anymore.
1 comment
Comments are closed.