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.
When setting up an environment, whether it be a new one or an existing one, a discussion needs to be held as to what profile type should be used to support end user and administrator requirements.
The Different Types of User Profiles:
There are numerous profile types, here are the 8 most common:
1) Local Profiles
Local profiles are created when a user logs into their computer for the first time. They are called local profiles because they are stored directly on the computer’s local hard disk on the computer desktop. Local profiles are ideal for laptop computers that will be used by one individual because changes made to the user profile are only stored to the computer where the changes occur.
Local profiles offer users the advantage of accessing their profile, even if the computer isn’t connected to the network. Users can sync when they connect but can work separate from the network. Additionally, local storage means there is no latency for retrieving profiles settings, making for a quick and easy login and logoff process. The main disadvantages are that settings and documents are only available on one computer and that users don’t back up their computers frequently, and can easily lose their data if the drive fails.
2) Roaming Profiles
Roaming profiles are the preferred profiles for networks because a copy of the local profile is stored to the server. This means users can easily access their profile from any computer in the network. When the user logs onto a computer, the roaming profile is downloaded at login, and any changes made under the roaming profile are stored and synced to the network when the user logs off.
One benefit of roaming profiles is that users don’t have to worry about creating separate profiles for every computer they use. Plus, automatic data syncing reduces the likelihood that users will lose data due to a computer drive failure. The main disadvantage of roaming profiles is network latency. Because data must be downloaded at login and saved to the server during logoff, the login and logoff process can take a while.
3) Mandatory Profiles
Mandatory profiles are used exclusively by system administrators to specify users’ settings and prevent users from saving changes to their profile. System admins are the only ones permitted to make changes to mandatory profiles and any changes made by the user to their desktop settings are lost once they log off.
Mandatory profiles are useful in circumstances where employees are not permitted to make changes to their computer and customize their settings. That means no custom wallpaper or screensavers. Mandatory profiles are similar to roaming profiles because the user profile is downloaded to the system at login. However, unlike roaming profiles, mandatory profiles are not copied back to the server at logoff, so users can’t make changes.
4) Super-Mandatory Profile
Both mandatory profiles and super-mandatory profiles are set by administrators to prevent user changes to the profile. Mandatory profiles allow users to log in even if the server is unavailable; however, super-mandatory profiles cannot log into the profile if the server is unavailable. This is because mandatory profiles store a locally cached copy of the profile while super-mandatory profiles do not.
5) Temporary Profiles
Temporary profiles are only available on computers running Windows 2000 or later. These profiles are issued to a user if the OS or default user profile fails to properly load. If these fail, the system automatically creates a temporary profile for the length of the user’s session, and it is deleted when the user logs off.
6) Guest Profiles
If you don’t have a user profile on your desktop or server you may be considered a guest user. Guest profiles are the same as temporary profiles and are issued to users who don’t have a profile of their own in the system. If you no longer want a guest profile, speak with your system administrator to see if you can get your own user profile so you no longer need to use a guest profile.
7) Flex Profiles
Flex profiles are different than roaming or mandatory profiles because instead of downloading all the applications in the profile at login, applications are downloaded when the user opens them. This makes for quicker login and logoff times as well as reduced latency for the profile. Flex profiles also have the advantage of allowing user desktops and applications to be available between multiple devices, which makes IT troubleshooting and upgrades easier.
8) Hybrid Profiles
Sometimes users have more than one user profile out of necessity. Keeping information synced between profiles is possible with hybrid profiles. This type of profile redirects users from their SharePoint Server profile to their Office 365 profile and allows users to keep all their information synced and in one place. Hybrid profiles are used in Office 365 and are available on SharePoint Server 2013 and 2016.
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.
FAQs Before Choosing Your User Profile Type:
There are a number of considerations to be decided on before choosing what profile type for your users:
- 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.
Profile Type Comparisons: Mandatory, Local, & Roaming
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.
What is a Super-Mandatory Profile?
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.
Mandatory Profile Storage & 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.
Mandatory Profile Versions
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 created for each profile version.
*Incompatibility between Windows 8.1 roaming user profiles and those in earlier versions of Windows
Methods of Creating Mandatory Profiles
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:
1) 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;
Benefits: 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.
Negatives: 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.
2) Upload the default profile from an endpoint to a network share and rename the ntuser.dat to ntuser.man.
Benefits: 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.
Negatives: 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.
At the end of the day it is down to your individual requirements for the environment.
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.
Application Compatibility - Mandatory Profile
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.