User profiles
May 28, 2016
By default, Citrix Profile management is installed silently on master images when you install the Virtual Delivery Agent, but you do not have to use Profile management as a profile solution.
To suit your users’ varying needs, you can use XenApp and XenDesktop policies to apply different profile behavior to the machines in each Delivery Group. For example, one Delivery Group might require Citrix mandatory profiles, whose template is stored in one network location, while another Delivery Group requires Citrix roaming profiles stored in another location with several redirected folders.
-
If other administrators in your organization are responsible for XenApp and XenDesktop policies, work with them to ensure that they set any profile-related policies across your Delivery Groups.
-
Profile management policies can also be set in Group Policy, in the Profile management .ini file, and locally on individual virtual machines. These multiple ways of defining profile behavior are read in the following order:
- Group Policy (.adm or .admx files)
- XenApp and XenDesktop policies in the Policy node
- Local policies on the virtual machine that the user connects to
- Profile management .ini file
For example, if you configure the same policy in both Group Policy and the Policy node, the system reads the policy setting in Group Policy and ignores the XenApp and XenDesktop policy setting.
Whichever profile solution you choose, Director administrators can access diagnostic information and troubleshoot user profiles. For more information, see the Director documentation.
If you use the Personal vDisk feature, Citrix user profiles are stored on virtual desktops’ Personal vDisks by default. Do not delete the copy of a profile in the user store while a copy remains on the Personal vDisk. Doing so creates a Profile management error, and causes a temporary profile to be used for logons to the virtual desktop.
Automatic configuration
The desktop type is automatically detected, based on the Virtual Delivery Agent installation and, in addition to the configuration choices you make in Studio, sets Profile management defaults accordingly.
The policies that Profile management adjusts are shown in the table below. Any non-default policy settings are preserved and are not overwritten by this feature. Consult the Profile management documentation for information about each policy. The types of machines that create profiles affect the policies that are adjusted. The primary factors are whether machines are persistent or provisioned, and whether they are shared by multiple users or dedicated to just one user.
Persistent systems have some type of local storage, the contents of which can be expected to persist when the system turns off. Persistent systems may employ storage technology such as storage area networks (SANs) to provide local disk mimicking. In contrast, provisioned systems are created “on the fly” from a base disk and some type of identity disk. Local storage is usually mimicked by a RAM disk or network disk, the latter often provided by a SAN with a high speed link. The provisioning technology is generally Provisioning Services or Machine Creation Services (or a third-party equivalent). Sometimes provisioned systems have persistent local storage, which may be provided by Personal vDisks; these are classed as persistent.
Together, these two factors define the following machine types:
- Both persistent and dedicated – Examples are Desktop OS machines with a static assignment and a Personal vDisk that are created with Machine Creation Services, desktops with Personal vDisks that are created with VDI-in-a-Box, physical workstations, and laptops
- Both persistent and shared – Examples are Server OS machines that are created with Machine Creation Services
- Both provisioned and dedicated – Examples are Desktop OS machines with a static assignment but without a Personal vDisk that are created with Provisioning Services
- Both provisioned and shared – Examples are Desktop OS machines with a random assignment that are created with Provisioning Services and desktops without Personal vDisks that are created with VDI-in-a-Box
The following Profile management policy settings are suggested guidelines for the different machine types. They work well in most cases, but you may want to deviate from these as your deployment requires.
Important: Delete locally cached profiles on logoff, Profile streaming, and Always cache are enforced by the auto-configuration feature. Adjust the other policies manually.
Persistent machines
| Policy | Both persistent and dedicated | Both persistent and shared |
|---|---|---|
| Delete locally cached profiles on logoff | Disabled | Enabled |
| Profile streaming | Disabled | Enabled |
| Always cache | Enabled (note 1) | Disabled (note 2) |
| Active write back | Disabled | Disabled (note 3) |
| Process logons of local administrators | Enabled | Disabled (note 4) |
Provisioned machines
| Policy | Both provisioned and dedicated | Both provisioned and shared |
|---|---|---|
| Delete locally cached profiles on logoff | Disabled (note 5) | Enabled |
| Profile streaming | Enabled | Enabled |
| Always cache | Disabled (note 6) | Disabled |
| Active write back | Enabled | Enabled |
| Process logons of local administrators | Enabled | Enabled (note 7) |
- Because Profile streaming is disabled for this machine type, the Always cache setting is always ignored.
- Disable Always cache. However, you can ensure that large files are loaded into profiles as soon as possible after logon by enabling this policy and using it to define a file size limit (in MB). Any file this size or larger is cached locally as soon as possible.
- Disable Active write back except to save changes in profiles of users who roam between XenApp servers. In this case, enable this policy.
- Disable Process logons of local administrators except for Hosted Shared Desktops. In this case, enable this policy.
- Disable Delete locally cached profiles on logoff. This retains locally cached profiles. Because the machines are reset at logoff but are assigned to individual users, logons are faster if their profiles are cached.
- Disable Always cache. However, you can ensure that large files are loaded into profiles as soon as possible after logon by enabling this policy and using it to define a file size limit (in MB). Any file this size or larger is cached locally as soon as possible.
- Enable Process logons of local administrators except for profiles of users who roam between XenApp and XenDesktop servers. In this case, disable this policy.
Folder redirection
Folder redirection lets you store user data on network shares other than the location where the profiles are stored. This reduces profile size and load time but it might impact network bandwidth. Folder redirection does not require that Citrix user profiles are employed. You can choose to manage user profiles on your own, and still redirect folders.
Configure folder redirection using Citrix policies in Studio.
- Ensure that the network locations used to store the contents of redirected folders are available and have the correct permissions. The location properties are validated.
- Redirected folders are set up on the network and their contents populated from users’ virtual desktops at logon.
Note: Configure folder redirection using only Citrix Policies or Active Directory Group Policy Objects, not both. Configuring folder redirection using both policy engines may result in unpredictable behavior.
Advanced folder redirection
In deployments with multiple operating systems (OSs), you might want some of a user’s profile to be shared by each OS. The rest of the profile is not shared and is used only by one OS. To ensure a consistent user experience across the OSs, you need a different configuration for each OS. This is advanced folder redirection. For example, different versions of an application running on two OSs might need to read or edit a shared file, so you decide to redirect it to a single network location where both versions can access it. Alternatively, because the Start Menu folder contents are structured differently in two OSs, you decide to redirect only one folder, not both. This separates the Start Menu folder and its contents on each OS, ensuring a consistent experience for users.
If your deployment requires advanced folder redirection, you must understand the structure of your users’ profile data and determine which parts of it can be shared between OSs. This is important because unpredictable behavior can result unless folder redirection is used correctly.
To redirect folders in advanced deployments:
- Use a separate Delivery Group for each OS.
- Understand where your virtual applications, including those on virtual desktops, store user data and settings, and understand how the data is structured.
- For shared profile data that can safely roam (because it is structured identically in each OS), redirect the containing folders in each Delivery Group.
- For non-shared profile data that cannot roam, redirect the containing folder in only one of the Desktop Groups, typically the one with the most used OS or the one where the data is most relevant. Alternatively, for non-shared data that cannot roam between OSs, redirect the containing folders on both systems to separate network locations.
Example advanced deployment - This deployment has applications, including versions of Microsoft Outlook and Internet Explorer, running on Windows 8 desktops and applications, including other versions of Outlook and Internet Explorer, delivered by Windows Server 2008. To achieve this, you have already set up two Delivery Groups for the two OSs. Users want to access the same set of Contacts and Favorites in both versions of those two applications.
Important: The following decisions and advice are valid for the OSs and deployment described. In your organization, the folders you choose to redirect and whether your decide to share them depend on a number of factors that are unique to your specific deployment.
- Using policies applied to the Delivery Groups, you choose the following folders to redirect. | Folder | Redirected in Windows 8? | Redirected in Windows Server 2008? | | —————- | ———————— | ———————————- | | My Documents | Yes | Yes | | Application Data | No | No | | Contacts | Yes | Yes | | Desktop | Yes | No | | Downloads | No | No | | Favorites | Yes | Yes | | Links | Yes | No | | My Music | Yes | Yes | | My Pictures | Yes | Yes | | My Videos | Yes | Yes | | Searches | Yes | No | | Saved Games | No | No | | Start Menu | Yes | No |
- For the shared, redirected folders:
- After analyzing the structure of the data saved by the different versions of Outlook and Internet Explorer, you decide it is safe to share the Contacts and Favorites folders
- You know the structure of the My Documents, My Music, My Pictures, and My Videos folders is standard across OSs, so it is safe to store these in the same network location for each Delivery Group
- For the non-shared, redirected folders:
- You do not redirect the Desktop, Links, Searches, or Start Menu folders folder in the Windows Server Delivery Group because data in these folders is organized differently in the two OSs. It therefore cannot be shared.
- To ensure predictable behavior of this non-shared data, you redirect it only in the Windows 8 Delivery Group. You choose this, rather than the Windows Server Delivery Group, because Windows 8 will be used more often by users in their day-to-day work; they will only occasionally access the applications delivered by the server. Also, in this case the non-shared data is more relevant to a desktop environment rather than an application environment. For example, desktop shortcuts are stored in the Desktop folder and might be useful if they originate from a Windows 8 machine but not from a Windows Server machine.
- For the non-redirected folders:
- You do not want to clutter your servers with users’ downloaded files, so you choose not to redirect the Downloads folder
- Data from individual applications can cause compatibility and performance issues, so you decide not to redirect the Application Data folder
For more information on folder redirection, see http://technet.microsoft.com/en-us/library/cc766489%28v=ws.10%29.aspx.
Folder redirection and exclusions
In Citrix Profile management (but not in Studio), a performance enhancement allows you to prevent folders from being processed using exclusions. If you use this feature, do not exclude any redirected folders. The folder redirection and exclusion features work together, so ensuring no redirected folders are excluded allows Profile management to move them back into the profile folder structure again, while preserving data integrity, if you later decide not to redirect them. For more information on exclusions, see To include and exclude items.