Decision: Folder Redirection

Decision: Folder Redirection

While redirecting profile folders, such as user documents and favorites, to a network share is a good practice to minimize profile size, architects need to be aware that applications may frequently read and write data to profile folders such as AppData, causing potential issues with file server utilization and responsiveness. It is important to thoroughly test profile redirection before implementation in production to avoid these issues. Therefore, it is important to research profile read / write activities and to perform a pilot before moving to production. Microsoft Outlook is an example of one application that regularly performs profile read activities as the user signature is read from the user profile every time an email is created.

Decision: Folder Exclusion

Excluding folders from being persistently stored as part of a roaming of hybrid profile can help to reduce profile size and logon times. By default Windows excludes the Appdata\Local and Appdata\LocalLow folders, including all subfolders, such as History, Temp and Temporary Internet Files. In addition, the downloads and saved games folders should also be excluded.

Decision: Profile Caching

Local caching of roaming or hybrid user profiles on a server or virtual desktop is default Windows behavior and can reduce login times and file server utilization / network traffic. With profile caching,

the system only has to download changes made to the profile. The downside of profile caching is that it can consume significant amounts of local disk storage on multi-user systems, such as a hosted shared desktop server.

Citrix recommends not deleting locally cached profiles for the following scenarios:

For optimizing logon times:

• Hosted VDI – Dedicated / Existing / Physical

• Hosted VDI – Static with PVD

• Hosted VDI – Remote PC

• Local VM

For optimizing logoff times:

• Non-persistent virtual desktops and Hosted Shared Desktop servers, with reboot on logoff or daily reboot.

Citrix recommends deleting locally cached profiles on logoff for the following scenarios to avoid the proliferation of stale profiles:

• Hosted shared provided by persistent hosted shared desktop servers.

• Hosted VDI pooled without immediate reboot on logoff.

Configuring the “Delay before deleting cached profiles” Citrix policy sets an optional extension to the delay before locally cached profiles are deleted at logoff. Extending the delay is useful if a process keeps files or the user registry hive open during logoff. This can also reduce logoff times for large profiles.

Decision: Profile Permissions

For security reasons, administrators, by default, cannot access user profiles. While this level of security may be required for organizations that deal with very sensitive data, it is unnecessary for most environments and can complicate operations and maintenance. Therefore, consider enabling the “Add the Administrators security group to roaming user profiles” policy setting. The configuration of this policy should be aligned with the security characteristics of the user groups captured during the

assess phase. For more information on the permissions required for the file share, please refer to Microsoft TechNet - Deploying Roaming Profiles.

Decision: Profile Path

Determining the network path for the user profiles is one of the most significant decisions during a user profile design process. In general it is strongly recommended to leverage a redundant and high performance file server or NAS device.

There are three topics that must be considered for the profile share:

• Performance – File server performance will effect logon times. For large virtual desktop infrastructures, a single file server cluster may not be sufficient to handle periods of peak activity.

In order to distribute the load across multiple file servers, the file server address and share name will need to be adjusted.

• Location – User profiles are transferred over the network by means of the SMB protocol, which does not perform well on high latency network connections. Furthermore, WAN connections are typically bandwidth constrained, which can add additional delay to the profile load process. Therefore, the file server should be located in close proximity to the servers and virtual desktops to

minimize logon times.

• Operating system platforms – User profiles have a tight integration with the underlying operating system and it is not supported to reuse a single user profile on different operating systems or different platforms like 64-Bit (x64) and 32-Bit (x86). For more information, please refer to the Microsoft knowledge base article KB2384951 – Sharing 32 and 64-bit User Profiles. Windows 2008 and Windows Vista introduced a new user profile structure, which can be identified by .V2 profile directory suffix, which makes older user profiles incompatible with newer operating systems such as Windows 2012, 7 and 8. In order to ensure that a separate profile is used per platform, the profile

directory has to be adapted.

There are two methods that can be used to address these challenges that are based on Windows built-in technology:

• User object – For every user object in Active Directory, an individual profile path, which contains file server name and profile directory, can be specified. Since only a single profile path can be specified per user object, it is not possible to ensure that a separate profile is loaded for each operating system platform.

• Computer group policy or system variables – The user profile path can also be configured by means of computer specific group policies or system variables. This enables administrators to ensure that a user profile is dedicated to the platform. Since computer specific configurations affect all users of a system, all user profiles will be written to the same file server. To load balance user profiles across multiple servers dedicated XenDesktop delivery groups have to be created per file server.

Note: Microsoft does not support DFS-N combined with DFS-R for actively used user profiles. For more information, please refer to the Microsoft articles:

• Information about Microsoft support policy for a DFS-R and DFS-N deployment scenario 

• Microsoft’s Support Statement Around Replicated User Profile Data

When using Citrix Profile Management, a third option is available to address these challenges:

User object attributes and variables – Citrix Profile Management enables the administrator to configure the profile path by means of a computer group policy using attributes of the user object in Active Directory to specify the file server dynamically. In order to achieve this, three steps are required:

1. Create a DNS alias (for example, fileserver1) which refers to the actual file server

2. Populate an empty LDAP attribute of the user object (for example, l or UID) with the DNS Alias

3. Configure Citrix Profile Management by means of GPO to use a profile path which refers to the LDAP attribute (for example, If attribute UID is used the profile path becomes \\#UlD#\Profiles\

profiledirectory)

In addition, Citrix Profile Management automatically populates variables to specify the profile path dynamically based on the operating system platform. Valid profile management variables are:

• !CTX_PROFILEVER! – Expands to v1 or v2 depending on the profile version.

• !CTX_OSBITNESS! – Expands to x86 or x64 depending on the bit-level of the operating system.

• !CTX_OSNAME! – Expands to the short name of the operating system, for example Win7

By combining both capabilities of Citrix Profile Management, a fully dynamic user profile path can be created, which can be load balanced across multiple file servers and ensure profiles of different

operating system platforms are not mixed. An example of a fully dynamic user profile path is shown below: \\#UlD#\profiles$\%USERNAME%.%USERDOMAIN%\!CTX_ OSNAME!!CTX_OSBITNESS!