Since I blogged about Health Monitoring and Recovery (a.k.a. Health Assistant) feature of XenApp, I received several requests on the internals of the 10 test packs. So, here you go.

  • Logon/Logoff test

This test detects failures (typically external to XenApp) that cause users to rapidly logoff the system and potentially create a black hole in the farm. The test will monitor logons and logoffs to a XenApp server. If logoffs are rapid and consistent, the test will throw an error condition.

This test has the following three unique parameters that must be updated through command line arguments. These arguments can be managed centrally using the Access Management Console.

  1. SessionTime -  specifies the time spent in each session.  If the amount of time spent in the session is less than this value, it is treated as an error.
  2. SessionThreshold – specifies the session error threshold at which the service should throw an error condition.
  3. SampleInterval – specifies the time for which the session time sampling is done.  After each interval, the monitor checks to see if the SessionThreshold has been reached.  If it has, it will signal an error when queried by the logon monitor test.
  • Terminal Services test

This test enumerates the list of sessions running on the server and queries session information (such as user name).  It is similar in functionality to the “quser” utility. The test communicates directly with Terminal Services by using the “WTSEnumerateSessions” API call.

  • IMA test

The IMA test queries the IMA service to ensure that it is up and running by performing an app enumeration on the IMA service. It uses an internal API call to enumerate the applications.

  • XML Ticket request test

This test queries the Citrix XML service on the local machine.  The service responds with XML data that includes a XenApp ticket. This ticket is checked for validity. If the ticket check fails or if a server/port fails to respond to the request (e.g. a socket timeout occurs) the test returns an error. This test communicates directly with the XML service through a TCP socket via the Winsock API.

  • Microsoft Print Spooler test

The Print Spooler test attempts to ensure MS printer spooler reliability.  It will enumerate printers on the local server, enumerate printer drivers and printer processors using Microsoft Windows APIs.  Exercising these tasks is fundamental to ensure that the MS printer service is running smoothly.  The reason we enumerate these three different items is because enumerating just printers may not give us any information as we will only be able to enumerate printers that an administrator gives Local Service permission to read. However, drivers and processors can be enumerated by Local Service.

  • Citrix Print Manager Service test 

This test is responsible for ensuring that the Citrix Print Manager service is operating properly.  The Citrix Print Service test calls internal APIs to ensure reliability.  Specifically, the test will use RPC to call Citrix Print Manager service to enumerate all printers on the local machine. If enumeration does not complete successfully the test will throw an error condition.

  • Check DNS test

By default this test will run a forward DNS lookup that is guaranteed to go over the wire to the local machine’s DNS server. Optionally, users may run a reverse DNS lookup. For either test, we gather the locally configured information and then make a DNS query to compare the results.   

The forward DNS lookup will gather the IPv4 address of the local machine from the installed NICs. The test will then make a DNS query based on the locally configured hostname and compare the resulting IP address to the one we grabbed locally. If these two IP addresses do not match, the forward DNS lookup will throw an error. 

The reverse DNS lookup will gather the hostname from the local machine.  It will also take the locally configured IPv4 address.  Using the local address, it will convert it to the reverse DNS address and query for the hostname.  The test will then compare the resulting hostname with the one it originally queried from the local machine. The reverse DNS look up will not be set to run by default as many organizations neglect configuring this and which may lead to false negatives. 

Successful completion of this test will ensure DNS is working properly on the local server.

  • ICA Listener test

The responsibility of the ICA Listener Test is to ensure clients can make a successful connection to the local server via the ICA protocol.  We will validate this functionality by pinging the ICA listener and monitoring the response.  When idle, the ICA listener emits the text “ICA”. By looking for these characters we can verify that the ICA listener is in a good state.

  • Check XML Threads test

The Check XML Threads test will run as a monitor test.  This means that we will look for unwanted behavior over a period of time.  The Check XML Threads test will look for too many XML worker threads to be running for a prolonged time period.  By default we set this time to be one minute.  If the test determines that the worker threads are past the default threshold of 10 threads for over a minute this will indicate that the XML service is being stressed too much.  The administrator may wish to add an extra server to handle some of the load.  When the threshold is met, the corrective action will execute. 

This test aims to monitor XML service trafic load.  When the service is overloaded, Web Interface connections will suffer. This test will alert administrators that they may need to address XML performance. This test will make use of a new performance counter that we added with the test pack. The performance counter will measure the number of active worker threads running in the XML service. There were recent changes made to the XML service where worker threads are not killed when they are done being used. Instead, they are kept alive but are made idle. This change was made to improve performance. However, the old performance counter still reflects the total number of worker threads. This value is not what we are interested in because there may exist worker threads that are idle. With data from the new performance counter, the test will simply poll the counter for the number of worker threads that are actually doing work.

  • Check Local Host Cache test

The Check LHC test is responsible for recognizing and responding to LHC corruptions and inconsistencies on the local machine that could result from stale data left when removing a server and/or published app.  LHC corruption refers to compromised integrity of LHC object(s). The test will check what the object size should be versus the actual size of the object.  LHC inconsistencies occur when there are duplicate entries or when entries do not match the datastore objects. To verify inconsistencies we focus on four contexts:  MfServer, CommonServer, MfApp, and CommonApp. If we detect an error when running these checks, we perform an LHC refresh. After the refresh is complete, we check the integrity and consistency to ensure that the problem has been resolved. If the problem persists, the administrator configured corrective action will be executed.