RG01E – Dealing with Mandatory Profile Crap

By Max Ranzau


Sooner or later we all have to deal with them: Death, Taxes… and Mandatory Profiles :)

As more and more customers are starting to utilize User Settings (the technology formerly know as User Preferences) in Workspace Manager, mandatory profiles are comming into play more often. This has a certain deja-vú over it. This was the same thing we experienced back in the early Citrix days: All of a sudden we had to learn how to deal with all the horrors of unmanaged Roaming Profiles, simply because that’s what was needed when you had multiple Citrix servers in a farm. When Metaframe XP came along, many of us had to take a crash course in what SQLserver and ODBC was all about. Ring a bell for any of ya?

So, we’re now on the next rung on the evolutionary ladder of profiles. Hybrid profiles, Flex profiles, User Settings. Call ’em what you like; from the 30.000 ft perspective, it’s pretty much all the same. Base the user session on a mandatory profile, store the user stuff you want retained, then load the stuff back in, uppon login or applaunch somewhere else. That’s all nice and dandy, but amounts to squat if you can’t get the damned mandatory profile to work in the first place. That’s what this article is about.

When dealing with mandatory profiles within a RES environment, you may have come across the whitepaper describing how to Streamline User Settings in a Windows Environment. That document describes how you can create a mandatory profile, store it in custom resources, and configure some example Workspace Manager 2008 User Preferences on top of the whole thing. That’s fine and all, except if the Mandatory Profile keeps giving you grief. That will make a rainy day real fast, if you’re burning implementation time trying to troubleshoot basic MS profile problems instead of getting on with the fun stuff in Workspace Manager

Here’s a couple of examples of what you can run into, once you log on a user:


Usually this one will follow straight afterwards:


So, what to do? First things first, get a few assumptions in place.  Suppose you want to:

  • Use a mandatory profile. Doesn’t matter if it’s on SBC or workstation environments.
  • Store it locally on the target computers in order to reduce the profile-load impact on the network. This has the bonus of being usable on offline laptops too.
  • Create an environment variable to point to the mandatory profile.  This bit is actually rather important. It was not described in the mentioned streamlining document. Using a variable will let you use multiple mandatory profiles. This is very usefull if you have a mixed environment of terminal services, windows 7 and XP, for example.

