Jump to content
Welcome to our new Citrix community!
  • 0

XA 7.15 LTSR CU4 or CU5 breaks HdxSslEnabled Broker Access Policy

Christoph Sinabell




We are experiencing an perfectly reproducible issue. When applying CU4 or CU5 to a VDA (only the VDA), the VDA ignores the HdxSslEnabled Broker Access Policy Rule setting. Since setting up XA 7.15 we have two policies one for direct connections to the delivery group and one for connecting via Netscaler Gateway. One with HdxSslEnabled=$true (Direct - NotViaAG) and one with HdxSslEnable=$false (Netscaler - AnyViaAG). Because we use a single FQDN for internal and external connections this ensures that a) users don't receive any SSL error message when using HTML5 Receiver internally as the ICA websocket connection is made via a enterprise CA assigned to the VDA directly and b) external users would still be able to use DTLS and EDT. This worked perfectly fine. However after applying CU4 or later this is broken. It seems that upon connection the HdxSslEnable=$false is ignored and connections fail with:


"The Citrix ICA Transport Driver received SSL initialization error 0x80090331."


until we also set HdxSslEnabled=$false for the BrokerAccessPolicy Rule with AllowedConnections=NotViaAG. This is weird since this shouldn't apply to connections made through Netscaler and it also shows that the system knows the connection is made through Netscaler in Director (Connected Via ...). Unfortunately this of course again breaks internal websocket connections which go directly to the VDA, which is why we created these two BrokerAccessPolicyRules  in the first place. Btw if HdxSslEnabled=$true on CU4 or CU5 internal connections would still work without issues it's only when going over Netscaler that issues start to appear.


And last but not least when upgrading the VDA from 7.15 CU4 to 1906 it starts working again.



Link to comment

2 answers to this question

Recommended Posts

  • 0



Thanks for taking your time to look into this. I've done some further testing, because we have pressure from the customer on our end to get this up and working again. We went back to our working XenApp 7.15 CU1 Image (Windows Server 2016 as OS) and instead of upgrading removed the VDA rebooted and then used the VDACleanupUtility (most recent version) to get a clean base image again. We created a snapshot of this stage and then tried a fresh install of the below versions. Reverting back each time to the snapshot:


XenApp 7.15 CU4 -> broken.

XenApp 7.15 CU5 -> broken.

XenApp 1906.2 -> works. HdxSslEnabled is false again for connections via AG.

XenApp 1909 -> broken again!





Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...