Introduction

How often have you found that there is a lot of “How To” or run-book style documentation out there, but none of them seem to completely address the combination of your requirements? And while you have expertise in one or more product areas, have you found that making the pieces work together seems challenging sometimes?

I ran into such an example not too long ago. I had to configure an Access Gateway SSL VPN to a XenDesktop environment, accelerate the traffic, and support Single Sign On. There was not a comprehensive document out there that I could leave behind with the customer.

So I took a different approach. Rather than create an exhaustive document, I just listed the steps and referenced only the specific sections in existing product documentation, knowledge base documents, and some custom information.

For my specific project needs, (User/AGEE PlugIn/Repeater PlugIn > NetScaler AGEE > Repeater > XenDesktop) I came up with the following set of instructions that I left behind with the customer.

Step One – Create the XenDesktop Environment

I, personally, was OK with setting this up. Otherwise I would have used the Evaluating XenDesktop section (Section 4) of the XenDesktop product documentation available from the Citrix eDocs site. This can be retrieved from http://support.citrix.com/proddocs/index.jsp and selecting XenDesktop.

Step Two – Install the Citrix Repeater

To insert the Citrix Repeater into the data flow, I simply performed the steps outlined in the Citrix Repeater Quick Installation Guide. This document comes with the product, or can be downloaded from the Citrix product download site(http://citrix.com/English/ss/downloads/index.asp in my case.

One note was that on the second page of this guide, the “Gateway” address referred to is the default gateway that is used by the management dialogs – not the default gateway for user traffic.

Then I added the licenses to the Repeater. The licensing process is driven by the “License Host ID” that is shown in the Repeater Management GUI. I found the details of this procedure in the Citrix Branch Repeater Licensing Guide, which was part of the product documentation set I downloaded.

Lastly, I set up the Signaling IP address. This is the Repeater-hosted IP address that the client-based repeater plug-in-in connects to in order to establish acceleration with the repeater appliance. This is discussed on page 7-84 of the Citrix Branch Repeater Family Installation and User’s Guide document available from the product download section of the Citrix web site. This IP address is set in the Repeater GUI > Configure Settings > WANScaler Client panel. Note that this Signaling-IP must be enabled in the menu as well.

Step Three – Configure the NetScaler Access Gateway

In this step, I added the configuration elements to the NetScaler Access Gateway such that it would allow the Repeater to optimize the traffic to the XenDesktop infrastructure behind it. I used the instructions in the “Turbocharge Access Gateway” document which is available for download from: http://support.citrix.com/article/CTX121035.

Since I was using NetScaler Access Gateway Enterprise Edition, I used only Section 7 for the details of how this is done.

Section 9 of this handy document pertains to customizing the Repeater Client software – used at the remote user’s laptop, etc. – in order to pre-populate the signaling IP address. In volumes, this is good to do for ease of distribution. Because mine was a simple, limited-user configuration, I chose to let the user customize the parameter after installing the Repeater Plugin.msi (from the Citrix product download site(http://citrix.com/English/ss/downloads/index.asp in my case) on their own.

Then they simply do the following:

• Open the Receiver and right click the Acceleration Plug-in in the list.
• Selecting Manage Acceleration will present a menu to specify the Signaling-IP address.

Also, since my configuration goes straight to the XenDesktop system and not to a landing page, updating the NavUI home page as discussed on page 25 in the above document, was not required.

Lastly, because the acceleration traffic policy set above breaks the Single Sign On process, I needed another Access Gateway Traffic Policy. This traffic policy causes Repeater-specific optimization to be bypassed for all http traffic sent to the XenDesktop Desktop Delivery Controller.

I simply repeated the steps on pages 18-19, but using SSO-Policy and SSO-Profile. The specific overrides will include:

• Policy -> DestIP == <IP address of DDC> Netmask 255.255.255.255
• Profile-> Protocol = HTTP; WanScaler = OFF

Then I bound the two policies to the Traffic section in the Virtual Server’s Policies tab. There I made sure that the exclusion policy is set to a higher priority (lower numeric value) than that of the generalized traffic policy. This causes optimization to be turned OFF for http (the SSO traffic) requests to the Desktop Delivery Controller only.

Acceleration is performed, however for all other (TCP) traffic to the rest of the subnet because this traffic does not match the criteria of the first policy in the list.

Summary

In following the above steps, I quickly created a configuration which authenticated and accelerated user traffic to the XenDesktop virtualized environment.

Furthermore, using the Repeater Plug-in dialogs, the user can see the actual acceleration realized.