Microsoft's official enterprise support blog for AD DS and more
[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 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.
The solution is to use separate roaming profiles for each operating system by utilizing an environment variable in the profile path.
File server for profiles:
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
4. Edit Win8GPO
5. Set user profile paths to \\Server\ProfilesShare\%OSVer%\%username%\
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
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
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.
This effectively blocks rolling out win8 when you're using DFS for your userprofiles in enterprise environments.
Now we even have to do a DCR for a new namespace setting us back months.
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 ?
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.
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.
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?
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.
If you end the profile path in AD with a slash \
then the separate V1, V2 and V3 suffixed profile folders are automatically created.
Why could you not just use UE-V?
trying to implement this, have changed the profile path (DFS) to \\server\share\users\userid\%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?
The link to the knowledgebase article is dead, which I know for sure it existed before.
The technet article "Deploy Roaming User Profiles" doesn't describe any possible incompatibilities between Windows 7 and Windows 8 roaming profiles.
This is confusing to me, and I'm asking myself if the problem is solved or if we still have to be vigilant?
This is not working for me...
I have added the GPO as you outlined, but the variable simply isn't translating...
The profile gets created at:
Where it literally creates a folder called '%OSVer%', then creates the users profile folder under it...
I have confirmed via command-line that the variable is definitely there, and even set up a logon.bat file that echoes the variable (then pauses), and the variable is present...
Any ideas? Would love to get this working reliably...
And I second the question about what the heck was Microsoft thinking using the same profile extension (.V2) for an incompatible profile... insanity!
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...
Ok, unless I come across something new explaining what I may have been doing wrong, I'm giving up on this otherwise really promising method.
After a bit more reading, apparently there is no danger of messing anything up by setting the GPO for all users logging on to the computer, but that one was also a royal pain in the butt... everything I tried, simply didn't work, it failed with just a vague error: can't find profile path or some such...
Then I looked at the actual registry setting in the ProfileList - and noticed the path had 4 (FOUR) forward slashes before the computername instead of just two... wtf?
So, I eliminated the \\ in the GPO (so, the value used was just "%LOGONSERVER%\PROFILES$\Win8\%USERNAME%\" (minus the quotes of course) - and presto, it works...
Maybe it was because I used a variable for the servername(%LOGONSERVER%), but I'm tired and don't feel like testing that theory right now...
How frustratingly infuriating.
In all honesty I'd much prefer this method outlined in this post though, so if the author ever circles back and reads these comments, hopefully you can point out what I may be doing wrong...
In answer to Snapdragons comment:
"If you end the profile path in AD with a slash \
then the separate V1, V2 and V3 suffixed profile folders are automatically created."
Sorry, tried that, didn't work as you described.
In fact, using the GPO method, it doesn't even append the .V2 for Win8 profiles, it uses the same style as XP profiles (plain username)...
Sheesh, I wish Microsoft would be more consistent...
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?