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.