Partager via

Roaming Profile Compatibility - The Windows 7 to Windows 8 Challenge

  • Article

[Editor's note: Everything Mark mentions for Windows 8 clients here is also true for Windows 8.1 clients. Windows 8 and Windows 8.1 clients use the same (v3) profile version, so the 8.1 upgrade will not prevent this from happening if you have roaming profiles in your environment. Something to be aware of if you're planning to migrate users over to the new OS version. -David]

 

Hi. It’s Mark Renoden, Senior Premier Field Engineer in Sydney, Australia here again. Today I’ll offer a workaround for an issue that’s causing a number of customers around the world a degree of trouble. It turns out to be reasonably easy to fix, perhaps just not so obvious.

The Problem

The knowledge base article "Unpredictable behavior if you migrate a roaming user profile from Windows 8 to Windows 7" - https://support.microsoft.com/kb/2748329 states:

Windows 7 and Windows 8 use similar user profile formats, which do not support interoperability when they roam between computers that are running different versions of Windows. When a user who has a windows 7 profile signs in to a Windows 8-based computer for the first time, the user profile is updated to the new Windows 8 format. After this occurs, the user profile is no longer compatible with Windows 7-based computers. See the "More information" section for detailed information about how this issue affects roaming and mandatory profiles.

This sort of problem existed between Windows XP and Windows Vista/7 but was mitigated by Windows Vista/7 using a profile that used a .v2 extension.  The OS would handle storing the separate profiles automatically for you when roaming between those OS versions.  With Windows 7 and Windows 8, both operating systems use roaming profiles with a .v2 extension, even though Windows 8 is actually writing the profile in a newer format.

Mark’s Workaround

The solution is to use separate roaming profiles for each operating system by utilizing an environment variable in the profile path.

Configuration

File server for profiles:

  1. Create profile share “\\Server\ProfilesShare” with permissions configured so that users have write access
  2. In ProfilesShare, create folders “Win7” and “Win8”


 

Active Directory:

  1. Create OU for Windows 7 Clients (say “Win7OU”) and create/link a GPO here (say “Win7GPO”)
  2. Create OU for Windows 8 Clients (say “Win8OU”) and create/link a GPO here (say “Win8GPO”)

Note:As an alternative to separate OUs, a WMI filter may be used to filter according to Operating System:

Windows 7 - SELECT version FROM Win32_OperatingSystem WHERE Version LIKE “6.1%” and ProductType = “1″

Windows 8 - SELECT version FROM Win32_OperatingSystem WHERE Version LIKE “6.2%” and ProductType = “1″

3. Edit Win7GPO

    1. Expand Computer Configuration -> Preferences -> Windows Settings
    2. Under Environment create an environment variable with
      1. Action: Create
      2. System Variable
      3. Name: OSVer
      4. Value: Win7

4. Edit Win8GPO

    1. Expand Computer Configuration -> Preferences -> Windows Settings
    2. Under Environment create an environment variable with
      1. Action: Create
      2. System Variable
      3. Name: OSVer
      4. Value: Win8

