Creating a mandatory profile on Windows 10 1803

Microsoft hate mandatory profiles, but they are useful. Here’s a guide to creation on Win10.

Note:- this article refers to the mandatory profile creation process on Windows 10 version 1803, fully patched as of 16/07/2018. Further servicing updates (Windows patches) or feature updates (OS upgrades) will possibly invalidate this, although I will strive to keep this article as up-to-date as humanly possible.

About mandatory profiles

Mandatory profiles (or their bigger brother, super-mandatory profiles) are a variant of the Windows roaming profile that many people still find useful. Changes to a mandatory profile are discarded at logoff, meaning that any modifications the user has made in-session are purged and the profile deleted. This is ideal for educational or kiosk scenarios where a default set of configuration items is required for every logon, or even for environments where people are using third-party profile solutions to hold user settings, such as Ivanti UWM or LiquidWare ProfileUnity.

Mandatory and super-mandatory

The difference between a mandatory and super-mandatory profile is very simple, the super-mandatory profile will prevent logon if the specified profile is unavailable. A standard mandatory profile allow the logon to continue if it cannot find the configured profile, and simply load a temporary profile instead. Configuring super-mandatory is essentially the same as configuring a mandatory profile and setting the “Log users off if roaming profile is unavailable” GPO. This is handy for ensuring users can’t sidestep any restrictions built into the profile by logging on with a temporary profile. To make a mandatory profile super-mandatory, you need to name the profile folder with a “.man” suffix, in the same way you rename the ntuser.dat file to ntuser.man.

Profile version suffixes

Of course, we don’t want to forget about profile version suffixes. XP and 2003 used “v1” profiles, whereas 7 and 2008/2008 R2 gave us the first version change as they moved to “v2” profiles. Later OSes originally used .v2 by default, but after Windows 8.1 they decided to implement strict versioning for all later implementations of the Windows operating system. You can convert profiles upstream (e.g. take a .v2 profile and make it .v6), but they will no longer be backwards compatible.

So let’s put in a table of what you would have to name your mandatory and super-mandatory profile folders on each OS version (assuming your folder structure was \\SERVER\SHARE\Profile). Remember, the OS appends the suffix to the folder name, there is NO NEED to change the name of the folder specified in AD on the user object, or in the GPO. (This also applies to standard roaming profiles as well)

Windows XP
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man

Windows 2003
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man

Windows Vista
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man

Windows Server 2008
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man

Windows 7
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE.v2
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man.v2

Windows 2008 R2
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE.v2
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man.v2

Windows 8
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE.v3
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man.v3

Windows 2012
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE.v3
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man.v3

Windows 8.1
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE.v4
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man.v4

Windows 2012 R2
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE.v4
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man.v4

Windows 10 RTM/1511
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE.v5
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man.v5

Windows 10 1607/1703/1709/1803
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE.v6
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man.v6

Windows Server 2016
Profile folder in AD or GPO – \\SERVER\SHARE\PROFILE
Actual mandatory profile folder – \\SERVER\SHARE\PROFILE.v6
Actual super-mandatory profile folder – \\SERVER\SHARE\PROFILE.man.v6

Storing mandatory profiles

Should you store them locally in the image, or on the network? The choice is yours, depending on whether you need to maintain access in the event of a network outage, and how easy you want any updates to be. I usually try and get the best of both worlds by having the mandatory profile in the image but updating it from a central file location using scripting, Group Policy Preferences or a tool like Ivanti UWM. Here’s an example of it being updated centrally and pushed out via UWM.

Deployment of mandatory profiles

Mandatory profiles can be defined on the user object in AD (on the Profile tab, RDS Profile tab or both of them, as required) or pushed via a Group Policy Object (for RDSH only). Bear in mind, though, that if you define the GPO it is a Computer setting, and will apply to all users logging on to the machine (including Administrators), so if you’ve over-restricted the base profile, test your admin access. I’ve also seen people deploy mandatory profiles in a more targeted fashion using scripts to modify the profile settings.

I know I already mentioned this in the previous section, but because so many people fall down on this point I will mention it again 🙂 The path to a mandatory or roaming profile is independent of the actual folder path. For instance, if we defined the path in AD or via GPO as C:\Users\MandatoryProfile, the OS would look for a folder unique to the OS as in the table above. This is because dependent on the operating system that the user logs on to, the “.vx” extension will be automatically added as required. So if a user had a mandatory profile path defined as C:\Users\MandatoryProfile, and they logged on to a Windows 7 machine, the operating system would actually look for the profile in C:\Users\MandatoryProfile.v2 rather than the specific path. This is very handy and means we can define a single mandatory profile path yet have multiple, OS-dependent profiles available.

