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”
Now it gives me the error:
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
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?
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
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”:
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:
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:
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. 🙂