A Brief History of User Profiles …and an Idea for Microsoft!
Here is a great piece written by Jacques Bensimon.
Before getting into it, let me stress that this is not a survey of all available (native and third-party) Windows user profile “solutions” out there, nor is it a description of their inner workings, details & caveats, configuration, resource requirements, costs, etc. It is, at best, an attempt to share a broad classification that I’ve found useful when discussing alternatives with colleagues and clients, followed by a welcome to the newest kid on the block and by a related suggestion (that could very well be idiotic!)
In the beginning, to start biblically, there was the local user profile: a user’s data files and settings (both file- and Registry-based) are stored somewhere on the Windows machine on which they’re used, and nowhere else. Simple, efficient, and remains to this day how profiles work on (I’m guessing) over 99% of home machines and private portables. (I’m ignoring here the few items, like wallpaper & user picture, that you can choose to have follow you from machine to machine when you use a Microsoft account with Windows 10 – not relevant to this discussion). A local profile, all else being equal, leads hands-down to the fastest possible logon times. Keep this in mind as we proceed.
But business computing generally involves more complexity: for a variety of reasons, including travel, remote work, app segregation, etc., users in the enterprise often find themselves using a number of different machines, in some scenarios assigned “randomly” as part of the logon process from among dozens, hundreds, or even thousands of “pool” machines. As can easily be imagined, users balk at the idea of having to recreate their preferred working environment (desktop and application settings & preferences) on every machine they touch. To make matters worse, even if it were acceptable to users and practical for IT to maintain local profiles on each machine (which it generally isn’t), some enterprise computing strategies entail non-persistent machines, i.e. machines that revert to a known initial “template” state every time they boot up, so any added local profiles would get wiped out in such cases.
The “classic” answer to such multi-machine situations, pretty much as old as Windows itself, is the roaming user profile: at every logoff, almost the entirety of the user’s local profile contents are copied to a network location, and are copied back to function as a local profile during the subsequent logon (regardless of whether the new logon occurs on the same or a different machine than the last). The roaming profile mechanism offers an extremely limited ability to exclude a specified set of profile subfolders from this logoff-time copying, in theory subfolders with “unimportant” content that applications can recreate automatically in subsequent sessions without user inconvenience. In reality however, the exclusion mechanism is such a blunt tool (unable as it is to allow selected subfolders of excluded folders to be included nonetheless) and applications from various vendors are so “undisciplined” as to where in a profile their “important” settings are stored, that the set of excluded folders must be kept to a minimum (if not almost eliminated) lest users be overly affected. The net effect of that is that roaming profiles tend to grow in overall size over time, sometimes dramatically, and the result of that is that logons (and less annoyingly logoffs) tend to take longer and longer over time (the half-joking advice to roaming profile users soon becomes to go prepare their morning coffee during logon).
More than any other factor (ignoring issues of concurrency, support for multiple Windows versions, etc.), this creeping logon speed decline has led to a vibrant market for (mostly third-party) alternatives to roaming profiles. I in fact sometimes wonder whether it would have been quite as vibrant had Microsoft somewhere along the line endowed roaming profiles with a much more granular profile content exclusion/inclusion mechanism. These alternatives differ wildly as to when, where, and how profile contents are stored, at what point they are retrieved for use in the course of subsequent sessions, the back-end infrastructure they require, the resiliency features they offer, etc., all of which factor into my own love/hate determinations, but logon speed is the attribute they universally claim, and the one IT generally considers above all others when evaluating them.
As an implementer of these solutions (and co-creator of one of them), I tend to categorize profile-related products into two broad buckets:
I. “Save NOTHING except for …”: the default stance of products in this category is to only save (and later restore) the profile items (folders & files, Registry keys & values) that administrators explicitly select. This involves a little more work for the implementers, generally requires a deeper understanding of what makes specific applications and OS components “tick” (do I ever miss an opportunity to recommend Total Uninstall?!), and often entails an iterative pilot process to arrive at a fully satisfactory configuration, but the control freak in me likes it. Template configurations are generally made available (sometimes by “the community”) for commonly encountered applications, but you’re on your own where uncommon or in-house apps are concerned. As examples, this category includes
- IPM Hybrid Profile: If you’re not one of IPM’s clients, I’m quite certain you’ve never heard of this one! Created about 5 minutes after Microsoft introduced Windows NT 4 Terminal Server Edition, it combines a mandatory or local Default profile with some limited folder redirection and custom logoff/logon scripts driven by configuration files that specify what file system and Registry items to save & restore (or as we and others like to say, to persist).
- VMware User Environment Manager (previously Immidio Flex Profiles, previously the freeware Flex Profile Kit): the save/restore mechanism has changed over time, as has the format of the saved data, but the principle remains essentially the same: what specifically do you want to persist?
- Microsoft User Environment Virtualization (or UE-V): yet another misuse and abuse of the word “virtualization”, but the principle is again identical.
II. “Save EVEYTHING except for …”: the products in this category tend to save “everything” in a user profile (I’ve been known to call them “roaming profiles in sheep’s clothing”) but offer much more sophisticated exclusion/inclusion/sync capabilities than plain roaming profiles and can therefore, when carefully configured (“spare the exclusions, spoil the profile”), also claim to beneficially impact logon times. The implementation effort here is initially perhaps lighter than with the technologies in the first category (since users in theory lose nothing from the very beginning), but further effort is required at some point to identify and exclude unimportant “bloat” in order to truly achieve optimal logon times (I’m consciously ignoring here their de rigueur “streaming” feature that can restore application settings just-in-time at launch rather than during logon). Here again, configuration recommendations (exclusion lists) are available from vendors and from “the community”. Examples include
- Citrix User Profile Management (previously sepagoPROFILE, previously a glint in the eye of Helge Klein): one of the most popular such
products since the Citrix acquisition and its inclusion in Citrix Virtual Apps and Desktops, this technology is extremely easy to implement, requiring only that a profile storage location on the network be defined and a single activation policy be set to get the ball rolling. Citrix UPM does a very competent job of persisting user settings and is now a staple of Citrix deployments. - Ivanti (previously AppSense) Environment Manager: an early and still popular entrant in the profile game, this product’s initial versions belonged only to my above Category I, but later versions introduced a (true this time) user settings virtualization capability that by default “grabs” all app settings and restores them (from a SQL database no less!) not to their original locations in the user profile but rather on demand to a local cache from which they are made available to applications via injected file system and Registry API interception components (frankly, I’ve never been a fan of that aspect!). Some might argue that I’m miscategorizing the product since you must first specify the applications (or application groups) for which settings are captured, but that’s a top-level configuration after which EM uses its API interception technology to, by default, nab everything the applications touches in the user profile.
- FSLogix (now Microsoft) Profile Containers: a component of the broader FSLogix Apps product, this is the new entrant (at least under the Microsoft umbrella) that I wish to discuss in slightly more detail below. Microsoft making it available at no extra cost to a broad swath of its enterprise customers has made quite a splash in the End User Computing (EUC) world in recent weeks, and a previously respected (even admired) niche product that we’ve always liked is now on everyone’s lips.
I’m not sure whether or not the clever folks at FSLogix were first with the idea but, by way of a brilliant file system filter driver (the same sort of component that allows anti-virus and remote file system drivers to get first crack at disk read/write requests before they’re allowed to reach the physical disk driver), a user’s profile root folder is captured immediately upon creation into a VHD file stored at a configured network location. Since the contents of the VHD are seamlessly made to appear at the expected location of a user’s local profile on the local disk (as far as the operating system and the applications are concerned) in both the initial and all subsequent sessions, whether on the same or a different machine, the entire contents of the user profile transparently exist on (and are accessed from) the network at all times, without any of the explicit copy operations that all of the previously mentioned products entail. I am not here trying to minimize the performance impact of continuously accessing profile contents from a network location, albeit one made to appear local (it is in fact the subject of the “stupid idea” section of this post coming up), but the access is distributed granularly and strictly on demand over the course of the session rather than in larger bursts at logon, or logoff, or at any time in between as applications are launched. The mounting of a user’s profile VHD during logon and its unmounting after logoff are essentially “bookkeeping” operations that add no significant time to either event, and this technology therefore shares the “true” local profile’s logon speed advantage to which I alluded at the top (yes, the Registry hive is now indirectly loaded into memory from a network location, but that’s generally only a couple of megs). I like to think of the FSLogix approach as “local profiles that magically roam”!
A couple more quick things before I get to my stupid idea: I’ve grossly oversimplified some aspects of the FSLogix behavior. For one, it does offer a rudimentary exclusion mechanism (equivalent to that of roaming profiles) that can keep selected folders truly local, out of the profile container – useful mostly to try to keep down the size of the network-stored VHDs. For another, I’ve completely glossed over the challenge of multiple concurrent sessions: since a profile VHD is necessarily a writable object, it can’t be simultaneously mounted and used on more than a single machine. When one of the FSLogix concurrency support options is enabled, differencing disks off the base VHD are employed on each active machine and may eventually be merged into the base (or not, depending on the selected option and the logon/logoff order).
Now for the stupid idea: my description above didn’t say so explicitly, but you probably already know or have guessed that, other than a network share, no FSLogix back-end infrastructure is required – the FSLogix Agent installation includes the few components (service, drivers, and utilities) necessary to create, mount, unmount, and redirect into the user profile containers, based on Registry/policy configuration settings. The VHDs are therefore necessarily accessed from file server or network appliance shares via the SMB protocol (with its well-documented inefficiencies) over the course of the entire session. [Side-question: is anybody else amused by the fact that Microsoft seriously frowns upon Outlook “Cached Exchange Mode” cache files being stored on the network, but now seems okay with their being stored inside VHDs on the network? I guess what Outlook doesn’t know can’t hurt it!] So I wondered, how could access to the profile VHDs be made so efficient as to truly approach the performance of local file access? … and an example with which many of us are familiar immediately came to mind: Citrix Provisioning Services (PVS) utilizes a UDP-based super-efficient iSCSI-like protocol to make not merely a few profile folders but entire C: drives (stored as VHDs) available to its target machines with excellent performance, even in the Read/Write (aka “private”) mode that a similar use for profiles would require.
The idea for Microsoft is therefore this (TL;DR):
Develop, buy, borrow, or steal an efficient data transfer protocol similar to PVS’s, and put it to work in both an updated FSLogix Agent and a new optional “FSLogix Server” with the necessary storage (local to the server) and network bandwidth to deliver profile container contents to endpoints at maximum speed. If the FSLogix Server concept comes to be, one can also imagine other associated features, like the distribution of profile VHDs among multiple servers (with the agent contacting a virtual address for redirection to the appropriate server), scheduled or dynamic VHD grooming to reduce their size, maybe even some sort of opportunistic VHD replication for fault tolerance, etc..
And here’s the kicker: Citrix also has a (currently limited) “profile container” capability within its Profile Management product (no entire profiles, no concurrent access) and it of course already owns all the PVS technology, so with a little effort it could actually do this first. Microsoft, on the other hand, now owns a polished profile container technology, and has the means to come up with a kick-ass non-SMB data transfer mechanism. Who wins? … or is the answer “nobody” because it is in fact a stupid idea?
JB
Be sure to follow Jacques Bensimon on twitter at @JacqBens
Continue this conversation in the comments below. How are you tackling profiles? What improvements do you wish you could see in future products?