Showing posts with label XenDesktop. Show all posts
Showing posts with label XenDesktop. Show all posts

Saturday, February 2, 2013

Poor Video Performance in vsphere 4.1 remote console after Xendesktop VDA is installed


When you build a Windows 7 XenDesktop image that is hosted on VMware vSphere 4.1 you will find that your gold image will perform as it should when using vSphere's remote console feature until you install the XenDesktop Virtual Desktop Agent (VDA). After the VDA is installed, your remote console session has poor video performance. On top of that when you launch a XenDesktop session using your Windows 7 image all the user gets is a black screen.

This is due to a conflict between the WDDM video driver that the XenDesktop VDA installs and the version that VMware tools installs. When VMware Tools 4.1 (Version 8.x) is installed the default video driver is set to the VMware SVGA 3D (Microsoft Corporation – WDDM) driver and when you install the XenDesktop VDA it replaces the VMware driver with the Citrix Display Driver (Citrix Systems - WDDM) as the default video driver. If you leave the XenDesktop WDDM driver installed the remote console in vSphere has very poor video performance which causes the mouse to be very choppy and not responsive. If you update the video adapter to use the VMware SVGA 3D driver then the remote console works correctly however your users will get nothing but a black screen when logging into XenDesktop. To resolve this driver issue try the following:

  • Launch the vSphere client
  • Open a remote session to your gold image machine
  • If the XenDesktop VDA is installed uninstall it and reboot
  • Open device manager and change the default VMware video adapter to use the VMware SVGA II driver and reboot (Driver is located at C:\Program Files\Common Files\VMware\Drivers\Video)
  • Log back into your golden machine and confirm that video performance in the remote console works normally
  • Now we need to install the VDA without the Citrix WDDM driver as outlined in CTX130851
    • Open a command prompt and browse to \\<VDA Installation files>\x64\XenDesktop Setup (Substitute x86 for x64 if you are using a 32-bit operating system
    • Run the following: XenDesktopVdaSetup.exe /NOCITRIXWDDM (This will install the VDA without the WDDM driver
    • After the install completes reboot the system
  • Once the machine reboots log back in and open Device Manager
  • Navigate down to the Display adapters and expand it
  • You should now have two display adapters listed
    • Citrix Systems Inc. Display Driver
    • VMware SVGA II
This configuration will allow you to use the remote console feature of the vSphere client properly and allow users to launch a XenDesktop session successfully. The only gotcha that I have found so far is when I’m using the remote console  from time to time the session will freeze and you have to reset the virtual machine. Hopefully with the newer releases of vSphere the issue is resolved.

Sunday, January 20, 2013

Troubleshooting a XenDesktop Issue... What do the Logs Say?

Over the years when working with System Center Configuration Manager you get used to combing logs to resolve issues. ConfigMgr has a log for everything so it was my surprise when I starting working with XenDesktop how limited logging is out of the box. After working through my first major outage, I quickly found out that logging is no good if it is not enabled. It’s not that XenDesktop doesn’t have logging it just doesn’t have enabled by default. I would highly recommend enabling the following logging in XenDesktop – on the VDA, on the DDC and PorrtICA.

Enabling Virtual Desktop Agent (VDA) logging (CTX117452):
  • Change your vDisk to Private mode and boot your template machine
  • Log in with an admin account
  • Navigate to %ProgramFiles%\Citrix\Virtual Desktop Agent
  • Backup WorkstationAgent.exe.config
  • Open the configuration file with a program such as Notepad
  • Locate the following section <appSettings> section  (Near the top of the config file) and update as follows:
    • <add key=”LogToCDF” value =”1”/>
    • <add key="LogFileName" value ="D:\XDLogs\vda_log.log"/>
    • <add key="OverwriteLogFile" value ="1"/>
  • Save and close the file
  • Restart the Citrix Desktop service or reboot your template machine and confirm that the log file gets created
The above configuration will redirect the log file to the D:\ partition (Assuming that you have persistent disk) but you can change the location to whatever works for your environment. If you set to the location to somewhere on the C:\ drive ensure that you set the correct permissions. You can also configure the log to overwrite itself anytime that the Citrix Desktop Service starts. (Shown above) If you don’t set the log file to overwrite just be mindful of your disk space.

Enabling Desktop Delivery Controller (DDC) logging (CTX117452) with XenDesktop 5.6:
  • Log into your DDC with an admin account
  • Navigate to %ProgramFiles%\Citrix\Broker\Service
  • Backup BrokerService.exe.config
  • Open the configuration file with a program such as Notepad
  • Locate the following section <appSettings> section  (Near the top of the config file) and update as follows:
    • <add key="LogToCDF" value ="1"/>
    • <add key="LogFileName" value ="D:\XDLogs\controller_log.log"/>
    • <add key="OverwriteLogFile" value ="1"/>
  • Save and close the file
  • With XenDesktop 5.6 I did not have to enable logging for CdsPoolMgr.exe.config as outlined in CTX117452
  • Restart the Citrix Broker Service (This will cause any virtual desktops connected to the server to re-register with another controller)
The above configuration will create a log file on the D:\ partition assuming that you have one. If you set the log location to be somewhere on your C:\ partition watch that your permissions are set correctly. Since the log file will only overwrite itself when the Citrix Broker service is restarted this log file can grow quite large. Personally I only enable this logging when I’m troubleshooting a specific issue and then I leave it disabled.

Enabling PortICA logging (CTX118837):
  • Change your vDisk to Private mode and boot your template machine
  • Log in with an admin account
  • Navigate to %ProgramFiles%\Citrix\ICAService\XML (If the XML folder does not exist, create one)
  • Create an new XML file called PorticaConfig.XML
  • Paste the following into the file:
  • <?xml version="1.0" encoding="utf-8"?>
    <Config xmlns="Portica.xsd">
            <Portica>
            <LogFile>
                <LogLevel>5</LogLevel>
            </LogFile>
            <CdfTrace>
                <LogLevel>5</LogLevel>
            </CdfTrace>
            <FunctionTrace>
                <LogLevel>5</LogLevel>
            </FunctionTrace>
        </Portica>
    </Config>
  • Save and close the file
  • Restart the Citrix ICA service or reboot your template machine
You can change the level of logging with the following values 0, 1, 5 or 9 with 0 being the least verbose. Unfortunately you can not change the directory where the log file gets created so you if you use a standard vDisk that gets refreshed at every logoff you’ll need a shutdown script to copy the log to either a persistent disk or a file share. By default on Windows XP the log file is located at: C:\Documents and Settings\LocalService\Local Settings\Temp and on Windows 7 it’s located at %WinDir%\ServiceProfiles\LocalService\AppData\Local\Temp

There is also a logging tool that Citrix has published as outlined in CTX127492 that can enable more logging however I have solved most of my issues using VDA, DDC and PortICA logging. Regardless of how you setup logging a great utility to help you read them is Trace32.exe from the ConfigMgr toolkit. Download and install the tools and then open your log files with Trace – your eyes will thank you.

Monday, March 19, 2012

PowerPoint causes 100% CPU usage in a seamless XenDesktop session


For last couple of days I’ve been trying to determine the root cause of a problem that I was having with PowerPoint and XenDesktop. The scenario was a Windows XP workstation with Office 2010 being launched in a seamless XenDesktop 5.0 SP1 session on a dual monitor machine. Whenever I opened PowerPoint it would cause Explorer.exe to use 100% CPU and render the virtual machine useless. The issue did not occur if I started PowerPoint in safe mode. After much trial and error and countless searches online I came across the following Citrix article that was just published – CTX132436. It’s not the exact setup that I had but it did bring to attention the Disable hardware graphics acceleration setting in the Advanced options of PowerPoint. Once I enabled this option PowerPoint could open in a seamless session without pinning the CPU. 

This setting is a per-user setting so you will need to apply it to every user that logs on. To deploy this via GPO you will need to download the Office 2010 ADM, ADMX/ADML files from here. Once you have downloaded and installed them, (Note if you use ADM files you’ll need to add them to your policy using Add/remove Templates from within the GPO) open your GPO editor
  • Navigate to User Configuration\Policies\Administrative Templates\Microsoft Office 2010\Miscellaneous
  • Set Do not use hardware graphics acceleration to Enabled