Archive for December, 2011

Optimise XenApp RAM and CPU

Thursday, December 29th, 2011

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 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache to 1
  4. Processor Scheduling can be further optimised by setting the key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\PriorityControl\Win32PrioritySeparation 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.

Securing NetScaler / AGEE interface

Monday, December 19th, 2011

By default when you install a NetScaler or AGEE the admin interface can only be connected to by HTTP. To configure the device to allow you to connect by HTTPS complete the following steps:

1) Connect to the devices configuration utility using a browser
2) Expand the Network node
3) Click on RPC
4) Select the NSIP (NetScaler admin IP Address)
5) Click Open
6) Tick the Secure check box
7) Click OK