I have been wondering about the need for fault-tolerant architectures specifically with regard to the servers hosting the virtual desktops. I definitely believe the supporting infrastructure should be fault-tolerant, but what about the myriads of servers running just a hypervisor and hosted desktops?

Here are my two premises:

1. Virtual desktop adoption right now is primarily driven by cost savings, but most architectures required to support virtual desktops are expensive.

2. Fault-tolerance increases the architectural cost so it makes sense to only design fault tolerance into an architecture when either the impact or the risk of failure are high.

In some situations, such as when the user has access to only a single dedicated or assigned desktop, it makes sense that desktop would need to be highly available. The impact of a user not having a desktop available would be high. However, let's consider the case of a desktop pool where a user could be assigned any one of a 1000 desktops. In this situation of a single desktop becomes unavailable, the user could simply reconnect and get the next available desktop. Similar to a car rental agency, as long as the extra capacity exceeds the number of unavailable resources no user goes without access.

In a physical environment, when my desktop crashes, I maybe shout some disappointing statements about losing my unsaved work and then reboot, I am usually up and running again within five minutes. In a virtual environment, the end-user experience is similar. When the virtual desktop becomes unavailable, the user makes statements about lost work, reconnects to the desktop pool and then logs back in - usually within five minutes. The impact of the lost desktop is minimal because of extra capacity available to handle the temporary loss of resources.

One obvious difference between the physical workstation crashing and the loss of a virtual desktop scenario posed above is that a failed hardware component in a virtual environment would impact all the desktops on a host, not just a single user. So, the trick is to calculate the impact of losing a host server or two and compensate by adding additional capacity. In most cases that additional capacity will be less expensive than incorporating fault-tolerant server components into every server.

Since I believe the community is always more wise than a single person, in this case me, I thought I would solicit some feedback around my thoughts. Of course, my wisdom does not extend to figuring out how to get poll to show up in my blog, so if you would like to vote or view the results of the poll question shown below, you will need to click here If you have an opinion not covered by the poll please add a comment to my blog.

As always if you found this blog useful and would like to be notified of future blogs, follow me on Twitter @pwilson98.

If you have read some of my recent blogs, you know that I have been spending time testing XenDesktop 4 and Microsoft Windows 2008 R2 Hyper-V. I thought I would take a moment and highlight the top seven things I have learned during this testing. Some of these items I briefly mentioned in my previous blog Optimizing Windows 7 for FlexCast Delivery posted a few weeks ago.

1. Use Fixed-Size VHDs for the Drives

This tip perhaps has the greatest impact on performance. Quite honestly I had no idea about how much of a difference disk alignment influences performance until I started testing with a dynamic VHD. When using local disks for storage, this is generally not noticeable. However, when using block-level SAN storage, the difference could be significant. Using a fixed disk VHD prevents both fragmentation and disk alignment issues by pre-allocating all the required space when the file is created and not requiring that extra footer at the end of the file and effectively creating a SAN friendly file.

Numerous resources are available on internet to discuss this topic, but for the sake of simplicity, I will try to give a brief synopsis here. The smallest block of data written by the SAN is called a "stripe" and it normally crosses several sectors on the underlying LUN. The NTFS file system is formatted with blocks of data or clusters. A file is written to a cluster, which in turn causes a write to the SAN "stripe". When the data block written from the virtual hard disk aligns with the SAN stripe, then only one disk is affected during the write. If that SAN stripe resides on a RAID1 or RAID10 array, then two writes will occur (a 2x write penalty) because the writes will be written on the primary disk and then again on the mirror disk. If SAN is on a RAID5 array, a three data disks and a fourth parity disk will be accessed causing four writes (4x write penalty) in a single parity RAID5 configuration.

When the data block is out of alignment with the SAN, that same single disk write is spread across multiple disks. For instance, if that write is on a RAID1 or RAID 10 array the single write operation becomes four write operations on the SAN. If it is on a RAID5 single parity array, the write operation becomes eight operations on the SAN. As you can see, a single write operation can quickly create a backlog of write operations on the SAN.

Unfortunately, the dynamic VHD file format needs to manage the size of the file, so at the end of each VHD file, is included a 512 byte footer. Every time a data block is added to the dynamic VHD, the footer is moved to the end of the file. Since the VHDs are normally written in 2MB blocks, the addition of this footer is virtually guarantees alignment issues with underlying SAN storage as it changes the offset of the file next to it. To further add to the overhead, as the file expands, the additional data blocks will be placed at the next available location on the NTFS partition, causing fragmentation of the file across multiple stripes.

2. Format VHDs with the Windows 7 Diskpart Utility

Windows XP setup and Diskpart utility create the boot partition with a 31.5 byte offset that causes misalignment with block-level disk subsystems. The Diskpart utility included with Windows 7 / Server 2008 has been corrected to create the boot partition at a more alignment-friendly offset. In essence, if the disk is over 4GB the utility will set the offset to 1024KB by default. If it is under 4GB, which is the case for most write-cache drives, it will set the offset to 64KB by default. I recommend manually creating the partition for VHDs and verifying it as well. To learn more about Windows Server 2008 disk alignment and how to configure it correctly with Diskpart, see the Microsoft KB #929491.

3. Include the .BIN File in the Disk Space Calculations

Microsoft Hyper-V always allows a machine to be placed in a suspended state, such that the contents of the machine's RAM is saved to disk for later retrieval when the machine is resumed, similar to hibernation on a laptop. In order to prevent possibility that disk space is not available in the future for saving the RAM contents, when a virtual machine is started, Hyper-V creates a .BIN file that is equal in size to the RAM configured for the virtual machine. This .BIN file cannot be disabled or deleted and must be present for the virtual machine to start. The file is also stored in the same folder as the virtual machine's configuration file. Therefore, when calculating the necessary disk space on a SAN to support virtual machines, be sure to add in space equal to the RAM of the virtual machines.

4. Configure Two Network Interfaces When Using Provisioning Services

The default network adapter for a Hyper-V virtual machine is the synthetic adapter, which is optimized for a virtualized environment. However, this adapter is purely virtual and cannot be associated with any BIOS-level hardware, virtualized or not. Since PXE booting requires a BIOS-level interface, the synthetic adapter cannot be used. Instead, Hyper-V includes a legacy network adapter that includes a BIOS-level integration and that supports PXE booting. The legacy network adapter must be added to the virtual machine and set as the default boot device.

To provide the best performance, the guest image should include both adapters so that the legacy adapter is used for PXE booting and the higher-performing synthetic adapter is used to pass the network traffic after the operating system boots. Both adapters can be connected to the same logical network since the synthetic NIC has precedence over the legacy network card in the route table.

5. XenDesktop Integration with VMM is Still Developing

The System Center Virtual Machine Manager (VMM) server provides numerous APIs for integrating with Hyper-V. XenDesktop supports the standard APIs for starting, suspending, resuming, and creating virtual machines. However, XenDesktop 4 does not utilize the Microsoft VMM GetRating API for any desktop-related operations. Without the support for the GetRating API, the XenDesktop infrastructure cannot intelligently placing virtual machines when creating or starting them.

When creating virtual machines with the XenDesktop Setup wizard, the wizard retrieves a list of hosts managed by the VMM server and then evenly distributes newly created machines across all the hosts that VMM has registered with it. In situations where the machines are being created on identical host hardware and for the first time, this behavior is desirable. However, if the host capacity is not identical or if they already have virtual machines the Setup wizard may overburden the host.

If you need to deploy additional virtual machines to unequally loaded hosts, one option is to use a VMM staging server, which has only servers of equal capacity registered with it. The XenDesktop Setup wizard can then be pointed to the VMM staging server. After the wizard completes, re-register the Hyper-V hosts with their permanent production VMM server, and adjust the desktop group properties as appropriate in the XenDesktop farm.

6. Virtual Machine Manager Design is Critical

Microsoft recommends protecting against failure by virtualizing the VMM Server and placing it on a highly-available cluster. However, this approach only protects against hardware failure, not against software failure. In situations where the VMM server is running but the service fails to respond communications between XenDesktop and VMM Server come to a halt. When the communication link is broken, the XenDesktop DDC stops sending connections to the desktops hosted on that VMM Server. As of now, protection against this type of failure is currently not available without the creation of custom detection and complex failover routines. For the time being, the best approach is to limit the number of desktops managed by a single VMM Server to around 1,000 so that it will not get overloaded.

