Our deployment includes Windows Embedded and Windows ThinPC clients that use the Citrix Desktop Lock to connect to our XenDesktop environment. The Citrix Desktop Lock requires a services site, otherwise known as legacy support in Storefront. In XenDesktop 5.6, this worked well and we connected to our internal site via HTTP with web interface. In Storefront, however, there are some caveats. HTTPS is required for Receiver to connect to Storefront stores unless you modify a registry setting in receiver. Additonally, with Desktop Lock in the mix we cannot simply use a redirect with responder or web interface to direct the clients to the new Storefront URL. When Desktop Lock is present, it presents (incorrectly) error 404, not found.
With that in mind, we decided to address the issue of migrating our clients from web interface (with XD 5.6) to Storefront (with XD 7). There are some key discoveries we made while trying to create a rewrite, many of which should be well known to Netscaler admins.
First, netscaler processing order. We were trying to re-write the http.req.host and not seeing anything apparently change. For all intents and purposes, the req had already ‘arrived’, so changing the host header wasn’t going to magically send it along its way.
Second, we must transform the url to match the new Storefront legacy format.
Third, we must send this request to the Storefront backend server. For testing we did this by modifying which vServer the service sent traffic to, but since we want to retire that vserver, we’ll change DNS to point to the SF vserver in the future.
Finally, Storefront legacy sites only support one authentication method, and only one legacy site can be configured per store. This meant to support our n500 devices and our Windows Embedded Devices (which are configured for passthrough) we needed 2 stores, 2 legacy sites, one with prompt, one with passthrough.
To configure a rewrite action, enable the feature in netscaler if it is not. Create a new policy. Assign the expression or one similar shown below.
Create an action similar to the one shown below
Assign the rewrite policy to the vServer the clients are looking up via DNS
(Optionally) assign this to the storefront vserver and change the DNS record to point to the storefront vserver instead of web interface.
That is it. You should now be able to seamlessly move all of your clients over to your new Store if you need to use the services site!
What do I put for the policy expression?
Hi Taylor. You can use any standard NetScaler policy to match — for example, if you wanted to rewrite every single request, you could simply use “true”. However, if you wanted to match specifically Wyse Thin clients, you could do something like ‘REQ.HTTP.HEADER User-Agent Contains WTOS ‘
Can you tell me more about the project and environment you’re trying to use this in?