App-V 5.0 OS Integration - Part 3 – Registry

Now we understand the package format and client file system for App-V 5.0, let’s take a look out how the registry looks in terms of OS integration.

As mentioned in Part 1 of this blog series, within the .appv package we can see a registry.dat file which contains the entire registry that was captured for the particular package.

Also as discussed in Part 2 we can also see that the registry.dat sits in the cache location on the client once the package has been delivered.

So what actually happens with this registry hive? Well it gets mounted and there twos views of this, native and virtual….

Native Registry

Gone are the days when we have to break into the bubble to see an App-V applications registry, similar to the file system cache, we store assets in natively to windows standards. The only difference is the physical registry location is not stored directly in HKEY_LOCAL_MACHINE\SOFTWARE but rather HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Packages.

In this location we can see a reference by GUID to all of our packages. For example below I have drilled down into Paint.NET:

The exact same concepts exist for HKEY_CURRENT_USER\Software for all App-V 5.0 packages. So that’s the native registry, plain to see on the local machine but how does the application itself see itself in registry?

Virtual Registry

The virtual view of registry is a much more simplistic view in that the application sees itself exactly where it was sequenced to, HKEY_LOCAL_MACHINE\SOFTWARE.

When we pan native and virtual views of HKEY_LOCAL_MACHINE\SOFTWARE next to each other we can clearly see the difference.

Again the same principles exist for HKEY_CURRENT_USER\Software but we will talk about that more in Part 4 where we will discuss state changes.

Author:Thamim Karim

Source:http://blogs.technet.com/b/virtualvibes/archive/2013/03/28/app-v-5-0-os-integration-part-3-registry.aspx

Comments

Active Setup Registry Key : What it is and how to create in the package using Admin Studio Install Shield

While launching from Admin account or doing “Run as Admin” it was launching properly but when launched from the standard-user account, though it was launching but GUI was not coming properly and before launching, it throws the error that some particular Skin file is missing. I checked in installation folder and skin file was there but still while launching I was getting the error, but when launched from Admin account or using “Run as admin” it was launching properly with proper GUI and no skin file missing error. On exploring further I found that application was installed by admin account and it created some entries in HKCU, and these entries contain the path and name of skin file to be used. So when we launched the application from Standard user account then these entries were empty in HKCU for Standard user. So to solve this problem while re-packaging I used Active Setup . Active Setup provides a great solution for installing current user data when the package is not installed

Remove previous versions using MSI Upgrade Table

There are several methods to uninstall the existing older versions of an application e.g. Script, MSI upgrade table, SCCM deployment conditions. We are here discussing the method using Upgrade table. Upgrade table can be used effectively to detect and uninstall the previous versions of a MSI based application provided the upgrade code is known. Here is an example on populating Upgrade Table: Locate the U pgradeCode in Property Manager . Remember this could either be same or different in previous version and if it is different then grab the code from previous version. Go to the Upgrade Table in Direct Editor . Copy the upgrade code to its column. Populate the Version columns based on requirement (consider all the digits as per previous MSI versions). Attribute column needs to be configured with appropriate bit flag for corresponding upgrade behavior. Refer to Upgrade Table to calculate the proper bit flag. In example, 768 is the sum of 256+512 which means, det

Active Setup for MSI with no Entry Points

Active setup provides a solution when the aim is to deliver user based components when no advertised entry points exist in an MSI package. Most packages will contain some kind on entry point; commonly an advertised shortcut. When launching this kind of shortcut Windows Installer will check the keypath of the component the shortcut belongs to and verifies that the component is installed. If it is found to be missing Windows Install will kick off a repair. This provides a great solution for installing current user data when the package is not installed in the user context. It is also a very good reason why you should never mix machine and user data in the same feature. So what do you do if there are no shortcuts to advertise? Active Setup will solve the problem. An MSI package has been created to install an Outlook plug-in. This package installs both user and machine data. User preferences are stored as a combination of HKCU registry and a XML file written to %USERPROFILE%. As t

Collection of Useful Posts

Search This Blog