Design methodology resource layer

The resource layer is the third layer of the design methodology and the final layer focused specifically on the user groups.

The overall user acceptance of the solution is defined by the decisions made within the resource layer. Profiles, printing, applications and overall desktop image design play a pivotal role in how well the desktop is aligned with the user group’s requirements, which were identified within the assess phase.

User Experience

Perception is everything when it comes to a good VDI experience. Users expect an experience similar to or better than that of a traditional, physical desktop.

Codecs, transport protocols, and self-service capabilities affect the overall experience. Poor quality graphics, lagging video or 120 second logon times can destroy the user experience. A proper user experience design can meet any network challenge.

Decision: Display Protocol

Selecting the correct display protocol determines the quality of static images, video and text within the user’s session as well as determining the impact on single server scalability. Administrators have the following options:

  • Legacy - optimized for Windows 7 and Windows 2008R2 graphic engines (GDI/GDI+).
  • Desktop Composition Redirection – offloads desktop Windows manager DirectX commands to the endpoint, but only supports a Windows desktop VDA. Plus, in the 7.15 LTSR release, Desktop Composition Redirection is a depreciated feature.
  • Framehawk – a UDP-based protocol that is able to provide high refresh rates in environments with high latency and high packet loss scenarios at the cost of greater network bandwidth utilization, commonly found on broadband wireless connections.
  • H.264 – Often referred as the video codec, which provides the highest frame rates required for high quality video while saving network bandwidth. It does come at the expense of CPU processing time, reducing single server scalability. H.264 is the preferred codec when users predominately use multimedia applications.
  • Thinwire – Based on the original Citrix patents from the 1990s that thinly transfers data over a wire. Use Thinwire in the majority of use cases as it provides a good user experience with minimal resource costs. There are two variations of Thinwire:
    • Legacy - Optimized for Windows 7 and Windows 2008R2 graphic engines (GDI/GDI+).
    • Thinwire+ - Optimized for Desktop Windows Manager (DWM) graphics engine in Windows 8, Windows 10, Windows 2012 and Windows 2016
  • Selective H.264 (Adaptive Display) - utilizes multiple codecs (H.264 and Thinwire+) simultaneously for portions of the screen
    • Do not use – Only uses Thinwire+ and not H.264. Best for users without server-rendered video or other graphically intense applications.
    • For entire screen – Only uses H.264. Best for users with heavy use of server-rendered video and 3D graphics, especially in low-bandwidth situations.
    • For actively changing regions – Uses H.264 for the portions of the screen that are constantly changing while the remainder of the screen uses Thinwire+. This is the best option for most users.

Selecting the right codec not only has an impact on the overall user experience, but also on the scalability of the server.

Codec impact on Single Server image

Decision: Transport Protocol

There are three ways to transport the HDX protocol across the network:

  • TCP – Uses the industry standard TCP transport protocol. Common transport protocol over LAN and low-latency WAN connections, but suffers when connection distances increases, thus increasing latency and incurring more retransmissions.
  • EDT – Uses a Citrix proprietary transport protocol called Enlightened Data Transport, based on UDP. Meant for high latency/packet loss networks, most common on long-distance WAN links. Provides a more interactive experience for the user without increasing CPU load on the server, but consumes more network bandwidth than TCP.
  • Adaptive Transport – Uses TCP and EDT transport protocols. EDT used unless the network does not support transporting EDT over the network, which then automatically changes to TCP.

Most environments will use Adaptive Transport as the standard transport option unless the network does not have the appropriate firewall ports opened or NetScaler Gateway configured appropriately.

Decision: Logon Optimization

Every time a user logs onto a XenApp and XenDesktop session, the logon process must complete, which includes session initialization, user profile loading, group policy preferences execution, drive mapping, printer mapping, logon script execution and desktop initialization. Each process takes time and increases logon duration.

Most organizations include many mappings and complex logon scripts. When each of these items executes, the logon time drastically increases.

Logon time image

Workspace Environment Management removes drive mappings, printer mappings, logon scripts and roaming profiles from the standard logon process. With logon optimization, Workspace Environment Management applies the mappings/scripts/profiles in the background after the session and desktop initializes. The user receives the same environment but they receive their desktop interface faster. To learn more, review the following Logon Optimization video.

Most environments should enable logon optimization as a default configuration.

Decision: User Self Service

Self-service allows users to modify, update and troubleshoot their environments on their own without requiring help desktop intervention. Most organizations have policies in place that require users to change their passwords every 60-90 days. When users have multiple endpoint devices with saved passwords, it is extremely easy for their account to be locked out until each device is updated.

With StoreFront, can save time by self-servicing their own accounts with the following capabilities:

  • Account Unlock – When the user’s account is locked due to too many failed logon attempts, common with multiple devices, they can unlock their account if they know answers to their security questions.
  • Password Reset – When users forgot their newly created password, they can reset their password if they know the answers to their security questions.

The self-service password reset architecture introduces the SSPR Service, Central Store and two accounts:

  • Data Proxy Account – Responsible for accessing the central store, which contains encrypted answers to the user’s security questions.
  • Self Service Account – An Active Directory account with password reset and account unlock rights.

SSPR architecture image

In addition, properly designing self-service password reset requires the admin to create security questions that users will answer. Ideally, admins should create groups of questions around different categories than require users to answer a subset of questions for each group. The questions must be something the user knows that does not change and is not known by others.

User Profiles

A user’s profile plays a critical role in delivering a consistently positive experience within a virtual desktop or virtual application scenario. Even a well-designed virtual desktop solution can fail if users are frustrated due to lengthy logon times or lost settings.

The user profile solution chosen must align with the personalization characteristics of the user group captured during the assess phase as well as the VDI model selected.

Decision: Profile Type

