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.

Figure 2: Using UEM tools with internal access.

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.