Mandatory profiles are something that came in from NT4 or earlier. They are a great way of working around limits of the Windows profile model. If you have a few hundred users who don't need a customisable profile or to save profile settings, a man profile provides a great way of setting up users with one profile on the server that they can't change.
Essentially Windows has a certain mindset when it comes to profiles. Man profiles give you the ability not to have a local profile stored (saves disk space on the desktop), the ability to have a common profile for everyone (saves disk space on the server) and the ability to have a profile that the user can't change. For some users, individual profiles aren't really necessary. The way that Windows works with profiles makes it difficult to dispense with them completely on a network. The ideal would be a local profile on each machine that doesn't get saved, but this isn't supported. The man profile is what we get, and if we can live with its issues, it does a pretty good job.
The documentation for Windows suggests ambivalence towards man profiles. XP documentation suggests using policy lockdowns instead of man profiles, but the policy settings can't replace everything that a man profile can do. Man profiles are supported in Vista, but I haven't yet found out whether this is for backward compatibility or because MS has been listening better to customers' needs. There are some things for a user that can only be done in a profile, and other issues like the profile storage space requirement, synchronising roaming profiles, and upload bandwidth at logoff. As long as the profile model used in recent versions of Windows continues, man profiles will be justified.
There are some problems in use of man profiles. One of the most significant concerns per-user GPOs. If you have not got the profile set up properly, none of your GPOs will be applied. This is a big deal if you have lockdown policies in effect. There is no obvious reason, apart from setting the correct security permissions for the Everyone group, why this should be so. I've spent hours trying to figure out why a man profile wouldn't load GPOs, only to give up, create a new one and see it work.
Essentially Windows has a certain mindset when it comes to profiles. Man profiles give you the ability not to have a local profile stored (saves disk space on the desktop), the ability to have a common profile for everyone (saves disk space on the server) and the ability to have a profile that the user can't change. For some users, individual profiles aren't really necessary. The way that Windows works with profiles makes it difficult to dispense with them completely on a network. The ideal would be a local profile on each machine that doesn't get saved, but this isn't supported. The man profile is what we get, and if we can live with its issues, it does a pretty good job.
The documentation for Windows suggests ambivalence towards man profiles. XP documentation suggests using policy lockdowns instead of man profiles, but the policy settings can't replace everything that a man profile can do. Man profiles are supported in Vista, but I haven't yet found out whether this is for backward compatibility or because MS has been listening better to customers' needs. There are some things for a user that can only be done in a profile, and other issues like the profile storage space requirement, synchronising roaming profiles, and upload bandwidth at logoff. As long as the profile model used in recent versions of Windows continues, man profiles will be justified.
There are some problems in use of man profiles. One of the most significant concerns per-user GPOs. If you have not got the profile set up properly, none of your GPOs will be applied. This is a big deal if you have lockdown policies in effect. There is no obvious reason, apart from setting the correct security permissions for the Everyone group, why this should be so. I've spent hours trying to figure out why a man profile wouldn't load GPOs, only to give up, create a new one and see it work.