This section provides an overview on the different profile types available and provides guidance on the optimal user profile for each VDI model.

  • Local profiles – Local profiles are stored on each server or desktop operating system and are initially created based on the default user profile. Therefore, a user accessing these resources would create an independent profile on each system. Users are able to retain changes to their local profile on each individual system, but changes are only accessible for future sessions on that system. Local profiles require no configuration; if a user logging into a server or desktop operating system does not have a profile path administratively defined, a local profile is created by default.
  • Roaming profiles – Roaming profiles are stored in a centralized network repository for each user. Roaming profiles differ from local profiles in that the information in the profile (whether it is a printer, a registry setting, or a file stored in the documents folder) can be made available to user sessions accessed from all systems in the environment. Configuring a user for a roaming profile requires an administrator to designate the user’s profile path (for virtual desktops) or terminal server profile path to a particular network share. The first time the user logs on to a server or desktop operating system, the default user profile is used to create the user’s roaming profile. During logoff, the profile is copied to the administrator-specified network location.
  • Mandatory profiles – Mandatory profiles are typically stored in a central location for many users. However, the user’s changes are not retained at logoff. Configuring a user for a mandatory profile requires an administrator to create a mandatory profile file (NTUSER.MAN) from an existing roaming or local profile and assign users with a terminal services profile path. This can be achieved by means of Microsoft Group Policy, customizing the user properties in Active Directory or Citrix Profile Management.

  • Hybrid profiles – Hybrid profiles combine a robust profile core (a mandatory profile or a local default profile) with user specific registry keys or files that are merged during logon. This technique enables administrators to tightly control which changes are retained and to keep the user profiles small in size. Furthermore, hybrid profiles address the last write wins issue using mature queuing techniques that automatically detect and prevent simultaneous writes that could potentially overwrite changes made in another session. Thus minimizing user frustration resulting from lost profile changes when accessing multiple servers or virtual desktops simultaneously. In addition, they capture and record only the changes within the profile, rather than writing the entire profile at logoff. A good example of a hybrid profile solution is Citrix Profile Management, which will be discussed in detail within this chapter.

The following table compares the capabilities of each profile type.

In the table:

  • Y indicates Functionality available.
  • o indicates Optional.
  • N indicates Functionality not available.
Feature Local Roaming Mandatory Hybrid
Central management / roams with user N Y o Yes
User settings are stored persistently Y Y N Yes
Granular capture of user settings N N N Yes

In order to select the optimal profile type for each user group it is important to understand their personalization requirements in addition to the VDI model assigned.

The following table provides recommendations on selecting the appropriate user profile type based on VDI resource:

In the table:

  • Y indicates Recommended.
  • X indicates Not Recommended.
  • o indicates Viable.

User setting persistence required (personalization characteristic: basic / complete)

Feature Local Roaming Mandatory Hybrid
Hosted Windows App X Y X Y
Hosted Browser App X Y X Y
Hosted Shared Desktop X Y X Y
Hosted Pooled Desktop X Y X Y
Hosted Personal Desktop º Y X Y
Hosted Pro Graphics Desktop º Y X Y
Local Streamed Desktop X Y X Y
Local VM Desktop Y º X º
Remote PC Access Y º X º

User setting persistence not required or not desired (personalization characteristic: none)

Feature Local Roaming Mandatory Hybrid
Hosted Windows App X X Y X
Hosted Browser App X X Y X
Hosted Shared Desktop X X Y X
Hosted Pooled Desktop Y X Y X
Hosted Personal Desktop X X Y X
Hosted Pro Graphics Desktop º X Y X
Local Streamed Desktop Y X Y X
Local VM Desktop º X Y X
Remote PC Access º X Y X

Decision: Folder Redirection

Redirecting special folders can supplement any of the described profile types. 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 an application that regularly performs profile read activities, as the user signature is read from the user profile every time an email is created.

The following table provides general recommendations to help identify the appropriate folders to redirect:

In the table:

  • Y indicates Recommended.
  • X indicates Not Recommended.
  • o indicates Viable.
Folder Local Roaming Mandatory Hybrid
Application Data X o X o
Contacts X Y X o
Desktop X Y X o
Downloads X o X o
Favorites o Y o Y
Links X Y X o
My Documents o Y o Y
My Music o Y o o
My Pictures o Y o o
My Videos o Y o o
Saved Games X o X o
Searches X Y X o
Start Menu X X X X

Decision: Folder Exclusion

Excluding folders from being persistently stored as part of a roaming or 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. All folders that are redirected should be excluded from the profile solution.

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 hosts.

In certain VDI models and configurations, the VDI resource is reset to a pristine state. Having locally cached profiles be deleted upon logoff is an unnecessary consumption of resources. Based on this, the leading recommendation is to not deleting locally cached profiles for the following VDI models:

  • Hosted Personal Desktops
  • Hosted Pooled Desktops – only in situations where a reboot occurs after logoff.
  • Local VM Desktops
  • Remote PC Access

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 hosting user profiles and data, 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 four topics that must be considered for the profile share:

  • Performance – File server performance will affect logon and logoff times, and depending on other decisions such as redirected folders and profile streaming, can impact the user’s experience within the session. 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.

  • Indexing capabilities – To take full advantage of Windows Search functionality on a user’s redirected data, Windows file servers that index the user’s data must be used, as opposed to a share on a NAS appliance. This is important for use cases that are heavily dependent on Windows Search or are especially sensitive to perception of slowness or latency

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:

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) that 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 that 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- Windows 7.

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:


Decision: Profile Streaming

Note: The following design decision only applies to those environments that use Citrix Profile Management.

With user profile streaming, files and folders contained in a profile are fetched from the user store (file server) to the local computer when a user accesses them. During the logon process, Citrix Profile Management immediately reports that the profile load process has completed reducing profile load time to almost zero.

Citrix recommends enabling profile streaming for all scenarios. If it is desired to keep a local cached copy of the user profile for performance reasons, it is recommended to enable the “Always Cache” setting and configure a size of 0. This ensures that the user profile is downloaded in the background and enables the system to use this cached copy going forward.

Experience from the Field

  • General – Some poorly written applications might load faster if their AppData has already been streamed to the VDI resource. Enabling the “Always Cache” option for profile streaming can help improve performance when the AppData folder is not redirected.

Decision: Active Write Back

Note: The following design decision only applies to those environments that use Citrix Profile Management.

By enabling the active write back feature, Citrix Profile Manager detects when an application has written and closed a file and copies the file back to the network copy of the profile during idle periods. In scenarios where a single user leverages multiple virtual desktops or hosted shared desktops simultaneously, this feature can be tremendously beneficial. However, Citrix Profile Management does not copy any registry changes back to the network, except during an ordered logoff. As such, there is a risk that the registry and files may get out of alignment on non-persistent systems, where locally cached profile information is wiped upon reboot. Therefore, it is recommended to disable active write back functionality for non-persistent scenarios.

Decision: Configuration Approach

Note: The following design decision only applies to those environments that use Citrix Profile Management.

Citrix Profile Management can be configured by means of an “.ini” file, Microsoft Group Policy and Citrix Policy (Citrix Profile Management 5.0 and newer). While each option offers the same configuration settings, Group Policy is recommended because it allows administrators to perform Windows and Citrix profile configurations from a single point, minimizing the tools necessary for profile management.

