Deploying Desktop Director 2.0 for XenApp

Desktop Director gives you a nifty little helpdesk application that allows support personnel an insight into the end user experience when connecting to XenDesktop or XenApp.

This blog post details installing Desktop Director in a pure XenApp environment. My XenApp server is running Xenapp 6.5. The process itself is relatively simplistic but the first thing you need to do is get a copy of the software. This is available in the downloads section of the Citrix site, just log on with your MyCitrix id, browse to XenApp 6.5 (I access Enterprise Edition) and expand out the language you prefer. You should see a link like the below:

This separate iso contains the installation binaries. Simply access the ISO (burn it to disk or present it up to your VM etc) and open the Desktop Director folder. Double click on InstallDesktopDirector and work through the guided installation.

Desktop Director has 2 pre-requisites, .NT Framework 3.5 and IIS. The install routine took care of the installation of both of these for me. When asked for a XenDesktop controller I entered in the FQDN of my XenApp 6.5 controller server.

Once Desktop Director has been installed we need to configure the solution. This involves the following:

  1. Configure Desktop Director to contact one of our XenApp controllers.
  2. Allow Desktop Director through the firewall on the XenApp servers (port 2513).
  3. Configure each XenApp server for remote management.

To configure the Desktop Director server to contact XenApp, access the IIS Management Console and drill down to the DesktopDirector virtual application. In the right hand pane you will see “Application Settings”.


Double clicking allows us to configure the application settings. For XenDesktop an entry already exists for Service.AutoDiscoveryAddresses and it is this field that we populated earlier. This can be edited and the address of our XenApp server removed. For desktop Director to monitor XenApp we need to add another field for the application, Service.AutoDiscoveryAddressesXA.

To do this we simply click on the Add button on the top right of the screen.


We then name and populate our field.

We enter the server address of one controller per XenApp farm: Any of the other controllers in a XenApp farm are then used automatically for failover. Desktop Director does not load balance between controllers. If we are running multiple farms we separate the names of the designated controlelrs with commas. The Value field will look as below:


Once that’s done we just need to configure our XenApp servers. The next two steps can either be done manually or by using a GPO, for more than 2 or 3 servers, use of a GPO is the preferred method.

First we allow Desktop Director to connect to the controller servers on port 2513 (the old CMC port).


To maintain security the rule can be restricted to only allow access from the Desktop Director server.

We then enable Windows Remote Management on each XenApp worker server (Session Host). This can be done by running the WinRM QuickConfig command on each host.


This does three things.

  1. It creates a listener to listen on port 80 (which will need to be allowed through the firewall if it isn’t already).


  2. It sets the WinRM service to automatically start.


  3. It opens port 5985 on the server for external clients to manage the server. Again, this can be limited to the Desktop Director if required. This port is already configured as a disabled rule and can simply be enabled if required.

Once the above steps are done you should now be able to access Desktop Director using the URL http://servername/DesktopDirector.


As stated, WinRM can be configured using GPO’s and details on how to do that are at Equally, the firewall port (2513) can also be set using a GPO. This is true for our full administrative account. But what about helpdesk users ? Well, if they are full administrators on the XenApp servers then there is no problem. If a more restrictive assignment of rights is required this can be achieved by following the guide at




Optimise XenApp RAM and CPU Part 2

