Setting up fresh test environment - unable to launch apps

[Kenneth Schall]

I'm setting up a brand-new test environment for XenApp using 7_2305.  I also have Netscaler as the gateway.  I've set up the Delivery Controller, StoreFront, and an app server with the VDA.  Set up the Netscaler to mimic our production environment with also uses Netscaler (other than different STA targets, URL, etc.).

 

I can authenticate into the test Web interface (and through the Workspace app) with no problems, I can see the test apps that are published, but when I try and launch them, it basically says 'Nope' ?.  When I disable an app, it disappears from the available apps, and re-appears after it's enabled - so I can talk to the StoreFront and it updates properly.  The StoreFront server is added to Studio, licenses are good and valid.  I've seen similar if the app server needed to be rebooted or something, but that hasn't helped in this case.  STA showing UP in the Netscaler.

 

    

 

I'm not sure what I'm missing or what else I can check.  Log files have not been fruitful.  Adding some screen caps for context and clarification.

[Vijaykumar P]

Does it work if you byspass the gateway using storefront hostname in the url.

This error is for unavailable vdas

By any chance do you have FAS configured for your store?

 

Storefront event logs(delivery services log) and ddc application event logs will help here 

[Robert Peck]

Vijay is right.  This error points to the VDA, and bypassing the gateway for now will isolate where the issue is.  First thing to do is check to make sure the VDA is powered on, registered, and not in maintenance mode.

[Jeff Riechers]

Download the ICA file and see if everything is correct in the server address.

 

Also bypass the gateway like the others said and see if you can launch without the Gateway.

[Kenneth Schall]

Thanks for feedback - I'll check on these resources and see what I can figure out.  I'll post back what I find.

[Kenneth Schall]

Launched directly from StoreFront and got the following

 

Followed the CTX article at https://support.citrix.com/article/CTX134123/unable-to-launch-applications-or-desktops-using-https-url-via-workspace-app-for-html5

 

Reading the article, lead me to https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/secure/tls.html.  This describes enabling TLS on the VDA - OK that's new for deployments.  This hasn't been a problem in previous versions that we have deployed.  It also notes that "Solution 2 is to have your connections from the clients first go through a Citrix Gateway. Citrix Gateway will proxy the connections and perform a SSL handshake between the client and the Citrix Gateway.  In this scenario there is no inconsistency and connections via HTML5 Receiver will succeed."  Well, if that's the case, then the apps should launch, but that's not the experience.

 

Solution 1 of that article brought me to https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/secure/tls#configure-tls-on-a-vda-using-the-powershell-script.  Following the instructions on here to Enable-VDASSL.  When trying to apply our internally issued cert (internal CA, so all internal certs issued are trusted across the domain), and the command returns "Verification of the certificate failed.  Please install a valid certificate and try again."  Do the certs need to be publicly valid (issued by a public CA like GoDaddy)?  Or will internal CA issued certs be OK as long as they are trusted (The internal Root CA certificate and the intermediate CA certificate are both installed in the "Trusted Root Certification Authorities" folder)?  I tried the cert that the VDA installed on the application server and it produced the same error.

 

Trying the manual way to do the update via RegEdit (not my favorite way). 

 

For those interested, more to come, but this is looking to be an SSL issue along the lines of the VDA and its communications with the rest of the Citrix XenApp infrastructure.

[Kenneth Schall]

I decided to test the theory and installed our public issued cert (via GoDaddy) on the server and attempted the same PowerShell commands to use it.  The command was successful - meaning that the certs used for this probably need to be publicly issues certs from an authorized CA.  SSL to VDA was successfully enabled.  Rebooted server.

 

