Profiling

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).

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.

Data Consistency in Version Updates

Applications must be updated regularly; distribution by means of App-V changes fundamentally nothing in this respect. It will have no negative effects on the configuration data if the previous application is opened, patched, and saved again in the sequencer. The version GUID may be updated when saving the new version, but the package GUID remains the same, and it is referenced with the configuration data. Not even simple UEM solutions that collect the configuration data outside of the virtual environment need to be configured specifically.

From time to time, you will need to completely re-sequence a package (e.g., to finally get rid of the three-year-old ballast of the original package). Because the new package receives a new GUID, the connection between the package and configuration data is interrupted, which means the new version only has a basic configuration. Simple UEM tools that do not act within virtual environments are faced with a challenge here. However, as the old package GUID and the new GUID are known, a script could adopt the configuration data from the old locations as a one-off event when publishing (or first starting) the new package. In contrast to App-V 4, the data are not encapsulated in a proprietary PKG file but can instead be copied freely. Registry values that have been redirected to the App-V client's machine registry key can be problematic. A profile management tool that can access the configuration data within the virtual environment, of course, has no difficulty.

Managing Connection Groups

The App-V 5 (application) Connection Groups, a common execution environment for several App-V packages, possess many properties in common with individual packages. Connection Groups have their own Group GUID and a version GUID. As with individual packages, the software organizes configuration changes in the context of a Connection Group in the filesystem and in the registry under the Group ID.

As with individual packages, the software organizes configuration changes in the context of a Connection Group in the filesystem and in the registry under the Group ID. If an application setting is changed in the context of a Connection Group, this change does not affect the same application if it is run as a standalone package. Therefore, although Connection Groups "only" contain references to individual packages, one and the same application can have different configurations. This can become confusing for users.

Of course, from the perspective of profile management, various behaviors emerge for the internal or the external approaches (Figure 2). If the UEM only sees the local storage locations with the package and group GUIDs, transferring the configurations is possible, but not easy. To this end, scripts are required that copy and paste the settings between the package and the Connection Groups accessing it. It is therefore simpler for UEM solutions within the virtual environment (no matter how it is launched, Adobe Reader Process is assigned its settings). Things become more exciting if single-package and Connection Groups are deliberately intended to have different settings. If the UEM does not support a sophisticated system for setting conditions, this could be difficult.

The Problem with Configuration Manager

The integration of App-V 5 with System Center 2012 Configuration Manager (SCCM) raises the bar slightly higher. To get warmed up, Microsoft has a special definition of the term "virtual environment" in Configuration Manager. Although this concept typically described the run-time environment of an App-V application in the past (i.e., the effectively visible filesystem, the registry as an overlay of virtual settings and local values, etc.), in Configuration Manager, a virtual environment is defined as a Connection Group created on the client. Unlike the other deployment methods in which a Connection Group must be published specifically or deliberately to a client, virtual environments are a dynamic description: A Connection Group is created if, for example, the client has three or more packages from a list. The Connection Group is not created – dynamically through AND and OR connections – if only two packages are available (or if a critical package is missing). This is a very flexible, but not very transparent, beast.

Although this dynamic may be seen as useful from an application functionality point of view, it has a technical peculiarity that can bring about the downfall of a solution involving saving and restoring user configurations: A Connection Group generated by Configuration Manager through a virtual environment receives a different GUID each time. Even if the same packages are available on two computers and if, in effect, identical Connection Groups are created by the ruleset, they each have different GUIDs. Different users on a computer potentially lead to different GUIDs. If a Connection Group has (temporarily) been removed from one computer and then added again, this will also mean different GUIDs.

Each profile management solution that relies on GUIDs as a reference for backing up and restoring is bound to fail here. A UEM that can act within the App-V environment is therefore imperative for the Configuration Manager scenario.

Publishing Performance and UEM

