In this article, I use the terms "Profile Management" and "UEM" (user environment management) to summarize tools that are able to transfer user configurations selectively from one machine or session to another and go beyond the capabilities of pure roaming profiles and folder redirection. The key word here is "selectively." Moreover, if such a solution can influence the user environment (e.g., connect drives or display application icons), it really deserves to be called profile management.

Configuration Data

Life was simple in the good old days of App-V 4: The App-V client stored virtually all configuration changes made while using an application in the (roaming) AppData folder in a .pkg file. The few exceptions were, in most cases, negligible but, in special cases, even more difficult to address.

With App-V 5, Microsoft is striving for greater expression of standards in application virtualization. This "same-as-local" approach justifies some of the great new features of App-V – in particular, significantly improved integration with the local operating system. On the other hand, this approach to classic application behavior brought some innovations that could have an unpleasant effect. App-V 5 changes initiated by the user are stored separately, rather than in the machine-global package cache (under ProgramData). Copy-on-write (COW) now takes care of this process, with a few fundamental exclusions. In particular, no copies of executable files are produced; therefore, they are, in effect, read-only. Some file types are considered "executable" and thus immutable [1]. Furthermore, additional registry and filesystem exclusions for client machines can also be defined.

It is necessary to distinguish between the filesystem and the registry for saved changes. All COW redirection sites are also visible from outside the virtual applications, because App-V 5 does not use any proprietary user delta files. If files are changed using the virtual application in the AppData\Roaming folder, the COW copy is also there (in the subfolder, Microsoft\AppV\Client\VFS). If files are saved outside of AppData\Roaming, they are redirected to AppData\Local (Table 1).

This means that if users switch between computers, some of the configuration changes are stored centrally, and the rest are potentially discarded, creating the possibility of inconsistencies.

The behavior is somewhat different in the register (Table 2), but also not uneventful: Changes made under HKEY_CURRENT_USER are stored, as expected, under HKCU in Software\Microsoft\AppV\Client. App-V does not save these changes itself, however; instead, it relies on the operating system's HKCU handling (e.g., roaming profiles).

The situation becomes a little more interesting if changes are made in the local machine part of the registry – HKLM. Here, the App-V client differentiates between privileged and unprivileged access: If the user has no local right to make changes in HKLM, changes to the machine part are redirected back to the user key (HKCU). However, if the change is made by a user with privileged rights (e.g., an admin in User Account Control [UAC] mode), these changes are redirected to a key under HKEY_LOCAL_MACHINE (HKLM; Table 2). Both the user's location and status therefore determine the location in the registry to which the configuration changes are directed. It is also the case in the registry that, under certain circumstances, some of the configuration changes are migrated off-site, whereas other data remains on a machine.

Folder Redirection Under App-V 5

Although the AppData\Roaming folder has been mentioned repeatedly, the mechanism described so far only works if the AppData folder is not redirected, but resides instead – as on PCs or laptops – in C:\Users\…. If you really want to redirect the AppData\Roaming folder, the minimum technical requirements are Service Pack 2 for the App-V 5 client and use of a profile management tool. If the folder is redirected, the App-V client detects this configuration and adjusts its behavior: Changes to files in AppData\Roaming are not immediately written back to the redirected folders but, instead, only when the application has ended (in zipped format). A timestamp is then entered in the registry.

Unfortunately, this timestamp can cause problems because it is written back by profile management when the user logs back on, and the contents of the redirected archive in AppData\Roaming are extracted as a local copy. Unfortunately, however, the local copy has a different timestamp (time of logging on) from the registry (time of logging off). The App-V client then discards the recovered files because they are obviously not correct. It would therefore not be possible to restore the file-based configuration changes. The workaround here is to delete the timestamp value, AppDataTime, in the registry (or not recover it), although, under certain circumstances, the machine registry [2] must also be taken into account. Microsoft also describes the requirements for environments with folder redirection [3].

Starting Points

Basically, UEM tools have two ways to enable backing up and restoring configuration data. With the "external method," the UEM has no access to the virtual environment and can only collect whatever can be found on the local system. With the "internal method," UEM has access to the virtual environment.

If using the "external method," UEM simply considers what configuration data the App-V client left behind on the system: the package GUID folder in AppData\Roaming, AppData\Local, and HKCU (Figure 1). Up to this point, this approach could even be implemented with relatively simple logon and logoff scripts. More tricky is the fact that some changes are potentially stored in the machine part of the registry – simple solutions might be able to read it, but whether or not they are able to rewrite the values for the application is a different matter. When configuring such a simple method, you should not forget the recommended exclusions (such as the timestamp).

Figure 1: Using UEM tools with external access.

The implementation of App-V 5 is more complicated than that of App-V 4, because the configuration data for App-V 5 is written to such different locations. The implementation is simpler if the UEM solution can run within the virtual environment: Just as with a local installation, the configuration data is (apparently) in HKCU\Software\<Manufacturer>\<Product Name>. Compared with the external method, the particular advantage is that assigning data to applications does not need to be done via cryptic GUIDs, but often folder or key names.

Technologically, virtualized data are accessed in two ways: The UEM taps into the virtual process calls and redirects some of the requests, or start and end script parameters are used within a virtual environment. One drawback for some UEM providers is that no switch in App-V 5 allows a script to be executed after an application has finished but is still allowed within the virtual environment. Thus, it is virtually impossible today to back up the settings selectively using this method. In the meantime, all practically relevant UEM providers can manage configuration data at the process level or via filter drivers when accessing files and values, even for App-V 5 applications.

In addition to normal backing up and restoring of configuration data are a few special cases, in particular application updates and App-V Connection Groups and their specific implementation in Configuration Manager environments.