Can’t be without: App-V 5 and UEM

With App-V 4, using a Profile Management or User Environment Management solution was recommended, but not highly required, as App-V managed user configurations quite OK for itself. With App-V 5 – especially in a ConfigManager scenario – this changed dramatically. Furthermore, UEM can help overcoming some of App-V 5’s most popular downsides.

Here is why I consider any UEM is a requirement for App-V 5.

 

User Environment Management (UEM) intro

I’m not going to tell the entire history and definitions of UEM, but I’d at least define a baseline of what I mean by UEM. Once users started to use more than one PC or logged on to different Terminal Servers, there was a requirement to move (or roam) configuration data and documents with them across their various devices or sessions. Microsoft’s Roaming Profiles address this requirement, but especially in the past that did such a bad job that about a million self-created in-house scripts were used to copy user configurations and data from session to session. Because of the lack of one big player, a remarkable amount of commercial tools with significant marked shares popped up. They’ve been extended by new features and approaches, forming now the class of UEM solutions. Other terms are Profile Management solutions or User State Virtualization solutions. Almost every vendor more or less invented its own term for this. Essentially, UEM has two tasks

• Ensure that configuration changes of an application made by users roam with the user
• Ensure that an appropriate working environment, including shortcuts, mapped drives, printers and others, is prepared

UEM in App-V 4

I presented and wrote quite a few times about the reasons for using a UEM solution along with App-V, but frankly App-V 4 did (and does) quite a good job with respects to the user environment: Especially in the original native deployment, management of shortcuts and file type associations was an elementary benefit of App-V itself, and in all scenarios App-V 4 is very good in storing and restoring user configuration data with its .pkg files. Of course even the good old version could benefit from UEM, but mainly in just two scenarios:

• An application was sequenced from scratch but should leverage user settings that belong to another package (like a previous major version of the same application). As .pkg files are tightly bound to the original package, a UEM solution could help to migrate such setting
• Certain applications are part of a Dynamic Suite Composition group, but are part of other DSC groups and/or are used stand-alone. If for such applications user settings should be consistent across their usage or grouping, UEM was required, because originally the settings would be store partially on the package and partially on the DSC object level. Tim Mangan wrote an awesome whitepaper about that: App-V DSC Transpereny Research.

User Configuration Data Management

So, what are the key items that make me demand a UEM solution for App-V deployments?

Let’s start with

User Configuration Data Roaming

In App-V 4, almost every user configuration change was stored in the package’s .pkg file, regardless of its origination (Registry, File system, user or machine specific location). It was that simple. (well… there are exclusions like localappdata, but this could be addressed, and there is data being modified by application services… Check the great post by Kalle Saunamäki:  What everyone and their mother should know about VFS in App-V, pt. 2).

In App-V 5 a basic design principle was the ‘same as local’ experience. Therefore, App-V 5 respects the application’s original intention for storing user configuration data: Some data is stored in roaming or redirected locations, some data is store in non-roaming per-user locations, and there is data that is stored in non-roaming per-machine locations. In fact this is a simplification of a new kind of science. Thamin Kharim’s article Where the App-V Client puts stuff  and MS’ whitepaper App-V 5 (SP2) Application Publishing and Client Interaction gives a good insight into that. As you can imagine, the ‘stored somewhere’ fact doesn’t really align with a user’s expectation of a well-configured application across different physical or virtual clients or RDSH sessions. And while it required a workaround or at least Hotfix 4 for Service Pack 2 to actually allow users to store configuration data for instance in .ini files in the program files or program data directory, roaming only the pieces in appdata but not in program data for a virtualized application may not only cause a bad experience. It even may force the applications to crash if they rely on a synchrony of those.

For a consistent experience, a UEM solution is required that maintains storing and restoring of non-roaming configuration data. This might be achieved by logon/logoff tasks, but then the UEM solution has to be aware of or configured to monitor the App-V specific, redirected locations. The same goal of roaming user configuration data also might be achieved by process injections, so that data can be managed inside the virtual environment (without actually knowing the redirected locations). Either way the UEM solution should have a component running with elevated privileges, as some data may need to be stored and restored in protected, machine-level locations (actually this also became a bit easier in App-V 5 SP2 HF4 and above).

User Configuration Version Update Consistency

