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.

The Good

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.

The Bad

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.

The Ugly

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.

Conclusion

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.