Mandatory Profiles – The Good, the Bad and the Ugly
This article is part of Helge’s Profile Toolkit, a set of posts explaining the knowledge and tools required to tame Windows user profiles.
A mandatory profile is a special type of roaming profile. As with a roaming profile, a mandatory profile is copied from its network location to the local machine during logon. But during logoff, changes are not copied back. Instead, the local copy of the mandatory profile is reset to its initial state at the next logon. In essence, mandatory profiles are read-only roaming profiles. This has advantages, but also severe drawbacks.
Since mandatory profiles are read-only, a single mandatory profile can be used for large groups of users. Storage requirements are minimal – a single mandatory profile is kept on the file servers instead of thousands of roaming profiles.
Users cannot mess with a mandatory profile. As soon as they log off and back on, everything is reset to its original, pristine state.
Because a mandatory profile can be used for large groups of users, very few mandatory profiles are needed. This makes manual customization possible. Adding a link here and changing a registry value there poses no problems at all. Compare this to thousands of roaming profiles – carefully fine tuning each profile is out of the question for the sheer amount of work involved.
Mandatory profiles must not contain user-specific data. That makes them very small. As a result, logons are fast since the amount of data that needs to be copied over the network is negligible.
With what has been written in the previous paragraph it might seem tempting to actually use mandatory profiles. Please read the rest of this article before doing that!
Everybody likes to customize his or her work environment in some way or another. These customizations are stored in the user profile – normally. With mandatory profiles, any changes are discarded upon logoff. If you do not want your users to hate you with all their heart you will have to set up a mechanism that extracts the changed bits from the profile before it is reset during the next logon. Such mechanisms tend to be complicated and often induce significant administrative overhead.
Mandatory profiles are difficult to create. Although the process looks pretty straightforward at first, it is hard to get exactly right. Do not underestimate the amount of tuning required.
If used on terminal servers, mandatory profiles pose a severe security issue. Of course, each user gets his own local copy of the mandatory profile. Windows takes care of setting the correct permissions on each local profile folder – but it does not alter the permissions in the mandatory profile’s registry hive (NTUSER.MAN). As a result, each user has full control to every other user’s part of the registry, opening up a whole avenue of privacy issues and even exploits. Staff associations / workers’ councils would love this (if they only knew). Especially their German incarnations, known as “Betriebsrat”, are not known to take such privacy issues lightly.
What is stored in a mandatory profile stays there for better or worse. Imagine the existence of a simple registry value would cause some unnerving message to appear after logon. After each logon. Would that seriously bother you? Me too. Such things exist en masse. Just think of the infamous Windows XP tour. Of course such annoyances can be removed by you, the admin. But that is time-consuming and error-prone. And even after thorough testing of a mandatory profile some bugs will remain. Some users will notice and call you. You then investigate the problem report, try to reproduce the issue, research a solution, implement it, get back to the user reporting the problem…
Certain things just do not work with mandatory profiles. The developers of Microsoft’s CryptoAPI may have deemed them insecure enough to simply disable major functions.
It should be obvious that mandatory profiles can only be used on kiosk-like systems. “Real” users want personalization and persistence.
“But wait”, you might say, “aren’t you the guy who co-developed sepagoPROFILE, a user profile management solution later sold to Citrix that was based on mandatory profiles?”. I am. And yes, sepagoPROFILE and the later Citrix User Profile Manager v1 did make use of mandatory profiles. But by now the product has evolved significantly. For the reasons discussed here (and some more) User Profile Manager does not rely on mandatory profiles any more. I see that as an important evolutionary step whose benefits may only truly be revealed in the future.
Hi, I enjoyed your notes about mandatory profiles and found it helpful. I would add to the list of “bad” parts of mandatory profiles: If you need to make a change later on, it can be very difficult to update. For example, when a Google update to their toolbar is processed on a computer, the Update Notifier window tells you about the update, and you click “OK” and it disappears. Except that, with a mandatory profile, those sorts of questions NEVER go away! You have to completely recreate the profile, you have to delete the Mandatory profile on the client (every single client!), and then the popup questiosn will stop. Very tedious!
If I never have a user logon to a desktop – meaning they only launch a single app off our Citrix server – wouldn\’t a mandatory profile be perfect? The app is a front end to a database, so all data is stored in the DB.
a mandatory profile might be perfect in your scenario if the application you are talking about does not store anything in the profile (either in the registry, HKCU, or in the file system) and if your users do not need general Windows settings like changing the mouse from right-hand to left hand.
Would there be any issues with auto-created printers in a mandatory profile? Each thin client has a printer connected to it that is auto-created.
As for settings, I’m checing with the vendor now. Thanks for the info!
I do not think that auto-created client printers would pose a problem when used with a mandatory profile (MP). A MP basically is a roaming profile that is not written back to the file server during logoff, but discarded instead. What should happen during logon is that the MP gets copied to the TS, after which XenApp creates the client printers and the environment is set up. So that should work.
Nevertheless, be sure to test the setup thoroughly and have the app “owner” test, too.
I am trying to setup a manditory profile and I am having some problems making it work. We run in a Server2003 Domain environment.
We want to use manditory profiles for our student labs. We don’t want them to change the desktop icons,backgrounds, or anything else. If they do find a way to change it, I want it reset after the machine is rebooted. (all labs log into a restricted account automatically.)
The problem I am running into is that the local copy doesnt seem to be going away at log off. So if a person changes the background, then logs off, and logs back on the changes they made are still there.
you should enable user environment debug logging to see what is going on.
Additionally, if some application or service is not properly closing its handles to elements inside the profile during logoff, install UPHClean.
i want to create a mandatory profile for Windows 7 which will be used by only one user (userABC)
in a Server 2008 R2-Domain.
Can i avoid the complicated creation of the profile as described here http://support.microsoft.com/kb/973289 (section: How to turn the default user profile into a mandatory user profile in Windows 7, Windows Vista, Windows Server 2008, and Windows Server 2008 R2) if i do the following?:
A. Create and customize a roaming profile for userABC.
B. Rename ntuser.dat to ntuser.man
C. Assign the appropriate share permissions for the mandatory profile
D. Only use this mandatory profile with userABC, so there won´t be any problems with
hardcoded usernames in HKCU, right? Because this seems to be the main problem…
Thanks for your suggestions
That should work.