Tailing off of Part I (<a href="http://blogs.egroup.jasonmangone.com/?p=681" target="_blank">which can be found here)</a> , I will go more into detail on the technical benefits of running Server 64-bit over 32-bit in a Terminal Server environment.

On single core, older or lower-end servers, processing power tends to be the major bottleneck. But with most servers today being shipped with multiple processors or processor cores, the bottleneck shifts away from hardware.

<!--more-->
In this scenario, the 32-bit limitation on kernel memory often becomes the bottleneck—the amount of virtual memory that can be directly addressed is only 4GB, and half of which is allocated to the OS for kernel memory, drivers, system cache, etc. and then shared across all processes.  All other processes can only use a max of 2GB of virtual memory space (per process). This becomes an obvious limitation.

It is here that 64-bit builds soar to unprecedented levels.  The limit with the addressable memory space currently used in 64-bit versions of the Server OS is 16TB, and when divided into two it provides 8TB of virtual address space for both the OS and application processes (please note: current 64-bit versions only use a 40-bit addressable memory space, and the TRUE number for a 64-bit address is well into the EXABYTES). 8TB of memory space should be plenty for the immediate future (and if not, you might be working for NASA).

The Citrix XenApp (the artist formally known as Presentation Server) whitepaper does a pretty good job of outlining the benefits of running 64-bit as its backend. For servers with Quad processors (or cores), Citrix claims up to 200% increase in user density. 200%! Just think what the percentage would be if you had 8, 16, or more CPU cores in the servers hosting your farm.

The bottom line is simple—fewer servers will do more for less.