Sharing Personalization Settings between Operating Systems – Debunking the Myth

I have recently heard, from several different sources, that it is “best practice” not to share user profiles, or personalization settings, between different operating system platforms. On the surface, this seems a sensible limitation since different operating systems have different user profile structures. 

Vista and Windows Server 2008 (WS08) put most profile data somewhere in “\users\%username%\appdata”, whereas XP and Windows Server 2003 (W2K3) may place it in “\documents and settings\%username%\application data” or “\documents and settings\%username%\local settings” or somewhere else entirely.

We can’t predict where the data will go for a given application which doesn’t help us understand the “splatter” that it makes in the file system. This folder lottery is further compounded by the fact that Vista and WS08 implicitly add the “.v2” extension to any profile path you define for a user. What this results in is that with a roaming profile solution, you are forced to have different profiles, and therefore different settings, between XP/W2K3, which implicitly use a “v1” profile, and Vista/WS08 which explicitly use a “v2” profile (even though the path defined for this profile does not actually include the “.v2” extension).

Applications should get the paths to use within the profile folder hierarchy by using operating system API calls that are the same between the different operating systems but will yield the correct folder for the operating system it is being run on. Unfortunately, not all applications are written this way and some will make assumptions about paths and maybe even hard code them which is likely to cause problems even before operating system migration, particularly in Terminal Server/Citrix XenApp environments.

There is also the class of setting that is actually different between the different operating systems. Take for instance the good old desktop wallpaper which most people, if pushed, will confess is the one item that makes their PC experience “personal” (while this is not an essential productivity related personalization setting, it does however provide a good example as to how even the most basic of settings fail to migrate between OS platforms)  Although users don’t know, and indeed do not need to know, they are actually stored in different file formats between XP/W2K3 and Vista/WS08. Therefore if the setting for this, which is stored in the user’s registry hive, was just unintelligently transplanted between the two operating systems then one of the desktops wouldn’t show the correct wallpaper.

Some implementers may say that it is a good idea to start with clean profiles when moving from one operating system to another system since it is a good opportunity, in their view, for a clean start and to leave all the myriad of settings behind that aren’t apparently used for anything and just clutter the profile. However, against this has to be weighed the cost of the user having to re-personalize their applications and desktop. This costs both in terms of time (both users being interrupted during their workflow as they find a toolbar or application setting they need is missing, and then having to remember where and how to re-make the customization, which could be different to how they would have changed the option on their old OS)  and also can cause a certain amount of resistance when these users tell their yet-to-be-upgraded colleagues is that this great new operating system, which has been months in planning, has lost all of their settings and they are struggling to find the new ways to set things the way “they should be”.

Enter AppSense Environment Manager. All of the technical issues outlined above are addressed by Environment Manager making the migration from one operating system to another, and back again if required, a much less painless experience and instead now becomes an automated, seamless process for both the user and administrator alike. The files used by an application within the locally cached profile folders are stored in a relative, rather than absolute, form in the Environment Manager database which then allows them to be subsequently put back in the correct, operating system specific, folder hierarchies. Because Environment Manager functions on a per-application basis, it can much more accurately target which settings need to be brought over onto the new operating system and it also silently transmogrifies items and their settings, such as desktop wallpapers, to help ensure that seamless migration that administrators dream of. All this, of course, is done with next to no configuration by administrators so they do not need to understand the intricacies of any of the applications and subsequent registry settings and profile structures the user uses. This helps make for quick and easy migrations, although I don’t personally like the term “migration” since it implies a one way movement whereas Environment Manager provides bi-directionality with no extra effort.

So in summary…While it is right to say that it is NOT best practice to share ‘roaming profiles’ across OS platforms, AppSense Environment Manager dispels the myth that sharing ‘personalization settings’ between operating systems is not a recommended best practice –in fact AppSense recommend you embrace it…