Creating a mandatory profile

So, we’ve run through all of the considerations and given you a lovely table of OS profile versions, but what do we have to do to create a mandatory profile? Specifically, we’re going to talk about doing it on Windows 10 1803, but the instructions below should be valid in their most part for other operating systems as well.

Create the customized profile

The most time-consuming part needs to be done first 🙁 What you need to do is create a custom default profile as specified in this article. When creating the custom default profile, make sure you add all required user-level customizations into your default profile, because this is what we will convert into the mandatory profile. On Windows 10, you can’t convert anything other than the default profile into a mandatory profile (although you could copy and paste the underlying profile folder, but this way is technically unsupported, and make sure you grab all the hidden and system files too if you go this way). Personally, although it takes a bit of time and may involve spinning up an additional Windows 10 image (which you can just discard as soon as you’re finished), I would go this way – at least it means you know you’re not giving any support vendors a “get out of jail free” card.

Copy the profile to your profile store

When you’re finished all the steps from the previous article (including running the PowerShell scripts which tidy up the default profile!), log on to the machine that now has your custom default profile. Make sure you log on as an administrative user. At this point I like to make sure the device we’re using is fully patched, so ensure this is so. Next, open the Advanced section of System settings from Control Panel. (Easiest way to do this – press Windows-R for the Run command and type sysdm.cpl). Click on the Advanced tab, and click on Settings. You will see this dialog

Click on Default Profile so it is highlighted. The Copy To button will now become available. Click on it and another dialog box will open. Fill in the Copy profile to location with the folder you wish to store the mandatory profile in. Ensure the Mandatory checkbox is ticked. Click on Change under Permitted to use and type “Authenticated Users” into the Object field. The dialog box should now look like this

When you click OK, the folder you have specified as a destination will be created if it didn’t already exist. Also, if the user account does not have access to the destination folder you will get an error like this

Once you have resolved any access issues, click OK and the profile will be copied. What is odd is that there is no success dialog and the window for copying the profile remains open – once you’ve clicked OK and it has copied, you must then click Cancel to exit the dialog box.

Tidy up after 1803 bugs

The folder should now contain your copied default profile. Well, hopefully it should, but in some isolated instances I’ve seen it fail to copy some of the files, although not all, so we need to check on them. Make sure that your destination folder contains the ntuser.dat and ntuser.ini files. This is very annoying, when it happens – in 1709 there was a bug that wouldn’t work on network paths, now in 1803 we have a bug that sometimes fails to copy two of the (admittedly most important) files in the profile. If this happens to you – browse to c:\users\default and literally copy and paste them to the destination folder. (Thanks to Rich Thompson for helping verify this wasn’t something that happens every time!)

Set permissions on filesystem

Now that we’ve actually got the right files copied, we can check that the filesystem permissions are OK. The file copy will have added Authenticated Users with RX permissions, but we also need to make sure the All Application Packages user has access as well. Make the permissions on the root folder of your mandatory profile store as below, and set them to propagate. Also, make sure that the Administrators group owns the folder, and all subfolders. The pertinent settings are highlighted below.

Set permissions on Registry

Now we need to do the same for the Registry, but we need to be a little more careful here. Open the Registry file (ntuser.dat) from your mandatory profile folder by running regedit.exe, highlighting the HKEY_USERS hive, then clicking on File and choosing Load Hive. Browse to the folder where the mandatory profile is and select the ntuser.dat file (it is hidden, so make sure you are showing hidden files before running the Registry Editor).

Once you do this it will ask you to give the hive a name, simply type anything in as this will not be saved anywhere. The hive will now show as loaded under HKEY_USERS with the name you have given it. You can then right-click on the root of the hive and select Permissions. Modify it again so that it looks like this (this time we have given Authenticated Users Full Control, because the Registry is essentially a filesystem within a file that has its own ACLs).

When clicking OK, it is normal to see an error like this, as some of the subkeys cannot be accessed.

