Profile design for Citrix implementations has been a hotly contested debate for some time. Citrix consultants usually find themselves walking into a customer environment that was set up years before, and having to troubleshoot the current environment. Because we often have no control over what the current Citrix farm is using for profiles, I’ve devised a troubleshooting process that seems to work well for Citrix profiles, which I’ll include in a later blog, but for now I want to cover Citrix profile design.
According to Citrix, In a XenApp environment, Terminal Server profiles behave as follows:
|Local Profiles||Local profiles are stored on each farm server and are initially created based on the default user profile. A user accessing applications in a load-managed XenApp farm creates an independent profile on each server. Users can save changes to their local profile on each individual server, but changes are only available to future sessions on that server. Local profiles require no configuration; if a user logging onto a XenApp server does not have a profile path specified, a local profile is used.Although local profiles are the default, Citrix does not recommend using them because profiles are created for each user on every server to which they have connected, which leads to an inconsistent user experience.|
|Roaming Profiles||Roaming profiles are stored in a central location for each user. The information in roaming profiles, such as a printer or a registry setting, is available to all XenApp servers in the environment. To configure a user for a roaming profile, you specify the user’s Terminal Server Profile Path to a particular location on a file server. The first time the user logs on to a XenApp server, the default user profile is used to create the user’s roaming profile. During logoff, the profile is copied to the specified location on a file server.|
|Mandatory Profiles||Mandatory profiles are stored in a central location for each user. However, the user’s changes are not retained on logoff. To configure a user for a mandatory profile, you create a mandatory profile file (NTUSER.MAN) from an existing roaming or local profile, and assign the users’ Terminal Services profile path to the location where the file can be accessed.Citrix recommends, where feasible, using mandatory profiles if they address the defined requirements.|
|Multiple Profiles||Multiple profiles combine two or more of the profile types (local, roaming, or mandatory) for the same user. Multiple profiles are useful in environments with load-managed groups or application silos. For example, in a XenApp farm with two load-managed groups serving SAP and Microsoft Office, you can configure users with a mandatory profile for the SAP servers and a roaming profile for the Microsoft Office servers. Multiple profiles are also useful for farms that span WAN connections, so that profiles can be accessed from local file servers.Multiple profiles are more complex to administer and maintain and are not widely used.|
Depending on the profile that you are using, you could run into a range of different issues. Let’s examine some of each that I’ve seen most often:
Citrix exams will tell you that local profiles are the most low maint easy profile solution you can roll out to your users. While this may be true on the admin side, your Citrix user base might disagree. With local profiles, we often see users calling the help desk because their desktop icons or customized settings have seemingly disappeared. If you are publishing desktops, for example, the user might log in to find a document they had saved to their desktop the week before completely missing. This is the result of having a desktop published across multiple Citrix servers, and the user having their local profile saved on a single server. The result is that depending on which Citrix server the client logs into, they may get a different profile each time. Clients in this type of environment should understand that they can’t depend on anything saved locally to the profile, and that they must save all important data and customizations to their private sharedrive.
Still a popular solution for many Citrix healthcare clients, roaming profiles never seem to die. While they may initially seem to work flawlessly, as they grow in size over the years a Citrix farm can become slow and bloated. I’ve seen roaming profiles that have exceeded 500MB, with users calling the help desk to ask why their logins take 1-2 minutes to complete. If users have figured out how to save large graphics, music, or god forbid – video to their roaming profile, it can cause your profile server to run out of space after being clogged with excess “data”. The resulting profile corruption that occurs from profiles growing in size and being accessed often is commonplace in the roaming profile world, and something that most Citrix techs live with. You either decide to give your help desk the ability to log into the profile server and delete corrupt profiles from time to time, or you roll out a solution like Citrix profile manager which is supposed to limit profile corruption and last-write-wins conflicts. Either way, these types of profiles are going to be the highest maintenance solution that you could have chosen for your environment. Many Citrix techs will regret going this route sooner or later, but some don’t have a choice because of application customizations that won’t work with any other profile, etc. If you have applications that require writing to the HKEY_Current_User (HKCU) registry hive, then you are stuck using roaming profiles.
If you do decide to go with a roaming profile, it’s a good idea to deploy it with Citrix Profile Management. This will speed up logins, limit profile corruption, and eliminate last-write-wins conflicts that may occur without profile management in place.
Citrix, and most savvy Citrix Techs will recommend using mandatory profiles whenever feasible. They are considered lower maintenance than roaming profiles, because your users essentially are handed a profile that is read-only every time they log in. If they need to save data or customizations, it’s a good idea to map them a share drive and consider employing some folder redirection. Mandatory profiles can’t handle applications that write to the HKEY_Current_User (HKCU) registry hive, so be aware that your applications must be tested before deployment. Mandatory profiles are a good way to ensure that logins to the environment stay quick, and that help desk calls remain low.
In 7+ years of working with Citrix, I’ve only ever seen someone deploy multiple profiles once. It was in an environment where users needed a roaming profile on some servers to comply with a very custom application’s requirements. On the rest of the servers in the environment, the users were given a roaming profile. This is the only scenario I can think of when it may make sense to use multiple profiles throughout an environment. This is obviously an option that is born out of necessity more than anything, and should be looked at with caution.
In conclusion, profile design should be based around your user base and the applications you intend to virtualize in your environment. Only by understanding an evaluating how the applications function can you truly decide which profile solution will be best for you. User bases can vary widely with a range of technical skill and understanding. Depending on the type of users you are working with, you may choose to go with one profile solution over another.