When you open a package on the Sequencer, patch it and save it again, the Package GUID will stay the same, only the Version GUID will change. From a user configuration data perspective, there is nothing special required on the client as AppV just uses the previous configuration data with the new package version.

But if a new application version is sequenced from scratch as a new package (often approached for major version release changes, just to clean up the 3-years-long update chain), the App-V client doesn’t migrate the original configuration data to the new version – which is clear, because for the App-V client this new package is technically totally independent from the other one. A similar situation may arise if a long-time used application now has to be branched-out for a set of users with slightly modified configuration requirements (branching was re-introduced in HF4 for SP2, too). Also such a branched package technically is an independent, new one.

UEM solutions that act inside the protected environment have an easy job here, as they can just load the application specific settings (like for .exe) regardless of the App-V package version. UEM solutions that are limited to logon/logoff triggers or are executed script based have to have to be App-V-aware and have to know the redirected locations of the old and the new package and then perform an explicit migration (copying).

User Configuration of Connection Groups

In difference to App-V 4, now Connection Groups are treated very much the same as packages – they have their own ConnectionGroup GUID and Version GUID – and all settings that are stored by any application of such a ConnectionGroup is stored nicely along with the group.

This similarity with stand-alone packages indeed causes the same challenges of managing roaming, non-roaming, per-user or per-machine data, but we talked about that already.

The little extra comes when you want or have to establish a consistent user configuration settings experience between grouped and stand-alone applications or between applications that are part of more than one Connection Group. Because every Connection Group and every Package stores its user configurations separately, you’d need an UEM solution if for instance KeePass is used as a stand-alone package but also as part of the Devolutions Remote Desktop Manager ConnectionGroup – and your users require that the ‘last opened database’ information is available in both use cases.

User Configurations of Virtual Environments in ConfigManager

As you may know, the ConfigManager folks decided to assign another term to describe that a ConnectionGroup could or should be created on an SCCM-managed client: They opted for the term ‘Virtual Environment’. So, after we already talked about Connection Groups a few seconds ago, is there really a need to have a dedicated section on like the same topic, but just using the ConfigManager way of doing it? So, yes, there is. And it even was ConfigManager’s implementation of VEs and CGs that drove be writing this article. Let’s start with a simple statement: System Center Configuration Manager creates Connection Groups dynamically on the client, depending on a rule-set that is defined as a Virtual Environment in the console. There is nothing scary with that, right? It is even better than the PoSh or native way of creating CGs, because it is dynamic. Very dynamic. Too dynamic! When reviewing Nicke Källen’s work on our book’s chapter about the ConfigManager integration there was that section unveiling that the ConnectionGroup GUIDs are created dynamically and actually aren’t store (or used) centrally. This is bad in several ways: As a new ConnectionGroup GUID is generated on every machine a user logs on, traditional roaming technologies have not a single chance to roam user settings. So you log on to another computer with exactly the same applications, all work nicely together, as a ConnectionGroup is generated with exactly the same configuration – except for the GUID, except for the link to you first PC’s user settings. Not too bad for you, but how about your friendly users that access an essentially new VDI desktop or RDSH session twice a day. Sure you store all that ConnectionGroup GUID user folders in a central location, but effectively they are used just once. Or one single application gets unassigned from your computer, turning the Virtual Environment validation to return a ‘not more required’ – and then you get the app again, causing a new CG to be created…

In a ConfigManager integrated scenario with roaming users or shared desktops or sessions, having a UEM solution is vital for the usability of that environment.

(I’m not sure if I should be glad that so far ConfigManager only has a limited share in Dynamic Desktop environments.)

To roam user configuration data consistently between sessions and devices, the UEM solution must be able to be controlled by application or process launch triggers, as any artificial mapping of redirected App-V folders will fail.

App-V Publishing Performance and UEM

While we were looking at configuration changes made by virtualized applications, we now will shift our scope away from individual applications and turn over to the App-V client itself and especially to its Publishing process.

Basically there are methods how application extensions (or OS entry points, as we called them back then) can be assigned to the client: on a machine basis (globally) or on a user basis.

Global Publishing affects the entire client machine, as most native installations do: Shortcuts, File Type Associations, COM Objects, Shell Extensions, Fonts and all that fancy stuff that was introduced with App-V 5 and its SP2 will be created in machine data locations and/or the ‘all users’ profile location.