7. Windows 7 Behaves Well When Virtualized

Windows 7 is a virtualization-aware operating system. Windows 7 includes several features which improve its performance in a virtualized environment. First, Windows 7 includes the Hyper-V Host Integration Services as part of the base operating system. Second, Windows 7 notifies the hypervisor when it is idle so the hypervisor does not schedule guest operations. Finally, Windows 7 provides improved storage and optimized page file management. When compared to Windows XP, an operating system that has no idea it is being virtualized and is supposed to reach end-of-life this year, Windows 7 is an attractive solution.

If you found this blog useful and would like to be notified of future blogs, please feel free to follow me on twitter @pwilson98.

Introduction

With the release of XenDesktop 4, Windows 7 is now a supported operating system for XenDesktop. Since Microsoft announced the end-of-life for Windows XP many institutions are considering moving their user population to Windows 7. Since Microsoft and Citrix work closely together, I was assigned to work at their Enterprise Engineering Center on some preliminary scalability testing XenDesktop 4 on Microsoft Hyper-V 2008 R2. Out of that joint operation, came several recommendations around deploying Windows 7 with XenDesktop which I wanted to get out to the field and disseminated as quickly as possible.

Microsoft has built Windows 7 as a virtualization-aware operating systems and as such it is already optimized for such an environment. However, my initial investigation has yielded the following performance optimizations that can be further applied to Windows 7 when deploying it via XenDesktop (XD) and/or Provisioning Services (PVS). Of course, as in the original [Windows XP Optimization blog|ocb:/2008/10/24/Windows XP Performance Optimizations for XenDesktop and Provisioning Server vDisks|Windows XP performance optimizations], none of the optimizations below are required, but they can be used if you want to streamline your Windows 7 desktop delivery. Used for this blog was Windows 7 Enterprise Edition.

Installing Windows 7

This may be obvious, but when creating the virtual hard disk (VHD) to store the Windows 7 image, use the Windows 7 Diskpart utility, not the Windows XP/2003 version. In other words, do not create the VHD from a Windows Server 2003 host and then install Windows 7 on it. The Windows XP/2003 version of Diskpart places a disk signature to the beginning of the disk and then starts the partition in the last few sectors, guaranteeing that the file system blocks will be out of alignment with the underlying storage system. I don't want to spend a lot of time here on disk alignment issues, but if you want to know more about disk alignment, check out section 3.3 of the Virtuall (PQR) whitepaper on VDI storage, available at http://virtuall.eu/download-document/vdi-storage-deep-impact.

If Provisioning Services will be used, create virtual machines with multiple network interface cards (NIC) in the operating system image and on the underlying hypervisor hosts. Create two networks, one without a gateway to manage the streaming data from the provisioned server and one network that has a gateway for all other traffic. If you are planning on using Windows 7 with Microsoft Hyper-V, you will need two network cards – one will be the legacy network adapter for the PXE booting with provisioning services and the other will be the synthetic network adapter used for all other network traffic. The dual NIC configuration will provide the best performance on Hyper-V, since the synthetic NIC is optimized for a virtualized environment and has a higher throughput than the legacy NIC required for PXE booting. When the host is not Hyper-V, dual NICs will still allow the "disk traffic" from PVS to be separated from the normal ICA and network traffic of the workstation.

Also, if using Provisioning Services, do not join the Windows 7 image to the domain prior to creating the vDisk image. Create the vDisk and then boot from the vDisk image in private mode, join it to the domain. After the machine reboots from the domain join, install the Virtual Desktop Agent, shut it down and switch the vDisk to standard (read-only) mode and use that version of the vDisk for XenDesktop. For more information on the process of creating a vDisk image, see the Citrix Knowledge Base article CTX121028 – http://support.citrix.com/article/CTX121028.

Removable Windows 7 Features

Once you have installed Windows 7 into the VHD, you will find many new features. Windows 7 with its media-rich focus does install a couple of features that can be removed before taking an image if the users will be accessing Windows 7 through XenDesktop. Here are the features I saw installed with Windows 7 Enterprise that can most likely be uninstalled in the XenDesktop environment.

• Windows Media Center: XenDesktop users are unlikely to be watching TV on their desktop.
• Windows DVD Maker: Most users will not be creating DVDs through their XenDesktop.
• Tablet PC Components: Users of XenDesktop are not likely to be using a tablet PC for connectivity.

Please note that if you are reviewing these optimizations to use FlexCast technologies to deliver locally streamed desktops, you may want to leave these features engaged, since users could be doing any of those tasks listed above.

Run the XenConvert Optimizer

The quickest way of optimizing Windows 7 is to use the optimizer that comes with XenConvert. The XenConvert Optimizer tool will automatically set the correct values on a Windows 7 operating system for many of the items that I had included in the previous Windows XP blog. The optimize button can be found on the following screen in XenConvert:

Hint: The Optimizer can be manually executed outside of XenConvert by running C:\Program Files\Citrix\Provisioning Services\TargetOSOptimizer.exe.

Unfortunately, the optimizations usually upset the Windows Security system because it disables Windows Update. After optimizing, the Action Center will now show a message with an error. To stop the message, go to the Action Center and disable security messages for Windows Update and any other services that you have other software to support. For instance, in my environment I am using McAfee Security for the other options, so I have stopped the warning messages from appearing in Action Center.

Settings for the Default User Profile

This section lists a few of the settings that will improve the user experience but are set at the user profile level. Keep in mind that creating a default user profile in Windows 7 is quite a bit more complex than in previous versions of Windows. I have provided guidance around how to modify the default user profile at the end of this section, but you might want consider applying these changes through Active Directory Group Policy.

Force Offscreen Compositing for Internet Explorer

This setting is disabled by default in Windows 7 with Internet Explorer 8 and is still recommended for XenDesktop 4. Turning this setting off removes any of the flickering that may display when using Internet Explorer through XenDesktop, by telling Internet Explore to fully render the page prior to displaying it. To change it, complete the following steps:

1.    Open Internet Explorer
2.    Select Tools >> Internet Options from the menu
3.    Select the Advanced tab
4.    In the Browsing section, enable the checkbox for "Force offscreen compositing even under Terminal Services"
5.    Click OK to save the changes
6.    Restart Internet Explorer

More information available at http://support.microsoft.com/kb/271246/en-us

Remove the Menu Delay

With Windows 7, the Start menu has a built-in delay of 400 milliseconds. To speed the menu response time, follow these steps to remove the delay:

1.    Start the Registry Editor (Regedit.exe)
2.    Navigate to HKEY_CURRENT_USER\Control Panel\Desktop{color}
3.    Set the value of MenuShowDelay to 0
4.    Exit the Registry Editor

Remove Unnecessary Visual Effects

Disabling unnecessary visual effects such as menu animations and shadow effects that generally just slow down the response time of the desktop. Keep in mind that right now XenDesktop 4 with Windows 7 doesn't support the Aero effects but that is on the roadmap.

1.    Open Control Panel
2.    Select the System applet
3.    Click Advanced System Settings on the left
4.    Click the Settings button under the Performance section
5.    Click "Adjust for best performance" radio button
6.    If you want to keep the ClearType font settings, enable the "Smooth edges on screen fonts" checkbox
7.    If you want to keep the XP Visual Style, scroll to the bottom and check the last box titled "Use visual styles on windows and buttons"
8.    Click OK twice to close the dialogs and then exit the System Properties screen

Set the Default Behavior for the Power Button

When using XenDesktop 4, setting the default behavior to "Log off" will be the best action. Users can still select other available options, but this selection will probably make the most sense and allow the Desktop Group settings to control whether the virtual workstation reboots or not at logoff. To change the default setting, complete the following steps.

1.    Right-click the Taskbar or Start button
2.    Click Properties
3.    Select the Start Menu tab
4.    Select the appropriate action under Power button action:
5.    Click OK to save the default action

Make the User Profile the Default User Profile

