The ‘Windows User Profile’ – words to make even the most optimistic Windows admin shake his head and grimace. On one hand, it’s a sound idea – grouping all of the settings that are specific to a user into one location on a device – all nice and neat. On the other hand, we have the problem of how Microsoft achieved it and all the legacy baggage that goes with it.
This blog post looks (somewhat in general) at what modern tools can do to both counter the issues often associated with the user environment in Windows and enhance the capabilities. While there are some really clever tools out there, some more and some less capable in different ways, this post will focus primarily on VMware User Environment Manager as a reference (mainly because it’s a pretty simple product). The concepts can apply to other products, such as RES ONE Workspace, because the underlying issues are common.
So what’s up with Windows Profiles?
Well, to be fair, the native approach is optimised for local use, predominantly in a stand-alone context. Microsoft have included some options to provide either a draconian response, the Mandatory Profile (locked down, no changes permitted – rock solid, but inflexible) or Roaming Profiles for a portable option that’s sometimes a little flaky. Group Policy added some much needed granular abilities – most notably folder redirection, which we’ll discuss later.
The profile can be boiled down to the following:
- User Data – all those documents, music files, dodgy GIFs you keep in the My Documents, My Pictures and so on.
- Application settings – The user’s configuration for discrete applications. These may be in the user’s own part of the Windows Registry or in configuration files.
- Environment Settings – These are typically start menu items, desktop shortcuts, wallpaper. However, you can include printer and disk mappings to this.
All this, without careful management can lead to problems. Firstly, without management of User Data in particular, the profile can get somewhat obese. If the profile is just maintained locally, size isn’t necessarily a big issue. However, in a modern environment where a user wants to log on and access their data anywhere in the business, a big profile is cumbersome and causes both reliability and performance issues. We can alleviate some of these issues by using native tools, but only to a point.
The Windows profile is, to a certain extent, unreliable, with respect to the registry settings and has little ability to self-heal in the event of a fault in the profile. Windows Policy often doesn’t go deep enough to override faulty settings and often, the only approach to profile corruption is the dreaded all-or-nothing Profile Reset. Yuk.
The user profile is very proprietary with respect to operating system releases (with Windows XP version 2 profiles differing considerably from later releases). This makes migrating between releases quite painful too.
Loading the Windows Profile, (particularly when roaming is an all-or-nothing affair) in the roaming case, it’s all downloaded on log on, then loaded into memory – in the case of application settings, these will be loaded even if the application isn’t needed.
So we have a solution that works, but not very fast, nor efficient or reliable. We can fix some issues with just native tools, but it only goes so far.
User Environment Management
So we want to fix these problems, sure, but we don’t want to stop there. We want to be able to centrally administer some settings and maybe allow user control of others. We might want to do clever things based on context – what about different settings if a user logs on in VMware View rather than on an office PC or maybe different again when off site?
We need a third party solution above and beyond the basic native Windows toolset. As mentioned earlier, there are numerous options out there – this speaks volumes as to how seriously this issue is seen across the industry – if it were an obscure problem, there wouldn’t be many tools – good old supply and demand economics. Here, we’ll consider VMware’s User Environment Manager (UEM), what was once upon a time known as Immidio Flex+.
Setting up VMware UEM
I won’t go too far into the details of how to set up UEM – as others out there have blogged about this already, but it boils down to these steps:
- Set up a couple of shared folders – A UEM Configuration Share (stores all the common, centrally managed items) and a Profile Archive (for user-specific stuff).
- Set up some Windows Active Directory Group Policy to apply to users and devices to configure them to use UEM.
- Install a UEM management console to configure the solution and an agent into all managed endpoints.
Once these are in place, the good stuff begins.
User Data
Let’s consider the easy one first. By establishing a centrally managed file services solution on a NAS or server infrastructure, we can establish user home folders on a per user basis. Into this we can use the native Windows Group Policy to redirect My Documents etc to the Home Folder share. We can repeat this for Pictures etc.
We can apply this either to the Organizational Unit containing the users, or we can do clever things like enable LoopBack processing and apply the setting via the computer account’s location in Active Directory. This works especially well in VDI and RDSH environments where the file solution is in proximity to the desktops.
Application Settings
One of the key attributes of UEM and others is the central administration of application settings. In the case of UEM, a tool is provided to capture application settings – Application Profiler. This tool is run on a reference machine similar in configuration to the user endpoints, with the application installed (but not run) alongside the Application Profiler.
The application is launched from the Profiler – any configuration settings are recorded by the Profiler and held in the form of XML content in the Config Share. This is important as it provides flexibility with respect to migrating between OS as it isn’t a Windows native profile format. It is possible to manually edit the captured config to include additional elements if required.
An important difference with respect to application settings is that in Windows native profiles, the settings are loaded to memory at user log on regardless. In the case of UEM, it is possible to select the application profile to be loaded only if the application is started. This has a substantial benefit with respect to log on times and is applicable to most applications (an obvious exception being those that run on log on, perhaps with a service).
A useful feature here is that UEM can even intervene in ThinApp packages, applying settings within the sandbox. It can also interface with App-V 4 and 5 in a similar manner.
Applications that aren’t defined would fall into the scope of the user’s personal settings and are saved to the archive share.
User Environment Settings
Beneath the application layer, we have elements of the operating system and environment we may wish to adjust. Typically, these might include printer settings, drive mappings etc. We can even pull in Microsoft ADMX Policy templates and configure templates here rather than via Windows Group Policy.
In the example below, we have a home drive mapping.
As with application settings, items not otherwise locked down are managed using the user’s personal archive.
Applying Settings on Conditions
In UEM, there are a number of different ways we can apply settings based upon the context in which they are needed.
With the User environment tab, these are applied when the user is logged on. Taking our Home Drive mapping above, we could apply this based on a condition where it is only executed when logged on via an internal IP address.
In the case of application settings, these can be set to apply when an application is run. So we could map a drive when VLC is launched and undo it when the application exits….
We could take this one step further – we can apply the environmental setting for an application based on a condition. For example, the user runs VLC, it will run a drive mapping if the user is logged on from a PC on a particular IP range or the Remote display protocol is PCoIP….
To Conclude
So, by implementing a fully featured product such as UEM, we can simplify and centralize the administration of user and application settings, improving security, reliability and compliance to corporate standards. We can even customise the needs depending on a variety of conditions, such as whether the user is connected to a desktop via a remote desktop protocol, or on a laptop running on battery; a member of a particular Active Directory group or connected from a particular IP address range.
The extended capabilities, such as applying application settings on-demand improve the user experience by reducing the log on time for a start. By implementing folder redirection as well, we further eliminate reliance on a particular endpoint in the equation – a valuable tool for both Remote Desktop Session Host shared desktops or non-persistent virtual desktops.