As all those extensions are already existing on the machine before a user logs in, there isn’t that much to do for a UEM solution.

This changes, if the application packages are published to individual users (regardless of the deployment method like Publishing/Management Server, ConfigManager or script based): When users log on to a client or server with a ‘clean’ profile, all the extension points have to be created after the user logged on, which may take up to several minutes.

With a UEM solution, on a first look this process can be accelerated, as the UEM solution should be able to restore such extensions from the last user sessions (this is what UEM tools always do, right?) Even simple Roaming Profiles together with Folder Redirection may help a little, but based on the design of Roaming Profiles this may have a negative impact on the logon time for its own.

In fact a UEM solution could restore Shortcuts or other extensions that aren’t available for that user any longer (we just restored the previous session’s state). In this case, the Publishing process, which is usually initiated during logon, just removes those orphaned entries or applies modified UserConfig.xml based settings.

So, you’re going to use a UEM solution to decrease the logon time, and there is all good?

Well… not entirely, because the App-V 5 client prior to SP2 HF4 is smart: It quickly checks if the available extensions have corresponding packages on the client. And if not, the extensions are removed. So, the user logs on to a pristine VDI session, UEM restores the extensions, the App-V client launches and validates whether the applications exists that are used by those extensions. Do you see the issue? At this point-in-time, App-V’s Sync process did not happen yet, so right now there is not a single user-targeted application available on that system. A clear statement for the App-V client: Clean up that orphaned mess!

Luckily, this behavior changed (or more precise. Can be controlled) with HF4 for App-V 5 SP2: Microsoft introduced a new settings called PreserveUserIntegrationsOnLogin, telling the client to skip the clean-up (See MS’ Performance Guidance for App-V 5). By enabling this setting on the clients, the extensions that were restored by the UEM solution are not cleaned up right away. As the ‘normal’ Publishing task later on will do a cleanup to, it again might happen that applications seem to disappear a few seconds after the logon process, if they aren’t available to users any longer. This looks like the ‘all good’ we were aiming for.

Using a UEM solution for managing the App-V client’s catalog information can dramatically improve the user’s logon/publishing experience by reducing the logon time from several minutes to just a few seconds? Don’t believe it? Check this short post by Login Consultants: First results App-V 5 SP2 Hotfix 4!

The UEM solution has to be triggered during Logon/Logoff to save and restore the App-V publishing (or ’catalog’) information.

UEM is a must-have for most App-V 5 implementations

To summarize the above a little:

A User Environment Management or User Profile Management solution is vital for the very most App-V 5 implementations, because

• It allows to roam data that originally are stored in non-roaming locations
• It may allow to roam settings that are stored by App-V in protected locations (like HKLM in the Registry)
• It allows to retain configuration data for situations where a newly sequenced package should replace applications of another package
• It allows to provide user configurations to applications regardless of their usage in one or more Connection Groups or stand-alone
• It allows to persist User Configurations across extremely dynamically created Connection Groups that are defined by ConfigManager’s Vrtual Environments.
• It allows to improve the user logon experience in any shared scenario dramatically.
• Slightly depending on the real requirements, the UEM solution should
• Be explicitly supported for App-V 5 SP2 (with its new extensions)
• Be able to act inside the protected application runtime environments, usually by injecting virtualized processes
• Be able to modify certain protected, machine specific locations
• Be able to be triggered upon logon/logoff to support the publishing process

Resources

UEM Smackdown: http://www.pqr.com/user-environment-management-smackdown

App-V Client Interaction Guide: http://www.microsoft.com/en-us/download/details.aspx?id=41635

App-V Performance Guide: http://technet.microsoft.com/en-us/library/dn659478.aspx

MS UE-V Template: http://gallery.technet.microsoft.com/Authored-UE-V-Settings-bb442a33

 

UEM Vendors

AppSense: http://www.appsense.com/solutions/use-cases/user-environment-management

Immidio http://immidio.com/flexplus/

Microsoft UE-V: http://www.microsoft.com/de-de/windows/enterprise/products-and-technologies/virtualization/UE-V.aspx

RES: http://www.ressoftware.com/product/res-workspace-manager

 

 

---

Posted in App-V, Client, Management
Tags: 5.0, App-V