Important Note: This has been tested on the 1811 release and may or may not impact other versions.
As part of a recent deployment I had the opportunity to configure Citrix Director App Probes in a customer environment. If you don’t know what App Probes are, they are a recent addition to Citrix Director which enables the automatic testing of Application Launches on daily basis. This enables you to test the critical path for application launch including;
- StoreFront Reachability
- Storefront Authentication
- StoreFront Enumeration
- ICA File Download
- Application Launch
Errors captured by any of these tests would indicate that a user would not to be able to access an application, so any failures can be notified to an administrator or administrators via email alert.
In order to run these tests, you need to install an App Probe Agent on a machine along with a Citrix Workspace App (Receiver) installation. The Probe itself is pretty lightweight and has a wizard driven configuration, the installation and configuration of these is well documented so I won’t go into the details on this, however I would highlight that you need to enable explicit authentication in your StoreFront store for it to work (as I missed this first time around!).
This looked great, nice and simple setup and useful functionality – Citrix for the win! And then it just failed – completely.
By this I mean I couldn’t configure it at all – despite the environment being up and running and for all intents and purposes in production, the App Probe agent would not connect to StoreFront, or NetScaler Gateway at all with “Workspace was unreachable”.
There is a log available in the installation directory for the app probe agent – this contains little useful information beyond the parameters I have entered, so nothing to go on there.
At this point I gave up, but came back to it the next day with fresh hopes. My first attempt was to use Fiddler to debug the comms between the agent and the StoreFront deployment. Out of the box, the TLS configuration that Fiddler uses, only uses either SSLv3 or TLSv1.0 to connect to websites – as per leading practices , these are disabled on the Citrix ADC Virtual Server that load balances the StoreFront servers in the environment – so the first thing we get in the logs is that Fiddler can’t connect at all to StoreFront.
At this point some mental bells were ringing, so I disabled Fiddler and on the StoreFront vServer I tried re-enabling TLSv1.0.
With this enabled, we can get past the first step of the configuration! Great – we’ve identified the problem, but unfortunately we can’t really leave a TLSv1.0 vServer in production.
This behaviour is partially a Microsoft thing and partially a Citrix thing. By default, .Net based applications will only use TLSv1.0 to establish network connections. In the code of the application the developer can specify that they want to enable secure protocols, but if this is not done then it defaults to TLSv1.0. If the back-end service that the application connects to does not accept this, then the connection will fail.
Thankfully we can override this behaviour in the registry on the App Probe machine by applying the below registry settings.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
“SchUseStrongCrypto”=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
“SchUseStrongCrypto”=dword:00000001
With these registry settings enabled, the App Probe Agent is successfully able to connect to the StoreFront vServer and access the configuration. Now for the next problem…
“Workspace Credentials fail to authenticate” – now obviously you check the account details you have provided are entered correctly, but you continue to get the same error.
On checking the StoreFront event logs, something is clearly amiss.
This error implies that the persistence configuration is incorrect – despite this many users are using the StoreFront deployment in anger without issue.
On further analysis using Fiddler, the StoreFront load balancing vServer is configured to use Cookie based session persistence. When the App Probe agent sends requests to the vServer it is issued a cookie to maintain persistence with the same storefront server, however it does not send that cookie with subsequent requests causing each request to potentially be directed to an alternate StoreFront Server.
The way to mitigate this is to configure Source IP based persistence instead. Now this may not be a good idea for a production load balancing Virtual Server as with proxy servers or NAT devices in play, you could potentially have large numbers of clients with the same persistence configuration behind a single IP address, however with the current configuration, Cookie based persistence simply won’t work.
Your options here are to either change the persistence method in use to Source IP for all connections (less ideal), access a single StoreFront server directly (reduced resilience and alters the connection path which reduces the efficacy of the tests) or to create a second load balancing vServer using the same Certificate on a different IP address but with the required persistence, then configure the hosts file on the App Probe machine to direct the StoreFront DNS name to the “new” Load Balancing vServer.
Resolution Summary:
The App Probe Agent uses TLS1.0 by default – force this to use TLSv1.1 or 1.2 using the SchUseStrongCrypto registry setting. More info here.
The App Probe Agent does not support cookie based persistence requiring an alternative persistence mechanism on the load balancer.
Application Delivery and Desktop Virtualisation 