Now, one of the questions that always comes up here is, because Authenticated Users now have Full Control over the Registry in the mandatory profile, does that mean that a tech-savvy user could access the Registry of a user on the same system, or another? Well, firstly, the Registry as I said is a filesystem within a file, and the “file” outside of it is locked down on an NTFS basis. So really, a user shouldn’t be able to load or access the Registry of another user in any normal situation. But just in case there was an instance where they could, there are a couple of things you can do to mitigate this. Firstly. prevent the running of regedit.exe or cmd.exe/PowerShell.exe (because you can invoke Registry changes from the command prompt) for non-admin users via GPO, AppLocker or another tool. Secondly, maybe even run a script just after logon that resets the permissions on the current user’s Registry so that the entry for Authenticated Users is replaced by one for the user themselves. In a high-security environment this might be necessary, but for most normal operations the NTFS protection on the ntuser.dat file should suffice to prevent any unauthorized access.

Registry sanitization

Whilst we’ve got the Registry file “open”, we can remove stuff from the Registry that shouldn’t be there. Firstly, we can remove references to the user who the profile was created under, which if you used the default profile method will be “Administrator”. Remove all references to the Administrator username from the Registry hive (there is a Find command you can use for this in regedit). If you’ve used a domain account to create the mandatory profile, then also at this point search for any references to the SID of the user and remove them as well (psgetsid is ideal if you need to find the user SID).

You can also go through, if you wish, and delete any Registry keys or values that you deem unnecessary. Prime example of unnecessary keys would be any Policies keys – generally found in HKCU\Software and also in HKCU\Software\Microsoft\Windows\CurrentVersion.

You can also remove any other items from the Registry you think shouldn’t be there (you will be amazed at the references you find). HKCU\Software\AppDataLow is generally useless, as are references to the likes of Adobe and Google (how do they get there when I’ve no software from either installed?) Be careful, though, that you don’t break something by being over-exuberant (although I’ve been pretty brutal in the past, to be fair, and I’ve yet to cause an issue). You may find some keys (like Google, naming no names) have keys that are locked via permissions and you will need to take ownership of them and edit permissions to get rid of them. How far you go here is up to you – I’ve (in the past) gotten the ntuser.dat file down to about 256KB by being gung-ho, but don’t take that as a challenge, the Registry file sizes tend to grow as Windows moves on to newer versions 🙂

Once you’ve done all of this, don’t forget to unload the profile by clicking File | Unload Hive with the top-level key selected, otherwise you will lock the profile and no-one will be able to access it. This has happened to me in the past, so be warned, it’s easy to do!

Delete extraneous files

Once you’ve edited the Registry file you will notice a bunch of *.log* and *.blf files in the folder where your profile is stored. Just delete these.

Rename the dat file

Now, to truly make this “mandatory” rename the ntuser.dat file to ntuser.man. If you’re going super-mandatory, rename the holding folder to one with a .man.vx suffix (if you hadn’t already).

Check Group Policy

Check that you have got the Group Policy Object configured for Computer Config | Admin Templates | Windows Components | App Package Deployment | Allow deployment operations in special profiles set to Enabled. If you have UWP apps in your image, without this GPO set it cannot deploy them into special (roaming/mandatory/super-mandatory) profile types and you will end up with a broken Start Menu.

Deploy

The final step is to populate the user’s Profile or Remote Desktop Services Profile field in ADUC with the path to the mandatory profile (minus the suffix, remember!) If you’re using RDSH and you want to use the GPO method, populate the path into the GPOs for mandatory profiles (found in Computer Config | Policies | Admin Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Profiles | Use mandatory profiles on the RD Session Host server and Set path for Remote Desktop Services Roaming User Profile).

Now log in as a (different) test user and see if you get the mandatory profile loaded (you can check the profile type from the sysdm.cpl applet or Registry, or simply see if the user profile changes persist between logons).

Troubleshooting

If you’ve followed everything in this article, you should hopefully have no issues. Adding the All Application Packages to the ACL for filesystem and Registry and making sure the GPO for deployment operations is set are the two biggest mistakes people make. Check that the User Profile Service is running and that you can access the location where the profile is stored, be it local or networked.

If you do get issues, especially if logon fails, then checking the event log is paramount. The User Profile Service logs any errors here and you should be able to figure them out from the details here.

Summary

For those of us who still use mandatory profiles (and there are more of them than anyone would think), using this guide should help you avoid the pitfalls you may well encounter on Windows 10 version 1803. I will try and record a video to go along with this, as well as possibly keep it updated for newer Windows 10 versions.