With the above things in place, let’s dig in to what actually needs to be done:

  • First, you need to start with a fresh user account. Preferably create a brand new user you haven’t logged in with before to ensure maximum freshness. Never use your existing [admin] user account as it is very likely not to be representative of what a regular user would need. The user doesn’t need to be set up with a roaming profile. We will refer to the profile of this user as the template profile.
  • Now, log in with the template user and set up as many baseline settings as you can. Remenber whatever you configure in the session will be imprinted on your mandatory profile, so think lowest common denominator. Some good examples of this could be IE settings, citrix client settings or explorer view settings (you know; display, display display, don’t hide, don’t hide, etc). In general stuff you don’t want to waste time later googeling for, which should apply to most users. Don’t worry if there will be exceptions, that’s what you got Workspace Manager for! :) Finally, remember to clean up any unwanted files which MS stuffs in the profile per default. For example, you might want to get rid of all the, MS Links, Radio station guides, etc which are put in the profile as default.
  • Once you’re happy with the template profile, log out and back in with an admin user. Go to C:\Documents and Settings.
  • First take ownership of the template profile you’ve just doctored. At this time you also want to review the NTFS permissions.
    1. Remove the user, to which the user originally belonged.
    2. Add domain admins (or equivalent) with full control
    3. Add Domain Users or any specific group you want with Read & Execute.
  • That done,  it’s time to set the internal registry security on the NTUSER.DAT file in the profile. There are two ways of doing this. Either you can do it from My Computer|Properties|Advanced|User Profiles|Settings (yeah, I know the path may be different on Win7/Vista). The other way, which I personally prefer is to use regedit to set the security on the profile registry. It’s quite easy:
  1. Start regedit and go to the root of HKEY_USERS
  2. Go to the menu File|Load Hive. Browse to the NTUSER.DAT file in the template profile
  3. Regedit will prompt you for a key name, type anything within reason: Like temp for example
  4. Now rightclick on the newly created temp key, select Permissions
  5. Set permissions to Full Control for Everyone.  This will allow the profile to be used by anyone you assign it to. DO NOT exit regedit at this point!
  6. Click on the temp key again
  7. Go to the menu File|Unload Hive. Only at this point will the changes get saved and the NTuser.dat file released
  8. Rename the NTUSER.DAT to NTUSER.MAN . Remeber you can always load the .man file back into regedit if you need to make changes in the future.
  9. Finally if you’re on Vista or newer OS, you have the option to make the profile “super mandatory“. This essentially means refusing to log the user on if the profile is not available. Since we’re going to be storing the profile locally, there is little point to this as the profile always will be available. But just for reference, you make it supermandatory by adding “.man.v2” (withouth quotes) to the foldername – not to the ntuser.man!
  • Now you should have a mandatory profile which is applicable to whatever Windows OS you made it on. You might want to rename the folder to something logical, such as manprofile-<osname> or similar. This is usefull if you later will be storing multiple mandatory profiles side by side in the Workspace Manager custom ressources.
  • As mentioned before, there is good sense in adding a environment variable to point to the mandatory profile. To set this variable there are two important items to observe:
  1. The variable must be a system environment variable
  2. The target computer, where the mandatory profile is to be used and the variable is to be set, MUST be rebooted for the variable to work. I believe this is because winlogon.exe reads the environment variables when it’s initialized at boot.
  • The variable, call it manprofile, should point to where the mandatory profile is stored. If you are using RES Workspace Manager 2011 to deploy it, as outlined in chapter 9 in the mentioned streamlining document,  the profile is stored underneath %programfiles%\res software\workspace manager\data\dbcache\ressources\custom ressources\<the folder you stored it in>. Although you may recall there is a %rescustomresources% variable, which points to this path, please do NOT attempt to use this for filling in the value of the manprofile variable. The variable is used for in-session stuff, that may happen after the profile has loaded, and is first initialized when the Workspace Manager session is up and running. In short it’s not applicaple, don’t use it for this.
  • To ensure there is no problems with blank spaces, etc you may opt to use the 8.3 shortnames for the folders in the path. The value for the manprofile variable would then be c:\progra~1\respow~1\data\dbcache\resour~1\custom~1\<your folder> If you are in doubt what the shortname is for a particular folder, you can use dir /x to find out.
  • Note: From the Workspace Manager 2011 release the installation directory has changed to c:\program files\res software\workspace manager\. Also on x64 systems the install path will be different (i.e. Program Files (x86). In order to be prepared and on the safe side, it is suggested that you use the built-in system variable %RESPFDIR% which points to the main folder where the product is installed. The string you would put into your profile path would then be %RESPFDIR%\data\dbcache\resour~1\custom~1\<your folder>
  • Next on the agenda, we need to ensure that things are cleaned up nicely when a user logs out. More specifically, we want the users temporary copy of the mandatory profile to get blown away when the user logs out. This is a HKLM registry setting, which can also be set by policy. I am however going to presume you are using RES Wisdom for such, which is why the registry setting would be more important to you. To get the registry right, just copy the text below into a .reg file and merge it into the registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] “DeleteRoamingCache”=dword:00000001
  • Last,  we need to configure the user to to actually utilize the locally stored mandatory profile. This is quite easy:
  1. Open up the users properties in AD.
  2. Go to the Profile tab and insert the variable as %manprofile% in the Profile Path field
    • Take note that if you have a Citrix/TS environment in the same domain. When a user logs on to a terminal server, the WinLogon process there, will look at the Terminal Services Profile path first and use the value found here. If there is nothing specified in the terminal services profile in AS, the terminal server will use the value in the regular Profile as secondary choice. This is not a bad thing. Just remember to set the value of the %manprofile% on the citrix servers to a different path, to which you have distributed a mandatory profile for Terminal Services.


Further  reading

My good friend Iain Brighton has created some very useful articles in regards to Mandatory Profiles on his Virtual Engine blog. I would recommend you check them out here and here.

1 Comment

  • By Bas, June 9, 2010 @ 12:27

    Hi, you must change permissions on all subkeys of the registry, or else the user does not have permissions on the policies key’s. (inheritence is not enabled on this key) Furthermore if you copy the profile to the network, the local settings folder is also copied, that should not exist in the profile. If you want to have it in the profile you also have to set permissions on the class hive in these local settings folder.

Other Links to this Post

RSS feed for comments on this post. TrackBack URI

Leave a comment

Comments are welcome as always. Just do the math below. * Time limit is exhausted. Please reload the CAPTCHA.