Since the changes above apply to every user, the quickest way to apply them for all users logging onto the workstation is to set them in the default user profile. In Windows XP you could copy the profile over to the default user, however in Windows 7 the "Copy To" button has been disabled for every profile except the Default User (the one you are most likely to replace). Instead now with Windows 7 there is only one method of replacing the default user profile, which is to use the "CopyProfile" function of Sysprep. If you don't know how to do this, (and I did not want to learn it) you might want to check out the following Microsoft Support article, "How to customize default user profiles in Windows 7" --http://support.microsoft.com/kb/973289

For those readers wanting a bit more background as to the changes and options available, you can check out the Deployment Guys blog at http://blogs.technet.com/deploymentguys/archive/2009/10/29/configuring-default-user-settings-full-update-for-windows-7-and-windows-server-2008-r2.aspx.

Not wanting to "sysprep" my Windows 7 golden image, I went looking for an easier solution. I found it. I used the Forensit User Profile Manager 1.6 Vista tool available at http://www.forensit.com/desktop-management.html. This is a free tool (at least right now) and it replaces the Windows 7 profile management dialog with their own which will allow you to copy over the default profile. When you remove it, (which I did so the vDisk users will not be able to manage profiles) the default behavior returns and you cannot choose the "Copy To" any more.

NOTE: As before, be sure to remove any user or machine specific data for the ICA Client, the ICA Streaming Client, Password Manager, and EdgeSight before copying the profile over. Since the image prep for these items is beyond the scope of this blog, I will save it for a topic another day.

Settings for the Machine

This section provides a list of the optimizations that will affect all users of the image. These settings are usually set after logging in as an administrator. Several of the optimizations from the Windows XP blog are handled when using the XenConvert Optimize tool mentioned at the beginning of the blog. This section represents the remaining ones.

Power Configuration Settings

Two of the power settings can adversely affect the performance of Provisioning Services. One of them is the hard disk power savings. If the PVS server is using a local hard disk for the vDisk cache, you do not want the operating system to power down the local drive. The other setting is the Hibernate setting. The PVS Optimizer tool will disable hibernating, but you can manually do it as well. Here are the steps for disabling the power settings:

1.    Open Control Panel
2.    Select the Power Options applet
3.    Click Change Plan Settings
4.    Click Change Advanced power settings
5.    For the default power scheme, set "Turn off hard disks after" setting to Never
6.    You may want to repeat this procedure for the other power plans
7.    Click OK to save the changes
8.    Exit the Power Options applet

Modify the Windows Service Timeout

With Windows 7, the possibility still exists that in environments with large amounts of virtual machines rebooting simultaneously that Virtual Desktop Agent (VDA) may fail to register because the Windows Service timeout is reached before Citrix Desktop Service starts. I recommend changing the 30-second default to 120-seconds to give the service plenty of time to start before the Citrix Desktop Service starts.

1.    Start Registry Editor (Regedit.exe)
2.    Navigate to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
3.    If the ServicesPipeTimeout value is not present, use the following steps to create it:
       a.    Click theControl
       b.    On the Edit menu, point to New, and then click DWORD Value
       c.    Type ServicesPipeTimeout, and then press Enter
4.    Right-click the ServicesPipeTimeout key and then click Modify
5.    Click Decimal
6.    Type 120000, and then click OK (120-seconds in milliseconds)
7.    Quit the Registry Editor
8.    Reboot for the changes to take effect

Disable Remaining Unnecessary Services

You can go through the list of other services that are configured on Windows 7 and disable any ones that will not be used in your environment. One nice thing about Windows 7 is that some of the more critical services will explain in the description what will not work if the service is disabled. Here are few services that you may be able to disable:

Function Discovery Resource Publication: Publishes this computer and resources attached to this computer so they can be discovered over the network. If this service is stopped, network resources will no longer be published and they will not be discovered by other computers on the network. If the device will not be sharing any resources, you can safely disable this service.

Background Intelligent Transfer Service: Transfers files in the background using idle network bandwidth. If the service is disabled, then any applications that depend on BITS, such as Windows update or MSN Explorer, will be unable to automatically download programs and other information. In most instances this service can be disabled safely since auto-updating features are disabled for standard (read-only) vDisks.

Desktop Windows Manager Session Manager: Provides Desktop Window Manager startup and maintenance services. Basically, it is used or Aero and other special effects, like transparency and glass window frames, 3-D window transition animations and Windows Flip. If you are following the guidelines above to reduce most of the special effects, or the video card drivers on the host does not support Aero, you can safely disable this service.

Theme Service: Provides user experience theme management. As above, if you are following the guidelines above to reduce most of the special effects this is a prime candidate for being disabled.

Offline Files: The offline files service performs maintenance activities on the offline files cache, responds to user logon and logoff events, implements the internals of the public API, and dispatches interesting events to those interested in offline files activities and changes in cache state. Since most XenDesktops will be running in a data center remotely, the need for offline files and synchronization is not present.

Most of the other services are not set to automatic startup in the Enterprise edition, so I didn't bother reviewing them.

Final Recommendations

Here are few final recommendations, two of which are carry-overs from the Windows XP optimization blog that I believe still apply for Windows 7.

Flush the DNS cache

Although I have not had any issues with Windows 7 and ip address caching, I am leaving this recommendation in the list because it will not hurt anything and it only takes 10 seconds to complete. Flush the DNS Cache using the ipconfig /flushdns command. This prevents any IP addresses cached on the read-only disk from interfering with DNS resolution at a later date.

Run ChkDsk

This recommendation is a good idea since it verifies the file system or disk has no missing file links. Run chkdsk -f from a command prompt and verify that no issues are present.

Re-enable Windows Security Center

The XenConvert process seems to disable the Windows Security Center service resulting in yet another message in the Action Center. Unfortunately, I was unable to find any way to disable that message. So my current solution was to just re-enable Security Center after XenConvert disabled it during the image creation process and leave all the other warning messages disabled as mentioned at the beginning.

Wrapping it up

I realize that Windows 7 is a new operating system and as I learn more about its behavior, I will try to get that information out here on my blog. Of course comments are welcome if readers have optimization ideas that they have tried with Windows 7 and either XenDesktop or Provisioning Services.

As for my next blog topic, I am quite excited to share with you information regarding my experience at the Microsoft EEC which focused on testing XenDesktop 4 with Windows Server 2008 R2 Hyper-V. Stay tuned!!

If you found this blog useful and would like to be notified of future blogs, please feel free to follow me on twitter @pwilson98.

I had a few extra cycles this week, and I figured I had better get this second blog completed before I start four straight weeks of travel on a Hyper-V R2 XenDesktop project. Similar to my previous blog Changing XenDesktop Ports - Core Farm Ports, I have once again set the new port number to 5555 or 55555 (since on the first screen below two different port settings exist) in the examples to help you easily identify what is being changed. (Clearly, these are not the recommended port settings, you need to find ones that work in your environment.)

In this blog I cover changing ports for some of the key supporting technologies for XenDesktop, including Provisioning Services, XenDesktop Setup Wizard, EdgeSight, Single Sign-on (Password Manager), and the License Server. For some of these technologies I was able to find Citrix KB articles that describe how to make the changes. In those instances, I have referenced the KB articles rather than re-hash the content here.

Enough said, let's get down to the topic at hand....

Provisioning Services

Provisioning services has several different communication ports that are configurable, including the SOAP service, the management services, and target device communication. One thing I particularly like about this product is that all of the ports can easily be changed without much difficulty through the user interface and some can even be changed through the MCLI command-line interface (examples are provided where available). Provisioning Services is extremely network-oriented using a variety of ports to support the SOAP Service, Server-to-Server communication, Inbound device communication, Device booting, Outbound device communication, and Licensing.

SOAP Service (Used by Console and XenDesktop Setup Wizard)

The Provisioning Services 5.1 console by default uses TCP ports 54321-54322 (prior versions used ports 8000-8001) for communication with the SOAP service. The administrator can only specify the first port then the system will automatically use the next sequential number (xxxx+1) for the other communication port, so when specifying a new port number, provide a port where both ports are available.

I don't particularly have an opinion on changing this port, but keep in mind if you plan on using the XenDesktop Setup Wizard you will also need to make the change I explain below so it can communicate with the SOAP service. To change the SOAP service port number, start the Provisioning Services Configuration Wizard and navigate to the Stream Services dialog box as shown below. When you complete the wizard and the services restart, the change will be in effect.

Server-to-Server Communication (Management Service ports)

