XML Broker Health Check

I saw an interesting question in the Citrix support forum today, and thought I’d share. Scott Curtsinger asked the following:

Does anyone know what the easiest way is to check the health of the XML service on XenDesktop 5.6? I’m seeing a lot of information on the web for XenApp but not very much for XenDesktop beyond leveraging devices like a NetScaler.

My first instinct is that this could easily be done via PowerShell, so I did a quick search and found this blog post by Jason Pettys. I also found this great article on working with the Citrix XML service, and quickly put together the following script which I tested against my XenDesktop 5.6 XML broker:

$url = "http://localhost/scripts/wpnbr.dll"
$parameters = '<?xml version="1.0" encoding="utf-8"?><!DOCTYPE NFuseProtocol SYSTEM "NFuse.dtd"><NFuseProtocol version="5.1"><RequestCapabilities></RequestCapabilities></NFuseProtocol>'
$http_request = New-Object -ComObject Msxml2.XMLHTTP
$http_request.open('POST', $url, $false)
$http_request.setRequestHeader("Content-type", "text/xml")
$http_request.setRequestHeader("Content-length", $parameters.Length)
$http_request.setRequestHeader("Connection", "close")

Running this script in PowerShell on my XML broker returned the following list of capabilities, which is a good indication that the XML broker is up and running:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE NFuseProtocol SYSTEM "NFuse.dtd"> <NFuseProtocol version="5.1"> <ResponseCapabilities> <CapabilityId>separate-credentials-validation</CapabilityId> <CapabilityId>multi-image-icons</CapabilityId> <CapabilityId>launch-reference</CapabilityId> <CapabilityId>user-identity</CapabilityId> <CapabilityId>full-icon-data</CapabilityId> <CapabilityId>full-icon-hash</CapabilityId> <CapabilityId>accepts-client-identity-for-power-off</CapabilityId> <CapabilityId>session-sharing</CapabilityId> </ResponseCapabilities> </NFuseProtocol>

This simple script lays a nice foundation to perform XML broker health checks via PoSH. I then took the script a little bit further to test some other XML requests:

param($server, $port)
if ($port){$port = 80}
$creds = Get-Credential
$domainuser= $creds.UserName.Split('\')
$domain = $domainuser[0]
$user = $domainuser[1]
[String]$pw = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($creds.Password))
$nwINFO = Get-WmiObject -ComputerName $env:COMPUTERNAME Win32_NetworkAdapterConfiguration | Where-Object { $_.IPAddress -ne $null }
$ip = $nwINFO.IPAddress
$fqdn = $nwINFO.DNSHostName
$xmlcreds = '<Credentials><UserName>' + $user + '</UserName><Password encoding="cleartext">' + $pw + '</Password><Domain Type="NT">' + $domain + '</Domain></Credentials>'
$envelope = '<?xml version="1.0" encoding="utf-8"?><!DOCTYPE NFuseProtocol SYSTEM "NFuse.dtd"><NFuseProtocol version="5.1">'
$clienttype = '<ClientType>ica30</ClientType>'
$clientdetails = '<ClientName>' + $env:COMPUTERNAME + '</ClientName><ClientAddress addresstype="dot">' + $ip[0] + '</ClientAddress>'
function request ($parameters)
 $http_request = New-Object -ComObject Msxml2.XMLHTTP
 $http_request.open('POST', $url, $false)
 $http_request.setRequestHeader("Content-type", "text/xml")
 $http_request.setRequestHeader("Content-length", $parameters.Length)
 $http_request.setRequestHeader("Connection", "close")
$url = "http://" + $server + ":" + $port + "/scripts/wpnbr.dll"
$capabilities = request ($envelope + '<RequestCapabilities></RequestCapabilities></NFuseProtocol>')
if (!$capabilities[1].contains('error'))
 $testcreds = request ($envelope + '<RequestValidateCredentials>' + $xmlcreds + '</RequestValidateCredentials></NFuseProtocol>')
 if (!$testcreds[1].contains('bad'))
 $appdatareq = request ($envelope + '<RequestAppData><Scope traverse="subtree"></Scope><DesiredDetails>rade-offline-mode</DesiredDetails><ServerType>all</ServerType>' + $clienttype + '<ClientType>content</ClientType>' + $xmlcreds + $clientdetails + '</RequestAppData></NFuseProtocol>')
 $app = $appdatareq[1] -split "<FName>"
 $app = $app[1] -split "</FName>"
 $launchreq = request ($envelope + '<RequestAddress><Name><AppName>' + $app[0] + '</AppName></Name>' + $clientdetails + '<ServerAddress addresstype="dns-port"></ServerAddress>' + $xmlcreds + $clienttype + '</RequestAddress></NFuseProtocol>')

