Profile Series - Mandatory Profile Gotchas
*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.
There are numerous profile types, the most common are:
- Super Mandatory
Today I’m going to cover some of the differences between local, roaming, and mandatory profiles, as well as items that need to be considered when choosing a mandatory profile type for your environment.
There are a number of considerations to be decided on:
- What is the endpoint type?
- Are the profiles needed whilst the endpoint is offline?
- What applications are in use on the endpoint?
- Do I need to secure user data that could be stored in the user profile?
These questions are just some of the items that need to be considered BEFORE choosing the profile type.
The answers to these questions will help you make the decision as to which profile type should be chosen for the environment you are building. It may even be decided that multiple profile types are necessary to support the environment.
There are no right or wrong answers as to which profile type is correct for an environment, but the limitations of the different profile types need to be accounted for.
Some of the benefits/limitations of the profile types are listed below. The list below is not exhaustive nor is it a “catch all” for assumptions.
By default, the list above is correct. However, this does not mean that the limitations of each profile type can't be worked around.
The examples below provide an idea of what I mean and can be argued in many ways:
- Local [Consistent look and feel]
- Options can be locked down via Group Policy to prevent users from changing how the logon session looks.
- Roaming [Reduced logon times]
- Use Group Policy to only synchronize (roam) certain sets of data or cache the profile locally
- Mandatory [Stores user data]
- Redirect user data to a network share to save the user data
One of the biggest areas for concern though is the application compatibility, especially where mandatory profiles are concerned.
This article is not going to discuss how to create a mandatory profile, as there are plenty of articles already available out there. What I am going to discuss are some things to remember when considering them for your environment and when creating them, along with some tips when setting them up.
Mandatory profiles can be your best friend one minute and your worst enemy the next. One of the problems with them can be encountered in the very first phase of profile consideration.
Mandatory Profile Types
What sort of mandatory profile do I want to use?
There are two types of mandatory profiles, a basic mandatory profile and a super-mandatory profile. A mandatory profile is created by simply renaming the ntuser.dat file in the user profile to ntuser.man… Job done. A mandatory profile simply means that any change in settings that the user makes to the profile during the session will be lost at log off.
A super-mandatory profile has the same advantages/disadvantages of a regular mandatory profile but users are unable to log on to an endpoint should the profile path become unavailable.
For more information about mandatory user profiles please refer to the MSDN article on the topic.
Storage and Accessibility
During your mandatory profile design the save store location will need to be considered, Local or Network. Depending on your chosen location there will be some administration overhead that need to be understood.
If the mandatory profile is to be stored on the network then it will not be available should the endpoint not be connected to the network and will instead be presented with a temporary profile. In the case of a super-mandatory profile, a user will not be able to log on at all. The upside of this is that any changes that need to be made to the profile will be swift.
Should local storage be chosen for the mandatory profile then the issue surrounding offline usage is removed. However, this does then bring its own challenge in that if you need to update the profile then the changes will need to be rolled out to all locations instead of a single and central network profile.
You could lower this risk by using a script to copy the Mandatory profiles from a network location to the local storage on the endpoint at boot time for example.
Once you have decided on this you then have another decision to make… Where is the user going to log on to with a mandatory profile? If the user is to log on to multiple endpoints where a mandatory profile is going to be used AND the Operating System profile version is not consistent then you will need a mandatory profile creating for each profile version.
Method of Profile Creation
Still with me? We are not at the end of the decision chain. Now we need to decide on how we go about creating the profile. Should we:
- Create the mandatory profile by logging on, set the profile up, launch applications, log off, map ntuser.dat, sanitize ntuser.dat, unload ntuser.dat, upload to network share and then rename to ntuser.man; OR
- Upload the default profile from an endpoint to a network share and rename the ntuser.dat to ntuser.man.
Although the second choice may seem like the easier of the two options, there are still a number of considerations. How do I manage the applications that do not use the TSShadow key or utilize Active Setup to configure the application? You may need to use logon scripts that write/import settings to the file system and/or registry in order to allow them to work correctly.
The benefit of option B is that Active Setup will run every time and ensure that the applications are set up as expected and allow better compatibility. I have seen a number of issues in the past where if Active Setup does not run, Internet Explorer can then function incorrectly until you execute the ie4uinit.exe application.
Another downside to option B is that you will see the grey, Active Setup option during logon for any applications that have not been applied to the profile and may slow the logon down until completion.
The benefit of option A is that Active Setup will already have been run so the logon time will be reduced between endpoints with similar applications and operating systems.
The downside of option A is the time taken and margin of error for initially configuring the profile. A further downside is that the user session may appear less out-of-box.
At the end of the day it is down to your individual requirements for the environment.
The next gotcha you may encounter is application compatibility. There are a number of applications out there that simply do not work with a mandatory profile. Microsoft Lync is one of these.
One of the reasons for this is due to the fact that with a mandatory profile, Windows does not allow the import of certificates into the user Certificate Store. This can be a show-stopper for mandatory profiles in certain environments where these applications are deemed mission critical.
However, as with most things Windows, it is possible to work around the issue. One workaround is to use a script to spoof the profile type so that it appears to the application as being a different profile type. To change this, you will need to update the State value in the user SID key in the following registry location:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Setting the value to 0 [zero] will spoof Windows and other applications in to believing that the profile is actually a local profile. Below is a table describing some of the possible values of the State registry value.
As with all things computers, there are so many options out there to ensure that your environment is tailored to your exact requirements, whether it be a new virtual desktop solution, physical desktop rollout, operating system upgrade, or for a mobile workforce solution. Choosing the right profile type during the design phase is crucial to your success.
In my years in IT I have seen numerous projects and environments not fully meet requirements due to simple steps in the design phase being missed. Profiles are often one of them items that are easily overlooked, which then brings challenges in management afterwards.
Retro-fitting a different profile into an environment once live then starts to become a headache and are then pushed to one side as it will generate a large workload in migrating user data and testing to ensure that the solution is then fit for purpose.
I am an advocate of mandatory profiles and have implemented them in multiple organizations as they ensure a consistent user experience between your user base and environments. When used in conjunction with policies and scripts there is little that can’t be accomplished.
Another great use case for mandatory profiles where I have implemented them in the past are environments with a high staff turnover, such as call centers, as they have an extremely low disk space footprint, fast loading and no profile management required. If a user changes a setting they don’t like, log off and then back on they are back to where they started.
There are limitations of mandatory profiles such as saving of user settings, but all profile types have their own issues and, as long as you are aware of them during your design phase, there is little that cannot be achieved or worked around.
Most of the gotchas and benefits of using mandatory profiles can be worked around and improved on with the use of AppSense Environment Manager [EM] by utilizing the policy and personalization feature sets.
I hope this article has been an interesting read and helps with your profile type decisions for your environment. Look out for future articles where I shall be discussing roaming and local profiles and how we can use EM to help your profile implementations.