Netscaler Access Gateway issue

Randomly seen ¬†“Unable to launch application. Contact your help desk with the following information: Cannot connect to the Citrix XenApp server.SSL Error 43: The proxy denied access to …. ¬†port 1494” when using 2 or more PVS based STA servers, running on the same image.


So this is one of those annoying error messages that can mean a great many things.

  • Access gateway licenses might not be installed
  • Mismatched STA’s configured on the Access Gateway and Web Interfaces
  • You could actually have some firewall issues with the XenApp server you are trying to hit.

However in a recent case, all of those factors were fine, and the problem would appear randomly. Usually if any of the above issues are present, it is an all or nothing game. It is either totally broke every time or it works. However in my case it would randomly work. You click on your app in web interface, and if you got the above message and retried a few times it would connect fine. Other times it would connect with no message at all.

So to baseline the configuration,

  • 2x Netscaler 10.0 running Access Gateway
  • 2xXenApp 6.5 HRUP1 servers providing zone data collection for the farm and STA service.
  • KEY POINT : Both STA servers are provided off the same PVS vDisk.

So what is happening is best displayed in the Netscaler config for the Access Gateway virtual server. Go to the Published Applications tab and look at the STA identifiers


Now it is important to note this pic is from AFTER I fixed the issue. When the issue was occurring, both STA Identifiers were identical. Essentially Citrix was expecting the identifier to be unique and was getting confused when both STA servers were responding to the same identifier. The relevant (and fairly new) Citrix Limited Release KB article is here.

The hotfix side of the KB corrects an issue with using the XenApp Server Configuration tool, when you prepare a server for imaging and provisioning. It was not guaranteeing that each server had a unique STA. The second part of the fix is just to set the Citrix XML service to delayed start to ensure it comes up after the NIC does.

So a simple fix for an odd and random problem.