HOWTO and Best Practices creating a Windows 2008 R2 Mandatory profile

This articles shows HOWTO create a mandatory profile for Windows 2008 R2 and some best practices afterwards.

There’s a Microsoft KB Article “How to customize the default local user profile when you prepare an image of Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2″ (KB973289) available, which is ofcourse recommended to follow.

Below a description of a step-by-step method how to create a Mandatory Profile for Windows 2008 R2.

1.) Make a local user on the server (Windows Server 2008 R2 in my environment)
2.) Make the user member of the local administrators group on your server
3.) Login in with this user and customize for example the start menu
4.) Logoff and login again with an administrator account
5.) Create a share on your file server. For example \\SRV-RDSDC-01\TSmandatory
6.) For share permissions choose Everyone Full Control, NTFS permissions choose Authenticated Users Read
7.) Turn off Caching on this share
8.) Copy the complete template folder from the C:\Users directory to the new TSmandatory share
9.) Rename the template folder to TSmandatory.V2
You have to add the .V2 in the name of your folder, because it’s the new profile type in Windows Server 2008 and 2008 R2!
10.) Delete the Local and LocalLow folders from the AppData folder
11.) The next step is to add the right permissions on the mandatory profile
12.) Open REGEDIT and load the NTUSER.DAT hive
13.) Right-click on the TS Mandatory profile and choose permissions
14.) Delete the template user and add the Authenticated Users (Full Control)
15.) Unload the NTUSER.DAT from your registry
16.) Rename the NTUSER.DAT to NTUSER.MAN
17.) When you configure a GPO to specify the location of the Mandatory profile, you’ve to choose to following location:
\\SRV-RDSDC-01\TSmandatory\TSmandatory without the .V2!

Best Practices
There are a number of different ways that you can capture a profile that you want to subsequently use as a mandatory profile. My preferred approach is to logon as a non-administrative test user, run whatever applications are needed and configure as appropriate, logoff and then take the resulting ntuser.dat, obviously renamed to ntuser.man, as the mandatory profile’s registry hive. I generally do not have any folders in the folder specified for the mandatory profile – it just contains the ntuser.man file and nothing else. *** Update:  However, on Vista, Win7 and WS08, the empty folder AppData\Roaming does need to be created. In addition, if none of the folders that by default are used for items such as “My Pictures” and “My Music” exist in the base profile, these special folders will not be available to the user who is assigned this mandatory profile. However, it is strongly recommended that folder redirection is used to provide these special folders, if required, rather than using the defaults provided in the locally cached profile folder hierarchy. ***

Once the ntuser.man file has been copied away, I load it as a hive in regedit and then check various elements of it; namely:

1. Security – the Access Control Entries (ACEs) for the user used to generate the profile should be removed and an Everyone – Full Control ACE added in its place. It is not actually ideal to open up security to this extent but since we don’t know what user is going to use the profile, we cannot lock it down much further although it could be done with a tool such as subinacl.exe [http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b] at logon. For VDI environments, which are necessarily single user, it probably doesn’t matter but for Terminal Services, it means that a user with access to HKEY_USERS through regedit or other tools/scripts/macros can read and write/delete any other logged on user’s registry settings.
2. Search the hive for the username of the user used to generate the hive and delete/replace the values as appropriate.  Note that there is no guarantee that changing a REG_SZ value to a REG_EXPAND_SZ and using “%Username%” or “%UserProfile%” in place of the actual username or locally cached profile folder respectively will work since it is up to the application that reads the value to implement environment variable expansion. Don’t be tempted to delete a whole key unless you are prepared to test that no ill effects occur. For instance, deleting the key “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders”, because it contains values with the path to the generating user’s locally cached profile folder, will cause problems at logon whereas deleting all of the values in the key, but not the key itself, does not cause issues.
3. Delete all policy registry keys such as “HKCU\Software\Microsoft\Windows\CurrentVersion\Policies” and “HKCU\Software\Policies” (unless of course you want to apply GPO like lockdown this way but it can cause confusion).
4. Strip out anything that you do not want – the best mandatory profiles are generally the simplest. There is, unfortunately, no easy way of deciding what should be stripped out. I tend to focus on Most Recently Used (MRU) lists such as those for opened documents, searches, runs and so on. The benefit of starting with the default user profile rather than a “contaminated” user profile is that this step, generally, is not required.
5. Check all autorun locations, such as “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” and “RunOnce”. It is usually best to have nothing in these keys and have things run at logon via other means.
6. Set application defaults, such as disabling splash screens, either by running the application and configuring it or by directly editing the registry if you know what keys/values need setting.

Once you have unloaded the hive and quit regedit, delete all .log and similar files that may have been created when the hive was loaded. Also check that the folder containing the ntuser.man file and the file itself are owned by the local administrators group and have no write/delete access for non-administrators. This is particularly important if the mandatory profile will be local to the system it is used on rather than through a share since share level permissions can also help protect the hive from accidental or deliberate damage.