The publishing performance of App-V 5 (in simple terms, the period between the user logon and the chance to launch virtual applications) was not exactly outstanding in the first manifestations of App-V 5 – it could take 30 seconds or even a few minutes before the App-V client had created the integration points to the local operating system (particularly links, file type associations, or shell extensions) in a new session. Because the App-V client executes these actions rather meticulously (i.e., slowly), the idea arose to delegate the task of creating integration points to profile management solutions. After all, along with backing up and restoring application settings, shaping the complete user environment is a core competency of UEM. If App-V packages are assigned on a per-computer basis, there is no need to do anything because the integration points are stored in machine-global locations and are thus available even before the user logs on.

A user-based allocation of App-V applications should have advantages: The App-V client creates unique shortcuts, shell extensions, protocol handlers, and all the other new integration points, and the UEM ensures that this information is transferred from session to session. Even if this requires a certain amount of effort to teach the UEM solution about all these far-flung locations, the effort would be worthwhile if the App-V client did not have a safety mechanism in place. (See the "Requirements of UEM" box.)

Situations regularly arise in which a user (or computer) is deprived of access to a particular virtual application. The App-V client checks whether a matching virtual application for the integration points exists to prevent the storage of orphaned integration points on the system (for scenarios in which a user environment is not generated from scratch each time). The integration points are deleted if the appropriate package cannot be used, and this happens relatively early in the App-V client's launch process.

What's good for fat clients turns out to be counterproductive in virtual desktop infrastructure (VDI) or remote desktop services (RDS) sessions: Users log on to an empty session and the UEM generates the integration points at an early stage. The App-V client is now initialized, performs the consistency check, and deletes all integration points again because no App-V packages are known in this empty session. After that, the App-V client performs the scheduled tasks for the sync/publishing refresh, connects to the publishing server, loads the application list, and creates the integration points.

Fortunately, Microsoft has implemented a switch in Hotfix 4 (HF4) for App-V 5 Service Pack 2 (SP2): The switch can be used to disable counterproductive cleaning. If the registry value PreserveUserIntegrationsOnLogin is set to 1, the integration points generated by the UEM survive, even if the corresponding application is not known in the session. The publishing process that happens later would not only generate new integration points, it would also delete abandoned integration points. For users, this would mean that the same links that existed at the last logoff are visible shortly after logging on, and the superfluous icons disappear again, as required. Because Hotfix 4 implements further improvements, the publishing process should appear both significantly faster in empty sessions and complete from a technical point of view. This behavior was validated in a small test [4].

On the other hand, the UEM must become active in the logon process to create integration points. However, it must above all be able to identify the correct locations in which the App-V client creates these elements.

The shortcuts in the start menu and on the desktop are pretty simple – two folders from the perspective of UEM. What is significantly more complicated are the file type extensions, and you would probably have to give up identifying (almost) all of Explorer's shell extensions.

Fortunately, Microsoft not only has its own profile management solution (UE-V), but development of both products is also coordinated within the Microsoft Desktop Optimization Package (MDOP) family, meaning that Microsoft is searching internally for a solution.

As a result, there is now – as of SP2 HF4 – an executable file that handles the process of synchronizing with the publishing server. Of course, under the hood, the PowerShell Sync-AppvPublishingServer command is run again, but the calling process is no longer the frequently used PowerShell.exe, but rather the new SyncAppvPublishingServer.exe. It is a good thing that UE-V can be activated using precisely this kind of process launch (and even better that many other UEM solutions operate in a similar way).

UE-V and others therefore can easily archive all changes that have been initialized by the Sync-AppvPublishingServer process and then, of course, restore them. Precise analysis of the integration point targets is therefore no longer necessary. You will find the template for UE-V in the TechNet Gallery [5]; as an XML file, this can serve as inspiration for other UEM solutions.

Conclusions

You can dispense with the combination of App-V and profile management if App-V 5 is only used on fat clients in your environment and if these devices are only used by one user. Smart use of UEM is practically mandatory for scenarios in which users sometimes change machines, and you initially want to give them a clean environment, or if you use Configuration Manager's virtual environments.