Creating a mandatory profile

This blog will show you how to set up a mandatory profile and how to use it with a UEM product like RES Software of Liquidware Labs Profile Unity.
There are more blog like this, personally I like the blog from Robin Hobo a lot, so here that link.
I decided to create my own blog article for I wanted to point out some specific things and show how we integrate with RES Workspace Manager. Can’t show Profile Unity right now, my lab is to crowded with machines running to prepare for VCAP-DTA.


First a quick intro for them that are not into profiles…
There are three profile types (in general), Local, Roaming and Mandatory. 
We started out with local and evolved into roaming mid 90’s to solve the issue of working on different computers. Working with roaming brought a lot of issues for the get corrupt and all you can do is clean up and start over. Also with roaming it will grow, every day your profile will grow with stuff you don’t need.
So roaming is something you better stay away from.
To fix roaming we got mandatory, like it says it’s mandatory. You can’t change it, it doesn’t grow, doesn’t collect useless crap, it just stays like it is. 
From a management point of view that’s great, from a user point of view it’s crap because settings are not saved and need to be set everyday. 
So the next evolutionary step was User Environment Management. Controller what is being saved in the profile by taking it out and putting it back in when needed.
Great from a management point of view and great from a user perspective… best of both worlds (when set up the right way).
So that’s our starting point, a mandatory profile combined with UEM. Now let’s see how we get there.

Create a Mandatory profile

Like mentioned before, Robin’s blog handles this fine…I’m gonna do a little bit different because I can 🙂
There are a few step in the process
  • Create a template user without administrative rights;
  • Create a folder where to store the mandatory profile;
  • Clean up the profile;
  • Replace the template username with %username%;
  • Set permissions;
  • Load up the profile in UEM or point UEM to use the profile;

Create a template user

First we have to create a template user on the platform you are deploying the profile on. 

It’s just a simple user with nothing else to it, don’t add the user to administrative group just make it a basic user.

Create a folder

On the Domain Controller I create a folder to store the profile, this can be any server of course but in my lab my DC is a mix of things.
I created a folder name Profile and set security permissions as it would be used as a regular mandatory profile. In my case it won’t be used like that but hey in my lab you never know, better be safe than sorry.
Authenticated users – Read&Execute
System – Full Control
Administrators – Full Control

Sharing permissions are set to;

Authenticated user – Read&Execute
Domain admins – Full Control

Set up the desktop 

Now log on to the desktop and setup the desktop like you would like it to be… system tray icons that you want to disable etc etc. 
When you use either Profile Unity from Liquidware Labs or RES Workspace Manager you can do a lot of settings from there. If you want flexibility think about what you can do from there and what needs to be in the profile.  When you’re done, log off and log on as an Administrator.

Copy the profile

Log on with a domain administrator so you have enough rights to copy the profile to a central location.
The profile is located in C:Users and called after the user you just created. Here it is called Mandatory.
Copy the directory van paste it in the share you just created.

As you see it’s still pretty large but we’ll fix that in a minute.

Prepare the profile

As mentioned before the profile is kinda large when you copy it, so we have to clean it up and prepare it so you can use it for your users. If we open the profile folder and browse to AppData you will notice that there are three folders, Local, LocalLow and Roaming. Looking at local and locallow they make up 54MB of the 57MB profile. We don’t need those folders, they will be recreated locally when the user logs on. 
Delete both folders from the profile, not the profile size is down to 2,58MB already… 
Go through all folders and remove anything you find unwanted, like web slice gallery links under favorites or the file under contacts.
After you’re done with the cleaning it’s time to load the profile into the registry.
Start Regedit and browse to HKEY_Local_Machine. Go to File and click on “Load hive”
Browse to the profile location and select NTUSER.DAT click ok to load the hive.

You will be asked for a name, any name will do there.

…and the profile is loaded in the registry…now you can edit certain registry keys if necessary.
One thing we need to do is to change the username “Mandatory” in the profile to the variable %Username% so that the profile will work without issues.

Changing the profile can be done in two ways, either searching through the registry and changing the name manually to %username% or export the hive to a REG file and search and replace. The last option is tempting for it saves time but make sure you have a very unique name for the username otherwise you might break stuff.
I’m gonna do it manually for I chose a to common name and mandatory might be used also for different things instead of just the username.
One example to get you going… search for the name Mandatory and when if finds one change it to %Username% like in the screenshot below.

Copy %username% so that you don’t have to type it every time and don’t make a typo anywhere… 
depending on what you started while creating the profile you get more or less hits. Don’t start to much in the creating phase, try to make the profile as basic as possible.
At one point in the search you will come to Shell Folders. Shell folder needs some attention, we don’t just rename the name there we remove stuff. 
I highlighted all entries that have to be removed, the only things left are Default, !Do Not Use and Fonts.

After you’re finished this is what is left of Shell Folders.

To make sure active setup will recreate the entries you have to delete the following key

Method number II

