After having published the XmlServiceReader, I have described how to use this tool to customize health check in XenApp Health Monitoring and Recovery (HMR). In this article I will cover health checks that to not apply to a single server but assure the operation of the farm as a service independently of individual servers.
In my experience, terminal servers are not properly monitored resulting in administrators not knowing how a farm performs – neither concerning the peak performance nor the trend of the handled load. This leads to an inaccurate and often inadequate sizing of the terminal server environment because only rough estimates arise from such a negligence.
In this series of articles, I’d like to expand on the topic and stressing why monitoring is important for all environment (including terminal servers), what needs to be monitored and how is can be achieved.
When EdgeSight is set up correctly, all data is collected without any user interference especially no administrator credentials are required. Unfortunately, this is only true for historical reports generated from the EdgeSight database. As soon as real-time reports are used and workers are started manually on devices in trusted domains, the administrator’s job gets tricky.
We all know that it is trendy to use a profile solution to rid Windows of some shortcomings of roaming profiles. And quite a number of you have looked at Citrix Profile Management (also known as User Profile Manager). In its current incarnation, UPM is configured using a group policy specifying the profile path. But similar to utilizing the “Set path for TS Roaming Profiles” for Terminal Services (soon to be Remote Desktop Services), this introduces the limitation that all users logging on to a server receive the same profile path – most most likely with some dynamically substituted components like environment variables or, in the case of UPM, fields from the user object in Active Directory.
Unfortunately, both solutions (UPM and “Set path for TS Roaming Profiles”) are inferior to managing profile paths in Active Directory user objects. The latter enables administrators to distribute users across several servers or use components representing an organisational affiliation. Wouldn’t it be neat to combine those to methods of maintaining profile paths?
I have recently worked on an implementation for a customer and was concerned with a large number of group memberships. Although the solution for authenticating against the operating system are well documented by Microsoft (here, here and here), the XML service does not allow requests larger than 4KB. So if users have a large number of group memberships, authentication via the XML service can fail due to this limitation. But here’s the solution.
As EdgeSight is a component that is offered by Citrix in several Platinum Editions for strategic products as well as a substitute for Resource Manager in XenApp, customers like to profit from the value-add compared to traditional system management products. EdgeSight is often used to augment the data collected by those tools. But when using EdgeSight with Provisioning Server, things get a little more complex because an agent is assigned a unique ID to match data uploads to the correct database entries.
I have been involved in the rollout of EdgeSight with several customers. Sounds great so far, doesn’t it? But more than once I needed to tackle with very rigorous security standards causing the setup to take much longer than usual. These standards require installations to be executed with the minimal set of permissions. Unfortunately, most installers are not designed to work that way and vendors do not properly document the permissions expected for their setup wizard.
After publishing the XmlServiceReader and writing about the shortcomings of the health check for the XML service provided by Citrix, I like to expand on the process of creating a custom health check using the XmlServiceReader.
You may well ask why I created a tool to send arbitrary requests to the XML service and parse the reply in scripts – which is, by the way, called XmlServiceReader. First of all, I did not like the tool included with the Health Monitoring and Recovery of Presentation Server and XenApp – called RequestTicket.exe – due to its limitation to being executed on the same host as the XML service is located. Furthermore, this tools has a hard-coded request and does not allow customization of the request sent to the XML service.
Since I have released the XmlServiceExplorer and XmlServiceDigger,I have received several requests for another tool allowing for custom health checks against the XML service, e.g. see this comment. The XmlServiceReader is a command line tool sending arbitrary requests to the XML service and printing the reply to the same window. This output can be checked in a script to determine whether the reply is valid and the service fully operational.