But I still get the same error as before (referencing the CTX134123 article.

 

This section is probably the most relevant part of the logs that I downloaded via the prompt in the error message (scrubbed), and was found at the end of the log file.

 

[Wed, 09 Aug 2023 20:20:14 GMT] INIT :|: CONNECTION :|: TRANSPORT DRIVER :|: TRYING FOR SOCKET CONNECTION ON {appserver} : 8008
[Wed, 09 Aug 2023 20:20:14 GMT] INIT :|: CONNECTION :|: WEB SOCKET :|: INFO :|: websocket-url=ws://{appserver}:8008
[Wed, 09 Aug 2023 20:20:14 GMT] INIT :|: CONNECTION :|: WEB SOCKET :|: INFO :|: Current Protocol Index is : 0
[Wed, 09 Aug 2023 20:20:14 GMT] CONSOLE:|:log:|:enter OnErrorCallback
[Wed, 09 Aug 2023 20:20:14 GMT] SESSION:|:ICA:|:TRANSPORT:|:DRIVER:|:error with code=18 , name=SecurityError , message=Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS. ,call stack=Error: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.
    at U_q.connect [as b_zb] (https://{storefrontserver}/Citrix/XA75TestWeb/clients/HTML5Client/src/Business/TransportDriverCommon_23.4.0.12.js:20:2876)
    at y_rd (https://{storefrontserver}/Citrix/XA75TestWeb/clients/HTML5Client/src/Business/TransportDriverCommon_23.4.0.12.js:14:10937)
    at Z_G (https://{storefrontserver}/Citrix/XA75TestWeb/clients/HTML5Client/src/Business/TransportDriverCommon_23.4.0.12.js:14:11087)
    at globalThis.A_Ld.b_zb (https://{storefrontserver}/Citrix/XA75TestWeb/clients/HTML5Client/src/Business/TransportDriverCommon_23.4.0.12.js:14:13091)
    at b_ub.connect [as b_zb] (https://{storefrontserver}/Citrix/XA75TestWeb/clients/HTML5Client/src/Business/TransportDriverCommon_23.4.0.12.js:24:25223)
    at V_kd.start (https://{storefrontserver}/Citrix/XA75TestWeb/clients/HTML5Client/src/Business/WinstationDriver23.4.0.12.js:56:11379)
    at https://{storefrontserver}/Citrix/XA75TestWeb/clients/HTML5Client/src/Business/ModuleWrapper23.4.0.12.js:24:2949
    at Object.get (https://{storefrontserver}/Citrix/XA75TestWeb/clients/HTML5Client/src/Business/UiDialogFiles23.4.0.12.js:42:27525)
    at I_ab (https://{storefrontserver}/Citrix/XA75TestWeb/clients/HTML5Client/src/Business/ModuleWrapper23.4.0.12.js:24:2609)
    at c_Qe.W_Ic (https://{storefrontserver}/Citrix/XA75TestWeb/clients/HTML5Client/src/Business/ModuleWrapper23.4.0.12.js:24:1214)
[Wed, 09 Aug 2023 20:20:14 GMT] SESSION :|: ERROR :|: error-secure
[Wed, 09 Aug 2023 20:20:14 GMT] SESSION :|: ERROR :|: Citrix Workspace app cannot create a secure connection in this browser. Please refer to Citrix Knowledge Center article CTX134123., undefined)
[Wed, 09 Aug 2023 20:20:14 GMT] INIT :|: CONNECTION :|: TRANSPORT DRIVER :|: CHANNEL CGP
[Wed, 09 Aug 2023 20:20:14 GMT] INIT :|: CONNECTION :|: CGP SOCKET :|: INFO :|: Start Initializing CGP Socket
[Wed, 09 Aug 2023 20:20:16 GMT] SESSION:|:CTXAUDIO:|:AudioDevicesInterface:|:requestAudioDevicePermission:getUsermedia: [object Object]

[Jeff Riechers]

Ok, that is trying to connect with the HTML 5 client.  Try using the full client instead.  That will pull down an ICA file with more detail.

[Vijaykumar P]

WebSocket connections are no longer allowed for internal launch( Browsers like edge and chrome no longer supports it), you may neeFirefoxe gateway url.
Or you can try modifying firefox browser security 
https://support.citrix.com/article/CTX134123/unable-to-launch-applications-or-desktops-using-https-url-via-workspace-app-for-html5

[Kenneth Schall]

The test applications DID launch successfully INTERNALLY through the Workspace client, connected directly to StoreFront URL (not via the gateway URL).  The experience was very similar as to that with the Netscaler Gateway in front of our production environment.  Per recent comments, internal users will HAVE to use the Workspace app to launch applications in the new environment(s).  So, this success confirms that there doesn't appear to be anything wrong (that I can tell) with the test environment as far as the StoreFront and the App server go.  That leaves the Delivery Controller and/or the gateway/Netscaler.

 

Questions:

1. Do I still need to do this certificate process on my app servers?  (If unsure, I can spin up another app server without it and see what happens.)

2. For external users coming through our Gateway, what else should I be looking for - these still don't launch via Web or Workspace app.  Same problem occurs.  I don't get the offer to download logs in this case.  I know there are logs that can be collected through the Workspace app, just not sure what log file I should be checking in the ZIP file.

[Vijaykumar P]

you, do not need ssl cert on VDA to access via gateway.

for html5 launch you can collect logs like this 
open a tab in browser and enter your url appended with /Clients/HTML5Client/src/SessionWindow.html#engineType=log
example if your url after logon shows, https://domain.com/citrix/storeweb, then the logging url would be https://domain.com/citrix/storeweb//Clients/HTML5Client/src/SessionWindow.html#engineType=log, select start logging 
Now open another tab and start reproducing the issue, 
You will see logs in the logging tab.

the issue is mostly the communication between the snip and the VDA
a simple external access is like this
Client >(port 443) gateway >(this is gateway internal communication) snip >(port 1494,2598) VDA

also make sure VDA is allowed for incoming port 1494 and 2598 from any machine (at least for now, you can restrict it later)

 

[Kenneth Schall]

@Vijaykumar PI tried the HTML5 logging you noted, but there are no logs generated, as there is no session initated.  It never gets that far.  Presently, the firewall is not active on the test app server, so the issue with ports should be mitigated at this point.  I've also verified that RDS licensing (just in case), and there are no issues there (I know that kill it right away, too).  Starting to run Wireshark on the environment to see what I see.  Initial findings are not seeing any traffic to either the DC or app server from the Netscaler SNIP on any ports.  So my guess is that the problem is with the Gateway somewhere.

[Vijaykumar P]

Please try this once
Set 'useThinwireV2' to false in configuration.js file
Path: C:\Program Files\Citrix\Receiver StoreFront\HTML5Client\configuration.js

[Kenneth Schall]

Not knowing what that setting was, I looked it up and found this... https://support.citrix.com/article/CTX324216/disabling-enhanced-graphics-for-sessions-launched-with-citrix-workspace-app-for-chrome-os-21082.  I'm not sure I understand why this setting would make a difference.  I'm using the Workspace app on a Windows Laptop, and the app server is Windows Server 2016 (I know it's a little old, but that's due to our RDS licenses right now).

 

I did get a trace from the ADC while reproducing the problem and was reviewing it with one of our network engineers.  The communications between the ADC SNIP and the StoreFront server are pretty clean.  But there are a lot of comms to the NSIP from StoreFront as well, which doesn't make a lot of sense in this case - why would it use the NSIP?  Going to get a trace from production and see if I can make some parallel comparisons between them.

 

(just FYI - I am set to follow this thread, but I'm not getting the notifications, so I do apologize for any delayed responses.)

Edited August 16, 2023 by Kenneth Schall

[Vijaykumar P]

Hi Kenneth, 

 

Communication between SNIP and Storefront is expected when we do HTML5 lauch, 

But communication to NS IP could be due to incorrect callback config

During launch gateway contacts SF via SNIP to load the necessary components to the user's connection.

You may see some of the files in HTML5 folder for the user connection in the gateway network logs (if decrypted).

Only after the graphix is initialized for user's html5 connection, the connections are made to VDA via SNIP.

[Kenneth Schall]

@Vijaykumar PI did test the change you noted, but there was no positive effect.  Issue persisted.

[Jeff Riechers]

Ignore the whole html5 connection.  Set Storefront back to using the full client.  When you download the ica file from a web browser can you post it in the chat so we can see the connection info when attempting a direct connect?

[Kenneth Schall]

I do apologize up front for any lengthy periods between responses.  Citrix is only one thing that I do among a myriad of other things.  I'm one of those "jack of all trades, master of none" people.

[Kenneth Schall]

So, after fiddling with the environment, I finally found what I was missing.  Apps now work inside and outside of the network.  Internal works only with the Workspace App (which as we've found out is by design), and external works with both the Workspace App and the browser (with apps launching in browser tabs).

 

Solution:  Check StoreFront and the Gateway settings.  Once I set the STAs to use HTTP (rather than HTTPS), everything started working like it was supposed to.  Although it's set to HTTP here, the Netscaler gateway settings use HTTPS for the STAs configured there.

 

Very counterintuitive for those wanting security to be as good as we can get it.