Debugging Using XmlServiceExplorer - Part 2

Published on 24 Jul 2008
Tags #Free Tool #HTTP #Presentation Server / XenApp #Web Interface #XML service #XmlServiceExplorer

In the first part of my tutorial about the XmlServiceExplorer, I have explained how session management is performed by the Web Interface and how the same behaviour can be reproduced by the XmlServiceExplorer. I recommend you also read the initial article: Talking to the XML Service.

Now I’d like to introduce several requests providing useful information about a farm and its servers through the XML service.

Gathering Farm Information

Starting with a single server name and port, there are several interesting pieces of information to be retrieved from the XML service without authenticating. The XML service readily produces the name of the farm it belongs to as well as a list of member servers (see the screen shots below).

By using the server and client type fields, the selection of servers can be narrowed down. But in today’s world only Win32 and Ica30 matter for the server and client type, respectively.

Retrieving Farm Capabilities

Due to the on-going development and the integration of the products, a request was introduces to read the capabilities supported by the farm from the XML service. The following screen shot shows a list of features present in Presentation Server 4.5 FP1, for example:

separate-credentials-validation: The XML service is able to validate credentials before actually requesting applications.
multi-image-icons: Web Interface 4.6 allows for icons to be presented in higher resolutions and colour depths. This capability enables an application to request a specific icon format from the XML service.

Using this request on Presentation Server 4.0 and MetaFrame Presentation Server 3.0 may well result in a shorter list of capabilities as some were added in the younger releases.

Resolving Addresses

The XML service provides several ways to retrieve an address for a connection to farm resources. The first screen shot below shows the response received by requesting the address of the farm which is translated to the address any member server. Such an address comes in handy if the interaction with the farm is independent of the individual server, e.g. a member server is dynamically selected to create MFCOM objects via DCOM (CreateObject(MetaFrameCOM.MetaFrameFarm, "myserver")).

In other situations, obtaining any server does not suffice to complete a given task, instead the address of a specific server is required. By selecting the server radio button in the second screen shot, the string is interpreted as the name of a member server and resolved to its address.

In addition to the described use cases, application names can also be resolved to the address of any server publishing this resource. The third screen shot below demonstrates the use of the application name radio button to have the XmlServiceExplorer interpret the string as an application name.

The format of these presented addresses is specified by the server address type field.

After presenting several methods to resolve a name to an address, I’d like to refer back to the demonstration in the first part of this tutorial in the section how to retrieve information about disconnected sessions. I explained how to request a list of disconnected sessions for a user and client device. The RequestAddress also enables retrieving an address for a disconnected session.

Validate Credentials

The XML service does not perform any kind of session management for requests and does not perceive any logical connection between consecutive requests. Therefore, the application interacting with XML service is required to cache credentials and include them in all user-specific requests like session management.

Before such an application stores the user credentials for subsequent use, it needs to confirm the user’s knowledge of matching username and password. Just like the Web Interface, the application sends a RequestValidateCredentials to the XML service and receives and an empty ResponseValidateCredentials if the credentials are successfully validated.

The following screen shot demonstrates a request to validate credentials with the XML service. This comes in very useful to ensure the correct communication with any configured authentication backend like Active Directory.