Note: With Citrix Profile Management 5.0 and newer, the desktop type is automatically detected and Citrix Profile Management policies set accordingly. For more information, please refer to Citrix Docs – How automatic configuration works.

Decision: Replication

While having an active/active data center on a network level is easily accomplished with GSLB, the replication of user data makes having a fully active/active deployment complex in most situations. To have an active/active configuration where users are not statically assigned to a specific data center, will require users to have no form of personalization requirements. This will limit the user’s ability to make any configuration changes and will not allow them to create any documents or persistent data. The exception to this is when a high-speed, low latency connection such as dark fiber is available between data centers. This will let resources in both locations can point to the same file server allowing for a true active/active solution. Also, an active/active configuration can be accomplished when applications are used that rely solely on a backend database that is actively replicated between data centers and do not store any data in the user profile.

For redundancy and failover purposes, user data such as Windows profiles and documents should be synchronized between data centers. Although it is recommended to replicate user data between data centers, the replication would be an active/passive configuration. This means the data can only be actively consumed from a single data center. The reason for this limitation is the distributed file locking method inside Windows that only allows a single user to actively write to a file. Therefore, active/active replication of user data is not supported. Any supported configuration consists of a one-way replication of data that is active in a single data center at any point in time.

For example, the figure below describes a scenario where user data is passively replicated from data center A to data center B. In this example, File Server A is the primary location for user data in data center A and File Server B is the primary location in data center B. One-way replication of the user data occurs for each file server to allow for the user data to be available in the opposite data center if a failover occurs. Replication technologies such as Microsoft DFS can be configured to mirror user profiles and documents to a file server in another data center. DFS Namespaces can also be used to have a seamless path for the location of the user data. However, implementing a replication solution like this requires an administrator familiar with Microsoft DFS and user profiles.

Data center image

User Data

In order to be effective, users must access their data. The data must be in close proximity to the application for the user to have a good experience. As the distance between the application and data increases, latency also increases, which slows down any file operation (opening, saving, modifying).

In a VDI-based environment, administrators must understand where users store their data and impact of access.

Decision: User Data Location

Users traditionally stored their data on their local device or on a network file server designated with a drive mapping. Due to IT storage space limitations or the inability to have the data follow the user to other mobile devices, users turned to free, cloud-based storage offerings like OneDrive, DropBox and Box. To get access to the data, the user would install the storage vendor’s agent on their traditional Windows PC, allowing them direct access to the cloud-hosted storage repository.

Administrators must design the solution to take into account user storage by looking at the following options:

  • Multi-Agent Strategy – In VDI, users require the admin to install and configure the agent for each storage provider, which assumes the storage agent supports the non-persistent VDI model. Each agent is a new application that the admin must manage and maintain.
  • Storage Connector Strategy – A single agent consolidates storage repositories from numerous cloud-hosted and on-premises providers into a single folder structure. For example, when a user connects to Citrix ShareFile, they see a consolidated folder structure containing their user data from the cloud (ShareFile, OneDrive, DropBox, Box and Google Drive) and from on-premises (SharePoint, Windows network shares and local endpoint shares).

Decision: User Data Access

A critical aspect to a successful VDI solution is for the user experience to remain the same as it was with a traditional PC. If users open files from within the application, that functionality must continue to function. If users navigate with Explorer to access a file, that functionality must continue to function.

A user’s data can exist on the local PC, on a network file share and hosted in the cloud.

Date storage locations image

With local PC, on-premises network shares and cloud-hosted storage options available to users, administrators need to understand how users accessing their data affects the infrastructure and VDI experience.

  • Direct Data Access – Users access a file on a remote server (on-premises Windows server or cloud-hosted storage provider). The distance between the application and file directly affects the experience. Longer distances equates to higher latency. Each file operation (navigate, open, close, save, etc.) takes more time as the latency between application and file storage increases. Windows file servers are often located in the same data center as the user’s VDI desktop making direct data access feasible; but cloud-hosted solutions and local PC Access will experience poor response times if the connection between the VDI desktop and the storage repository has high latency.
  • Local Synchronization – With a traditional PC, users are accustomed to having files local, which mitigates any slow application response times due to extremely low latency. Many cloud-hosted solutions provide data synchronization to enable access speeds similar to a local storage model. Many of the cloud-hosted solutions provide full synchronization or user-configured partial synchronization of certain folders and files. With partial synchronization, only the synchronized files are visible and accessible on the device, causing user confusion. Full and partial synchronization increases VDI costs. Each session is an entirely new desktop requiring synchronization of user’s folders/files, which takes time, network bandwidth and VDI storage space. Every file synchronized to the VDI desktop must be stored within the organization’s data center for the duration of the VDI session.
  • On-Demand Synchronization – When navigating Explorer, users see a complete, but virtual, file/folder structure even though those files/folders do not physically exist on the desktop. Selecting a file begins an automatic synchronization to the VDI desktop for that single file. At this point, file access is local, which creates a user experience like that of a traditional PC. When the user saves or closes the file, the file synchronizes back to the cloud. Only the files accessed synchronize, eliminating the waste incurred with the local data access model. Citrix ShareFile includes Drive Mapper, allowing the user to interact with their data via Explorer while utilizing on-demand synchronization when accessing a file. As only accessed files synchronize, the impact to the underlying storage infrastructure and associated storage costs are minimal.

In the table:

  • Y indicates recommended.
  • N indicates Not recommended.
  Direct Data Access Local Synchronization On-Demand Synchronization
Network File Server Y    
Cloud-hosted N N Y
Local PC N N Y

Decision: Data Recovery

File corruption is an issue most users experience. Improperly shutting down the application or PC (hitting the power button instead of closing the application and shutting down the operating system gracefully) often causes many corruption issues.

A few options exist to provide users with data recovery options:

  • Multi-File – With a traditional PC, users have few recovery options if the files are local. Users often manually create a new copy of the file each day in order to provide some level of recovery. This solution is hard to manage.
  • Backup/Restore – Administrators can implement a backup and restore solution to help with file recovery. However, these solutions rarely work with local files and for a network file share, the backup process usually only runs nightly or weekly. In addition, restoring a corrupted file requires the user to call support.
  • Versioning –Cloud-hosted options, like Citrix ShareFile, include file versioning, which automatically creates new versions of the file as changes are saved. Versioning requires no user intervention and allows users to recover from corruption quickly and with little loss of data.

ShareFile versioning image


Policies provide the basis to configure and fine tune XenApp and XenDesktop environments, allowing organizations to control connection, security and bandwidth settings based on various combinations of users, devices or connection types.

