Blog

  1. Stress testing print drivers on XenApp

    While dodgy print drivers no longer often cause a BSOD, they are still an on-going source of issues on Citrix XenApp farms, namely print spooler crashes and application crashes. Resolving print driver problems within a production environment is challenging and time consuming due to user testing and the change control requirements of live environments, so suck it up and spend the time doing thorough testing during the project to ensure you don’t enter a world or printer pain later on.
    My interpretation of thorough is stress testing the print driver using Citrix’s StressPrinters utility followed by UAT to ensure the printer driver meets the user’s needs.
    I just wrote the following guidelines for a client and thought I would share:

    Use the Citrix StressPrinters utility to test print drivers before they are introduced into the XenApp farm. A test XenApp server must be used during stress testing to ensure the new print driver is not introduced into the production farm prior to successful testing.

      1. Install the print driver onto the test XenApp server
      2. A Printer Port must be created for use during the test. Open Print Management, expand the local Print Server right click Ports and select Add Port.

    • Choose Local Port, click New Port and enter the port name as test

     

    • There is a graphical interface for StressPrinters, but I prefer the command line interface. The following is an example showing a test of the HP Color LaserJect 2600n driver:

     

    addprinter64.exe -name “StressTest” -driver “HP Color LaserJet 2600n” -conc 5 -iter 10 -delay 500 -port “test”

     

    To test a different print driver simply replace the text “HP Color LaserJet 2600n” with the exact print driver name as displayed within Print Management.

    The symptoms of a failed stress test are one or more of the following:

    • The stress test hangs
    • The Print Spooler crashes
    • Interactive Services Detection pop-ups

    Note that a successful test may still show warning as shown below:

    If a print driver fails the stress test go back to the vendor’s web site and hunt around for an alternative driver and try again. While this process does take some time to complete, the resulting stable XenApp farm is worth the effort.

  2. Recommended XenApp 6 Hotfixes

    I am a huge fan of XenApp 6, but XenApp 6 does have more than it’s fair share of bugs. Citrix have published a list of recommended Citrix and Microsoft hotfixes which has recently been updated (March 2012). Here is my list of recommended XenApp 6 hotfixes to keep your farm (mostly) bug free:

    For Microsoft hotfixes when running Windows 2008 Server R2 SP1, I recommend the following hotfixes:
    I will try to keep this updated, but always check the XenApp 6 hotfix list and Citrix’s recommended hotfixes to see if there are new hotfixes which apply to your environment.
  3. Faulting module: svchost.exe_gpsvc

    A Group Policy problem on XenApp servers is a high visibility issue so I was not happy to see this error in the system log:
    The Group Policy Client service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 120000 milliseconds: Restart the service.

    And this error in the application log:
    Faulting application name: svchost.exe_gpsvc, version: 6.1.7600.16385, time stamp: 0x4a5bc3c1
    Faulting module name: ntdll.dll, version: 6.1.7600.16695, time stamp: 0x4cc7b325
    Exception code: 0xc0000374
    Faulting application path: C:\Windows\system32\svchost.exe
    Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

    That is what a crash of the Group Policy service looks like, followed by page after page of GroupPolicy 1128 warnings in system log. I am a big fan of Windows Error Reporting (WER) as WER automatically creates a crash dump file when this type of error occurs which means rather than just googling the crash I can analysis the dump and (hopefully) see what caused the crash. In this case, the key info from the analysis is:
    DEFAULT_BUCKET_ID: STATUS_HEAP_CORRUPTION

    PROCESS_NAME: svchost.exe

    ERROR_CODE: (NTSTATUS) 0xc0000374 – A heap has been corrupted.

    MODULE_NAME: gpprefcl

    IMAGE_NAME: gpprefcl.dll

    Now I know the offending module is gpprefcl.dll I hit google looking for the most recent hotfix which updates this dll and I come up with KB2514376. I will test this over the coming weeks to see if it fixes the Group Policy service crash.
    EDIT – 20 June 2011: The hotfix has not solved this issue and we have logged an incident with Microsoft
    EDIT – 08 July 2011: We have installed KB982293 and KB2526870 and not seen this issue again….. yet.
  4. Configuring Windows Search for XenApp 6

    Windows Search is enabled on XenApp 6 Windows 2008 R2 servers by installing the File Server > Windows Search Service role.

    Once the Windows Search Service is installed file searches on shares hosted on Windows 2008 R2 file servers can be off-loaded to the file server thereby conserving XenApp server resources. E-mail messages and Internet Explorer history will be also indexed….. and this is where the trouble can start:
    • The application event log may start logging event id 3036 from source Search:
    The content source cannot be accessed.
    Context: Windows Application, SystemIndex Catalog
    Details: No protocol handler is available. Install a protocol handler that can process this URL type. (HRESULT : 0x80040d37) (0x80040d37)
    • Outlook may fail to open and attempt to open in safe mode.
    • The Search database file C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb may grow very large – a “normal” size seems to be around 40 MB and a large DB can be 4 GB.
    • The SearchIndexer.exe process has high disk I/O
    We decided to only allow file searches as it seemed the main cause was indexing of MAPI content. The follow group policies fixed this issue:
    Computer Config/Admin Templates/Windows Components/Search
    • Prevent indexing certain paths
      • iehistory://{*}/
      • mapi://{*}/
    • Prevent unwanted iFilters and protocol handlers
      • Search.FileHandler.1
    The index path exclusion may not be required, but I have not tested without these settings. The “Prevent unwanted iFilters and protocol handlers” settings tells Windows Search to use only the file search handler. A caveat is that if your environment has custom search handlers installed, this setting will disable them.
  5. McAfee MOVE AntiVirus for VDI

    I was talking to Roly from MPA last week and he mentioned McAfee’s MOVE AntiVirus which is designed for VDI environments. The key point which grabbed my interest is that the scanning is done by an appliance on each virtualisation host, not within each desktop VM (although a light-weight agent is installed within each VM). McAfee call this “hypervisor-native detection”.
    I consider antivirus to be a necessary evil along the lines of paying taxes; you’re tempted not too, you know you could be so much better off….. but if you are found out the consequences could be massive and include a public execution. Well, maybe I’m exaggerating, but you get the point. I have seen antivirus cause numerous issues in XenApp farms and one of my standard practices is to ensure the antivirus configuration meets Microsoft and Citrix best practices (Symantec also provide a good best practise whitepaper). In a large XenApp 6 project last year we did not install antivirus on the XenApp servers as it we determined sufficient risk mitigation was provided by:

    • file server, e-mail and client device antivirus scanning
    • web filtering
    • read-only images delivered via Citrix Provisioning Server
    • AppSense’s Application Manager restricting what users can execute and from where.
    But for the most part, antivirus is NOT optional! McAfee’s MOVE product is designed for VDI environments with VMware View/VMware vSphere and Citrix XenDesktop/Citrix XenServer supported and promises to greatly improve VDI scalability. The big question is whether offloading the virus detection from the VM to a virtual appliance will really improve performance. My gut feeling is that performance and scalability will increase. But by how much? I see the product has been out for 9 months or so now so I am keen to hear from anyone who has tested or deployed MOVE.
  6. Script to install all print drivers from a print server

    I was just preparing to write a PowerShell script to connect to a print server, enumerate all the shared printers and connect to each one which will install the required driver…. when a quick Google search turned up exactly what I was looking for. I created this batch file:

    set PrintServer=PrintServerName
    powershell.exe “& { $Wmi = ([wmiclass]’Win32_Printer’) ; $Wmi.Scope.Options.EnablePrivileges = $true; gwmi win32_printer -ComputerName ‘%PrintServer%’ -Filter ‘shared=true’ | foreach {$Wmi.AddPrinterConnection( [string]::Concat(‘\\’, $_.__SERVER, ‘\’, $_.ShareName) )} }”

    The script is now running on a XenApp 6 server and seems to be working perfectly. Awesome, less work to do on this Sunday afternoon.

  7. Configuring Citrix UPM to only include specified items

    Citrix User Profile Manager (UPM) is designed to be inclusive. By this I mean it will include all changes in a users profile (file system and registry) unless you specify otherwise.
    I am setting up a XenApp 6 farm where only a single application is installed which stores it’s settings in a single registry key. For this type of environment I do not want the entire user profile to be managed by UPM, only the single registry key needs to be managed and the rest of the profile can be dropped at logoff. It is not difficult, but also not intuitive, to configure UPM to behave like this.

    Here is how I have configured UPM via Group Policy, note that the Citrix UPM adm needs to be added to the GPO before the below settings show up. Once the adm is imported, the settings are found here:
    Computer Config\Policies\Classic Admin Templates\Citrix\Profile Management

    General UPM Config

    Enable Profile Management = Enabled
    Active write back = Enabled
    Path to user store =
    Profile handling\Delete locally cached profiles at logoff = Enabled
    Profile handling\Migration of existing profiles = None
    Local profile conflict handling = Delete local profile
    Streamed user profiles\Profile streaming = Enabled
    Streamed user profiles\Always cache = 1 MB
    Timeout for pending area lock files = 1 day

    Specific UPM Config to exclude all setting except HKCU\Software\MyApp

    Registry\Exclusion list
    – Software
    Registry\Inclusion list
    Software\MyApp
    File system\Exclusion list – directories
    – AppData
    – Contacts
    – Desktop
    – Favorites
    – Links
    – My Documents
    – My Music
    – My Pictures
    – My Videos
    – Saved Games
    – Searches
    – Documents
    – Music
    – Pictures
    – Videos
    Exclusion list – files
    – *.*
    File system\Synchonization\Directories to synchronize = Disabled
    File system\Synchonization\Files to synchronize = Disabled

    There you have it, hopefully it comes in handy.

  8. STOP 0x00000035 NO_MORE_IRP_STACK_LOCATIONS error when shadowing on XenApp 6

    This issue started occurring when testing a newly build XenApp 6 server. When shadowing a user from this newly built XenApp 6 server the newly built server would bluescreen with STOP 0x00000035 NO_MORE_IRP_STACK_LOCATIONS as soon as the user accepted the shadow prompt.
    I analysed a memory dump and found mup.sys to be the faulting module and I soon found I wasn’t the only one seeing this issue.

    After a couple of days constantly tweaking the build process it looks like I have a fix. The build process was:
    deploy OS image > install Windows Updates > install XenApp & applications > install Windows updates
    and this equalled a bluescreen when shadowing

    I then tried this process:
    deploy OS image > install XenApp & applications
    and hurray, no bluescreen, but we really do need those 80 odd security patches!

    This was next:
    deploy OS image > install XenApp & applications > install Windows Updates
    Now things are getting interesting! With this process Windows Updates failed to install KB2467175 which is a VC++ 2005 update, but still no bluescreen

    Finally this process worked:
    deploy OS image > install XenApp & applications > install vcredist_x64 & vcredist_x86 > install Windows Updates

    Installing KB2467175 prior to XenApp was causing the bluescreen, but attempting to install KB2467175 after XenApp caused KB2467175 to fail. The answer was to download the vcredist executables and silently install them prior to running Windows Update (which installs KB2467175).

    The VC++ executables are silently installed using the commands:
    vcredist_x64.exe /q:a
    vcredist_x86.exe /q:a

    This worked for us, hopefully it will for you too!

    EDIT – 7 May 2011: The above did not fully fix this issue, as I saw the same BSOD again. This time I uploaded the dump to Citrix who provided a private hotfix named “258948V1” which updates icatdpipe.sys. So far, so good.


    EDIT – 23 June 2011: Citrix have released a public hotfix for this issue: XA600W2K8R2X64062
  9. Repurposing Win XP desktops as thin clients

    Repurposed PCs deliver Windows 7-like experience using XenApp Hosted Shared Desktops

    This excellent Citrix Community blog details how to turn old Win XP desktops into Desktop Appliances (thin clients). I plan to use some of this info in an upcoming project, but would like to take it further to the point where an existing Win XP desktop can simply be moved into a “Desktop Appliance” OU in Active Directory and after a reboot it auto-magically becomes a Desktop Appliance.

    Will keep you posted.

Subscribe to our Newsletter



Please leave this field empty.