Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Recent Posts

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

TIL: Windows 10 goes back to adding a .v5 suffix to profiles

So, back in the Windows 7/ Server 2008 era if you had a roaming profile it was always suffixed with a .v2 extension. So if you username was “rakhesh” and your profile path in AD was “\\someservers\profiles“, the actual path created there would be “\\someservers\profiles\rakhesh.v2“. This is because Windows 7/ Server 2008 had a different profile format to Windows XP/ Server 2003 and prior, so Microsoft decided to tack on this extension so there’s no corruption. Neat idea!

But with Windows 8/ Server 2012 and Windows 8.1/ Server 2012 R2 there was no similar extension. So if you started using roaming profiles with these OSes, and you had a mixed environment, you were in for some trouble. Everything would write to the .v2 profile.

Turns out you can apply a hotfix for Windows 8/ Server 2012 and Windows 8.1/ Server 2012 R2, and then create a new registry value UseProfilePathExtensionVersion (of data 1) under HKLM\System\CurrentControlset\Services\ProfSvc\Parameters and this will cause these two OSes to append a .v3 and .v4 suffix respectively to the roaming profiles. Nice!

With Windows 10/ Server 2016 though, the OS goes back to the old behavior of adding a .v5 extension. So no need for any hotfix or registry key changes. Nice!

As an FYI to myself here’s two alternative approaches to Windows 8/ Server 2012 and Windows 8.1/ Server 2012 R2 profile handling if one didn’t want to go the hotfix + registry key change route: this one’s from Microsoft, and this one’s something I found while Googling. I prefer the latter.

Update: To keep things interesting (via) –

  • Windows 10 build 1511 and older use v5 profiles. (These are builds 1507 and 1511 – aka Threshold 1 and Threshold 2).
  • Windows 10 build 1607 and newer use v6 profiles. (Build 1607 is also known as Redstone 1. The next one, build 1703 is known as Redstone 2, and so on).
  • Windows Server 2016 uses a v6 profile.

Roaming profile permissions and versions

Ever noticed that when you moved from Windows XP to Windows 7 the profile name as a .V2 appended to it? That’s because the profile format changed with Windows Vista and to avoid mistakenly loading the older profile format, Vista and upwards add a .V2 (version 2) to the profile folder name. This way a user can login to both XP and Vista/ 7 machines at the same time and the profiles won’t get mashed. 

Windows 8/ 8.1 changes the format again to version 3. This time, however, they don’t change the folder name. When a Windows 7 user logs in to a Windows 8/ 8.1 machine the profile format is upgraded in-place but the folder name is not changed. Later, if they log in to a Windows 7 machine there will be trouble. Workarounds include this one from a member of the AD team or using GPOs on the computers to redirect roaming profiles to different locations (the “Set roaming profile path for all users logging onto this computer” GPO setting). More information is available in this KB article which seems to be missing. 

Speaking of GPOs and roaming profiles, by default roaming profiles are configured with very minimal permissions. Only the Creator/ Owner and the Local System have full permissions to the roaming profile on the server. Administrators don’t have any permissions, including being able to see the existing permissions. There is a GPO setting which can be used to grant the Administrator group access to roaming profiles. This is a Computer policy, found under Computer Configuration > Policies > Administrative Templates > System > User Profiles and is called “Add the Administrator security group to roaming users profiles”. 

Once this policy is applied to computers, when a user logs in the computer adds the Administrator group to the ACL of the roaming profile. However, this policy has a catch in that it only takes effect on roaming profiles created after the policy was deployed. If a user has a roaming profile from before the policy was deployed, the Administrator group will not be added to it. Even if the user logs in to a new machine the Administrator group will not be added (because in effect the machine is downloading the existing profile and leaving things as they are). Of course, if you delete the roaming profile of an existing user so it’s recreated afresh then the Administrator group will be added. 

admin group gpo

 

The only way to assign access to the Administrator group in such cases is to take ownership of the user’s roaming profile add the Administrator group to its ACLs. Best to create a PowerShell script or a batch file and automate the whole thing.