While a mandatory based profile solution was the original approach (something we leveraged in the earliest releases), we are not going to return to that method. Let me explain why and get your thoughts and opinions on this.

One request that has been commonly voiced has been around a mandatory style implementation. While previously we had leveraged a mandatory profile as the base, for many reasons we moved away from that approach. One key reason was to save time that the merging process required (the copying of the mandatory down first and then copying of all the net changes). All in the spirit of logon speed. Another key reason is that it really was not a mandatory profile anymore. Profile management captured all the net changes from that base mandatory. So no settings were enforced or re-written at next logon. Basically it was a holder of starting settings when a profile was loaded. But the net changes were always re-applied over the base so nothing was ever enforced. So in the end, you needed to leverage Group Policy to enforce any permanent settings anyway.

It’s also been explained that having a mandatory approach enables customers without Group Policy delegation to have a means to control the profile settings. And mandatory by itself is a great solution albeit the limitations on the breadth of personalization – which the amount of personalization afforded by a mandatory solution is probably adequate for many scenarios. While you can redirect folders like My Documents, Favorites, Cookies and others, the ability to change anything registry related is prevented e.g. wallpapers, application configurations and such. But if you try to combine this with something like Profile management to enable those changes, how are you going to restrict what does not get saved? You would need to create an exclusion list of all the settings you want enforced (and thus excluded from being saved). Doable on a few settings but it will get unwieldy really fast. And I am willing to bet it’s going to be harder than Group Policy to manage before long. In the end, it seems capturing all the settings and using Group Policy to enforce setting as required is the way to go and thus the direction for our profile management solution.

Finally, let’s address the capability of having a base profile to start with. We do offer a template profile capability which you could think of as a Global Default User profile. When a user logs onto Windows and does not have an existing profile (be it local, mandatory, roaming or TS), Windows creates a new profile for that user based on the Default User profile located on that current machine. The fun of this is unless you want to sync all the Default User profiles across all the machines a user might likely log onto for the first time, the starting profile will different (although often only slightly) from user to user. Might not be a big deal initially or on smaller scales, but will be more problematic as your environment expands and grows.

The purpose of the template profile is to enable a consistence starting point for a new profile being created no matter the machine. The template profile can leverage a copy of the mandatory profile you use today but you just need to rename the NTUSER.MAN back to NTUSER.DAT (so no you can’t use the same one as both the template and a mandatory). And the template profile has to be complete (e.g. the entire directory structure and NTUSER.DAT). Also keep in mind that this is used for profile creation. So changing the template is fine, but only affects new profile being created and not existing ones. Need to change or enforce a setting for all users? Then we are back to using Group Policy for those situations.

So that is where we stand today with our Profile management feature (a feature of both XenApp (Enterprise and Platinum) and XenDesktop (Advanced, Enterprise and Platinum). Of course this is always open to debate and discussion if you have scenarios that illustrate weaknesses to this approach that Citrix should pay more attention to addressing.