Subscribe via Email

Subscribe via RSS/JSON


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan


Adding Registry keys to NTUSER.DAT for multiple users

A while ago I had pointed to a blog post I found wherein the author wrote a script to push registry keys to the NTUSER.DAT profile file of a large number of users. I wanted to try something similar in my own environment and while I didn’t go with the script I found I made up something quick and dirty of my own. I know it isn’t as thorough as the one from that blog post (so I’ll link to it again) but it serves my need. :)

So here’s the deal. I have a bunch of profiles located at “\\path\to\profiles\ctxprofiles$“. It has both v4 and v6 profiles. I’d only like to target the v4 profiles, and that too a specific user for testing. This user’s name contains the word “CtxTest” so I match against it. (Post testing I can remove the pipeline and target everyone).

All I do is get the list of folders, and for each of them load the NTUSER.DAT file from the correct location (it’s under a folder called UPM_Profile as I am using Citrix UPM). I just use the REG commands to load the registry hive, import a registry file, and unload the hive. Easy peasy. No error checking etc. so like I said it’s not as great a script as it can be.

[Aside] How to roam AppData\Local too

Came across this video from James Rankin. Apart from being an excellent video, it has one important thing which I felt I must note down here as a reference to myself. I always thought AppData\Local and AppData\LocalLow were not synced as part of your roaming profile because they were special in some way. Today I realized that there’s nothing special about them. They are not synced because of a key called ExcludeProfileDirs in HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. Any folder mentioned there is not synced as part of your roaming profile. Nice!

So to make AppData\Local roam, simply remove it from that registry key. Then selectively add any sub-folders you might want to exclude.

[Aside] Profile Manager NTUSER.DAT editing

I liked this blog post. That’s something I had thought of trying earlier when I was thinking about registry keys and applying them via GPP vs other methods. For now I am applying a huge bunch of my registry keys via the default profile and if there’s any subsequent changes then I’ll push the change out via GPP (for existing users) and also modify the default profile (for new users). But the geeky method the author followed of loading each user’s NTUSER.DAT and modifying the registry key directly is fun and something I had considered. Only catch though is that this has to be done during a period no users are logged in. Coz of this I don’t think I’ll be trying this in my environment but I liked the idea.

TIL: HKEY_USERS\.DEFAULT is not the default user profile

I knew this already but came across again from this script Q&A and thought its worth reminding myself: HKEY_USERS\.DEFAULT is not the default user profile (i.e. the profile used as the default settings for a user who logs in and does not have an existing profile).

HKEY_USERS \.DEFAULT is the profile for the LOCALSYSTEM account. It is an alias for HKEY_USERS\S-1-5-18.

The registry settings used as the default settings for a user who logs in and does not have an existing profile are at C:\Users\Default\ntuser.dat.

Also pointing to this blog post that explains this in more detail.

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.