How to fix Citrix Receiver for Windows when using NetScaler Gateway and StoreFront with backend HTTP

I came across an interesting issue with Receiver 4.6 for Windows the other day where I could not add a NetScaler Gateway URL to the Receiver. The error I was getting was:

“Your changes could not be saved due to an invalid configuration of the account Store”

When you hit OK it takes you back to the Add Account dialog. So I put in my NetScaler Gateway URL again and hit Add:

Now it gives me the error:

“This account is already added. Please select other account to add or press close button.”

at which point I’m brought back to the Add Account dialog and stuck in a time loop:

Are all Receivers doing this?

What’s interesting is that only Receiver for Windows was impacted by this, all of the following worked fine:

• Receiver for Web on StoreFront 3.8 and then launching app using Receiver 4.6 for Windows
• Receiver 2.2 for HTML5
• Receiver 7.1.2 for iOS on an iPhone
• Receiver 7.1.2 for iOS on an iPad
• Receiver 12.4 for Mac
• Receiver for Linux 13.3 (HDX SoC SDK) using Raspberry HDX Ready Pi

Here’s proof of that last one launching my Windows 10 Virtual Desktop. Love this little guy. Don’t leave home without it. 🙂

So the question is, why is the Windows Receiver behaving differently from the other Receivers? Why would it not let me add an HTTPS NetScaler Gateway URL to the native Receiver though launching via the StoreFront website (Receiver for Web) worked fine?

The Windows Receiver requires an “HTTPS” URL by default. If you add your URL like this, it is by default going to go over HTTPS over an encrypted SSL/TLS connection:

If you add “HTTPS” to it, it will look fine as well:

If you add “HTTP” to the URL, it will give you a warning like this:

HTTP Store requires additional configuration before being added to the Citrix Receiver. Please contact your system administrator.

This is because the best practice is to always use SSL, whether on the front end for clients or backend communication to your servers. I always take this approach in Production environments. Anytime I deploy something I always take on a FIPS 140-2 mindset because even though you may not have to worry about FIPS Compliance right now, you may need to do something similar later even through another regulatory body so it’s best to just start out on the right foot securing your infrastructure anytime you build something no matter what industry you are in. In a nutshell, encrypt everything in your datacenter. An attacker gaining a foothold in your datacenter is all too common these days, make it as hard as possible for them to sniff out traffic.

Citrix doesn’t want you to add an HTTP based StoreFront URL here. That’s fine but but we’re adding an HTTPS based NetScaler Gateway URL. Why is it failing?

In some environments I’ve seen, people like to use the NetScaler Gateway for HTTPS traffic to the clients, but leave the backend to StoreFront on HTTP over port 80. This saves just a little bit of cash on buying another cert as well as shaves off a few min off a StoreFront deployment (binding an SSL cert in IIS). Not worth it in my opinion but I’ve seen it. In my case I had done this setup in my lab in the interest of time for a quick XenApp 7.12 demo where I just changed my NetScaler Gateway session policy to go from my normal Production environment to this new demo environment. And that’s when I noticed this was failing for Windows Receivers.

My NetScaler Gateway 11.1 and StoreFront 3.8 Setup

To explain my setup, here is my NetScaler Gateway that all my Receivers are connecting to:

Here is the session policy for native Receivers:

and here is the session profile it invokes. This URL it is hitting a load balanced vServer on the NetScaler with both my StoreFront servers behind it:

Here is the loadbalanced vserver with my 2 StoreFront servers in a Service Group behind it. You can see here I am using HTTP (port 80):

On my StoreFront 3.8 servers, I have not installed an SSL cert in IIS. I have configured my StoreFront Base URL to be an HTTP site only.

You can see here StoreFront is warning me about this because again, in Production environments you should always use SSL whenever possible:

Tweaking Receiver for Windows to work

In some cases, you may want to force an HTTP StoreFront URL against best practices. This can be accomplished by following this CTX article from Citrix called “How to Configure Citrix Receiver for Windows to Manually Add HTTP Stores”:

https://support.citrix.com/article/CTX134341

This article really doesn’t apply to us. We’re adding an HTTPS URL from the NetScaler Gateway and not direct StoreFront. Because the backend StoreFront Base URL is HTTP, the Windows Receiver sees this in it’s config after authenticating against the NetScaler Gateawy and pulling down the config. It doesn’t like it. Other Receivers are fine, but the Windows Receiver fails. It seems to need this registry key even though you’re adding an HTTPS URL.

I want to take a minute to point out that CitrixAGBasic is NOT failing. Do a aaad.debug on your NetScaler Gateway and it’s fine. Check the “Citrix Delivery Services” event log on your StoreFront servers and they are clean. No Error or Warning messages anywhere. It’s purely a client issue that occurs after authentication takes place and the client begins talking to StoreFront.

Open regedit and navigate to:

and double click the “AllowAddStore” key to edit it. Add the value “A” like this:

Now your registry will look like this:

At this point you can open Receiver and hit Logon but it may act flaky as you login and enumerate your apps and desktops. The better thing to do is to right click Receiver in your system tray and go to Advanced Preferences. Click the Reset Receiver option:

Go ahead and click Yes, reset Receiver:

and you’ll get a confirmation once it’s done:

Now Receiver will ask you to Add Account again. Don’t do it. Go to the system tray, right click, Receiver and hit Exit:

Now go to your Start menu and and launch Citrix Receiver again:

Now add your gateway URL without putting HTTPS like this:

Type in your credentials like normal:

And voila! This time Receiver actually adds the Store and enumerates your apps and desktops fully:

Go to where your name is and click on it to see Accounts:

Double click on your Store:

In the Edit Account dialog, you can see it took the backend StoreFront Base URL. Receiver is complaining that “The specified URL is not secure” even though you are going through SSL ICA Proxy via the NetScaler Gateway:

Now in a lab or small demo environment this is fine because you can control this. In a Production environment you would have to edit this registry key via Group Policy and push it down to all your clients. Of course you won’t be able to do that for home users so they’ll constantly call the Help Desk for help on this saying Receiver is broken. That’s why you should really use an SSL cert on your StoreFront servers and prevent this headache as well as secure your environment. Keep in mind you don’t have to pay for a cert from a public CA. You can always stand up your own CA server and add an internal cert to your StoreFront server. All your internal clients hitting StoreFront will trust it. When you are proxying through the NetScaler Gateway, all external clients will work just fine because they are using the public cert bound to the NetScaler Gateway vserver for communication. And you can still use SSL Multiplexing on the backend via the NetScaler (aka end-to-end SSL) so there will be just a little bit less stress on your StoreFront servers.

Here’s proof this works. In this picture I am logged into a non-domain joined PC. It has no registry key but I was able to add the NetScaler Gateway URL just fine. This is because the StoreFront Base URL was set to use HTTPS using an internal certificate. The non-domain joined PC has not idea about the internal CA even though it shows it in it’s Receiver config. Everything is getting proxied through the NetScaler Gateway URL (gw.jasonsamuel.com) which has the public cert on it:

There is definitely a little bit of a disparity between how the Receiver for Windows behaves vs. other Receivers. I hope this article helps you out if you run across this. Please leave a comment below if this helped or if you have any questions. 🙂