When making policy decisions it is important to consider both Microsoft and Citrix policies to ensure that all user experience, security and optimization settings are considered. For a list of all Citrix-related policies, please refer to the [Citrix Policy Settings Reference.

Decision: Preferred Policy Engine

Organizations have the option to configure Citrix policies via Citrix Studio or through Active Directory group policy using Citrix ADMX files, which extend group policy and provide advanced filtering mechanisms.

Using Active Directory group policy allows organizations to manage both Windows policies and Citrix policies in the same location, and minimizes the administrative tools required for policy management. Group policies are automatically replicated across domain controllers, protecting the information and simplifying policy application.

Citrix administrative consoles should be used if Citrix administrators do not have access to Active Directory policies. Architects should select one of the above two methods as appropriate for their organization’s needs and use that method consistently to avoid confusion with multiple Citrix policy locations.

It is important to understand how the aggregation of policies, known as policy precedence flows in order to understand how a resultant set of policies is created. With Active Directory and Citrix policies, the precedence is as follows:

Policy Precedence Policy Type
Processed first (lowest precedence) Local server policies
Processed second Citrix policies created using the Citrix administrative consoles
Processed third Site level AD policies
Processed fourth Domain level AD policies
Processed fifth Highest level OU in domain
Processed sixth and subsequent Next level OU in domain
Processed last (highest precedence) Lowest level OU containing object

Policies from each level are aggregated into a final policy that is applied to the user or computer. In most enterprise deployments, Citrix administrators do not have rights to change policies outside their specific OUs, which will typically be the highest level for precedence. In cases where exceptions are required, the application of policy settings from higher up the OU tree can be managed using “block inheritance” and “no override” settings. Block inheritance stops settings from higher-level OUs (lower precedence) from being incorporated into the policy. However, if a higher-level OU policy is configured with no override, the block inheritance setting will not be applied. Given this, care must be taken in policy planning, and available tools such as the “Active Directory Resultant Set of Policy” tool or the “Citrix Group Policy Modeling” wizard should be used to validate the observed outcomes with the expected outcomes.


Some Citrix policy settings, if used, need to be configured through Active Directory group policy, such as Controllers and Controller registration port, as these settings are required for VDAs to register.

Decision: Policy Integration

When configuring policies, organizations often require both Active Directory policies and Citrix policies to create a completely configured environment. With the use of both policy sets, the resultant set of policies can become confusing to determine. In some cases, particularly with respect to Windows Remote Desktop Services (RDS) and Citrix policies, similar functionality can be configured in two different locations. For example, it is possible to enable client drive mapping in a Citrix policy and disable client drive mapping in an RDS policy. The ability to use the desired feature may be dependent upon the combination of RDS and Citrix policy. It is important to understand that Citrix policies build upon functionality available in Remote Desktop Services. If the required feature is explicitly disabled in RDS policy, Citrix policy will not be able to affect a configuration as the underlying functionality has been disabled.

In order to avoid this confusion, it is recommended that RDS policies only be configured where required and there is no corresponding policy in the XenApp and XenDesktop configuration, or the configuration is specifically needed for RDS use within the organization. Configuring policies at the highest common denominator will simplify the process of understanding resultant set of policies and troubleshooting policy configurations.

Decision: Policy Scope

Once policies have been created, they need to be applied to groups of users and/or computers based on the required outcome. Policy filtering provides the ability to apply policies against the requisite user or computer groups. With Active Directory based policies, a key decision is whether to apply a policy to computers or users within site, domain or organizational unit (OU) objects. Active Directory policies are broken down into user configuration and computer configuration. By default, the settings within the user configuration apply to users who reside within the OU at logon, and settings within the computer configuration are applied to the computer at system startup, and will affect all users who logon to the system. One challenge of policy association with Active Directory and Citrix deployments revolves around three core areas:

  • Citrix environment specific computer policies – Citrix servers and virtual desktops often have computer policies that are created and deployed specifically for the environment. Applying these policies is easily accomplished by creating separate OU structures for the servers and the virtual desktops. Specific policies can then be created and confidently applied to only the computers within the OU and below and nothing else. Based upon requirements, virtual desktops and servers may be further subdivided within the OU structure based on server roles, geographical locations or business units.
  • Citrix specific user policies – When creating policies for XenApp and XenDesktop there are a number of policies specific to user experience and security that are applied based on the user’s connection. However, the user’s account could be located anywhere within the Active Directory structure, creating difficulty with simply applying user configuration based policies. It is not desirable to apply the Citrix specific configurations at the domain level as the settings would be applied to every system any user logs on to. Simply applying the user configuration settings at the OU where the Citrix servers or virtual desktops are located will also not work, as the user accounts are not located within that OU. The solution is to apply a loopback policy, which is a computer configuration policy that forces the computer to apply the assigned user configuration policy of the OU to any user who logs onto the server or virtual desktop, regardless of the user’s location within Active Directory. Loopback processing can be applied with either merge or replace settings. Using replace overwrites the entire user GPO with the policy from the Citrix server or virtual desktop OU. Merge will combine the user GPO with the GPO from the Citrix server or desktop OU. As the computer GPOs are processed after the user GPOs when merge is used, the Citrix related OU settings will have precedence and be applied in the event of a conflict. For more information, please refer to the Microsoft TechNet article - Understand User Group Policy Loopback Mode.
  • Active Directory policy filtering – In more advanced cases, there may be a need to apply a policy setting to a small subset of users such as Citrix administrators. In this case, loopback processing will not work, as the policy should only be applied to a subset of users, not all users who logon to the system. Active Directory policy filtering can be used to specify specific users or groups of users to which the policy is applied. A policy can be created for a specific function, and then a policy filter can be set to apply that policy only to a group of users such as Citrix administrators. Policy filtering is accomplished using the security properties of each target policy.

Citrix policies created using Citrix Studio have specific filter settings available, which may be used to address policy-filtering situations that cannot be handled using group policy. Citrix policies may be applied using any combination of the following filters:

Filter Name Filter Description Scope
Access control Applies a policy based on access control conditions through which a client is connecting. For example, users connecting through a Citrix NetScaler Gateway can have specific policies applied. User settings
Citrix CloudBridge Applies a policy based on whether or not a user session was launched through Citrix CloudBridge. User settings
Client IP address Applies a policy based on the IPv4 or IPv6 address of the user device used to connect the session. Care must be taken with this filter if IPv4 address ranges are used in order to avoid unexpected results. User settings
Client name Applies a policy based on the name of the user device used to connect the session. User settings
Delivery group Applies a policy based on the delivery group membership of the desktop running the session. User settings
Delivery group type Applies a policy based on the type of machine running the session. For example, different policies can be set depending upon whether a desktop is pooled, dedicated or streamed. User and computer settings
Organizational unit Applies a policy based on the OU of the desktop or server running the session. User and computer settings
Tag Applies a policy based on any tags applying to the desktop running the session. Tags are strings that can be added to virtual desktops in XenDesktop environments that can be used to search for or limit access to desktops. User and computer settings
User or Group Applies a policy based on the Active Directory group membership of the user connecting to the session. User settings


Citrix policies in XenDesktop 7.x provide a merged view of settings that apply at the user and computer level. In table 24, the Scope column identifies whether the specified filter applies to user settings, computer settings, or both.

Decision: Baseline Policy

A baseline policy should contain all common elements required to deliver a high-definition experience to the majority of users within the organization. A baseline policy creates the foundation for user access, and any exceptions that may need to be created to address specific access requirements for groups of users. It should be comprehensive to cover as many use cases as possible and should have the lowest priority, for example 99 (a priority number of “1” is the highest priority), in order to create the simplest policy structure possible and avoid difficulties in determining the resultant set of policies. The unfiltered policy set provided by Citrix as the default policy may be used to create the baseline policy as it is applied to all users and connections. In the baseline configuration, all Citrix policy settings should be enabled, even those that will be configured with the default value, in order to explicitly define desired/expected behavior, and to avoid confusion should default settings change over time.

Citrix Policy templates can be used to configure Citrix policies to effectively manage the end-user experience within an environment and can serve as an initial starting point for a baseline policy. Templates consist of pre-configured settings that optimize performance for specific environments or network conditions. The built-in templates included in XenDesktop are shown below:

Built-in Templates Description
High definition user experience Includes settings for providing high quality audio, graphics, and video to users.
High server scalability Includes settings for providing an optimized user experience while hosting more users on a single server.
Optimized bandwidth for WAN Includes settings for providing an optimized experience to users with low bandwidth or high latency connections.
Security and control Includes settings for disabling access to peripheral devices, drive mapping, port redirection, and Flash acceleration on user devices.

For more information on Citrix policy templates, please refer to Citrix Docs - Manage Citrix Policy Templates.

A baseline policy configuration should also include Windows policies. Windows policies reflect user specific settings that optimize the user experience and remove features that are not required or desired in a XenDesktop environment. For example, one common feature turned off in these environments is Windows update. In virtualized environments, particularly where desktops and servers may be streamed and non-persistent, Windows update creates processing and network overhead, and changes made by the update process will not persist a restart of the virtual desktop or application server. Also in many cases, organizations use Windows software update service (WSUS) to control Windows updates. In these cases, updates are applied to the master disk and made available by the IT department on a scheduled basis.

In addition to the above considerations, an organization’s final baseline policy may include settings specifically created to address security requirements, common network conditions, or to manage user device or user profile requirements:


Citrix XenApp and Citrix XenDesktop support a variety of different printing solutions. In order to plan and successfully implement the proper printing solution it is important to understand the available technologies as well as their benefits and limitations.

Decision: Printer Provisioning

The process of creating printers at the start of a XenApp or XenDesktop session is called printer provisioning. There are multiple approaches available:

  • User Added – Allowing users to manually add printers gives them the flexibility to select printers by convenience. The drawback to manually adding network-based printers is that it requires the users to know the network name or path of the printers. There is also a chance that the native print driver is not installed in the operating system and the Citrix Universal Print Driver is not compatible, thereby requiring the user to seek administrative assistance. Manually adding printers is best suited in the following situations:
    • Users roam between different locations using the same client device (i.e. laptop, tablet).
    • Users work at assigned stations or areas whose printer assignments will rarely change.
    • Users have personal desktops with sufficient rights to install necessary printer drivers.
  • Auto Created – Auto-creation is a form of dynamic provisioning that attempts to create some or all of the available printers on the client device at the start of a user session. This includes locally attached printers as well as network-based printers. Auto-creating all client printers can increase the session logon time as each printer is enumerated during the logon process.
  • Session Based – Session printers are a set of network-based printers assigned to users through a Citrix policy at the start of each session.
    • Proximity based session printers are filtered by IP subnet. The network printers created under this policy may vary based on where the user’s endpoint device is located. Proximity printing is recommended in situations where: Users roam between different locations using the same endpoint device (i.e. laptop, tablet) and where thin clients are used, which do not have the ability to connect to network-based printers directly.
    • Session printers may be assigned using the “Session Printer” policy or the “Printer Assignments” policy. The “Session printer” policy is intended to be used to set default printers for a farm, site, large group, or OU. The “Printer Assignments” policy is used to assign a large group of printers to multiple users. If both policies are enabled and configured, the session printers will be merged into a single list.
  • Universal Printer – The Citrix Universal Printer is a generic printer object that is autocreated at the start of a session and is not linked to a printing device. When using the Citrix Universal Printer, it is not required to enumerate the available client printers during logon, which can greatly reduce resource usage and decrease user logon times. By default, the Citrix Universal Printer will print to the client’s default printer, however the behavior can be modified to allow the user to select any of their compatible local or network-based printers.

The Citrix Universal Printer is best suited for the following scenarios:

  • The user requires access to multiple printers both local and network-based which may vary with each session.
  • The user’s logon performance is a priority and the Citrix policy “Wait for printers to be created” must be enabled due to application compatibility.
  • The user is working from a Windows based device or thin client.


Other options for provisioning printers, such as Active Directory group policy, “follow-me” centralized print queue solutions, and other 3rd party print management solutions can be used to provision printers into a Citrix session.

Decision: Printer Drivers

Managing print drivers in XenApp and XenDesktop can be a tedious task, especially in large environments with hundreds of printers. In XenApp and XenDesktop there are several methods available to assist with print driver management.

  • User Installed – When adding a printer within a XenApp or XenDesktop session and the native print driver is not available, the drivers can be installed manually, by the user. Many different print drivers can potentially be installed on different resources creating inconsistencies within the environment. Troubleshooting printing problems and maintenance of print drivers can become very challenging since every hosted resource may have different sets of print drivers installed. To ensure consistency and simplify support and troubleshooting, user installed drivers is not recommended.
  • Automatic Installation – When connecting a printer within a XenApp or XenDesktop session, a check is made to see if the required print driver is already installed in the operating system. If the print driver is not already installed, the native print driver, if one exists, will be installed automatically. If users roam between multiple endpoints and locations, this can create inconsistencies across sessions since users may access a different hosted resource every time they connect. When this type of scenario occurs, troubleshooting printing problems and maintenance of print drivers can become very challenging since every hosted resource may have different sets of print drivers installed. To ensure consistency and simplify support and troubleshooting, automatically installed drivers are not recommended.
  • Universal Print Driver – The Citrix Universal Printer Driver (UPD) is a device independent print driver, which has been designed to work with most printers. The Citrix Universal Printer Driver (UPD) simplifies administration by reducing the number of drivers required on the master image. For auto created client printers, the driver records the output of the application and sends it, without any modification, to the end-point device. The endpoint uses local, device-specific drivers to finish printing the job to the printer. The UPD can be used in conjunction with the Citrix Universal Print Server (UPServer) to extend this functionality to network printers.

Decision: Printer Routing

Print jobs can be routed along different paths: through a client device or through a print server.

  • Client Device Routing – Client devices with locally attached printers (printers attached through USB, LPT, COM, TCP, etc.) will route print jobs directly from the client device to the printer.
  • Windows Print Server Routing – By default, print jobs sent to auto-created network based printers will be routed from the user’s session to the print server. However, the print job will take a fallback route through the client device when any of the following conditions are true:
    • The session cannot contact the print server
    • The print server is on a different domain without a trust established.
    • The native print driver is not available within the user’s session
  • Citrix Universal Print Server Routing – Print job routing follows the same process as Windows Print Server Routing except that the Universal Print Driver is used between the user’s session and the Citrix Universal Print Server.

The specifics with print job routing are based on the printer provisioning method. Auto-created and user-added printers can route print jobs based on the following diagrams:

Print job routing image

However, if the printers are provisioned as session printers, the print job routing options changes slightly. The jobs are no longer able to route through the user’s endpoint device.

Session printers image

The recommended option is based on the network location of the endpoint device, the user’s session and the print server.

  • Client Device Routing
    • Use for locally attached printer implementations.
    • Use if a Windows endpoint device and printer are on the same high-speed, low latency network as the Windows Print Server.
  • Windows Print Server Routing
    • Use if the printer is on the same high-speed, low-latency network as the Windows Print Server and user session.
  • Windows Print Server Routing (with Universal Print Server)
    • Use if non-Windows endpoint device and printer are on the same high-speed, low-latency network as the Windows Print Server.

Decision: Print Server Redundancy

Network-based printers, managed with a Microsoft print server or the Citrix Universal Print Server should be configured with redundancy in order to eliminate a single point of failure. The Citrix Universal Print Server redundancy should be defined within a Citrix Policy.

Experience from the Field

A print media company leverages Thin Clients and Windows-based workstations at the company headquarters. Network based printers are placed throughout the building (one per floor). Windows print servers reside in the data center and manage the network printers. XenDesktop and XenApp servers also reside in the data center.

A regional office has numerous Windows, Linux and Mac endpoints with network attached printers. A remote branch office has a few Windows workstations with locally attached printers.

Three different print strategies are applied:

  • Headquarters - A Citrix Universal Print Server is used for printing within the XenApp and XenDesktop session. Native print drivers are not required on the Windows based workstations. A session printer policy is configured per floor which connects the floor printer as the default printer. The policies are filtered based on the subnet of the thin client for proximity printing. Quality of Service (QoS) policies are implemented. Inbound and outbound network traffic on ports TCP 1494 and TCP 2598 are prioritized over all other network traffic. This will prevent HDX user sessions from being impacted by large print jobs.
  • Regional Office - A Universal Print Server is deployed within the regional office. The print job uses the Universal Print Driver and is compressed and delivered from the user’s session to the Universal Print Server, across the WAN. The job is then sent to the network-attached printer in the office.
  • Branch Office - Since all branch users work on Windows based workstations, auto-created client printers in conjunction with the Citrix Universal Printer Driver are used. Since the print job is delivered over ICA, the print data is compressed which saves bandwidth. The Citrix Universal Printer Driver ensures all printers connected to the client can be used within the XenApp or XenDesktop session without concern of the printer model used.


Properly integrating an application requires understanding compatibility and how the user/business requirements influence the appropriate delivery method.

Decision: Compatibility

VDI typically requires significant changes to be made to an organization’s application delivery and management strategy. For example, many organizations will take the opportunity to upgrade their desktop operating system and to simplify management by reducing the number of applications installed into the base image using techniques such as application streaming and application layering. These are significant changes that require comprehensive compatibility testing. Important compatibility requirements that may need to be verified include:

  • Operating system – The application must be compatible with the preferred operating system.
  • Multi-User – Some applications may be more appropriate for delivery via a hosted shared desktop or a hosted Windows App. In these situations, the compatibility of the application must be verified against the multi-user capabilities of a server operating system like Windows Server 2012R2.
  • Application architecture – It is important to understand whether the application includes 16-bit, 32-bit or 64-bit code so that an appropriate operating system can be selected. 16-bit code cannot be executed on a 64-bit operating system. However, a 16-bit application can be delivered to users as a Hosted Windows App from a 32-bit desktop based operating system like x86 editions of Windows 7, 8 or 10.
  • Interoperability – Some applications may experience complications if they coexist on the same operating system. Possible causes include shared registry hives, dll files or INI files as well as incompatible dependencies. Application interoperability issues should be identified so that appropriate remediation steps can be taken or an alternative delivery model selected.
  • Dependency – Applications may need to interact with each other to provide the users with a seamless experience. For example, applications that present information in a PDF format require a suitable PDF viewer to be available. Many times, the dependent (child) applications are version specific to the parent application.
  • Application virtualization – The use of application virtualization techniques, like streaming and layering, helps to simplify image management by reducing the number of applications installed into the base image. However, not all applications are suitable for streaming and layering because they may install device drivers, use COM+ or form part of the operating system.

Application compatibility can be achieved by doing a combination of manual, user testing, utilizing pre-verified lists maintained by the software vendor, or using an automated application compatibility solution, like Citrix AppDNA, which runs through thousands of tests to verify compatibility.

Decision: Application Delivery Method

It is unlikely that a single delivery method will meet all requirements. Based on the outcome of the application categorization assessment process and the overall image management strategy (installed images, scripted images and layered images), several application delivery methods can be considered.

Choosing one of the appropriate application delivery method helps improve scalability, management and user experience.

  • Installed app – The application is part of the base desktop image. The install process involves dll, exe and other files copied to the image drive as well as registry modifications.
  • Streamed App (Microsoft App-V) – The application is profiled and delivered to the desktops across the network on-demand. Application files and registry settings placed in a container on the virtual desktop and isolated from the base operating system and each other, which helps to address compatibility issues.
  • Layered App (Citrix App Layering) – Each layer contains a single application, agent or operating system. Layering simplifies ongoing maintenance, as an OS, agent and application exists in a single layer; update the layer and all deployed images containing that layer are updated. App Layering has two different delivery options:
    • Layered Image – By integrating one OS layer, one platform layer (XenApp and XenDesktop VDA, Provisioning Services agent) and many application layers, an administrator can easily create new, deployable images.
    • Elastic Layer – A XenApp and XenDesktop user can dynamically receive a new app layer based at logon. On a XenApp host, an elastic layer is session-aware, where an attached layer is only available to a user’s session granted access to the layer.
  • Hosted Windows App - An application installed on a multi-user XenApp host and deployed as an application and not a desktop. A user accesses the hosted Windows app seamlessly from the VDI desktop or endpoint device, hiding the fact that the app is executing remotely.
  • Local App – An application deployed on the endpoint device. The application interface appears within the user’s hosted VDI session even though it executes on the endpoint.

The following table provides recommendations on the preferred approaches for integrating applications into the overall solution.

In the table:

  • Y indicates Recommended.
  • N indicates Not Recommended.
  • o indicates Viable.
App Category Installed App Streamed App Layered App Hosted Windows App Local App
Common Y o Y o N
Departmental o Y Y Y N
User N o Y o Y
Management Y N Y o N

Experience from the Field

  • Energy – An energy company installs applications on the base image for the majority of users and streams departmental applications as required.
  • Financial – A banking customer maintains and deploys multiple desktop images containing user group focused applications as required by various departments.

Virtual Machines

Virtual resources require proper allocation of the processor, memory and disk. These decisions have a direct impact on the amount of hardware required as well as the user experience.

The key to successful resource allocation is to ensure that virtual desktops and applications offer similar levels of performance to physical desktops. Otherwise, productivity and overall user satisfaction will be affected. Allocating resources to the virtual machines above their requirements however is inefficient and expensive for the business.

The resources allocated should be based on the workload characteristic of each user group, identified during the assess phase.

Decision: Virtual Processor (vCPU)

For hosted desktop-based VDI models (hosted pooled desktops and hosted personal desktops), the general recommendation is two or more vCPUs per virtual machine so that multiple threads can be executed simultaneously. Although a single vCPU could be assigned for extremely light workloads, users are more likely to experience session hangs.

For hosted server-based VDI models (hosted Windows apps, hosted browser apps, hosted shared desktops), the proper vCPU allocation is based on the Non-Uniform Memory Access (NUMA) architecture of the processors.

NUMA architecture image

Each socket is divided into one or more NUMA nodes. Hosted server-based VDI models will often utilize 4 or more processors. Allocating more vCPU than the NUMA node contains results in a performance hit. Allocating a portion of a NUMA node to a virtual machine results in a performance hit if the portion allocated is not easily divisible by the size of the NUMA node. It is often ideal to allocate the number of cores within a NUMA node to a virtual machine or allocate ½ of the cores to a virtual machine, while doubling the number of virtual machines.

User Workload

  • Light
Operating System vCPU Configured for Scale vCPU Configured for Experience
Windows 7 2 vCPU 2 vCPU
Windows 10 2 vCPU 2 vCPU
Windows 2012R2 NUMA or ½ of NUMA NUMA or ½ of NUMA
Windows 2016 NUMA or ½ of NUMA NUMA or ½ of NUMA
  • Medium
Operating System vCPU Configured for Scale vCPU Configured for Experience
Windows 7 2 vCPU 3 vCPU
Windows 10 2 vCPU 3 vCPU
Windows 2012R2 NUMA or ½ of NUMA NUMA or ½ of NUMA
Windows 2016 NUMA or ½ of NUMA NUMA or ½ of NUMA
  • Heavy
Operating System vCPU Configured for Scale vCPU Configured for Experience
Windows 7 3 vCPU 4 vCPU
Windows 10 3 vCPU 4 vCPU
Windows 2012R2 NUMA or ½ of NUMA NUMA or ½ of NUMA
Windows 2016 NUMA or ½ of NUMA NUMA or ½ of NUMA


Windows 2012 R2 recommendations are based on the hosted Windows app, hosted browser app and hosted shared desktop VDI model.

Decision: CPU Optimization

In a shared and virtualized environment, a single user can monopolize CPU resources due to a runaway process or an intense data processing operation in Excel. If the processor is oversubscribed, it will not be able to fulfill other users’ requests, resulting in a hung session.

Citrix Workspace Environment Management, a component of XenApp and XenDesktop, incorporates CPU optimization. When a process consumes a certain percentage of the CPU over a defined timeframe, the process priority lowers from normal to low or very low, giving all remaining processes a higher priority and overcoming the runaway process risk. CPU optimization will also remember processes that triggered CPU protection and automatically start the process at a lower priority on future launches.

Most environments should enable CPU optimization as a default configuration.

Decision: Virtual Memory (vRAM)

The amount of memory allocated to each resource is a function of the user’s expected workload and application footprint. Assigning insufficient memory to the virtual machines will cause excessive paging to disk, resulting in a poor user experience; allocating too much RAM increases the overall cost of the solution.

The following table provides guidance on the virtual RAM that should be assigned based on workload.

User Workload

  • Light
Operating System vRAM Configured for Scale vRAM Configured for Experience
Windows 7 2 GB 3 GB
Windows 10 2 GB 3 GB
Windows 2012R2 256 MB per user 256 MB per user
Windows 2016 320 MB per user 320 MB per user
  • Medium
Operating System vRAM Configured for Scale vRAM Configured for Experience
Windows 7 3 GB 4 GB
Windows 10 3 GB 4 GB
Windows 2012R2 512 MB per user 512 MB per user
Windows 2016 640 MB per user 640 MB per user
  • Heavy
Operating System vRAM Configured for Scale vRAM Configured for Experience
Windows 7 6 GB 8 GB
Windows 10 6 GB 8 GB
Windows 2012R2 1024 MB per user 1024 MB per user
Windows 2016 1280 MB per user 1280 MB per user


  • Windows 2012R2 recommendations are based on the hosted Windows app, hosted browser app and hosted shared desktop VDI model.
  • Memory allocation above 4GB requires a 64-bit operating system.
  • If used, the Machine Creation Services and Provisioning Services cache in RAM amount should be added onto the virtual machine RAM specifications.

Decision: RAM Optimization

Even though users only work within a single application at a time, most have five or more applications running but idle. When a process moves from active to idle, the application and operating system releases a portion of the process’s active working set of memory to free up system resources. However, this is only a small percentage of the applications working set. The rest remains locked for the application, severely limiting available system resources.

Using RAM Optimization within Citrix Workspace Environment Management, applications that are idle (have not been interacted with by a user) for a certain time are forced to release excess memory until they are no longer idle. When the application returns to an active state, the released memory is loaded back into the active working set.

Most environments should enable RAM optimization as a default configuration. A RAM optimization exclusion list is available if certain processes encounter issues with optimization.

Decision: Disk Cache

The amount of storage that each VM requires will vary based on the workload and the image type. If creating hosted personal desktop without leveraging an image management solution, each VM will require enough storage for the entire OS and locally installed applications.

Deploying machines through Machine Creation Services or Provisioning Services can substantially reduce the storage requirements for each virtual machine. Disk space requirements for the write cache and difference disk will depend on application usage and user behavior. However, the following table provides a starting point for estimating disk space requirements based on machine sized with vCPU and vRAM as per the following guidelines:

User Workload

  • Light
Operating System Storage Space(Differencing Disk / Write Cache Disk)
Windows 7 10 GB
Windows 10 10 GB
Windows 2012R2 40 GB
Windows 2016 60 GB
  • Medium
Operating System Storage Space(Differencing Disk / Write Cache Disk)
Windows 7 15 GB
Windows 10 15 GB
Windows 2012R2 40 GB
Windows 2016 60 GB
  • Heavy
Operating System Storage Space(Differencing Disk / Write Cache Disk)
Windows 7 20 GB
Windows 10 20 GB
Windows 2012R2 40 GB
Windows 2016 60 GB

Decision: RAM Cache

Provisioning Services and Machine Creation Services have the capability to utilize a portion of the virtual machine’s RAM as a buffer for the storage cache. The RAM cache is used to improve the performance of traditional storage by sharing the virtual machine’s non-paged pool memory.

User Workload

  • Light
Operating System RAM Cache Configured for Scale RAM Cache Configured for Experience
Windows 7 128 MB 256 MB
Windows 10 128 MB 256 MB
Windows 2012R2 2GB 2GB
Windows 2016 4GB 4GB
  • Medium
Operating System RAM Cache Configured for Scale RAM Cache Configured for Experience
Windows 7 256 MB 512 MB
Windows 10 256 MB 512 MB
Windows 2012R2 4GB 4GB
Windows 2016 8GB 8GB
  • Heavy
Operating System RAM Cache Configured for Scale RAM Cache Configured for Experience
Windows 7 512 MB 1024 MB
Windows 10 512 MB 1024 MB
Windows 2012R2 6GB 6GB
Windows 2016 10 GB 10 GB


  • If used, the Machine Creation Services and Provisioning Services cache in RAM amount should be added onto the virtual machine RAM specifications.
  • If additional RAM is available on the host, the RAM Cache amounts can be increased to provide even greater levels of performance.

Decision: Storage IOPS

Storage performance is limited by the number of operations it can handle per second, referred to as IOPS. Under allocating storage IOPS results in a VDI desktop where apps, webpages and data are slow to load.

The following table provides guidance on the amount of storage IOPS generated per user based on workload and operating system. Storage I/O activity will be higher during user logon/logoff.

User Workload

  • Light
Operating System Storage IOPS (without RAM-Based Cache) Storage IOPS (with RAM-Based Cache)
Windows 7 10 IOPS 1 IOPS
Windows 10 12 IOPS 1 IOPS
Windows 2012R2 3 IOPS 0.5 IOPS
Windows 2016 4 IOPS 1 IOPS
  • Medium
Operating System Storage IOPS (without RAM-Based Cache) Storage IOPS (with RAM-Based Cache)
Windows 7 15 IOPS 1 IOPS
Windows 10 20 IOPS 1.5 IOPS
Windows 2012R2 4 IOPS 0.5 IOPS
Windows 2016 6 IOPS 1 IOPS
  • Heavy
Operating System Storage IOPS (without RAM-Based Cache) Storage IOPS (with RAM-Based Cache)
Windows 7 25 IOPS 2 IOPS
Windows 10 35 IOPS 3 IOPS
Windows 2012R2 5 IOPS 0.5 IOPS
Windows 2016 8 IOPS 1 IOPS

Decision: I/O Prioritization

With shared environments, every user’s I/O process receives an equal share of resources. A user running some I/O intensive task can affect mission critical applications. Citrix Workspace Environment Management allows administrators to define I/O priorities for processes.

If a process requires more I/O resources or the process is monopolizing I/O resources, the process and process priority is manually increased or decreased via the console. This advanced configuration is only used in special circumstances.

Decision: Graphics (GPU)

Without a graphical processing unit (GPU), graphical processing is rendered with software by the CPU. A graphical processing unit (GPU) can be leveraged to improve server scalability and user experience or enable the use of graphically intensive applications. During the desktop design it is important to decide how the GPU (if used) will be mapped to the virtual machines. There are three methods available.

  • Pass-Through GPU – Each physical GPU is passed through to a single virtual machine (hosted apps or hosted desktops).
  • Hardware Virtualized GPU – Using a hypervisor’s vGPU technology, a NVIDIA GRID or Intel Iris Pro is virtualized and shared between multiple machines. Each virtual machine has the full functionality of GPU drivers and direct access to the GPU.
  • Software Virtualized GPU – The GPU is managed by the hypervisor and intercepts requests made by the VDI desktops. This process is used if a GPU is not installed within the host.

In the table:

  • Y indicates Available.
  • X indicates Not Supported.

Citrix XenServer

  Pass-Through GPU Hardware Virtualized GPU (NVIDIA) Hardware Virtualized GPU (Intel) Hardware Virtualized GPU (AMD) Software Emulated GPU
XenDesktop Y Y Y X Y
XenApp Y Y Y X Y

Microsoft Hyper-V

  Pass-Through GPU Hardware Virtualized GPU (NVIDIA) Hardware Virtualized GPU (Intel) Hardware Virtualized GPU (AMD) Software Emulated GPU
XenDesktop Y X X X Y
XenApp Y X X X Y

VMware vSphere

  Pass-Through GPU Hardware Virtualized GPU (NVIDIA) Hardware Virtualized GPU (Intel) Hardware Virtualized GPU (AMD) Software Emulated GPU
XenDesktop Y Y X Y Y
XenApp Y Y X Y Y

User groups with a heavy use of graphical applications will often require the use of a NVIDIA hardware virtualized GPU. User groups who rely on office-based applications can have an observable benefit with the use of a hardware virtualized GPU from Intel.

Design methodology resource layer