5. Set user profile paths to [\\Server\ProfilesShare\%OSVer%\%username%\](file://\\Server\ProfilesShare\%OSVer%\%username%\)

 

Clients:

  1. Log on with administrative accounts first to confirm creation of the OSVer environment variable

2. Log in as users and you’ll observe that different user profiles are created in the appropriate folder in the profiles share depending on client OS

Conclusion

I haven't run into any issues in testing but this might be one of those cases where it's important to use "wait for network". My testing suggests that using "create" as the action on the environment variable mitigates any timing issues.  This is because after the environment variable is created for the machine, this variable persists across boots and doesn't depend on GPP re-application.

You may also wish to consider the use (and testing) of a folder redirection policy to provide users with their data as they cross between Windows 7 and Windows 8 clients. While I have tested this to work with
“My Documents”, there may be varying degrees of success here depending on how Windows 8’s modern apps fiddle with things.

 - Mark “Square Peg in a Round Hole” Renoden

Comments

  • Anonymous
    August 01, 2013
    Disappointed, but not suprised that the developers didn't take "lessons learned" from Vista.  In an enterprise environment, the Version 2 profile was a huge roadblock to corporate rollouts.  In discussing Win8 to management, the need to 'deal with' a version 3 profile now is not going to win any fans.

  • Anonymous
    August 02, 2013
    This effectively blocks rolling out win8 when you're using DFS for your userprofiles in enterprise environments. Brilliant (not). Now we even have to do a DCR for a new namespace setting us back months.

  • Anonymous
    August 02, 2013
    While I understand a new profile version, what's wrong it is pretty much impossible to detect (I don't even recall seeing a single Technet documentation on this, despite being a significant change). How comes there aren't, at least, v3 profiles being created ? How did this kind of bug went through QA unscatted ? Can we expect a fix for Windows 8.1, so we can avoid the same mistake repeated again ?

  • Anonymous
    August 08, 2013
    While I agree this behaviour isn't ideal, there's no reason you can't use this environment variable strategy in a DFS path. You're just steering the client to the path you want based on OS.

  • Anonymous
    August 22, 2013
    This seems to be a valid workaround for new environments/users, but does not help in existing environments. Especially, when users take the "roaming" seriously and indeed change places in heterogeneous environments (happens frequently at some clients). If you have the profiles on a share without the OsVer, and you change the setting on the account a new profile will be created.

  • Anonymous
    August 22, 2013
    I forgot: Wouldn't it be easier to set the "Set roaming profile path for all users logging onto this computer" GPO and leave the profile-directory in the user object empty a better solution?

  • Anonymous
    August 26, 2013
    support.microsoft.com/.../2748329 is a dead link. You might want to see what happened with this KB as even Google (and bing of course) report the dead link too.

  • Anonymous
    September 18, 2013
    If you end the profile path in AD with a slash then the separate V1, V2 and V3 suffixed profile folders are automatically created.

  • Anonymous
    September 25, 2013
    Why could you not just use UE-V?

  • Anonymous
    October 01, 2013
    trying to implement this, have changed the profile path (DFS) to \servershareusersuserid%OSVer%Profile and have created a system variable OSVer on the machine I am testing with, but when I log on, a new folder is created on the share above, with a folder %OSVer%. The variable is not being evaluated, even though it is present on the machine. Any ideas?

  • Anonymous
    October 03, 2013
    (This comment has been deleted per user request)

  • Anonymous
    October 09, 2013
    The comment has been removed

  • Anonymous
    October 09, 2013
    Note: I tried the suggestion by D. Oliana to: "I forgot: Wouldn't it be easier to set the "Set roaming profile path for all users logging onto this computer" GPO and leave the profile-directory in the user object empty a better solution?" and it worked (created the roaming user profile in the right location), BUT... I then discovered that this GPO also applies to local accounts - so caused problems with the local Admin account (and ( imagine other local accounts?), so is not an option in my opinion - it would probably be the best solutioon if there was an option to NOT apply this to local accounts. Also - to answer his remark about problems with existing users - you would obviously have to migrate the profiles one user at a time, so may not be workable in a really large environment, but I'm prepared to do this over a weekend for our 75+ users - IF I can get the GPO to work... Man, Microsoft sure does know how to bork things up sometimes...

  • Anonymous
    October 09, 2013
    The comment has been removed

  • Anonymous
    October 17, 2013
    I've tried this, and got it all up and running only a new problem has come to light. On my network passwords need to be changed every ... days. When I logged on to a windows7 pc I got the prompt to change my pw. When the next day I logged on to a windows 8 pc I had to use my old password. because there are two different profiles, passwords are not changed alike. the password changing interval is different in the win8 and win7 policies. Does anyone know how to make this work?

  • Anonymous
    February 18, 2014
    This is a collection of the top Microsoft Support solutions to the most common issues experienced using

  • Anonymous
    January 06, 2015
    So, we’ve been quiet for a few months, which is extraordinarily embarrassing after I basically