Wilco van Bragt - LinkeIn Wilco van Bragt - Twitter rssa 

The Alternatives for Mandatory Profiles

Within Server Based Computing environments using Roaming Profiles are a real challenge (see for more information about these challenges in this previous article written by me). However we would like to store/save the user settings for our end users to get a good user experience.  For many years the solution was to create a mandatory profile combined with a hybrid/flex solution product like Flex Profiles, AppSense Management Suite, RES PowerFuse  Workspace Management, Citrix Profile Management  and several others.

During all these implementations nobody doubted on the flex/hybrid profile solutions, but using the mandatory profile has some disadvantages founded out during those years. Think of security issues, using certificates and creating the perfect mandatory profile. Helge Klein wrote several good articles and presentations about this topic like this article about the security risk and this article describing the downsides of mandatory profiles. Personally I also struggled with mandatory profiles in some implementations, so I searched for another solution without falling back to a Roaming Default.




The starting point of the search for alternatives was that user settings should be retained and that a profile management product will be used for that and that the profile should not be copied from/to a central location to/from a local and that the solution should be applied to RDS Session Host, VDI solutions and local workstations. It turned out that there is still no perfect solution, but there are some alternative available for replacing the mandatory profile.

 

Prevent Roaming Profile changes from propagating tot the server

This is a GPO setting available from Windows XP/2003 that arranges when a roaming profile path is configured within GPOs or AD properties the changes made during the day will not be written to the defined roaming profile path. With this possibility the profile management product is responsible for saving and restoring the user data, while the profile settings are not copied during log off. However by default the (standard) profile will be copied to the local disk when the user logs on. This can be solved by creating a standard profile on the local disk and pointing to that profile as the roaming profile directory (again via AD properties or GPOs). However you need to give all authenticated user rights to that standard profile directory, just as with the mandatory profile. This introduces the same security risk as the mandatory profile.  So if that is the reason there are two other ways to accomplish this

  • Create a profile directory per user (on a network share) and during creation of the user copy the standard profile to that user profile directory. Logically the (small[er]) profile will be copied from that location to the local disk during start-up.
  • Alter the Default User profile on every machine to match your default settings. You should arrange a solution that you can manage the configuration by copying the configuration to the default user profile locally from a central location. Logically the configured roaming profile location should be empty.

Image

When using this GPO setting the profile will be shown as Read Only in the profile properties locally on the machine. I found out at one of my customers that this has a side effect on using certificates (and possible more settings). In this case the customer has an application that is using a certificate, but instead of importing the certificate in the personally certificate store it directly access the certificate from a network share. The process of reading this certificate fails when using the Read Only profile. Changing the profile to Roaming of Local (the next alternative) arranges that the process was working again. So keep this in mind.

Local Profiles

The second alternative is the "old" local profile. This one came in my mind when I was struggling the issue with the certificate stored on a file share. While troubleshooting that issue it was working fine for my administrator account that had no profile defined. Creating a test user also with no profile defined gave the effect that the option in the application was functioning, while all his settings were available at the user profile management product the customer is using. Discussing this it was a real good alternative because it offers some advantages. It requires less configuration (no GPO or AD settings), but you need to arrange that the default user profile on every machine is configured according to the needs. We arranged that by copying a standard defined profile to the default user profile (in these case it were workstations) when the machine is started up.

Conclusion

Still after all these years there is no perfect solution for managing and configuring user profiles. The Prevent Roaming Profiles can have the same security risks as the mandatory profile or will have a copy transaction during logon of the users or change the default user profile on the local disk accordingly. There is also the possibility that some functions does not work, like the example of one of my customers. The local profile also have the requirement that the default profile should be altered (and managed), but does not require many other configuration settings. Because a local profile is used on almost every personal machine all application will function. Remember that just with the mandatory profile solution a profile management product is required and indispensable.