Roaming Profiles in a mixed OS environment

**UPDATE: Microsoft recently released hotfixes for Windows 8/2012 and Windows 8.1/2012 R2 to address the roaming profile compatibility issue. The hotfix and regkey is outlined in Step 1 this technet article: http://technet.microsoft.com/en-us/library/jj649079.aspx. Note that there is no hotfix for Windows 7/2008 R2, so you’ll still need the procedure outlined below if you are trying to roam from Vista/2008 to newer versions.

Hotfixes
Windows 8/Server 2012 (KB 2887239)
Windows 8.1/Server 2012 R2 (KB 2887595)

I love mandatory roaming profiles. With the hundreds of servers I manage daily, it’s important I have to same settings on each system to maximize efficiency. Anything I do on one system is available on all systems – for the most part. Each version of Windows comes with a slightly different user profile and they’re not always compatible. For instance, the profile in use with Windows XP/2003 was vastly different from Windows Vista/2008 which was also different from Windows 7/2008 R2. This becomes an issue with roaming profiles since the path to the profile is set on the AD user account with no regard to the actual operating system you’ll be logging into. We support systems ranging from Windows Server 2003 to Windows Server 2012 R2, so I need the ability to roam on any platform.

Microsoft addressed this in the jump from XP to Vista by automatically appending a .V2 to profile names, so you actually had different profiles for XP and Vista. However, that’s as far as they went. Every version of Windows since Vista uses that .V2 profile, but they are not fully compatible. Make a change to the profile in Windows 8 and you’ll lose your Windows Vista desktop. Similarly, modify the start menu in Windows 8.1 and you won’t see the same layout on your Windows 8 systems.

The directory services team provided a workaround by creating multiple GPO’s with WMI filters that apply only to a specific operating system thereby allowing you to set an environment variable on every system to use the in the profile path of users. To me, that was too much clutter and too many GPO’s applying to all domain servers slowing down startup and login. A better solution is a single GPO with item level targeting. Item level targeting basically allows you to apply a preference only if certain criteria are met – in this case, the Operating System version.

To accomplish this, we’ll use a GPO to set an environment variable named PROFILEVER, and then use that variable in the user profile settings in AD. We’ll use the following values for each OS:

v1 = Windows XP/2003/2003 R2
v2 = Windows Vista/2008
v3 = Windows 7/2008 R2
v3.1 = Windows 8/2012
v3.2 = Windows 8.1/2012 R2

  1. Create a new Group Policy Object.
  2. Under Computer Configuration > Preferences > Windows Settings > Environment, create a new Environment Variable named PROFILEVER.
  3. Set the Action to Update, the name to PROFILEVER, the Value to v1.
  4. On the Common tab, select the check box for Item-Level targeting and click the Targeting button.
  5. We want this to apply to multiple Operating Systems, so first add a collection.
  6. Next, select New Item > Operating System, and then select Windows XP from the Product drop-down.*
  7. Drag the Operating System object under the collection.
  8. Repeat step 6 adding entries for Windows Server 2003 and Windows Server 2003 R2.
    ILT
  9. Repeat steps 2 through 8 for each profile version you wish to support using the proper value and Operating Systems.
    PROFILEVER Environment Variable
  10. As a fail-safe, I’ve added a v0 with no item-level targeting set. Because items are applied sequentially, PROFILEVER should be overwritten by one of the item-level targeted preferences.
  11. Be sure to update AD Profile path to use the new environment variable:
    \\server\share\profiles\%PROFILEVER%\%username%
  12. You’ll need to logoff any existing sessions and run a gpupdate /force on systems (or reboot) for the setting to take effect.

*Note: In order to properly select Operating System versions, you need to perform this from the highest OS you wish to support. For instance, you’ll only be able to select Windows 8.1/Server 2012 R2 if you are editing the GPO on a Windows 8.1/Server 2012 R2 system.

 

7 thoughts on “Roaming Profiles in a mixed OS environment

  1. Jeff,
    What if you have windows 8.1 clients and windows 2008 std.? How would I customize for my environment?
    It is currently running and I get unresponsive profiles from time to time but it seems to work most of the time. User profiles have the .v2 at the end.

    Thanks

    Kamran

    • The profile version is the same between server and client of the same release. The on caveat is that if you assign the GPO to a server after it’s already been booted, the environment variable may not be created until the next reboot.

  2. The environment variable is being set! but the variable is not recognised in the profile path. I have a %PROFILEVER% folder now.

    • You need either need to run gpupdate /force on the systems and then reboot, or wait until group policy has propagated and then reboot the systems. The environment variable will only get set on startup.

  3. This is an odd way to go about fixing this problem. You should be adding the UseProfilePathExtensionVersion flag, which you can easily set in Group Policy to apply to all domain computers. Combine with Folder Redirection for plug-&-play compatibility for any computers added to the domain and transparent transition for users between different OS versions (not dissimilar to your solution, just far simpler).

    This Microsoft KB article is a good start: http://support.microsoft.com/kb/2890783

  4. Pingback: Roaming User Profiles in Mixed OS Environments | vEffort

  5. Hi,

    On paper and theory this looks like a superb approach and a solution. I have to move to a mixed w7 / w10 environment and was scratching my brain. I thought surely folks would have faced this issue with a move from xp to vista to 7.

    Does this all hang together with no downside?

    But this is a great idea and thanks ever so much for sharing it.
    Nalin

Leave a Reply

Your email address will not be published. Required fields are marked *