Unable to connect to the server. Contact your system administrator with the following error: There is no Citrix XenApp server configured on the specified address. (Socket Error 10060) (Only with CWA App)

[Marcelo Flores]

Kind regards,

 

I have a CVA 7 1912 CU 2 site with a Citrix ADC gateway 13.0.88.16. The access to the applications works well when I connect through the web page. But with CWA (latest version) on Windows, I get the following error:

 

Unable to connect to the server. Contact your system administrator with the following error: There is no Citrix XenApp server configured on the specified address. (Socket Error 10060)

 

We applied the CTX236975 with no results. We opened all required TCP/UDP ports in the firewall but no results.

 

Connecting directly to StoreFront works well.

 

Could you help us with this case? 

Edited February 22, 2023 by Marcelo Flores Paz
mistyped

[Rhonda Rowland1709152125]

For clarity, I'm using the phrase "StoreFront Web" to refer to the StoreFront "Receiver for Web" web page for a given store. And "StoreFront Services" to refer to the StoreFront Store page that the Workspace App client usually uses.

 

I can't find the KB article with that number for reference.  So, I just broke down normal troubleshooting below. At bottom, I searched on the error message and made some notes about possible errors related to that message. See if those are more specific first.

 

So to confirm, for your external users (connecting with a  Gateway):  

- Users with a web browser CAN connect to Gateway and the StoreFront "Web" page.

- Users using Workspace App only CANNOT connect to Gateway/StoreFront "Services" page.

 

Can you confirm that internal users WEB and Workspace App can connect to StoreFront WEB and the SERVICES page successfully internally, so only one scenario is failing workspace app with gateway to Storefront "services" page?

 

There's not enough information to fully identify the problem for you but confirm which scenarios work and don't, and what you need to confirm next.

This may help with your troubleshooting.

 

1)General Information

- Are you using separate names for the Gateway FQDN and the StoreFront FQDN for external and internal access?

- Do you have a single Store with both a /Citrix/StoreNameWeb page for web access and the default /Citrix/StoreName for "services"/Workspace app access?

 

2) On the StoreFront:

- Is the Correct storefront "base url" set which matches the LB FQDN used for StoreFront or the name users/gateway use to get to the StoreFront address.

- Is the beacon information set properly.  The "Internal beacon" is usually the StoreFront FQDN and should be a name only resolvable internally.  The "external beacon" is usually the gateway fqdn, and the ping.citrix.com address. Usually these don't need to be adjusted unless you are using one fqdn for both gateway/storefront (under item 1). In which case, changes may need to be made.

- Check your gateway integration settings on the StoreFront and confirm authentication type on both store and "receiver for web", the gateway settings, the sta information, AND if you do or do not have a callback address set. (May not needed it.)

 

3) on the Gateway:

- What authentication method are you using and are you using "classic" or "advanced" expressions. There may be some additional things that have to be tried.

 - What session policies and expressions do you have for the "Web" vs. "Services" users and confirm the store paths and/or account services settings on both.  Either the expression or the profile for the non-web content may be wrong.

- This also might be an authentication pass through issue affecting the workspace app method and not the web method.

 

4) on the client, you can try to distribute a manual provisioning file. Which should include the "internal" address and the "external" gateway address.

If you right-click on the Workspace App, can you manually connect to the gateway. If the beacon information is wrong OR the provisioning file is wrong, it might result in the client not attempting a gateway connection when needed. Or this might be related to something else.

 

Start with the session policies and make sure they will get the right client type connected to the correct store information. (Exact format has varied over the years.)

 

Finally,

When you "test" your connection, on the Gateway appliance you can check logs for the following information:

Check syslog for any reported errors getting to "StoreFront"

shell

cd /var/log

tail -f /var/log/ns.log | grep -v CMD_EXEC

 

Your looking for events with SSLVPN, AAA modules, or messages indicating a storefront, xml, sta, or deny message of some sort.

 

If the transaction is getting to the StoreFront, you can check the EventViewer on the StoreFront server(s) for transactions related to gateway to see if there is a different error reported.

Expand the Applications node and look at events in the "Citrix Delivery Service" node.

If load balanced, you may need to check multiple storefront servers.

 

 

Regarding the error message you posted, I couldn't find article: ctx237965 (but you might have just flipped too numbers).  So I searched on error instead:

"no citrix xenapp server on specified address error 10060

 

You may have meant CTX236975:  https://support.citrix.com/article/CTX236975/unable-to-connect-to-the-server-contact-your-system-administrator-with-the-following-error-when-launching-desktop

This one is specific to TCP/EDT. If your issue isn't based on web vs. services, but TCP vs. EDT, then there are different things I would recommend you troubleshoot. One thing is that when enabling DTLS on the existing VPN vserver, you must unbind and rebind the cert so it attaches to both SSL (TCP) and DTLS (UDP) ssl entities; but this would affect both client types during launch and not just services in most cases.

 

 

IF your message is about the wrong info in the ICA file such as is referenced in either of these:

https://discussions.citrix.com/topic/409007-there-is-no-citrix-xenapp-server-configured-on-the-specified-address-socket-error-10060/

https://support.citrix.com/article/CTX340347/error-there-is-no-citrix-xenapp-server-configured-on-the-specified-address-socket-error-10060

 

