Skip to main content

App-V 5.0 OS Integration - Part 4 - State Changes

In previous parts of this series we looked at the App-V 5.0 package format, how it sits on our client OS in the file system cache and how the registry works. So that’s all well and good but what about when about when users make customisations to packages, how do we handle state changes?
There are two types of changes that can be made to our packages, file based and registry based. Let’s take a look at how they are both handled in App-V 5.0.

Registry

In Part 3 of this series we really went behind the scenes of how the registry hangs together both from a native and virtual perspective for our App-V packages. So what happens when we make a customisation to an application that makes a registry based change?
I’m going to customise Paint.NET above by hiding the floating windows Tools, Colors, History and Layers. This change is obviously retained every time I launch Paint.NET thereof as a customisation for the user.
Let’s take a look at where in the registry those changes get stored. Under HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\Packages we will find a reference all packages, if we drill down we then find the sub structure for the particular package:
Here we can actually see the amended keys:
Remember the virtual view of registry also applies here as discussed in Part 3, so if we break into the bubble we find that these same keys appear to the package directly under HKEY_CURRENT_USER\SOFTWARE\Paint.NET if we break into the bubble and open regedit.
In App-V 4.x we had a repair option for our packages and we have kept that with 5.0.
By clicking repair we clear down the registry changes as described above.
Our package therefore returns back to its golden state it was initially delivered in.

File System

Let’s take a look at what happens when a file based change is made to a package after it is deployed.
I’m going make a simple cosmetic change to VLC Player above and change the toolbar from being below the video to above.
Of course this change is kept with following launches of VLC Player. Now I know this app stores its changes in file system. In App-V 5.0 file based changes are stored in %AppData%\Roaming\Microsoft\AppV\Client\VFS. Here we find a list of all our packages in GUID based folders.
Drilling into the appropriate folder we can actually locate the .INI file where our customisation has been stored.
Again triggering a repair will clean out this location. By the way we can trigger repairs via PowerShell too if we wish using the Repair-AppvClientPackage cmdlet.
Returning our package to a golden state with the toolbar beneath the video again!
Please note that everything we talked about above relates to changes made to user profile locations and settings we would want to roam, to learn about how changes to non-user based locations are dealt with in App-V 5.0 click here.
So there you have it! State changes in App-V 5.0, be sure to check out the previous posts in this series if you haven't already.

Author:Thamim Karim

Comments

Popular posts from this blog

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