The management service Ports are specified on the same Stream Services dialog as the SOAP service and default to UDP ports 6905 - 6909. These ports use MAPI to provide the server-to-server communication. Keep in mind that there should be at least ports in this range and all servers in the farm must have the same range of ports configured.

I personally do not recommend changing these ports for the sole reason that if you do you must remember to make the same change on all the provisioning servers in the farm including future servers you add. However, we have a UI for it therefore I will explain how to make the change. Start the Provisioning Services Configuration wizard and navigate to the Stream services dialog as shown below. As before, once the wizard completes and the services restart, the change will be in effect.

Inbound Device Communication

Each provisioning server maintains a range of UDP ports used to manage all inbound communications from target devices. The default port range 21 ports starting at 6910. If you are planning on supporting a large number of target devices from the provisioning server, then you will probably want to adjust this port range. Before setting the range, it is probably a good idea to run netstat and verify none of the ports in the range are currently in use on the host. This setting also applies to all network cards installed in the provisioning server. So, if you had two network cards in the server and set the range of ports to 21, you would actually have 42 ports available for inbound connections.

Ideally, you should have one thread on the provisioning server for each target device if you have enough server cores to support it. By default, the provisioning server assigns 8 threads per port (configured by clicking the Advanced... button on the Network tab of the Server Properties dialog shown below) which means that with the recommended dual-nic configuration and the defaults for threads and ports the ideal load for the server will be about 336 (8*21*2) target devices.

Of course, a single thread can manage more than one target device and in most installations this is the case. However, if your server has the CPU cycles and memory available, I recommend modifying either the threads/port setting or the number of ports to bring the server up to ideal of one thread per port. To reach the ideal, you can choose to increase the threads, increase the ports, add more nics, or do a combination of all three. A single 1 GB network interface card, ideally configured with one thread per target device should support around 500 target desktops.

Once you have figured out the right amount of ports to support the number of target devices, you can open the Provisioning Services Console and right-click on the server and choose Properties from the context menu and select the Network tab. The inbound communication ports for that server shown in the server properties dialog displayed below.

If you don't want to access the console to make the change, you can leverage the MCLI command shown below (assuming the provisioning server name is PVS1) to change the port settings. The second command is used to restart the stream services so the changes will be applied.

MCLI Set Server -p serverName="PVS1" -r firstport=5555 lastport=5585
MCLI Run restartStreamService -p serverName="PVS1"

The range of ports specified is specific to that server and could be different for every server in the farm. However, Citrix recommends keeping the same range of ports on all the servers for simplicity and for booting, discussed in the next session. If the lower number (first port) is modified on any server acting as a bootstap server, you will need to adjust the bootstrap settings as well.

Device Booting

The default UDP port for device booting is 6910, which also happens to be the default lower bound of the inbound device port communication discussed above. At least one server specified in the bootstrap must have the same lower bound port number or the clients will not be able boot. Therefore, if you change the lower bound number on any servers that are configured as bootstap servers, you will need to change the bootstrap configuration as well. If you don't change the lower bound number for the inbound device ports, this can be left alone.

The bootstrap can be changed from either the Provisioning Services console or in the Provisioning Services Configuration Wizard. From the console, right-click the server and choose "Configure Bootstrap..." from the context menu or in start Configuration Wizard and navigate to the Stream Servers Boot List dialog as shown below.

This configuration can also be changed using the MCLI commands below. As indicated earlier, the first command makes the change, the second command restarts the stream service so the changes will be applied.

MCLI Set serverBootStrap -p serverName="PVS1" name="ARDBP32.BIN" -r bootserver1_Port=5555
MCLI Run restartStreamService -p serverName="PVS1"

Outbound Device Communication

The default UDP Source port 6901 is used by the target device for communication to the provisioning server. I have had one customer where this port had to be changed because a software program on the vDisk was using this particular port. The setting is set per target device. To change it the setting, open the Provisioning Services console and right-click on the target device. Choose Properties from the context menu and set the new port number.

This setting can also be set through the command-line interface. Use the following MCLI command to accomplish the same change as indicated in the dialog box above:

MCLI Set Device -p deviceName="wxpsp3_1" -r port=5555

License server

If you have changed the port on the Citrix Licensing Server, you can change it in the Farm Properties dialog from the Provisioning Service Console. To do this, right-click on the provisioning services farm name and choose Properties, then select the Licensing tab.

Alternatively, you can execute the same change with the following MCLI command:

MCLI set farm -r licenseServerPort=55555

XenDesktop Setup Wizard

If you change the Provisioning Services SOAP service ports as discussed above, you will need to modify the \Program Files\Citrix\XenDesktop Setup Wizard\SetupToolApplication.exe.config file with the correct port numbers so the XenDesktop Setup Wizard will know what ports to find the API on. The easiest way to make the change is to edit the file with Notepad and find the following two lines and modify them to have the correct port numbers.

<endpoint address="http://localhost:54321/pvs/mapi/commandset"
<endpoint address="net.tcp://localhost:54322/pvs/mapi/commandset"

Following the example above where I moved the SOAP service to ports to 55555 and 55556, the lines would look like this:

<endpoint address="http://localhost:55555/pvs/mapi/commandset"
<endpoint address="net.tcp://localhost:55556/pvs/mapi/commandset"

When the changes have been completed, save the configuration file and then restart the XenDesktop Setup Wizard.

EdgeSight

During the install of EdgeSight, the database communication ports could be changed if the SQL Server is running on a different port. These changes are handled during the install by clicking the "Client Configuration" button on the Database dialog. Since this procedure is similar to changing the database for XenDesktop, I will refer you to the Database section of the Changing XenDesktop Ports - Core Farm Ports blog posted earlier this month.

The EdgeSight server runs a web service that is used both for administration and for agent data upload. The web service usually runs over standard HTTP/S ports 80/443. The web services port can be changed, though it is not recommended when EdgeSight agents have already been deployed, because it will require that each EdgeSight agent be modified to use the new port number through the local Add/Remove Programs applet. If you want to change the web server port, follow the instructions found in CTX118848.

Real-time communication directly with the EdgeSight agent database occurs over TCP port 9035 and this port cannot be changed.

Single Sign-on (Password Manager)

The Password Manager Service is the only component in Single Sign-on that has a configurable port value. The Password Manager Service leverages the XTE engine and is configured during the initial install. The port for the service can be changed at anytime by re-running the Service Configuration tool. The port configuration is on the opening page.