After searching the whole registry I noticed that Mandatory isn’t that common so I might give it a try with my alternative method. After I loaded the hive and created an export of the loaded hive, it creates a profile.reg file.

I did a search and replace for Mandatory to %Username%. After it was finished I saved the reg file and double clicked it to load it in regedit. Now when I do a search I get 0 results, so all the entries have been replace. The only thin to do manually after this is the shell folder action.
Don’t know if it saves that much work but it was on my mind yesterday that why I had to test.


At the end of your search we have to set the permissions cause if you don’t you end up with this error which I blogged about earlier here,

Click on the loaded hive to get the context menu and choose permissions.

As you can see there is an Account Unknown there and no authenticated user is allowed to load this file.
We need to make sure that authenticated user can load the file.

First we remove the Account Unknown and the Administrators and then we add Authenticated Users to the list. Authenticated User are given Full Control here.

Click OK when you’re done and let’s move on to unloading the profile, we’re at 98%.
Click on the profile (make sure you click on the profile!!!!!!) and go to File/Unload hive.
You will get a warning and when you confirm the profile will be unloaded.
Two more thing have to be done before the profile is ready for a non-UEM controlled environment.
First we go to the profile folder and rename the NTUSER.DAT to NTUSER.MAN to make it mandatory.
Clean up a bit and rename.
The folder will look like this at that point, now we go one step higher because we have to change the folder name to make it a V2 profile folder.
Just make sure that you add .V2 to the folder name, Windows like this.
If you would have a default environment without RES Workspace Manager you could now point your user profile location to this location.

Group policy

Open Group policy management on one of your domain controllers and select the GPO that you use to set the profile folder. Edit the GPO and browse to Computer Configuration/Policies/Administrative Templates/System/User Profiles or  Computer Configuration/Policies/Administrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostProfiles.
Edit the setting “Set Roaming profile path for all users logging onto this computer”.
Add the path to the profile here but don’t add the .V2 to it.
There are some other options you can set, like delete cached profiles e.g. but that all up to you environment.
With Liquidware Labs Profile Unity you now be setting up a user environment. with RES Workspace Manager you can do it this way but I use a different approach like I think many do.

RES Workspace Manager

RES WM has a direct connection to the agent, like a tunnel that is open all the time. We can use that tunnel to send stuff to the agent. The agent in this matter is a desktop, a laptop, a VDI desktop or a RDS/XenApp server for all we care.
One of the issues users had with profiles was the time it would take to load them. In times when the network speed was rather poor it could takes ages to load your profile.
What if we would load it locally and therefore make sure we have nothing to do with the network.. that should save time, shouldn’t it?
Let me show you how this is done.
In the management console of RES WM we go to Administration/Custom Resources. Custom resources is the entry to the tunnel that leads to the agent.

 Click on “New” and browse to the Mandatory.V2 folder created and filled earlier. Don’t double click here but click OK. This will copy the whole folder into custom resources.

As you can see the complete profile is now loaded in custom resources.
When we look at the client side of things, the end of the tunnel we see in the picture below that the profile has arrived. Everything you punt in custom resources is copied instantly to the agent… if the agent is available of course.

This location is available through the variable %RESPFDIR%DataDBCacheResourcesCustom_Resources
This can be used in the GPO where you addressed the user profile, the location of the profile would be 
Again mind the fact that you don’t add the .V2.
Now when users log on to a RES WM managed desktop they will have the profile loaded for the local location and therefore save time loading the profile.

Editing the profile

A small piece about editing the profile. If you need to edit the profile, to add a registry entry that you can’t or won’t to edit by any other means, you need to load the NTUSER.MAN in regedit again. Edit the key and unload the hive, it’s pretty straight forward if you know it.
However when using RES WM there is another step to be taken, the profile RES is deploying is not located in the profile share, It’s located within RES.
So after you changed things in the profile and unloaded the file you need to replace this file in RES customer resources to make sure it will get distributed to the agents. If you don’t do that nothing will change.


In rare occasions we noticed that we had issues with the %RESPFDIR%DataDBCacheResourcesCustom_ResourcesMandatory folder, the security permissions were wrong. It hasn’t happened often but I’m mentioning it so that you are prepared if it does. If the user doesn’t have enough rights on that folder the profile won’t load…


I hope this blog helps you create a mandatory profile perhaps in combination with Liquidware Labs Profile Unity or RES Workspace Manager. 

3 thought on “Creating a mandatory profile”
  1. Hi Rob, Does this also work with Server 2016 with RES? We are getting the error:
    The user profile service service failed the sign-in. User profile cannot be loaded.

    The User profile Service is started.


    1. That to me sounds like another blog I wrote about Microsoft account sign in service that is enabled by default..
      might that be the case?

      ..and why not look at a UEM solution and let Windows just handle a local profile, less stress and more flexibility.

  2. That is also a possibility but then we need to run a logoff script wich makes the profile from local to roaming. User profiles have to be removed at logoff.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.