Why use a Netscaler to change the XML broker answer

Citrix NetScaler is a versatile tool to distribute and modify datastreams in very generic and powerful ways. Especially in enterprise contexts, where protocols are often proprietary, this enables customers to add a little extra piece of plumbing to protocols they can’t control without the need of hiring developers. This blog is about applying such a little extra piece of plumbing to one of Citrix’s own protocols, the one that StoreFront speaks with the XMLBroker instances of XenApp or XenDesktop. Obviously, this is not officially condoned nor supported by Citrix (The XMLBroker piece, the NetScaler piece is just regular configuration) but it solves a problem that is typically solved by other unsupported ways such as WebInterface modifications.

The Citrix Netscaler MPX/VPX is able to rewrite any HTTP answer with a very powerful engine. If you configure a Store to use a Netscaler LoadBalanced vserver for XML Broker you can modify the answer to any Storefront request originated from any kind of Receiver or device type or OS (Windows, Mac, iPhone, iPad, Android, …). It also works for Legacy Receiver to StoreFront.

If you want to Hide application with WebInterface please follow the instruction at http://support.citrix.com/article/CTX123969

Storefront communication with XML Broker

When a StoreFront wants to list the applications available in you XA/XD environment, it sends an XML request to the XML Broker servers defined in his config (also named Delivery Controller).

An example of XML broker REQUEST sent by a Storefront server to obtain the application list:

Then the XML broker server answers with the application list and provides some basic fields of all published applications.

An example of XML broker RESPONSE to a StoreFront request:

Each published application or desktop is defined by an xml block delimited by the tag <AppData></AppData>

Ie:

Application filtering based on the Application Name field in XenApp

The Application Name field specified in a XenApp published application corresponds to the “InName” xml tag of an xml broker response.

You will have to create a Rewrite Policy per Application (or Desktop) you want to hide.

Step 1: Configure a XML Broker Vserver on your Netscaler

Step 2: Create a Rewrite Action with the following parameters

Name xml_broker_desktop
Type DELETE_ALL
Expression to choose target text reference HTTP.RES.BODY(50000)
Pattern <Desktop_application_name>
Refine Search EXTEND(40,300).REGEX_SELECT(re#\s*<AppData>.*\s*<\/AppData>#)

Step 3: Create a Rewrite Policy

Name xml_broker_desktop_pol
Action Action name define at Step 2, ie : xml_broker_desktop
Expression HTTP.RES.BODY(150).CONTAINS(“<ResponseAppData>”)

Step 4: Assign the Rewrite policy to the XML Broker LB vserver

–          Open the vserver

–          Go into Policies/Rewrite/Response

–          Click on “Insert Policy”

–          Specify the Policy Name created at Step 3

–          At “Goto Expression” select NEXT or END depending if this policy is the last one or not.

Step 5: (Optional) Update your Storefront configuration to use this XML broker vserver.

Step 6: Enjoy !!!

REMARKS

–          The Regular Expression configured at the Step 2 for the Rewrite Action is to select everything starting by: 

and ending by: 

–          Take care about the value defined for the EXTEND command. The first value (40) defines the number of bytes to extend the selection BEFORE the matching PATTERN defined.

In this example the value has to be greater than 37.

The second value (300) is for the number of bytes AFTER the PATTERN.

In this example the value has to be greater than 242.

If you specify a value too high you could include the previous or following application definition like in this example:

  • An EXTEND(xx,515) or a greater value will include Desktop_application_name AND Notepad in the DELETE_ALL Action.

Warnings

This method of packet rewriting is presented “as is” and is not supported by Citrix Technical Support. I recommend you to have a second XML Broker vserver configured in parallel in the same Netscaler in order to troubleshoot your XenApp/XenDesktop platform access.