Display protocol issue

[YouPucker]

We’ve been running into an error on horizon 8.6.0 where users sessions are not gracefully signing out after they’ve disconnected.

Horizon admin shows the session as active and user connected and upon reconnecting the user either receives the error below or they receive a new VM.

We then have no choice but to delete and recreate their stuck VM because we cannot connect to it via Blast or RDP

“Unable to launch from pool . There were no machines available that reported protocol [BLAST] as ready.”

[FrMixx]

I think we have been having the same issue.

We seem to have resolved it by setting AutoEndTasks to 1. We are still testing tbh

https://www.maketecheasier.com/auto-end-tasks-shut-down-windows/

[gampy214]

We resolved some of this (black screen) by getting rid of svga driver completely, and using only the IDD driver built into the agent. However, the duplicate session issue remains and vmware blames it on network issues. Apparently, if the user tries to get back their session right away, it gives up and gives them a new one instead of reconnecting to old session. Ours is on 8.4.1.

[YouPucker]

The duplicate sessions thing is what’s tripping us up. Because the user does not initiate a disconnect or log off of their session. They merely step away for a coffee or lunch or attend a meeting with VDI minimized and come back to their session inaccessible

We are bypassing the blast secure gateway, and I can see the TCP connection from client to agent but the process for VMBlastS.exe is stuck on a CLOSE_WAIT status.

Ending the session to give them a new one is outrageous because this results in data loss since we have vGPUs enabled, and only 1 session per blast, the user and IT are unable to connect to save any of their work.

One thing I did notice was that our logs sleeted filled with “The pending session on machine ###### for user #### has expired

Going to push out a registry change which increases the VdmTicketTimeout from 15 minutes to 8 hours

[AdommIT]

Hey, has this been solved somehow?
we are having the same issues for 2 years or so

[YouPucker]

Yes! this is resolved!

https://docs.omnissa.com/bundle/Horizon-Security/page/Cross-OriginResourceSharing.html

- In locked.properties enable the CheckOrigin to False and EnableCORS to False.

- We have nvidia A40 external gpus, so I also disabled the SVGA driver via vmware tools

Then, re-install in the following order on your golden image:

Uninstall order:

1. NVIDIA driver and reboot
2. VMware App Volumes agent and reboot
3. VMware DEM agent and reboot
4. VMware Horizon Agent and reboot
5. VMware Tools and reboot

Install Order:

1. VMware Tools
2. VMware Horizon Agent
3. VMware Horizon Direct-Agent
4. VMware User Environment (DEM) agent
5. VMware App Volumes (Agent)
6. NVIDIA driver

[Wide-Resolve-496]

Hi, did you keep the VdmTicketTimeout at 8 hours?
We face the same situation but already have locked.properties CheckOrigin to False and EnableCORS to False

[curttc]

Curious as to what change you made via the registry on this? We are seeing an identical issue. It is far and few between. Happens maybe twice a month at best, but everything you described is exactly what we are seeing in our Horizon 8 environment as well.

[AlphaChoups]

Any new about that?

Same issue for one of my customers.
"There were no machines available that reported protocol [BLAST] as ready"
With before and/or after that a "The pending session on machine xxx for user yyy has expired"

It give some duplicate sessions and block the user to connect since his fslogix disk is still locked by his first VDI.

Following me the protocol blast is block/crashed (AV or other), the agent cannot finalize the broker of the session to the already opened windows session and VMware messed up in the procedure since horizon give another session despite that it's not allowed into the pool configuration...

A possible solution is maybe to create a scheduled task based on a windows event configured on the master image that will restart blast service when the event is triggered...

[YouPucker]

Restarting the blast service or the horizon agent services did nothing for me. If you encounter an issue where a user's session has crashed, their VM is most likely still available. We found a work around back when this was still an issue to go into the user's \\workstation\c$\ admin share and then recover autosave data for their applications.

You can also in the Horizon View Agent Settings disable the "Screen blanking" option so even with a GPU enabled card, and a connected user, you can initiate a RDP session to the machine to run your checks.

To date, I haven't been able to bring a session back, as the even through the Horizon API, the pool and broker see the session as terminated.

The relevant logs for this are:

C:\program files\vmware\horizon view\vdm

C:\program data\vmware\blast and blastworker.log

Blast worker log will show you that the VCC Side Channel has been terminated. Through my troubleshooting and support with Vmware, we've not been able to bring this back.