Roaming Profile Compatibility – The Windows 7 to Windows 8 Challenge

This post has been republished via RSS; it originally appeared at: Ask the Directory Services Team articles.

First published on TechNet on Jul 31, 2013

[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" - http://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%\




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



Leave a Reply

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

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.