At first, I was a little wary about Citrix Provisioning Server. When Citrix first acquired Ardence I thought, "it's just too good to be true". Since then, I've had the opportunity to deploy, maintain, and resolve issues with PVS for both desktop delivery and Data Center Delivery and I am now a believer. As with any product, there are the tricks and tools of the trade that make things work so much better. Here are just a few Do's and Don'ts with PVS.
Choose the Right Workload
PVS Targets are best served to application servers such as Web Servers, Front End Servers, Terminal Servers, XENapp Servers, and Virtual PC's. Choosing a target such as a database server can be pretty challenging and may require more scripting than it is worth it in the end. Workloads that have high disk read time may also hinder performance.
Choose the right write cache option 'right?'
Write cache is the temporary storage location used to place system writes, such as temp files, user profiles, and application log files. There are a few different places we can store these files:
- Write Cache on the PVS's hard drive is great for diskless machines. This is a great solution for LAB environments, training environments, or small workloads. Since the writes are performed over the network and the PVS servers disk holds the read and write cache for all targets, the write speeds could have a negative impact on the environment.
- Write Cache on the Target Devices RAM is a great solution for workloads that need fast temporary disk writes. This is a great solution for an Auto-CAD application or a high disk I/O driven application. The downside is that RAM that is used for caching is taken away from the target device, so there will be some limitations on 32 bit computers that can only use 4 GB of RAM. In many scenarios, RAM is also more expensive than storage so there may be an added cost.
- In most environments, Write Cache to the devices hard drive is appropriate. This can be on the devices actual hard drive or on shared storage.
The size of your write cache will depend on how much virtual memory and temp storage is used and how long the target device will remain booted.
Use your write cache to your advantage
Redirecting writes to the system drive off to the cache drive will improve performance of the target device. Common re-directions include:
- The system Page File
- The Print Spooler Directory
- Event Logs
- application log files and temp files
Anti-Virus makes it interesting
Anti-Virus software can really slow down an image in standard mode. This does not mean don't use it, just be smart about how you use it. If you are going to run Anti-Virus consider configuring excluding:
- boot sector scans
- boot scans
When Anti-Virus scans a file on the C drive, it is scanning within the shared vdisk on the PVS server, and therefore all systems that are sharing the vdisk will be effected by the scan. A boot scan can slow down the boot time of the device and even slow down all the systems attached to the vdisk while only one or two targets are booting.
XenApp Prep Tool
If you are straming XENAPP servers you should take a look at the XENAPP Prep tool. It is a wonderfule thing!!! The XENAPP prep tool is run once after installing XENApp for the first time. This tool prepares the XenApp server for streaming by removing the LHC and the RMdatabase. It also stops the IMA Service and the Citrix SMA service to prepare the system to be joined under a new name. It works by createing a new service so when the base image is streamed to any target, the XenApp Prep service starts and begins the personalization and integration into the XenApp farm. During boot, the service changes the STA ID, recreates the LHC, and adds the server to the farm (if it is not already added).
Run Device Optimizer Every time
The PVS device optimizer does all kinds of work in the back ground for us, it disables Windows Updates, disables indexing services, etc. Applications have the tendency to enable or turn on services after installations or updates, so running the optimizer every time before converting the image from Private to standard will ensure that those services get re-disabled...
Disable Un-Used Services
As with any virtual environment, disable services that are not being used. Things like Automatic Updates, BITS, Error reporting, indexing Service, Task Scheduler, Wireless Configuration, and EAP are services that may not be used in a PVS environment.
One thing i did find out recently is that the Provisioing Server uses the "File and Printer Sharing for Microsoft Networks" or in short "IPC$" for resetting the computer account password (every 7 days by default). So if your target devices are joined to the Domain, Do NOT disable "File and Printer Sharing for Microsoft Networks" found on the NIC card of the Target Device. This was one of those things that had me running around for days trying to figure out what went wrong...
Offload parameters could cause slow performance when enabled on the physical network adapter. Citrix recommends disabling Checksum Offload on the NIC of both the Provisioning Server as well as the target devices.
On the PVS Server:
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters - DisableTaskOffload 1
On the Targets:
HKLM\Sytstem\CurrentControlSet\Services\BNNS\Parameters - EnableOffload 0
HKLM\Sytstem\CurrentControlSet\Services\Tcpip\Parameters - DisableTaskOffload 1
Disable Spanning Tree or Enabling PortFast http://support.citrix.com/article/CTX117374
If you plan on Teaming your NIC's on the XENServer, be sure your are running PVS 5.1 or above.
Summary and related links
In summary, Making the right adjustments can help the performance of any Provisioned Desktop or server, but at the same time, you can make too many changes too fast and really break things. My advice is to make changes to the golden image slowly and with a systematic approach.
Here are a couple other posts that I've found interesting which can be applied to both Windows server and Windows Desktop computers in a stramed environment. Enjoy!