Please look at the Blast-Worker-SessionIDx log on the agent machine. You we see similar kind of events.
DestroyStoppedSession: cnx:1 closeReason:VDPCONNECT_GENERIC_LOGOUT (27) flags:0x1
Can you check your log and let us know the CloseReason
I guess I could do that but that kinda defeats what I am after...I don't want someone doing my log searches. I want the reference material so I can do it myself and really understand what is going when and where I need it.
But you asked so.....
robsisk1972 Close Reason code 4 is related to Network Failure. The message is clearly tells that Blast session failed due to Network reason, which can be due to several reason. Few of them are Firewall, session persistence, misconfiguration, etc.
Thanks surajr04 but I kinda knew that. What I am more interested in is on which side the network issue resides. Is the network issue on the user side (home network) or our network? Also...Where are you getting your information from? Do you work for Vmware?
Which side of the network is causing the issue ?
It depends and there is no straight forward answer to it. We need to troubleshoot the issue.
UAG ( if any)
Layer 2 switches, Routers, Firewall, Client device and their ISP and network strength.
When the disconnect happen, does it happen for all the end users connected to the VDI agent at that point of time? or one or 2 users ?
If on Connection server Blast Tunnel is disabled, then Connection server is not coming into picture at the time of disconnect.
If there is UAG and user who got disconnected is coming for external network and if there is only 1 or 2 User again, it may not be UAG issue. As UAG is working as Proxy for all external connection. If there is any issue with UAG, all users connected from external network would have been impacted.
You may need to look at the client logs as well.
Thanks for elaborating surajr04 So you're basically saying there is no smoking gun as far a just investigating Blast logs with or without an explanation of the codes used in those Blast Logs? Sure seems there should be to cut the troubleshooting in half by knowing to look on either the client side or horizon stack.
As far as my use case, it's just one user right now so it certainly points to an issue on the user's side (home network, DNS, Device settings, old horizon client etc). Just wishing I could prove it with data from logs. Any specific client logs you would recommend, and possibly key words to look for?
Client Debug log will tell the disconnect reason as well. Match the timeStamp with Agent and Client.
Also Blast use TCP port or UDP ( depending on the configuration). If you trace a wireshark on the client machine, you will see RST on TCP or UDP.
Again both these protocol TCP/UDP are running on the Transport layer and hence not application layer issue.
If the issue is with one user, then it is client specific issue.
Please mark helpful or correct if my answer resolved your issue.
In the Horizon Client window, from the Options menu, select Support Information, and in the dialog box that appears, click Collect Support Data.
From the command line, navigate to the C:\Program Files (x86)\VMware\VMware Horizon View Client\DCT directory and enter the following command: support.bat. On the Client desktop, the folder vdm-sdct contains zipped log files with the date of generation in the filename.
To enable advanced debug logging:
- Open a command prompt to the same location above and run:
Refer to VMware Knowledge Base
OR go to location C:\ProgramData\VMware\VDM\logs check the Debug logs