Following my earlier post ( I have done some digging and, thanks to the hard work done by Jeremy at J House Consulting and the advice he gives (, I can give what I think is a correct explanation of why the RAM and CPU are optimized in the way they are in the majority of XenApp deployment.

In a Windows 2003 32 bit environment server memory can be optimised either for System Cache or for Programs. The LargeSystemCache registry value ( found ain the registry at HKLMSYSTEMCurrentControlSetControlSession ManagerMemory Management) specifies whether the system maintains a standard size or a large size file system cache, and influences how often the system writes changed pages to disk.

Increasing the size of the file system cache generally improves server performance, but it reduces the physical memory space available to applications and services. Similarly, writing system data less frequently minimizes use of the disk subsystem, but the changed pages occupy memory that might otherwise be used by applications.

The value set for this key can be viewed in the server GUI by accessing the performance settings on the advanced tab of the system properties careen. There are two possible values for this key which are:

Value Meaning
0 Establishes a   standard size file-system cache of approximately 8 MB. The system allows   changed pages to remain in physical memory until the number of available   pages drops to approximately 1,000. This setting is recommended for servers   running applications that do their own memory caching, such as Microsoft SQL   Server, and for applications that perform best with ample memory, such as   Internet Information Services (IIS).
1 Establishes a large   system cache working set that can expand to physical memory, minus 4 MB, if   needed. The system allows changed pages to remain in physical memory until   the number of available pages drops to approximately 250. This setting is   recommended for most computers running Windows Server 2003 on large networks.


The LargeSystemCache is allocated from kernel memory area, which is shared with the paged pool memory and system page table entries. In a 32 bit environment paged pool memory is limited to a maximum of approximately 650MB however much physical RAM is installed on the server. Similar limitations exist for system page table entries. Reducing either of these in a Citrix environment may lead to increased paging and poorer performance.

In a 32 bit Citrix Presentation Server environment it is recommended that memory is optimised for Applications over System Cache to ensure that the maximum amount of RAM is available for kernel operations.

In a 64 bit environment the above limits have been increased and while the LargeSystemCache entry still exists in the registry its use has been deprecated.

In a Windows 2003 32 bit environment processor scheduling can be optimised either for Programs or Background Services.

Multi-tasking Operating Systems switch from task to task using various algorithms and heuristics giving the impression that they are multi-tasking whereas they are really processing each thread in turn. The time allocated to processing each thread is determined by the CPU scheduler. The choice of scheduling algorithm can be immensely important when it comes to determining the performance of a Server based Computing system such as Citrix Presentation Server.

Changing the processor scheduling option modifies the Win32PrioritySeparation value under the HKEY_LOCAL_MACHINESystemCurrentControlSetControlPriorityControl key, which consists of 6 bits (AABBCC).

  • Where AA =
    01 – longer timeslice interval
    10 – shorter intervals
  • Where BB =
    01 – timeslice can have variable length
    10 – timeslice has fixed length
  • Where CC =
    00 – foreground/background processes have same priority
    01 – foreground process gets 2 x boost compared to background process
    10 – foreground process gets 3 x boost compared to background process

When you set the performance option for processor scheduling in the GUI, you only see two possible choices for the duration of time allocated to a process:

  1. Programs – Registry value is 38 decimal, binary is 100110 = shorter intervals, variable timeslice length, 3 x boost
  2. Background Services – registry value is 24 decimal, binary is 011000 = longer timeslice interval, timeslice fixed length, no boost

Neither of these settings are optimal for a Remote Desktop Services Server, although the Programs option is the better of the two simply because shorter timeslices are mandatory for a Terminal Server environment.

However, in a Citrix Presentation Server environment the situation changes as Presentation Server provides functionality to optimize the environment over and above that provided by RDS.

If the CPU Utilization Management Feature introduced Citrix Presentation Server 4.0 Enterprise Edition and above has been enabled (which it is by default), the 3 x boost for the default Programs value makes this feature somewhat less effective. In these circumstances the variable timeslice length is often better fixed. Under these conditions it is suggested that the optimum value may indeed be 40 decimal, 101000 binary. That gives us small, fixed length timeslices, allowing the CPU Utilization Management Feature to efficiently do its job by giving each user a fair share of the CPU by modifying the normal job priority scheduling in the operating system.

Setting the Win32PrioritySeparation value to 40 decimal will produce a message similar to the following in the Application Event Logs once the “Citrix CPU Utilization Mgmt/Resource Mgmt” service is next restarted.


Event Type: Warning
Event Source: CTXCPUUtilMgmt
Event Category: (1)
Event ID: 1591
Date:  22/03/2008
Time:  12:34:28 AM
User:  N/A
Computer: CTX001

Windows is using a custom priority separation value and CPU Utilization Management performance may be degraded. To optimize CPU Utilization Management performance, on the Advanced tab of the System Properties dialog, open Performance Options and select Background Services. Then restart the CPU Utilization Management service.

From the above it can be seen that Citrix Best Practice when CPU Utilization Management is enabled is to set Processor Scheduling to favour Background Services. If processor performance remains a bottleneck or a very high number of conext switches are observed then it may be worthwhile changing the value of this key to 40.


In short it can be seen that the “default” settings in a 32 bit XenApp environment should be to optimize RAM for Programs and CPU for Background Services and in a 64 bit environment optimize CPU for Background Services UNLESS CPU Optimization has been disabled.

HDX Mediastream and Adaptive Display

Citrus recommend  that media is streamed to the end point whenever available bandwidth is higher than the bit rate of the video. Where there is not sufficient bandwidth Adaptive Display should be used. But what is the bit rate of differ video types ? There’s a handy table below obtained fromWikipedia:

[edit]World Wide Web HD resolutions

Source Codec Highest resolution (W×H) Total bit rate/bandwidth Video bit rate Audio bit rate
Amazon Video On Demand(formerly “Unbox”) VC-1[2] 1,280×720[3] 2.5 Mbit/s[3]
BBC iPlayer H.264[4] 1,280×720[5] 3.2 Mbit/s[4] 3 Mbit/s[4] 192 kbit/s[4]
Blockbuster Online (720p) 1,280×720[6] 2.5 Mbit/s[6] (1080p) 1,920×1,080[6] 3.5 Mbit/s[6]
DaCast VP6H.264[7] 7680×4320 5 Mbit/s[8]
Hulu On2 Flash VP6[9] 1,280×720[10] 2.5 Mbit/s[11]
iPlayerHD FLVQuicktimeH.264MP4 H.264[12] 1,920×1,080[13] 5 Mbit/s[14]
iTunes/Apple TV QuickTime H.264[15] 1,280×720[15] 4Mbit/s[16]
Netflix Watch Instantly VC-1[17] 1,280×720[18] 5 Mbit/s[19] 2.6 Mbit/s and 3.8 Mbit/s[20]
PlayStationStore Movies & TV Shows H.264/MPEG-4 AVC[21] 1,920×1,080[21] 8 Mbit/s[21] 256 kbit/s[21]
Vimeo H.264[22] 1,920×1,080[23] 4 Mbit/s[24] 320 kbit/s[25]
Vudu H.264[26] 1,920×1,080[27] 4.5 Mbit/s[28]
Zune Video (formerly “Xbox Live Marketplace Video Store”) 1,920×1,080[29] 3 Mbit/s[30]
YouTube H.264/MPEG-4 AVC 4,096×2,304[31]

As you can see, a user should have a minimum of 2.5Mbps before you even think of redirecting the video.

Optimise XenApp RAM and CPU

I see a lot of deployments of XenApp and / or Terminal Services on 32 bit systems, typically Windows Server 2003 R2 and, while its old hat, I thought it’s still worth taking a few minutes to make a note of the correct settings for optimisation of RAM and CPU in a thin client environment. When you first install Windows Server 2003 R2 the default performance settings for RAM and CPU before the operating system has had a role assigned are as below:


Once the Terminal Services Role has been installed these are changed to:


At a very basic level, these are the correct settings to use. But why ? For CPU, this forces the CPU to allot less time to a task before switching between tasks. In a service based environment (for SQL or Exchange for example) the CPU should be optimised for services so that the CPU allots more time to a single task before switching to any different task requiring processor time. As servers hosting services tend to have multiple cores this reduces context switching and results in higher performance for long running tasks.

In a thin client environment where multiple users are competing for processor time perceived performance is enhanced if the processor provides some time to each user. That is, if it can switch between threads more quickly. To do this, we optimise for programs in the GUI.

Regarding memory, the limiting factor in a 32 bit thin client server based computing environment is not necessarily user RAM but, more often, paged pool RAM and non-paged pool RAM. These are limited to around 650MB and 256MB respectively (for Windows Server 2003 – these limits have been removed somewhat in Windows 2008). These limits also hold true for Windows Server 2003 r2 Enterprise Edition. The server may have 32GB of RAM, for example, but will still have these small amounts of RAM available for end user tasks. If we optimise the RAM for programs then this reduces the amount of RAM available for these system type processes … the above figures are reduced still further. As paged pool RAM is consumed the server may start to page, even though there is ample spare user RAM. Even more concerning, if non-paged pool RAM is depleted this cannot be paged and, in the worst case, the server may even blue screen.

I hope the above brings some understanding as to why the above are the default settings. Some items to bear in mind:

  1. Mark Russinovich has an excellent article on RAM which applies to thin client environments at
  2. Jeremy Saunders has written an outstanding article on Processor Scheduling at
  3. RAM can be set to use prefer System Cache by setting the key HKLMSYSTEMCurrentControlSetControlSession ManagerMemory ManagementLargeSystemCache to 1
  4. Processor Scheduling can be further optimised by setting the key HKEY_LOCAL_MACHINESystemCurrentControlSetControlPriorityControlWin32PrioritySeparation to 40

Why do people change these settings to the exact opposite of the defaults ? I have no idea but hope that someone can enlighten me.

Deploying the Configuration Logging Database in XenApp 6

This blog post will walk you through deploying the configuration logging database in XenApp 6. I’ll be deploying the database on SQL 2008 SP1 running on Windows 2008 SP2 32 bit.

The first thing to do is create a standard domain account to own and connect to the SQL server database. I’ll call my account svcConfigLogging. The account should be set so that its password never expires.


Next, we create a blank database in SQL. I have called mine XAConfigLogging. You should follow best practice by pre-setting the database and log file sizes, holding them on separate disks, setting up backup plans etc.


We now add the service account created above (svcConfigLogging) to SQL as a logon. The default database for the logon is set to the database created above (XAConfigLogging).


Grant the user “db_owner” role access privileges.


As the database and security are created we can now use the Delivery Services Console to create the tables and objects in the database and the connection. To do this, right click the farm name and choose “Farm Properties”.



Select Configuration Logging and then click on the “Configure Database” button.


Enter the fully qualified domain name (FQDN) or IP address of the SQL server hosting the database created above (XAConfigLogging) and the credentials of the account created earlier which has db_owner rights to that database (svcConfigLogging).


Select the database created above (XAConfigLogging)

Change use Encryption to “No” (use of encryption requires the use of SSL certificates. As these are not in place a connection error will be generated).


Click on the “Test Database Connection” button

The connection should be successful (if it isn’t you will need to go back and check the settings entered).

Clicking on “Finish” will return you to the configuration screen.

The balance of the settings can now be configured. If you do not tick the “Log administrative tasks to Configuration Logging Database” then configuration logging does not take place.

Click on OK to complete configuration.

You can now make changes to the configuration of XenApp and they will be recorded to the database.

To view changes made to the configuration select the “History” node in the Delivery Services Console.



Clicking on the “Set Filter” link allows the SELECT statement to retrieve from the database to be constructed using the GUI.

Clicking on the “Get Log” link will retrieve the changes made within the constraints of the filter applied.


“Standard” administrators will have their changes logged to the database but will not be able to read from the database by default (i.e. will not be able to retrieve the log in history). To do this they need to be granted EXECUTE permissions against the stored procedures for the XAConfigLogging database.


The permissions required for administrators to the database are detailed at If security is not a concern then administrators can be granted db_owner rights to the database. Granting of rights is most easily achieved using domain groups.