This script takes the server and port, prompts for the credentials that you’re testing (password is sent in clear text), and sends a RequestCapabilities request, followed by RequestValidateCredentials, RequestAppData, and RequestAddress requests. To avoid dependencies on NFuse.dtd, I used a -split on the XML results of the RequestAppData results to get the ‘friendly name’ of the first application returned by RequestAppData, which I used for the RequestAddress post.

From here I’m going to develop a C# service that can monitor the XML service, though I’d like to figure out how to encode the password into the ‘ctx1’ format so that I’m not sending it in clear text.

Citrix ‘Local App Access’ Explained

I wanted to share some details on this feature that was introduced in XenApp 6.5 that I don’t think many people are aware of, even though the changes that were introduced to support it affect anyone using Reciever 3.X, XenDesktop 5.5+, and XenApp 6.5. In this post I’m going to attempt to explain the basic functionality that ‘Local App Access’ (LAA) provides, and the basics of how it works.

If any of you are familiar with RES software, they’ve been providing a platform agnostic ‘Reverse Seamless’ functionality for some time via their Virtual Desktop Extender product. Here’s a short video that gives you a good idea of what the challenges reverse seamless aims to solve:

As you can see, the purpose of a ‘reverse seamless’ window is to give users the ability to run local application windows within a remote desktop session. In XenApp 6.5 and XenDesktop 5.5+, this functionality is built-in by way of processes running on the client (redirector.exe) AND server (revseamlesslauncher.exe & vdaredirector.exe) that enumerate, launch, and handle local windows within a published desktop session.

The easiest way to see this functionality in action is to follow the steps listed in the Quick Start Guide for Local App Access and Integrating Local User Applications in XenApp 6.5. The gist of it is that published desktops that are presented using the Citrix ‘Desktop Viewer’, can be ‘Local App Access’ enabled by setting an ICA parameter, and allowing the virtual channel on the client side, which is disabled by default.

Once everything is configured and the ‘Local App’ shortcut is available on the desktop, you should be able to double click the LAA application to run it seamlessly within the published desktop session. The reason that the ‘Desktop Viewer’ is required is that it’s responsible for managing the Z-order of the LAA app within the seamless published desktop window.

The way that Citrix is able to present ‘reverse seamless’ windows is not that different from how they present regular ‘seamless’ windows, which is by injecting API hooks into all client side processes, which allows them to inject the necessary identifiers for Desktop Viewer to be able to detect and handle the window within the ICA session.

Another major feature included with LAA is the ability to redirect URLs to the local internet browser which is automatically launched as a reverse seamless window by way of an IE browser helper object that’s installed on both the client and server. This is useful for instances where a local browser can overcome challenges of screen painting, such as rich media that can’t otherwise be redirected, or security/location nuances that require the browser to be running on the client endpoint device.

I hope this brief rundown of LAA was useful, definitely let me know if you have any trouble getting it to work in your environment.

XenDesktop SiteDiag (aka Site Checker v2.0)

Introduction to XenDesktop SiteDiag featuring WorkerDiag

Latest stable build available for download here

SiteDiag is my reworking of the original Site Checker tool that I developed while I was working on the XenDesktop Global Escalation team at Citrix. The purpose of this tool is to provide administrators and consultants with a utility to help diagnose issues with, and configure advanced/PoSH-only settings of a XenDesktop 5.x Site.


SiteDiag was designed to have a look and feel similar to that of Desktop Studio, though it lacks certain functionality such as provisioning or assigning cloned vms. Since its a multi threaded winform that runs powershell scripts in a pipeline runspace, it’s pretty quick to use, and certainly more responsive than Studio. The main purpose of this tool is to view and modify site settings that aren’t otherwise displayed in Desktop Studio.


Some of the advanced settings that aren’t available in Desktop Studio are:

  • Check and fix issues with XenDesktop Site Services on all DDCs in a site
  • Enable service logging for each service on every DDC
  • Delete VM & PVD Storage
  • View & Cancel power actions
  • Edit advanced desktop group settings (all idle pool settings, logoff/disconnect power actions, WillShutDownAfterUse, etc.)
  • Display all details about almost any object clicked in the TreeView (ADIdentity pools, provisioning schemes, etc.)
  • View active/disconnected sessions by state
  • Enumerate a site to text file
  • Search for any element in a site

The tool also provides the following functionality as Desktop Studio, but is a MUCH faster alternative to the XD5.x MMC snapin:

  • Execute power actions
  • Enable/disable maintenance mode
  • Cancel/clear provisioning tasks (can run bulk actions)
  • Disconnect active sessions, logoff disconnected sessions

I’m currently working with Carl Webster to finish up the XenDesktop 5.x PowerShell documentation script, after which I plan to include in this tool. Also, I recently added remote connect functionality, though it’s only been tested by myself to this point, and requires the PowerShell SDK and required domain rights to access the DDC server.


