Your apps are not available at this time...Cannot contact *Store*

[DJAG Asset Management]

Hi folks,

I've had a search through the forums and haven't really seen a clear answer. The store account adds fine but upon clicking "Logon", it reports "your apps are not available at this time. Please try again in a few minutes or contact your helpdesk with this information: Cannot contact STORENAME".

Technical details:
- Citrix Receiver 4.0 client
- Load-balanced Cloud Gateway 2.0 with all three forms of auth enabled running on Server 2012

A few notes on things I've tried/confirmed:
- Store url (https://cgw.domain/Citrix/Storename) is added to trusted sites
- User auth security setting for trusted zone set to both automatic logon for Intranet zone and "...with current username/password"
- Group policy "allow pass through" and "allow pass through for ICA" enabled.
- Windows firewall disabled
- Can access, logon and launch apps via the StoreWeb url https://cgw.domain/Citrix/StorenameWeb just fine.
- Can access, logon and launch apps via an Access Gateway site pointing to said Cloud Gateway servers fine.
- https://cgw.domain/Citrix/Storename/discover sends a discovery.cr file containing all the Access Gateway details, beacon sites....etc etc.
- Issue occurs whether or not it's pointing to the Netscaler 10.1 frontend or directly to one of the CGW hosts.
- Citrix Pass-through Authentication (SSON) is present and running as client was installed wit /sson switch
- Receiver 3.4 Enterprise pointing to the legacy pnagent service on the CGW host runs fine and is not prompted for auth.

The odd this is there is no entries in eventlog on the local workstation or CGW host.

I think that's pretty much everything. Any thoughts?

[CarlStalhood]

Is your load balancer set to Source IP persistence (not cookie insert)? Cookie Insert doesn't work on some Receivers.

Are your load balancing services set to include the Client IP Header: *X-Forwarded-For*?

Do you have Remote Access enabled on the Store? If so, in the NetScaler Gateway object created on the StoreFront server, is the Subnet IP field blank? For newer versions of NetScaler Gateway there is no need to enter anything in this field.

On the StoreFront server, in the Authentication node, for Trusted Domains, do you have the NetBIOS and UPN suffixes added to the list?

On the client device, in Task Manager, do you see ssonsvr.exe as a running process?

In StoreFront, is the Base URL set to the load balanced DNS name?

Is the internal beacon actually accessible internally? If so then auth should go directly to StoreFront. If not then auth goes to NetScaler Gateway.

Are the Storefront URL (load balancing) and the NetScaler Gateway URL different? They must be different.

For Trusted Sites you only need the FQDN added and probably not /Citrix/Store. The auth URL is /Citrix/Authentication.

[Andres Echeverri]

Hi, i have the same issue. my scenario is less "complicated"
XD7
Storefront 2.0
Receiver 4
No Access Gateway
No Netscaler
Only auth with username and password

the storefront website works good, but don't with receiver client installed on my PC with win8
i'm receiving the same error.

all the recommendations has been applied, but doesn't work

[DJAG Asset Management]

Is your load balancer set to Source IP persistence (not cookie insert)? Cookie Insert doesn't work on some Receivers.
- Yes, source IP.

Are your load balancing services set to include the Client IP Header: X-Forwarded-For
- Not currently, but even with directing the load balancer to one CGW host only, the issue persists.

Do you have Remote Access enabled on the Store? If so, in the NetScaler Gateway object created on the StoreFront server, is the Subnet IP field blank? For newer versions of NetScaler Gateway there is no

need to enter anything in this field.
- Correct the SMIP field is left blank. Remote access is enabled for our 3 AG's, of which all test fine via web.

On the StoreFront server, in the Authentication node, for Trusted Domains, do you have the NetBIOS and UPN suffixes added to the list?
- Yes, both.

On the client device, in Task Manager, do you see ssonsvr.exe as a running process?
- Yes

In StoreFront, is the Base URL set to the load balanced DNS name?
- Yes

Is the internal beacon actually accessible internally? If so then auth should go directly to StoreFront. If not then auth goes to NetScaler Gateway.
- Yes

Are the Storefront URL (load balancing) and the NetScaler Gateway URL different? They must be different.
- Yes

For Trusted Sites you only need the FQDN added and probably not /Citrix/Store. The auth URL is /Citrix/Authentication.
- Tested with both, no change.

I have decided to go back to basics...with no change. I've removed the second CGW host from the "CGW Cluster" to make it standalone, removed all the cags including auth (leaving only username and password and passthrough), changed the primary URL to servername.domain but still the issue persists. I've added the primary url to trusted sites, confirmed sson is running, exact same issue. Testing the new URL via Web, auth works fine there as well as launching.

Any other ideas?

[Sadique Khan]

I had this problem (Receiver 4.0 and Storefront 2.0) and I found that 2 things were wrong on my development platform.
1st the URL for installing receiver was wrong .... if you export the provisioning file the URL that is actually used has /discovery on the end which I didn't know at first and had failed to enter previously.
Storefront shows the URL as
https://server.domain.com/Citrix/Storename
This is wrong, because the .cr file will show
https://server.domain.com/Citrix/Storename/discovery

2nd - my certificate was incorrect. I was initially using a self signed certificate and that didn't work so I created a proper cert request, setup my own CA on DC and signed the cert, uploaded it to the web server, added the root CA to the test win7 client. When there were no certificate errors finally receiver was able to single sign on
Obviously if you try to use the URL for web link and you get a certificate problem page then there's a problem - your receiver wont connect directly either

I fixed those 2 things and it worked.

(The receiver install command line must also have passthrough enabled and the GPO must use the template ICA settings to force passthrough ....)

CitrixReceiver.exe /IncludeSSON ENABLE_SSON=yes STORE0="NameOfStore;https://server.domain.com/Citrix/Storename/discovery;On;StoreDescription"

Edited by: sadique1972 on 24-Aug-2013 14:36

[Andres Echeverri]

Hi, Adding the "discovery" to the URL have not worked for me
i'm not using https, only http; could be the issue?

Thanks.

[DJAG Asset Management]

So long story short, I ran up a fresh SF2.0 host, made base customisations, installed the Receiver client with the below options and it worked a test. Passthrough also works fine. I do have an issues with launching apps from the Receiver for Windows 8 (think Metro, not desktop) but that's an issue for another day.

Installer batch file:

REM This is used to deploy and configure Citrix Receiver for Windows 7/8

REM Set variables
SET SOURCE=%~dp0
SET SOURCE=%SOURCE:~0,-1%
IF NOT DEFINED LOGDIR SET LOGDIR=%SystemRoot%\TEMP

SET OPTIONS=
SET OPTIONS=/QUIET
SET OPTIONS=%OPTIONS% /silent
SET OPTIONS=%OPTIONS% /includeSSON
SET OPTIONS=%OPTIONS% /ALLOWADDSTORE=S
SET OPTIONS=%OPTIONS% /STORE0="JAG MyApps;https://myapps01.justice.qld.gov.au/Citrix/JAG2/discovery;on;JAG MyApps"

REG ADD HKLM\SOFTWARE\Policies\Citrix /f /v EnableFTU /t REG_DWORD /d 0
START /WAIT CitrixReceiver.exe %OPTIONS%
shutdown -r -t 03

Group policy/registry changes:
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder\ProviderOrder", "CdmService,RDPNP,LanmanWorkstation,WebClient,PnSson,vmhgfs", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder", "CdmService,RDPNP,LanmanWorkstation,WebClient,PnSson,vmhgfs", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Logon\Kerberos\SSPIEnabled", "false", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Logon\Local Credentials\UseLocalUserAndPassword", "true", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Logon\Local Credentials\SSOnUserSetting", "true", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Logon\Local Credentials\EnableSSOnThruICAFile", "true", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Logon\Local Credentials\LegacyLocalUserNameAndPassword", "true", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\Proxy\AltProxyType", "", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\Proxy\AltProxyHost", "", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\Proxy\AltProxyPort", "", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\Proxy\AltProxyAutoConfigUrl", "", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\Proxy\AltProxyBypassList", "", "REG_SZ"
WshShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\EnableFTU" "0", "REG_SZ"
WshShell.RegWrite "HKEY_USERS\.DEFAULT\Software\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Logon\Local Credentials\UseLocalUserAndPassword", "true", "REG_SZ"

As for the guy who is using HTTP only, I did read something earlier today that a registrychange is required if HTTP only. Also, you really shouldn't use HTTP.

[Brett Long1709152229]

Having the same issue with SF 2.0 and Receiver 4 using a NS to load balancing.
Uninstalled and reinstalled SF and it worked for a day or so then the symptoms started up again.
Seems to be a bit intermittent.

We also have a backup App store that has no issues.

Going to do another clean install of SF and see how that goes.

Brett

[Brett Long1709152229]

Looks like it was the Persistence type on the Virtual Server for Storefront. Changed it from COOKIE INSERT to SRC IP and it seems to have done the job.

Brett

[Kyle Bassman]

Brett-

Are you talking about on the LB VIP ?

[Kyle Bassman]

Carl-

Is there any way around this ?

Are the Storefront URL (load balancing) and the NetScaler Gateway URL different? They must be different.

-Mine are the same.

Thanks,

Kyle

[Kyle Woodbury]

You must use source ip persistence for the Storefront LB

[CarlStalhood]

From eDocs: "The fully qualified domain name (FQDN) for your StoreFront deployment must be unique and different from the NetScaler Gateway virtual server FQDN. Using the same FQDN for StoreFront and the NetScaler Gateway virtual server is not supported."

http://support.citrix.com/proddocs/topic/dws-storefront-20/dws-manage-remote.html

[Kyle Bassman]

kylewo-

I am asking if you are talking about the Method and Persistence tab, underneath the LB VIP, which in my case I am load balancing 2 StoreFront servers.

Because, you can also check the Source IP of a StoreFront Service Group.

Thanks,

Kyle

[Kyle Woodbury]

The Methods and Persistence tab in the LB VIP must use SOURCEIP persistence in order to work correctly. We have seen a lot of issues when trying to use other methods such as Cookie insert.

Another thing that is recommended is to host file each SF server to have the server group fqdn point to its own local ip address to make sure that the auth callback gets back to its auth service correctly.

[William Fulmer]

This thread contradicts another thread - http://forums.citrix.com/thread.jspa?threadID=332471
as well as the Citrix Storefront 2.0 Guide - http://support.citrix.com/article/CTX133185

Page 43, Item 14 - Use Cookieinsert

[Juan Zevallos]

William

SOURCEIP persistence will work. There is a bug on Android with the COOKIEINSERT persistence. Once this bug is fixed, then COOKIEINSERT will be the preferred method.

Hope that clears things up.

J

[Hilary Clegg]

So if you don't use android, then COOKIEINSERT IS the preferred method, right? Good to know. I wish this was spelled out more clearly in CTX133904. Can you please provide details as to exactly how to employ COOKIEINSERT with storefront for those of us who don't care about Android support?

[Kyle Woodbury]

No, Source IP is still the recommended persistence method for the SF LB VIP. I just discovered last week that Cookie Insert breaks Domain pass through authentication also. We have found several things that do not work with Cookie Insert and Source IP works in every scenario so I would suggest to stick with Source IP persistence for the Storefront LB VIP.

[Hilary Clegg]

I don't know about your statement "Source IP works in every scenario" since I'm typing this response from a farm behind netscaler 10.0.76.7 with a pair of load balanced storefront 2.0 servers using Source IP persistence where I just had to re-authenticate to respond.

I guess I'm not the only one confused by all the conflicting information out there: http://forums.citrix.com/thread.jspa?threadID=332471&start=15&tstart=0

Is there any truth to this comment from Paul Blitz from the thread I referenced above? "you MUST use cookie-insert persistence with storefront, for the simple reason that the source ip seen by the LBVS is.... the netscaler itself!"

[Juan Zevallos]

COOKIEINSERT would eventually be the ideal method. But for now, until the bugs are worked out, SOURCEIP is the recommended persistence method.

[Hilary Clegg]

I finally figured out why my storefront timeout was not being honored with sourceip persistence. The timeout associated with the sourceip persistence method itself was overlooked (see the attachment for a screenshot of what I’m referring to). This was not just overlooked by me, but also by Citrix support and every storefront installation paper I can find on the Citrix website. Citrix – Please do a better job on documentation! Here’s a list of the bad documentation I've identified so far (and believe me, there is more):

http://support.citrix.com/article/CTX133904 - persistence timeout completely ignored and cutoff from the picture under resolution 5

http://support.citrix.com/servlet/KbServlet/download/30717-102-705735/StoreFront2_POC_Guide_updated.pdf - page 44 - persistence timeout left blank

http://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/citrix-storefront-2.0.pdf - page 44 timeout left at the default of 2 minutes

storefronttimeout.gif

[Juan Zevallos]

But you changed the session timeout on the Gateway, if it was set to the default value, then it would have worked as expected. I understand there may be frustration with some of the documentation, but in this case, a default parameter was changed, and in the IT world, changing default values can cause other 'unexpected' issues.

[Hilary Clegg]

I can see your point and I'm not saying its always appropriate to change the value. I'm saying there should be accurate documentation around changing storefront timeouts and the various places that you need to make changes depending on the architecture of the environment in question. So in the case of netscaler access gateway two or more storefront servers that are being load balanced by netscaler, you must touch the app config files on storefront (and propagate the change to all the other servers) the session profile timeout on the access gateway and finally the sourceip persistence timeout on the storefront vip.

Reading http://support.citrix.com/article/CTX133904 in hindsight, its clear to me that another cause which should be addressed is mismatched timeout values. But its your call, you could always keep doing what your doing. It's not like I constantly see complaints about lackluster documentation in Citrix forums all the time or anything. Oh wait, it's exactly like that.

[Hiep Nguyen1709155233]

To Kyle Woodbury.  This happens to just a couple of our users, the rest are OK.  Would the Cookie Insert methed affect 2-3 users instead of the whole VServer ?

 

Thanks.