Introduction to User Profiles and Their Problems

First, some profile history and knowledge. To begin, let’s look at and understand the Windows Profile.

The Windows user profile holds user-based application and operating system files and settings. The ntuser.dat file is effectively the user’s registry hive loaded up to HKEY_Users at logon, and is represented in HKEY_Current_User within the user session. These profiles include settings such as your wallpaper preference and Windows Explorer layout. Application files specific to the user are stored in %appdata%, with files that need to roam between PCs under %appdata%\roaming, and data to stay local under %appdata%\local. Many applications cache a *lot* of data to the %appdata%\local folder in order to optimize the user experience—Chrome being a prime example. 

There are several profile types. The main ones are local, roaming, and mandatory. Local profiles are now the most common, with mandatory being very similar to a local profile but typically customized for a better user experience and stored on a central file server. Both mandatory and roaming profiles come with their challenges—the main ones being that roaming profiles are prone to corruption and slow to logon when files are copied from the server. Mandatory profiles also present security risks and challenges around personal certificates, Skype for Business being a well-known offender.

If you want to read more about the history of profiles, please take a look at this popular blog written for Ivanti by James Rankin (Twitter: @james____rankin).

I first became aware of the problems with roaming profiles very early in my career, where 70% of my time on the helpdesk was spent resetting roaming profiles for users who had lost all settings and personalization in their Windows desktop. Normally there was a difficult problem to troubleshoot, or a device had unexpectedly powered off, leaving the profile corrupt. This was a common problem in the industry, and something needed to be done.

Profiles – Virtualized and Optimized by Ivanti

There were numerous attempts to solve this problem, but an early solutions leader was AppSense (now part of Ivanti as the User Workspace Management (UWM) group). The AppSense Environment Manager product not only solved the problem, it also optimized the user’s profile and user experience. And the solution wasn’t just a point product; it allowed easy management of profiles and developed into the gold standard for profile management. Competitors’ approaches stored profiles on file-server SMB shares, which might be acceptable for smaller deployments with 100% of users on virtual desktops and sessions, but these approaches didn’t fare so well for physical desktops, WAN links, and (looking to the future) cloud architectures requiring web services over HTTPS. 

To learn more about how UWM is leading the march to the cloud in workspace management and tight integration with Azure, read this blog.

The New Contender: Profile Containers

I first became aware of the idea of profile containers in the very early days of Office 365, as an AppSense engineer at HPe (now DXC). We looked to Environment Manager as a way of retaining the user’s Office 365 Outlook cache so it did not need to be re-cached each time the user logged onto a new non-persistent desktop or session. If the cache is not immediately available, the user’s experience is poor as they wait for the mailbox to be rebuilt and are initially unable to search.

Why not just capture the Outlook cache file through Environment Manager, like any other personalized file? Well, the problem is size—these cache files quickly grow to multiple gigabytes, which isn’t suitable for transfer at app start or even logon. Using VHDs as an alternative approach (managed through Environment Manager) was discussed at the time, but the idea never really took off. 

Around the time I joined Ivanti, the VHD idea was gaining popularity across the industry and we developed scripts for Environment Manager that allowed elements of the profile to be roamed in a VHD. These scripts worked nicely and, over time, evolved into the feature known as EM Cache Roaming, initially released in early 2018.

What does this have to do with profile containers? Well, this concept of using a VHD to solve a specific application cache problem can be extended to capture the entire user profile in one large VHD blob. It mounts quickly, ensures fast logons, and, compared to other approaches, doesn’t have the performance impact on the file server, which makes for exciting demos and appears simple. You could almost say that profile containers are Folder Redirection 2.0, or are at least trying to solve the same challenges.

UWM Virtualized Profiles vs Profile Containers

So how do profile containers differ from Ivanti’s profile management? First, the concept of a profile container actually dates back to Windows Server 2012, where it was known as “User Personal Disk” and was primarily used to solve Outlook roaming problems. It was buried deep in the UI and never got much love, leaving the door open for other vendors, including FSLogix, to advance the concept and extend it to capturing the entire user profile as well as other application caches.

So, do we need both approaches? Why does Environment Manager contain a mix of file and registry capture, and the option of VHD Cache Roaming for things like Office 365 caches? The key word is “Management”—if you place the entire profile into one large container then you lose so much of the ability to manage the user experience. Profile containers are a point solution to allow efficient redirection of a profile to a network share, that’s it.  Below are some genuine examples of “asks” I’ve had this week that simply are not possible (or at least very difficult) with profile containers:

  • A large financial organization wants the experience on its Windows 10 virtual desktops to be the same on Windows 10 laptops. This is impossible with profile containers because delivering a huge VHD file over a WAN or VPN won’t work, especially when the laptop user goes offline. In addition, sharing a single profile container across multiple devices can result in lost profile data.
  • If you have a user roaming geographically to different VDI farms, then a profile container cannot stretch across the world through a WAN link, unless you replicate the entire file system. The GeoSync feature in User Workspace Manager synchronizes data between datacenters.
  • Here’s another example I heard today: An Office setting is causing problems for 3,000 users and the organization needs to delete it from each user’s profile. With Environment Manager, this is easy to apply in bulk and just relaunch the app. With profile containers, however, it requires each user to log on again so the changes can be applied.
  • When profile settings cause a problem, either the administrator or the user (if self-service is enabled) can easily roll back to an earlier version either the specific application or operating system setting, rather than blowing away the entire profile.

The short version is that with Environment Manager, you have granular, centralized control over every aspect of the user profile, combined with the benefits of using VHDs for roaming caches in situations where it makes sense. In other words, the best of both worlds.

Profile Containers and Performance

When IT teams look at deploying profile containers, the most common questions we receive relate to the anticipated IOPS load on the file server that will host the VHDs. This article is a good discussion based on real world experience.

By comparison with Ivanti, personalization only synchronizes data on demand when an application or session starts (although it can be pre-loaded and cached for offline devices). With a little configuration, it is possible to capture a relatively small amount of profile data (typically 15-20 MB per user) and still provide a full roaming experience.

Conclusion

When weighing up how you want to manage your user profiles across the Windows desktop, consider it from an administrative and user-experience perspective.  I’ve provided a small snapshot of requirements that would be difficult/impossible to achieve with profile containers. With Environment Manager, you can reap the performance benefits of using VHD to containerize the parts of the profile that make sense without giving up management of the rest.

You can learn more about Environment Manager here.