I came up with this tool for a specific environment I was working on where the customer was experiencing intermittent registration issues among 10000+ static-assigned VMs spanning four XenDesktop ‘hosts’. The main purpose of this utility is to display key data points about VMs, or ‘workers’, that are unregistered from the XenDesktop site.

XenDesktop WorkerDiag

The biggest advantage of using this tool over Desktop Director is that it queries up to date WMI data points that are combined with XenDesktop PowerShell SDK results. For example, being able to see why certain machines were powered off, and comparing that to the WMI uptime can help to characterize power issues in a larger environment. I also added items such as displaying the VM’s ‘ListOfDDCs’ registry value, and check to see if the perfmon counter library is corrupt. All of the colums are movable, sortable, and hideable, and the results can be exported to CSV for reporting.

I’ll continue to update this page as I modify & expand this tool’s features and add compatibility with the next version of XenDesktop. Please let me know if you have any questions, comments, or concerns about these utilities.


NetScaler Bootcamp

The most advanced cloud network platform.

The most advanced cloud network platform.

A few of us at iVision just completed a two day NetScaler bootcamp led by Richard Nash at my old office in Alpharetta. With access to a hands-on learning lab, we were able to gain a solid understanding of Netscaler fundamentals.

Day one started with a lecture that covered core topics, including the following key features:

  • TCP Connection Multiplexing
  • Load Balancing
  • SQL Load Balancing (DataStream)
  • Compression
  • Clustering
  • High Availability
  • SSL Acceleration
  • Attack Defense
  • Application Firewall
  • Global Server Load Balancing
  • Caching

We then worked through several scenarios in the learning lab. Being new to NetScaler, I was impressed with how well the Java UI performed, and was quite pleased with it’s functionality and ease of use. The main menu was a bit scary looking at first, but once I navigated through the categories a few times, I was able to quickly find the settings I needed to configure.

The day one lab gave us a good understanding of the steps needed to setup a NetScaler VPX HA pair for load balancing, content switching, and SSL Offload. Generating the SSL cert was a hassle as it always is,  but fortunately the lab was already equipped with a Certificate server.

On day two of the bootcamp, we spent time working with HTTP header modification, port redirection, and URL transformation. We also covered DataStream SQL load balancing and rate limiting, which was very impressive functionality to configure and see in action. Database responders, token-based load balancing, and integrated SQL caching really rounded out the lab.

Unfortunately we didn’t get to cover Access Gateway, but I took some time to review Bill Hackley’s step by step instructions on the Citrix Blogs, which I was able to fairly easily implement in my lab environment. I was pretty satisfied with this training, and believe our team is much better equipped to lead many successful implementations with the foundation that this two day crash course provided!


First post – A little bit about me

Greetings, and welcome to my blog! My name is Kenny Baldwin, and I work as a Senior Citrix Consultant with iVision in Atlanta GA. I spent the last few years prior to iVision working as an Escalation Engineer for Citrix Systems, during which time my main area of focus was troubleshooting advanced technical issues reported by enterprise customers and Citrix partners alike. I’m MCSE/CCIA/Security+ certified, and have been in the field for over 10 years. I’m an Atlanta native, and have a wife and two daughters (1 & 3).

I’ve been working with Citrix products since 2009, and was fortunate to be able to spend a lot of time working with source code to help isolate and resolve customer reported bugs. During my time at Citrix I learned about many advanced debugging and troubleshooting techniques, with a focus on XenDesktop and XenApp issues. I gained a deep understanding of the inner workings of HDX, brokering, session launch, and site architecture, developing tools and scripts along the way. Working at Citrix also helped me to increase my understanding of Windows internals, as well as administering and troubleshooting the various supported hypervisor platforms.

I presented at TechEdge 2010 on HDX Flash as well as troubleshooting XenDesktop, and was awarded the ‘Services Hero 2012’ distinction for providing ‘world-class’ technical support. If you’ve ever worked with XenDesktop 5.x, you might be familiar with the ‘Site Checker‘ tool, which I created mostly out of necessity while supporting the product. I’ve been a major contributor to the XenDesktop support forum and visit CitrixIRC.com much less often than I’d like to.

Now that I’m a consultant with a Citrix partner, my main focus will be designing and implementing Citrix solutions. I hope to combine my unique understanding of XenDesktop and XenApp with iVision’s field-proven delivery assurance model to provide world-class Citrix solutions to our customers.

My hope is that this blog will give me an outlet to share my experiences with XenDesktop and XenApp including various tips, tricks, scripts, how-to’s, and troubleshooting tools for other Citrix professionals.

Thanks for stopping by, and may you find some Zen in your Xen! 🙂