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.

Saturday, January 26, 2013

Your Profile was not loaded correctly error on windows 7

I’ve had a few instances lately where corrupt profiles have prevented me from logging into with a Windows 7 or Server 2008 R2 machine. At the time of logon, the logon process takes a while and then I get the following error:

Your user profile was not loaded correctly. You have been logged on with a temporary profile. Changes you make to this profile will be lost when you log off. Please see event log for details or contact your administrator.

Also in the Event Viewer (Application) you have an entry for Event ID 1511. Normally this isn’t a big deal because you can log onto the machine with a different admin account and delete the problem profile. Only in this case when you go to remove the profile it doesn’t exist. I came across the following Microsoft article – KB947242 that deals with this issue. If you open regedit and Navigate to:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfielList

You will find a list of profiles that are identified by their SID. Locate the SID of the account in question (It will probably be called SID.bak) and delete the entry. Log off of the system and log back in using the problem account.

Wednesday, January 23, 2013

System Center 2012 SP1 Drops

It’s been just over a week since the official announcement that service pack 1 for System Center Configuration Manager 2012 was released. This is a really important release for the System Center teams as SP1 really drives home the idea of unified device management. Service Pack 1 adds support for  Windows Server 2012 and Windows 8, Windows 8 tablet plus added support for Mac OS X, Linux and Unix platforms. This is exciting for our environment because there has always been a gap with managing the subset of machines running Mac OS X or Linux. Can you manage one of these platforms to the level that you can manage the Windows platform? No. However this is a step in the right direction. Admins want a single pane of glass view for managing their environment – SP1 moves System Center in the direction. Some other features of this release are support for Windows Embedded devices, full PowerShell support, Windows Azure based Distribution Points and the ability to subscribe to email alerts. 
When you dig a little deeper into the CM 2012 release you’ll find added support for user profile and data management with their new User Environment Virtualization product (MDOP 2012) and real time administrative tasks for endpoint protection, network cost support for application delivery, updates to Bitlocker including TPM and PIN, and the ability to deploy Windows 8 applications.

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.