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, September 17, 2012

Where can I find that GPO setting?

Is there a policy for that? Would that be a computer based policy or a user based policy? If I can’t set that with a traditional group policy can I do it with a preference? When dealing with Group Policy Objects (GPOs) I find myself asking these types of questions all the time? Wouldn’t it be nice if there was a searchable site of policy settings? Sure you can Google settings and there are great sites such as www.gpanswers.com but I’m talking about a site that allows you to search for group policy settings, identifies where you can set them, explain what they do and most importantly what registry settings they touch.  There is. MSDN publishes a site that does this. Group Policy Search is a fantastic resource when dealing with group policies. When you search for setting the tool will provide you with the following information:
  • Policy Name
  • Category Path (Where you can find it in the console)
  • Supported Platforms (What the minimal operating system level required)
  • Registry Key
  • Value
  • Explanation of what the policy does
If you’re like me and deal regularly with group policy administration you’ll find this tool a huge time saver. And yes it has just been updated for Windows 8 and Windows Server 2012

Tuesday, September 11, 2012

WMI and the ConfigMgr Client

If you still manage Windows XP machines with ConfigMgr I’m sure that you know that 9 out of 10 client health issues are WMI related. Whether it’s the CCM namespace getting corrupt or the entire WMI repository getting corrupt... Windows XP WMI + ConfigMgr = unstable.
Most of the time you can get away with simply deleting the ccm namespace and then reinstalling the ConfigMgr client to correct the problem. (More on that later) However there are times when the fix requires you to rebuild the entire WMI repository – which should be used as a last resort as there could be other applications on the machine that rely on WMI.
After searching around for WMI resources I came across this post which does a great job of detailing different ways to resolve your WMI issues based on your Operating System version. I've used many of these approaches in order to resolve client health issues but I’ve had the most success with the following command:
  • From a command prompt run rundll32 wbemupgrd, RepairWMISetup
If you decide that rebuilding the WMI repository is what you need to do follow these steps for Windows XP:
  • Open a command prompt and run the following
    • net stop winmgmt
  • Browse to %windir%\System32\Wbem
  • Rename the Repository folder
  • Go back to your command prompt and run the following to rebuild your repository
    • net start winmgmt
As mentioned before, If you rebuild your WMI repository you run the risk of breaking other applications on that machine that require WMI. A safer method is to simply delete the CCM namespace and then repair the ConfigMgr client. One tool that I now use almost exclusively is SCCM Client Center. SCCM Client Center allows you to do a variety of things but one of the most handy options are it’s client repair options. After you install Client Center connect to the machine in question, (Top left-hand corner) click on the Agent Action menu (highlighted in the screen shot below) and as you can see there are a bunch of actions that you can kick off to repair the ConfigMgr client. Most of the time selecting Delete root \ccm will resolve your problem.

image

I find myself using this tool everyday for a variety of reasons.

Monday, April 30, 2012

Task Scheduler Does Not Save Network Credentials

Whether it’s PCI, HIPAA, CSOX or another compliance program that effects your organization, server hardening is most likely part of the program. Its one thing to provision a hardened server and then get you application installed and working correctly – your server’s behaviour doesn’t change after it’s provisioned. However when the hardening settings are pushed out post production the server’s behavior may change where things that once worked no longer do. For example recently I had an issue where a scheduled task on one of my servers would no longer store the network credentials of the service account that was running the job. What once worked, no longer did.

After a little digging I found that a security setting on the box had been updated. The following setting, Network access: Do not allow storage of credentials or .NET Passports for network authentication had been changed from disabled to enabled in the local security policy. For more information on this setting check out TechNet. Once this setting was reverted back to the default setting the scheduled task get be set to use a domain service account.

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