Then the first thing to do is check the download folder for the ICA file and open it in a text editor to see if it contains the GATEWAY FQDN and ports OR the direct VDA FQDN/IP and port.

If the latter, then that indicates the client isn't getting the "gateway"-based ICA file and is likely related to some of the information above.

You may also use a trace on the client to see where it is trying to go if you can't get the ICA file.

 

 

Try providing more information and someone may be able to help narrow it down.

 

 

 

 

[Marcelo Flores]

Hi Rhonda, thanks for your answer. Let me check it, but for your information the articles that I reviewed are: CTX340347 and CTX236975.

 

About your questions:

- Users with a web browser CAN connect to Gateway and the StoreFront "Web" page. (YES)
- Users using Workspace App only CANNOT connect to Gateway/StoreFront "Services" page. (YES)

Can you confirm that internal users WEB and Workspace App can connect to StoreFront WEB and the SERVICES page successfully internally, so only one scenario is failing workspace app with gateway to Storefront "services" page? (YES. Confirmed. Note: ADC VPX is in a DMZ Zone).

- Are you using separate names for the Gateway FQDN and the StoreFront FQDN for external and internal access? (YES) 
- Do you have a single Store with both a /Citrix/StoreNameWeb page for web access and the default /Citrix/StoreName for "services"/Workspace app access? (YES)

    

                          Here I have to tell you the following:

                          We have the CVA Site in production before the ADC VPX was implemented. So we have a internet site, remote.abc.com, connected to                                   DeliveryController/StoreFront server directly with NAT.
                         We implemented ADC VPX with a new internet site, sremote.abc.com, but remote.abc.com is still working. Each site use a different Store.
                         And abc.com is the same for internet access and Active Directory internal use.
                         (I will try to delete another store and path, and try again)

- Is the Correct storefront "base url" set which matches the LB FQDN used for StoreFront (YES) 

- Is the beacon information set properly. (YES. I think it is, otherwise no Web access) 

- Check your gateway integration settings on the StoreFront and confirm authentication type on both store and "receiver for web", the gateway settings, the sta information, AND if you do or do not have a callback address set. (May not needed it.) (YES, Double checked)

- What authentication method are you using and are you using "classic" or "advanced" expressions. (CLASSIC)

 - What session policies and expressions do you have for the "Web" vs. "Services" users and confirm the store paths and/or account services settings on both. (CONFIRMED)

- This also might be an authentication pass through issue affecting the workspace app method and not the web method. (I will check this)

 

When you "test" your connection, on the Gateway appliance you can check logs for the following information:

Check syslog for any reported errors getting to "StoreFront"

shell

cd /var/log

tail -f /var/log/ns.log | grep -v CMD_EXEC

Your looking for events with SSLVPN, AAA modules, or messages indicating a storefront, xml, sta, or deny message of some sort. (I will try this)

 

If the transaction is getting to the StoreFront, you can check the EventViewer on the StoreFront server(s) for transactions related to gateway to see if there is a different error reported. (NO Events in SF Server)

This one is specific to TCP/EDT. If your issue isn't based on web vs. services, but TCP vs. EDT, then there are different things I would recommend you troubleshoot. One thing is that when enabling DTLS on the existing VPN vserver, you must unbind and rebind the cert so it attaches to both SSL (TCP) and DTLS (UDP) ssl entities; but this would affect both client types during launch and not just services in most cases. (I will try this)

Then the first thing to do is check the download folder for the ICA file and open it in a text editor to see if it contains the GATEWAY FQDN and ports OR the direct VDA FQDN/IP and port. (It is the Gateway FQDN with sta information)
 

As I said I will try some of your recommendations and tell you about it later.

 

Edited February 22, 2023 by Marcelo Flores Paz
adding info

[Rhonda Rowland1709152125]

On 2/22/2023 at 10:10 AM, Marcelo Flores said:

- Do you have a single Store with both a /Citrix/StoreNameWeb page for web access and the default /Citrix/StoreName for "services"/Workspace app access? (YES)

    

                          Here I have to tell you the following:

                          We have the CVA Site in production before the ADC VPX was implemented. So we have a internet site, remote.abc.com, connected to                                   DeliveryController/StoreFront server directly with NAT.
                         We implemented ADC VPX with a new internet site, sremote.abc.com, but remote.abc.com is still working. Each site use a different Store.
                         And abc.com is the same for internet access and Active Directory internal use.
                         (I will try to delete another store and path, and try again)

 

I'm not sure if this is a problem, but is sremote.abc.com the new name of the new gateway vpn and not associated with a NAT to the storefront. We'll keep an eye on if this is related to anything; because your beacons or base url, may have been configured based on the original NAT address. (But I would check other things first.)

 

 

My guess is double check your session policy for the services URL:

1) Start with the policy expression

2)  Then in the session profile, confirm the StoreFront Address URL, Account Services setting, sson domain, and the HOME address.

As these settings changed depending on version of Workspace App Gateway in use. Did you configure this manually or let the wizard do it.

And then confirm version of ADC VPX, CVAD, and Workspace app.

Since only the services clients are failing, this profile may have a setting that is wrong that is in fact working fine for the web clients in the other profile.

 

Both gateway logs, client logs, may help on this.  Good luck though.