Keep in mind that if you modify this port from 443, you will need to include the new port number on the service URL (https://ctx1.ctxs.local:5555/MPMService) for all single sign-on settings that use the service, such as Key Recovery, Data Integrity, and Account Self-Service.

License Server

Finally, the Citrix License server uses two ports for communication. The first is the general inbound license server port which is 27000. The second is the vendor daemon port, which now is automatically configured for 7279. Normally, these ports are sufficient for most installations. If you wish to change the ports detailed instructions can be found in CTX118367. I would not change these ports unless it was necessary in the environment.

Well that concludes today's posting I hope you found the information useful. If you would like to be notified of future blogs, feel free to follow me on Twitter @pwilson98.

Recently several customers and integrators have asked me about the ports used by XenDesktop and whether or not Citrix recommends changing them. Since the ports used by Citrix products are well documented in CTX101810, I will leave that topic alone. However, in this blog I will provide some guidance around the ports you can change, where the change can be made, and whether it is a good idea to do so.  Like any good news story, the information is provided in order of relevance.

Due to the amount of content, I have decided to break this blog into multiple parts, starting with the core XenDesktop farm ports. I will tackle the supporting technologies like Provisioning Services and the XenDesktop Setup Wizard later.

Note:   To make the port number change obvious I have used 5555 in all the screen shots below. Clearly, bad things would happen if you set all the components to the same port value.

Virtual Desktop Agent (VDA)

The VDA communication is actually two one-way communications between the Citrix Desktop Delivery Controller Service running on the Desktop Delivery Controller (DDC) and the Citrix Desktop Service running on the desktop.  The significance of that statement is that the two ports can be set independently and do not have to be the same. To confuse this more, the default for both ports happens to be port 8080 which is the default for the Microsoft Windows Communication Foundation (WCF) services used by XenDesktop. Since port 8080 is used by other services, such as internet proxies or McAfee, I highly recommend changing this port on both sides of the communication.

Desktop Delivery Controller WCF Port

During the install of the DDC, the WCF port for the Citrix Desktop Delivery Controller Service is automatically set to 8080 and cannot be changed. To change the port, wait until after the installation is complete. Unfortunately, you cannot change this directly from the Add/Remove Programs Control Panel. Instead, you need to run the DDCServices.msi package from the installation media. Choose Modify, click Next, and then set the new port number. Click Next then Install to finish the wizard. I recommend rebooting the server after this change. The screen sequence is shown below.

Virtual Desktop Agent WCF Port

Changing the WCF port on the Virtual Desktop Agent side can be done either during the initial install or afterwards using the Add/Remove Programs control panel applet. To change it afterwards, open Add/Remove Programs, choose the "Change" option for the Citrix Virtual Desktop Agent, select Modify, click Next, click Next on the Custom Setup screen, enter the port number and then finish the wizard. The initial sequence looks similar to the DDC install and is shown below. 

Although in the examples above I have set the ports to be the same for both components, this is not a requirement.

Database

For security reasons, many institutions run SQL Server on a port other than 1433. If you are running the database on a different port, you can specify this information either during the setup by selecting the Client Configuration button on the ODBC setup screen and entering the new database port. Below are the screen shots for changing the ports during the installation for SQL Server.

Alternatively, you can directly edit the C:\Program Files\Citrix\Independent Management Architecture\MF20.DSN file that is used by the IMA service. For a SQL server, you would just add the line Address=servername,port to the file.  Restart the Citrix Independent Management Service for the change to take effect. Below is a sample MF20.DSN file where I have specified a different tcp port for the SQL server.

[ODBC]
DRIVER=SQL Server
UID=XDSQL
Trusted_Connection=Yes
DATABASE=XenDesktop
WSID=XDDDC4
APP=Citrix IMA
SERVER=SQLSVR1
Address=SQLSVR1,5555 

Session Reliability

Session reliability is another port that companies often modify to increase security for remote access. Unlike the ICA port number, this port can easily be changed by a setting in the Access Management Console. When session reliability is enabled, the ICA client tunnels its ICA traffic inside the Common Gateway Protocol (CGP) on the session reliability port. The XTE service will then unpack the ICA packets and forward them to the ICA listener port on the server.  If you change the session reliability port, you cannot just stop and restart the IMA and XTE services instead you will need to reboot the server. The session reliability port can be changed in the farm properties as shown in the screen shot below:

Virtualization Infrastructure

Changing the port of the API communications is not recommended.  However, if you have changed the inbound port for the API on VMWare Virtual Center or XenServer, you can configure XenDesktop by specifying the new port number on the location URL for the Access Management Console and the Setup Wizard as shown in the screen shot below.

IMA Ports

Changing the IMA ports (2512/2513) used by the farm for communication is not recommended. The primary reason I do not recommend changing the IMA port numbers is because the vast majority of quality assurance testing is done with the default port numbers. However, if you feel so inclined, you can use the IMAPORT.EXE utility to set the IMA ports for the IMA service and CMC to different values. After running this utility, you will need to restart all the Citrix services or just reboot the server.

XML Service

The XML Service port can be changed on the Desktop Delivery Controller. However, changing the XML service port is not recommended as there have been several reports of strange behaviors after changing it. If you must change the port number, you can use the CTXXMLSS.EXE command-line utility to do so and use the same XML service port for all DDCs in the farm.

That is all I have time for now. I hope to the have the next set of ports for the supporting technologies out by the end of the month. If you found this helpful and would like to be notified of future blogs postings, please follow me on twitter @pwilson98. 

I wanted to take a moment and provide some thoughts around selecting the correct logoff behavior for your XenDesktop environment. When working with a pooled desktop environment, the administrator can choose between restarting the virtual desktop at logoff and doing nothing.  Below is a screen shot of the two settings I am referring to for a pooled desktop group:

When selecting a logoff behavior, administrators should consider the operating environment since selecting the wrong logoff behavior could have a negative impact on your user experience. In order to see how this could be the case, let's first look at the logoff process and then apply it to a simple customer scenario. Here are the steps executed when "Restart the virtual desktop" is selected for the desktop group and the user logs off:

1. Virtual Desktop Agent notifies the Desktop Delivery Controller of the user logoff event.
2. Desktop Delivery Controller initiates the shutdown and restart via the pool management service.
3. If the DDC contacted is not the farm master then the request is routed through IMA to the farm master and then executed.
4. The farm master sends a desktop shutdown command to the hosting infrastructure. 
5. If the idle pool count is not met the Desktop Delivery Controller then sends a startup command for the desktop to the hosting infrastructure.
6. The desktop boots up, and if streamed from provisioning services anywhere from 90MB (XP) to 220MB (Vista) of data will be sent over during the boot process for the desktop.

When the logoff behavior is set to "Do nothing" the following sequence is executed for each user logoff.

1. Virtual Desktop Agent notifies the Desktop Delivery Controller of the user logoff event.

Probably obvious now is that a significant amount of overhead is avoided by not restarting the desktop each time a user logs off. Now the question for administrators is "when does not restarting the desktop make sense?"  In most situations, restarting the desktop is the best answer. However, there are some situations where restarting the desktop after each logoff will impact the user experience. Consider the following basic XenDesktop configuration:

• 2 Desktop Delivery Controllers
• 500 virtual desktops hosted on 10 servers in a single resource pool
• 2 Provisioning Servers hosting a single Windows Vista vDisk used by all 500 desktops

If the 500 desktops in above example are supporting 1200 users across three shifts (400 desktops per shift) then during a shift change the amount of overhead caused by restarting the desktops could be significant and easily introduce user logon delay. When 400 users logoff in a relatively short time span, say 15-20 minutes, you would end up with 400 desktop boot processes occurring. If we pick the longer 20-minute interval, and assume even distribution (best case), that is 20 desktops per minute that will need to reboot (400 desktops/20 minutes).

If you are using Provisioning server to deliver Windows XP desktops, you have 90MB of data traversing the wire for each of those desktops and considerably more for later desktop operating systems. In addition, some hosting infrastructures have a limitation of how many desktops can be started within a given time period for a single resource pool or server. Furthermore, if the XenDesktop farm master is throttled (usually by a registry setting for performance reasons see the XD Best Practices Guide) and has a limited number of outstanding VM management commands then the 400 restart commands will get queued thus further slowing the end user's response time.

As the number of virtual desktops in the environment increases, the impact of a restart becomes more noticeable. For instance, if we were considering 5,000 desktops across 2 resource pools with the same 3 shifts and 80% utilization, the number of desktops being rebooted in a short time span becomes 4,000. Even splitting this across 2 resource pools would lead to 100 desktops per minute rebooting in each resource pool.

In contrast, setting the desktop group to "Do nothing" provides a much faster response for the users during shift changes and taxes the network and disk infrastructures less. In addition, if the user is routed back to a desktop they have been to before, the user profile update is faster since the entire user profile will not need to be created and loaded.

Of course, like any architecture decision, it has tradeoffs. By not rebooting the workstations at every user logoff, the write cache file for the provisioning services will grow larger than it would if the workstation was rebooted more often. How much larger, really depends on the environment. In addition, if the users are local administrators on the desktops, then user security is at risk because any files left by other users would then be visible to anyone logged on.

In this case, to mitigate the write cache file issue, I would leverage something like Workflow Studio to reboot the 20% of unused desktops in between shift changes. To prevent users from gaining access to left over files, you could not make users local administrators or employ a profile management solution in conjunction with redirected folders to keep the sensitive data stored on remote drives and/or remove the data at logoff.

So, now you have another perspective around designing a XenDesktop farm and something more to consider during your configuration. If you found this posting valuable and would like to be notified of future blogs, please follow me on twitter @pwilson98.
 

I was on-site last week with one of our large Systems Integrator partners and they asked what recommendations we had for organizing the devices within the Provisioning Services console. Of course, working for Worldwide Consulting Solutions, I answered, "It depends".  Seriously, though, I reviewed their proposed XenDesktop design from a Provisioning Services view and developed a model which would work well as a XenDesktop farm scales. Keep in mind that this suggested organization is based on their design. Your design may work better with a different organization methodology.

Product Architectures

Since the organization is design-dependent, before explaining the Provisioning Services organization model, let me share with you the XenDesktop design that will be used for this model.

The design discussed here is referred to as the Modular Management (MM) design and the architecture is based on building a single XenDesktop farm out of smaller self-supporting Desktop Delivery Modules (DDM). Each DDM contains a group of virtual desktop hosts, a block of shared storage, and a set of provisioning servers to support the number of desktops hosted. This design also provides smaller units that can be managed through delegation. For the purpose of this blog, the example DDM contains four provisioning servers organized as a single site for fault tolerance, 20 XenServer hosts, and shared storage on a SAN. The diagram below provides a visual representation of a single DDM.

Console Organization

Now all the core architecture is understood for both XenDesktop and Provisioning Services, we can begin to look at the organization of the items within the console. To simplify this, we will focus on a single XenDesktop farm that has three DDMs: DDM 1, DDM 2, and DDM 3 (Notice the space in the name of each DDM to distinguish the XD DDMs from the provisioning services objects which are named without the space). Each of these DDMs supplies a different operating system image. DDM 1 supplies Windows XP desktops, while DDMs 2 and 3 supply Windows Vista and Windows 7 desktops respectively. In the XenDesktop Access Management Console (AMC) the administrator has configured three Desktop Groups: Windows 7 Desktops, Windows Vista Desktops, and Windows XP Desktops as seen in the screen shot below.

Ideally, a single Provisioning Services farm is used to support a single XenDesktop farm, such that you have a 1:1 mapping between the two farm types. In the screen shot below of the Provisioning Services console, depicts the Provisioning Services farm name (XenDesktop3) that matches the name of the XenDesktop farm name as shown above.  

The screenshot above shows clearly the different objects available. Below I will discuss each one and explain how it maps to a DDM for management. 

Sites: Sites are created in the Provisioning Services console for each of farm DDMs.  The sites names will correspond to a single farm DDM. In the example, the site names are DDM1, DDM2, and DDM3 per our farm architecture above.  In other words, in this configuration the terms site and DDM can be used interchangeably when referring to objects within the Provisioning Services console.

Servers: The provisioning servers that are assigned to service a single farm DDM are then added to the appropriate site DDM in the Provisioning Services console.

Device Collections: Device collections contain all the target machines that are delivering a specific desktop image. Group similar images into a one device collection such that the entire group can be managed as single entity. This grouping will simplify management later when images need to be versioned or updated. In the example, since DDM 1 is responsible for delivering only Windows XP images, a single device collection, named Windows XP Desktops in the screen shot, can be used for all the hosts in DDM 1.  If DDM 1 had multiple images being delivered, then multiple device collections would be created.

Stores: vDisk stores are created for each of the DDMs: DDM1, DDM2, DDM3. The vDisks are then added to or created in the store for the DDM. The key here is that the corresponding servers in the DDM are assigned to the vDisk store so the vDisks are visible within the site. In the example, the DDM1 store would have the four provisioning servers assigned to DDM 1 would have check marks next to their names for that store. This will allow any of the provisioning servers for the DDM to serve up the vDisks contained in the store.

vDisk Store: The vDisk pool will include all the vDisk images that will be used by a site and shared among the provisioning servers supporting the DDM. The vDisk pool displays any images that are managed by a server in the site. In the example, vDisk pool DDM1 would contain the Windows XP images used for DDM 1 and Windows XP Desktops group. Likewise, vDisk pools DDM2 and DDM3 would contain their respective images for Windows Vista and Windows 7.

Delegated Administration

Keeping DDMs at the site level will allow administrators to leverage the partition-level delegated administration of the Provisioning Services console. Server administrators can be granted permissions over the DDMs they manage at the site level. Desktop administrators can be granted administrator permissions for the devices they manage by assigning them to device collections. Help desk personnel can be granted operator permissions on the devices at the farm, site, or device level. From a higher perspective, desktop farm administrators can be granted permissions for all the farms managed. The best part is that if an administrator has multiple farms to manage, they can use a single Provisioning Services console to manage all of them.

I hope you found this information useful. Follow me on twitter @pwilson98 to keep abreast of design and architecture tips for Citrix XenDesktop, Provisioning Services, and Password Manager (SSO) products.

Ever wonder how easy it will be to move users from physical workstations to XenDesktop? Well, the answer is that it depends primarily on your current environment. Most of the work involved is in isolating and maintaining the user's current personalization and application data. I recently completed a document for the Solution Center, part of Worldwide Consulting Solutions, which addresses this topic in more detail. However, I thought I would take a moment and blog a little bit about what I learned.

XenDesktop, when deployed in the most economical sense, is leveraging a single copy of a shared virtual disk. To keep the environment pristine for the user, the system is normally configured to reset the desktop between logons. This reset removes all installed or saved information and brings the user to a "new desktop" at each logon. For users to keep their personalized settings and data, a profile management solution is required to maintain the user settings independent of the workstation.

The good news is that if you currently have some type of a roaming profile solution configured in your environment, the move to XenDesktop is not complicated. The biggest challenge will be setting up the printing architecture. If you don't have roaming profiles, or some other type of profile management solution in place, plan on implementing one as part of moving users to XenDesktop.

In most cases, you can get Microsoft roaming profiles to fit the bill for your profile management solution. The one scenario where they do not work so well is when migrating users from Windows XP or Windows 2000 workstations to Windows Vista desktops. With just roaming profiles implemented, users will receive a new Vista profile and be required to setup their desktop preferences again.

I have to take a moment and plug AppSense, one of the Citrix Ready Partners, for their XenDesktop integration. If you are curious about AppSense, check out their XenDesktop video available on YouTube at http://www.youtube.com/watch?v=xi3oHO1wIzc. During my research for this white paper I became a huge fan of AppSense because it solves so many of the issues enterprises are likely to encounter when moving users from workstations to XenDesktop. For instance, AppSense can migrate profile settings between Windows XP (v1) and Vista (v2) profiles. With the latest version of AppSense, the two profiles are synchronized even if users move back and forth between Windows XP and Vista during the transition period.

Consulting Solutions has investigated the challenges around migrating users to XenDesktop and has documented them in a whitepaper, Migrating Users from Physical Workstations to XenDesktop (http://support.citrix.com/article/ctx122044) available at Citrix.com.

Introduction

Many environments have already managed to streamline the image building process and already have familiarity with the many Windows XP performance and optimization tips. Both XenDesktop (XD) and Provisioning Server (PVS) support the Windows XP operating system and can benefit from performance enhancements. For those who are familiar with these performance enhancements, this blog may provide little assistance in the way of new information. None of the optimizations below are required, but they are available here for your convenience if they make sense in your environment.

The optimizations are put into three sections: Those that apply to the current user profile, those that apply to all users on the machine, and recommendations before creating the vDisk. The first section deals with the items that can be set in the default user profile. The second section deals with settings that can be set by the administrator for all users that work on the machine. The final section recommends a few things to do before taking the vDisk image. When available, the section will provide links to the URL on Microsoft's website that explains the setting further.

Settings for the Default User Profile

This section lists a few of the settings that will improve the user experience but are set at the user profile level.  The recommendation is to create a generic user and then set the applicable settings, when completed, replace the default user profile with the generic user profile, the steps for which are found at the end of this section.

Force Offscreen Compositing for Internet Explorer

Turning this setting off removes any of the flickering that may display when using Internet Explorer through XenDesktop, by telling Internet Explore to fully render the page prior to displaying it. This is especially helpful on Internet Explorer 7.

1. Open Internet Explorer
2. Select Tools >> Internet Options from the menu
3. Select the Advanced tab
4. In the Browsing section, enable the checkbox for "Force offscreen compositing even under Terminal Services"
5. Click OK to save the changes
6. Restart Internet Explorer

More information available at http://support.microsoft.com/kb/271246/en-us

Remove the Menu Delay

The Start menu has a built-in delay of 400 milliseconds. To speed the menu response time, follow these steps to remove the delay:

1. Start the Registry Editor (Regedit.exe)
2. Navigate to  HKEY_CURRENT_USER\Control Panel\Desktop\
3. Set the value of MenuShowDelay to 0
4. Exit the Registry Editor

Remove Unnecessary Visual Effects

Disabling unnecessary visual effects such as menu animations and shadow effects that generally just slow down the response time of the desktop.

1. Right-click My Computer
2. Click Properties
3. Click Advanced
4. Click the Settings button under the Performance section
5. Click "Adjust for best performance"
6. If you want to keep the XP Visual Style, scroll to the bottom and check the last box titled "Use visual styles on windows and buttons"

Disable the desktop cleanup wizard

To stop the wizard from automatically running every 60 days:

1. Right-click a blank spot on the desktop, and then click Properties to open the Display Properties dialog box
2. Click the Desktop tab
3. Click Customize desktop to open the Desktop Items dialog box
4. Disable the "Run Desktop Cleanup Wizard every 60 days" setting
5. Click OK twice to close the dialog boxes

More information available at http://support.microsoft.com/kb/320154

Disable Automatic Searching of Network Printers and Shares

Automatic search periodically polls your network to check for new shared resources and adds relevant icons into My Network Places if anything is found. If you wish to prevent XP from regularly searching your network unnecessarily then follow these steps:

1. Open the Control Panel
2. Select Folder Options.  If you use the Control Panel Category View you'll find Folder Options under Appearance and Themes
3. Click the View tab
4. In the Advanced Settings list, disable the "Automatically Search for Network Folders and Printers" setting
5. Click OK

Disable the Windows XP Tour Notifier

If you did not turn this off before you logged in as your base user for the default profile, you can manually disable the prompt on a per-user basis by following these steps:

1. Start Registry Editor (Regedit.exe)
2. Navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Applets\Tour
3. On the Edit menu, point to New, click Dword Value, type RunCount
4. Set the data value to 0 (zero), and then click OK
5. Quit Registry Editor

More information available at http://support.microsoft.com/kb/311489

Turn off Automatic Updates

Since you are running a read-only image, using automatic updates will cause the operating system to continually download the same updates each time the image is booted. The best course of action is to turn it off. You have three options that can be used to disable the service:

• Use the PVS Optimizer tool and leave the "Disable automatic update service" box checked

~ or ~

• In the Services Control Panel, change the Startup Type of the Automatic Updates service to "Disabled"

~ or ~

• Run GPEDIT.MSC and navigate to:  Local Computer Policy > Computer Configuration >  Administrative Templates > Windows Components >  Windows Update. Set the "Configure Automatic Updates" setting to "Disabled"

Turn off Language Bar

If there is no need for the language tool bar (the pen icon in the systray) you can disable it using either of these two methods.

• Right-click taskbar > Toolbars and uncheck the "Language Bar" option.

~ or ~

• Navigate to Control Panel > Regional and Language Options > Languages (tab) > Details (button) > Language Bar (button at bottom). Disable the "Show the Language bar on the desktop" and "show additional Language bar icons in the taskbar".

Make the User Profile the Default User Profile

When you are done completing all the User Profile Settings (using a generic user) you can copy the profile over to the default user using the process below.

Login as an administrator (Local Administrator is recommended) not as the base user for the profile because you cannot copy a profile that is in use.

1. Right-click on My Computer
2. Choose Properties
3. Select the Advanced tab
4. Click the Settings button under the "User Profiles" section
5. Select your base user profile where the changes above were made and click Copy To
6. Click the Browse button and browse to C:\Documents and Settings\Default User
7. Click OK once to save the path
8. Click the Change button under "Permitted to use"
9. Enter Everyone
10. Click OK to save
11. Click Yes to confirm overwriting of the default user profile

NOTE: Before copying it over, be sure to remove any user or machine specific data for the ICA Client, the ICA Streaming Client, Password Manager, and EdgeSight. Since the image prep for these items is beyond the scope of this blog, I will save it for a topic another day.

If you would like to know more about user profile management in general, check out David Wagner's blog on the Citrix User Profile Manager available at http://community.citrix.com/blogs/citrite/davidwag/.

Settings for the Machine

This section provides a list of the optimizations that will affect all users of the image. These settings are usually set after logging in as an administrator.

Power Configuration Settings

Two of the power settings can adversely affect the performance of PVS. One of them is the hard disk power savings. If the PVS server is using a local hard disk for the vDisk cache, you do not want the operating system to power down the local drive. The other setting is the Hibernate setting. The PVS Optimizer tool will disable hibernating, but you can manually do it as well. Here are the steps for disabling the power settings:

1. Open Control Panel
2. Select the Power Options applet
3. Select the Power Schemes  tab
4. For the default power scheme, set "Turn off hard disks" setting to Never
5. Select the Hibernate tab
6. Disable the "Enable Hibernation" setting
7. Click OK to save the settings
8. Delete the c:\hiberfil.sys hidden file

Permanently Remove the Language Bar

If there is no need for the language tool bar to be installed at all, you can permanently remove it by running the following command from a command-prompt:  

Regsvr32.exe /u msutb.dll

To reinstall it because you later found out you should not have removed it, you can run this command: 

Regsvr32.exe msutb.dll

Disable TCP Checksum Offloading

This performance optimization is highly recommended by both Citrix and Microsoft for all Windows XP workstations that will be communicating over the network with other Microsoft resources. To work around this problem, turn off TCP checksum offloading on the network adapter using these steps:

1. Start the Registry Editor (Regedit.exe)
2. Navigate to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. In the right pane, make sure that the DisableTaskOffload registry entry exists. If this entry does not exist, follow these steps to add the entry:
   1. On the Edit menu, point to New, and then click DWORD Value.
   2. Type DisableTaskOffload, and then press Enter
4. Click DisableTaskOffload.
5. On the Edit menu, click Modify
6. Type 1 in the Value data box, and then press Enter
7. Exit Registry Editor

More information available at http://support.microsoft.com/kb/904946/

Turn off Security Center

To disable the Security Center service, so users are not prompted when the firewall or anti-virus updates are out-of-date, you can disable it by peforming the following steps:

1. Open the Services Control Panel
2. Edit the Security Center service properties and set the Startup Type to "Disabled"

Disable Last Access Time Stamp

Windows XP has a habit of time stamping all the files it reads with the date and time it was last accessed. While this is a nice feature, it is not always necessary in PVS environments where the files are statically supplied from a standard image and no backup software will be used. Putting a timestamp on a recently read file creates a write access every time a read is executed. With Provisioning Server, these writes go to the vDiskCache file increasing network traffic if cached on the PVS server. To disable the last access timestamp behavior, complete the following steps:

1. Start a command prompt
2. Type FSUTIL behavior set disablelastaccess 1 and press Enter
3. Requires a reboot to take effect

Disable the Windows XP Tour Notifier for New Users

Windows XP likes to notify all new users that an XP tour can be taken. While this is a nice feature for new users, it typically is annoying for existing users. To suppress the XP tour prompt for all new users, follow these steps:

1. Start Registry Editor (Regedit.exe)
2. Navigate to the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Applets\Tour
3. If the Tour key does not exist, follow these steps to create it:
   1. From the Edit menu choose New
   2. Click Key and type Tour as the key name
4. On the Edit menu, point to New, and then click Dword Value
5. Type RunCount as the name for the new value
6. Set the data value for the RunCount value to 0 (zero), and then click OK
7. Quit the Registry Editor

More information available at http://support.microsoft.com/kb/311489

Turn off System Restore

System Restore is the feature that allows a computer system to be rolled back, or restored, to a point before certain events took place, for example, prior to specific software or hardware installations. When you are using a standard mode (read-only) vDisk, there is no reason to have the System Restore feature enabled. The PVS Optimizer tool disables the System Restore feature, but if you are not using that tool, you should complete the following steps:

1. Right-click My Computer, and then click Properties
2. On the Performance tab, click File System, or press Alt+F
3. On the Troubleshooting tab, click to select the Disable System Restore check box
4. Click OK twice, and then click Yes when you are prompted to restart the computer
5. To re-enable System Restore, follow steps 1-3, but in step 3, click to clear the Disable System Restore check box

More information available at http://support.microsoft.com/kb/264887

Disable Windows Indexing Services

Windows Indexing service adds overhead to the PVS vDisk by reading the files from the vDisk for indexing. Use one of the following three methods to disable Indexing:

• Use the PVS Optimizer tool and leave the "Disable Indexing Services" setting enabled

~ or ~

• To turn off indexing at the drive level, perform these steps:

1. Open My Computer
2. Right-click on the drive on which you wish to disable the Indexing Service
3. Select Properties
4. Under the General tab, disable the "Allow the Indexing Service to index this disk for fast file searching" setting

~ or ~

• To disable the indexing service at the service level, perform these steps:

1. Click Start, Run, type services.msc then press Enter or click OK
2. Scroll to the "Indexing Service" in the right-hand pane and double-click it
3. Change the Startup type to "Manual" or "Disable" and Apply
4. Click the Stop button and wait for the service to stop then click OK

Modify the Windows Service Timeout

In environments with shift changes and large amounts of virtual machines rebooting some virtual machines may fail to register because the Windows Service timeout may be reached before Citrix Desktop Service starts.  The Windows Service default timeout is 30 seconds which may not be long enough for all the services to when the virtual machines are coming online simultaneously. We recommend changing the 30-second default to 120-seconds to give the services times to start before the Citrix Desktop Service starts.   The timeout value is represented in milliseconds so 60 seconds = 60000 ms.  The following registry change can be made to lengthen the Windows Service timeout period.

1. Start Registry Editor (Regedit.exe)
2. Navigate to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
3. If the ServicesPipeTimeout value is not present, use the following steps to create it:
   1. Click the Control subkey
   2. On the Edit menu, point to New, and then click DWORD Value
   3. Type ServicesPipeTimeout, and then press Enter
4. Right-click the ServicesPipeTimeout key and then click Modify
5. Click Decimal
6. Type 120000, and then click OK
7. Quit the Registry Editor
8. Reboot for the changes to take effect

Disable Remaining Unnecessary Services

You can go through the list of other services that are configured on Windows XP and disable any ones that will not be used in your environment. Two possible services are the Wireless Zero Configuration service and the Themes service.

Enable ClearType

To enable ClearType and make any adjustments to suit your eyes, go to the Microsoft Typography pages and follow the simple instructions. You can adjust ClearType in the Control Panel after installing the software at the link.

Recommendations Before Imaging

Below is a list of recommendations that can be completed right before creating the vDisk image. Most of these are designed to optimize the layout of the files on the disk so that PVS server can operate at maximum efficiency.

Zero Deleted Files

SDelete is a secure file delete utility that can be used to free and cleanup unused space on the image. In short, it zeroes out any files that have been freed up by the operating system and helps the image run faster. For more information about how it works or to download it, visit the URL below. The recommended options are -z and -c. (sdelete -z -c)

Usage: sdelete [-p passes] [-s] [-q] <file or directory>
sdelete [-p passes] [-z|-c] [drive letter]

More information available at http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx

Defragment the Local Disk

Run the some type of disk defragmenter tool to optimize the files on the image. It is best to run the utility after removing the pagefile.sys and hiberfil.sys files. If you will use a page file, just re-enable it after you defragment the disk, that way the page file is contiguous. The Windows Defragmenter can be found at Start >> Programs >> Accessories >> System Tools >> Disk Defragmenter.

Flush the DNS cache

Flush the DNS Cache using the ipconfig /flushdns command. This prevents any IP addresses cached on the read-only disk from interfering with DNS resolution at a later date.

Run ChkDsk

Verify the file system has no missing file links or pieces by running chkdsk --f from a command prompt.

Conclusion

I hope that some of these performance optimizations will come handy as you build and work with XenDesktop and PVS images in your environment. If you have other optimizations that you know have worked in your environment, please feel free to add them via the comment section on this blog.

I have had several customers, and even other Systems Engineers here at Citrix, ask me about the differences between the newly released XenApp plugin, formerly known as the ICA client, and the Desktop Receiver which ships with XenDesktop.  So, I figured I might as well write my inaugural blog on this topic.

Introduction

Because the XenDesktop and XenApp technologies are so closely tied, many customers, and even some SEs, get confused around which client to use for the XenDesktop environment. Others view the Desktop Receiver and the XenApp plugin as interchangeable and believe they can be used to access either type of resource. Recently, confusion has increased around which client to use when you need both XenDesktop and XenApp connectivity because of two statements found in the documentation for XenDesktop 2.1.

Statement 1 from the Product Update for XenDesktop 2.1:

An updated Desktop Receiver for use on XenDesktop AND XenApp resulting in a single point of access and management for customers living the virtualization dream and benefiting from the entire Citrix solution. 

Statement 2 from the Release Notes of XenDesktop 2.1:

Installation of either the Desktop Receiver or the Desktop Receiver Embedded Edition on the same computer as XenApp plugins (client-side software for Citrix XenApp) is not supported. If you want your users to be able to access both virtual desktops and virtual applications from the same computer, Citrix recommends installing XenApp plugins on the virtual desktops that you create with XenDesktop. This allows your virtual desktops to receive virtual applications.

At first, I was confused by what appeared to be a contradiction of statements. However, as I began to research the behavior, I decided to go ahead and try the two clients. After spending part of a day testing both, I think I can explain how both of the statements above are correct, though they could have probably been worded a bit clearer.

The XenApp plugin (version 11.0) and Desktop Receiver (version 10.251) are different ICA clients. They both use a similar code base, so the functionality is similar. Both clients allow you to access published XenDesktops and/or published XenApp resources (applications or desktops), depending on what resources are available.  However, at the moment, these two clients are not yet merged into a single code base, so you get slightly different behaviors between the two clients.
 

Using the Desktop Receiver 

Since the Desktop Receiver and the XenApp plugin client share similar ICA code they cannot co-exist together, hence the need for Statement 2 from the XenDesktop 2.1 Release Notes.  If you install the XenApp plugin client first and then attempt to install the Desktop Receiver, the install will fail and require that you first remove the XenApp plugin because it holds a version number higher than the Desktop Receiver. 

The Desktop Receiver has only support for PNAgent and the web client. The Program Neighborhood Classic (with custom ICA connections) client is not installed with the Desktop Receiver. The Desktop Receiver does support the Desktop Toolbar, so you can run in modes other than full screen. The only limitation that I am aware of in the Desktop Receiver is that if you are using the Desktop Toolbar, the pass-through authentication method is not supported on Web Interface. You need to set the site to Explicit authentication. Once you authenticate to the site, the credentials are passed automatically into the XenDesktop. The loss of pass through authentication when using the Desktop Toolbar is a result of a tightened security infrastructure. Citrix is looking to address this in a future release.

When the Desktop Receiver is pointed to a XenApp farm, it works as a standard PNA client, and displays those resources only, thus validating Statement 1 from the XenDesktop 2.1 product update. The screenshot below shows the Desktop Receiver working like a normal PNAgent when pointed to a PNAgent configuration site that only has a XenApp farm configured. 

One thing to remember is that with the Web Interface 5.0 that ships with XenDesktop, you can create a Web Interface or PNAgent site that aggregates resources from both the XenDesktop and XenApp farms, by simply adding the additional farm through the Manage Server Farms link on the site configuration. Then when users access the site, they will have all their available resources displayed. The screenshot below shows the Desktop Receiver when pointed to PNAgent site that has aggregated a XenApp farm with a XenDesktop farm.

Using the XenApp Plugin

With the XenApp plugin, access to normal XenApp published resources works as expected and you have the PNAgent, Web, and Program Neighborhood Classic (with custom ICA connections) options available. When accessing a published XenDesktop, you only get Full Screen mode (no support for the Desktop Toolbar or long-running operations feedback). I was able to successfully install and use the XenApp plugin to access both a published XenDesktop and a published XenApp application.

If you have an older ICA client, and you want to use XenDesktop, the recommendation is to use the Desktop Receiver for the user's workstation and then inside the XenDesktop, install the older ICA client for connectivity into the existing farm.  If you are going to use an ICA client or XenApp plugin in the XenDesktop image, be sure to point it to a site that does not have the XenDesktop published, or you risk letting the user create a XenDesktop auto-reconnect loop that will require manual intervention to stop.
 

Conclusion 

In the end, it depends on what functionality you want or need to provide to the end-users. If you need Desktop Toolbar support, you need to deploy the Desktop Receiver. If you need the Program Neighborhood Classic or custom ICA connections, then your choice is to use the XenApp plugin. If you don't have any pressing needs for either of the client-specific features, then you can choose either one.