Timeout was reached vmware horizon ошибка

Обновлено: 05.07.2024

I opened with notepad and it works, it is compressed to 1 from 5kb

then I just post it here.

"18","0.323939000","192.168.178.29","192.168.0.8","TCP","66","49765 > 443 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1"

"19","0.324010000","192.168.0.8","192.168.178.29","TCP","66","443 > 49765 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=2 SACK_PERM=1"

"20","0.324475000","192.168.178.29","192.168.0.8","TCP","60","49765 > 443 [ACK] Seq=1 Ack=1 Win=131328 Len=0"

"22","0.335299000","192.168.0.8","192.168.178.29","TCP","54","443 > 49765 [ACK] Seq=1 Ack=158 Win=65378 Len=0"

"23","0.360269000","192.168.0.8","192.168.178.29","TLSv1.1","1075","Server Hello, Certificate, Server Key Exchange, Server Hello Done"

"24","0.386587000","192.168.178.29","192.168.0.8","TLSv1.1","284","Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message"

"25","0.397283000","192.168.0.8","192.168.178.29","TCP","54","443 > 49765 [ACK] Seq=1022 Ack=388 Win=65148 Len=0"

"26","0.404559000","192.168.0.8","192.168.178.29","TLSv1.1","60","Change Cipher Spec"

"27","0.404995000","192.168.0.8","192.168.178.29","TLSv1.1","123","Encrypted Handshake Message"

"28","0.405371000","192.168.178.29","192.168.0.8","TCP","60","49765 > 443 [ACK] Seq=388 Ack=1097 Win=130304 Len=0"

"30","0.416349000","192.168.0.8","192.168.178.29","TCP","54","443 > 49765 [ACK] Seq=1097 Ack=697 Win=64840 Len=0"

"34","0.431046000","192.168.178.29","192.168.0.8","TCP","60","49765 > 443 [ACK] Seq=878 Ack=1523 Win=131328 Len=0"

"37","0.436215000","192.168.0.8","192.168.178.29","TCP","54","443 > 49749 [RST] Seq=1 Win=0 Len=0"

"38","0.436354000","192.168.178.29","192.168.0.8","TCP","60","49749 > 443 [RST, ACK] Seq=54 Ack=1 Win=0 Len=0"

"39","0.446324000","192.168.0.8","192.168.178.29","TCP","54","443 > 49765 [ACK] Seq=1523 Ack=1235 Win=64302 Len=0"

"41","0.466337000","192.168.0.8","192.168.178.29","TCP","54","443 > 49765 [ACK] Seq=1523 Ack=1544 Win=65536 Len=0"

"44","0.634692000","192.168.178.29","192.168.0.8","TCP","60","49765 > 443 [ACK] Seq=1544 Ack=2285 Win=130560 Len=0"

"112","4.413532000","192.168.0.8","192.168.178.29","TCP","54","443 > 49765 [ACK] Seq=2285 Ack=1901 Win=65178 Len=0"

"114","4.423536000","192.168.0.8","192.168.178.29","TCP","54","443 > 49765 [ACK] Seq=2285 Ack=2594 Win=64486 Len=0"

"147","4.678458000","192.168.178.29","192.168.0.8","TCP","60","49765 > 443 [ACK] Seq=2594 Ack=3127 Win=131328 Len=0"

"149","4.691548000","192.168.0.8","192.168.178.29","TCP","54","443 > 49765 [ACK] Seq=3127 Ack=2951 Win=64128 Len=0"

"151","4.701584000","192.168.0.8","192.168.178.29","TCP","54","443 > 49765 [ACK] Seq=3127 Ack=3100 Win=65536 Len=0"

"154","4.795270000","192.168.178.29","192.168.0.8","TCP","60","49765 > 443 [ACK] Seq=3100 Ack=3873 Win=130560 Len=0"

"308","1.768750000","192.168.178.29","192.168.0.8","TCP","66","49749 > 443 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1"

"309","1.769172000","192.168.178.1","192.168.178.29","ICMP","94","Redirect (Redirect for host)"

"312","1.770650000","192.168.0.8","192.168.178.29","TCP","66","443 > 49749 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=2 SACK_PERM=1"

"313","1.770720000","192.168.178.29","192.168.0.8","TCP","54","49749 > 443 [ACK] Seq=1 Ack=1 Win=131328 Len=0"

"315","1.780436000","192.168.0.8","192.168.178.29","TCP","60","443 > 49749 [ACK] Seq=1 Ack=158 Win=65378 Len=0"

"318","1.811578000","192.168.0.8","192.168.178.29","TLSv1.1","1075","Server Hello, Certificate, Server Key Exchange, Server Hello Done"

"319","1.859810000","192.168.178.29","192.168.0.8","TCP","54","49749 > 443 [ACK] Seq=158 Ack=1022 Win=130304 Len=0"

"320","1.883643000","192.168.178.29","192.168.0.8","TLSv1.1","284","Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message"

"321","1.905421000","192.168.0.8","192.168.178.29","TCP","60","443 > 49749 [ACK] Seq=1022 Ack=388 Win=65148 Len=0"

"322","1.905493000","192.168.0.8","192.168.178.29","TLSv1.1","60","Change Cipher Spec"

"323","1.905945000","192.168.0.8","192.168.178.29","TLSv1.1","123","Encrypted Handshake Message"

"324","1.905991000","192.168.178.29","192.168.0.8","TCP","54","49749 > 443 [ACK] Seq=388 Ack=1097 Win=130304 Len=0"

"326","1.936678000","192.168.0.8","192.168.178.29","TCP","60","443 > 49749 [ACK] Seq=1097 Ack=697 Win=64840 Len=0"

"330","1.945060000","192.168.178.29","192.168.0.8","TCP","54","49749 > 443 [ACK] Seq=878 Ack=1523 Win=131328 Len=0"

"332","1.957461000","192.168.0.8","192.168.178.29","TCP","60","443 > 49749 [ACK] Seq=1523 Ack=1235 Win=64302 Len=0"

"334","1.967477000","192.168.0.8","192.168.178.29","TCP","60","443 > 49749 [ACK] Seq=1523 Ack=1544 Win=65536 Len=0"

"337","2.003566000","192.168.178.29","192.168.0.8","TCP","54","49749 > 443 [ACK] Seq=1544 Ack=2285 Win=130560 Len=0"

"359","6.903774000","192.168.0.8","192.168.178.29","TCP","60","443 > 49749 [ACK] Seq=2285 Ack=1901 Win=65178 Len=0"

"361","6.914856000","192.168.0.8","192.168.178.29","TCP","60","443 > 49749 [ACK] Seq=2285 Ack=2594 Win=64486 Len=0"

"364","7.030403000","192.168.178.29","192.168.0.8","TCP","54","49749 > 443 [ACK] Seq=2594 Ack=3127 Win=131328 Len=0"

"366","7.044746000","192.168.0.8","192.168.178.29","TCP","60","443 > 49749 [ACK] Seq=3127 Ack=2951 Win=64128 Len=0"

"368","7.055910000","192.168.0.8","192.168.178.29","TCP","60","443 > 49749 [ACK] Seq=3127 Ack=3100 Win=65536 Len=0"

"371","7.144683000","192.168.178.29","192.168.0.8","TCP","54","49749 > 443 [ACK] Seq=3100 Ack=3873 Win=130560 Len=0"

"407","34.169464000","192.168.0.8","192.168.178.29","TCP","60","443 > 49749 [FIN, ACK] Seq=3926 Ack=3100 Win=65536 Len=0"

"408","34.169571000","192.168.178.29","192.168.0.8","TCP","54","49749 > 443 [ACK] Seq=3100 Ack=3927 Win=130560 Len=0"

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

VMware Technology Network
:
Digital Workspace
:
Horizon
:
Horizon Desktops and Apps
:
Horizon client cant connect to connection server ".

simonsimon1129

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Horizon client cant connect to connection server "ERROR:Timeout was reached"

Where should I start troubleshooting I cant connect my Horizon Client my home laptop. "ERROR:Timeout was reached".
How to fix this ?

Locally my set up is working, but using client that's my error. 1st time deploying Horizon.
Here are some info's log file and screenshot

Shreyskar

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

What is the horizon client version you are running?

Did you install it from windows store?

Are you connecting internally or from external network? Does the connection goes through a security server/UAG/load balancer?

simonsimon1129

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

What is the horizon client version you are running?

Did you install it from windows store?
No, from VMware website sir.

Are you connecting internally or from external network? Does the connection goes through a security server/UAG/load balancer?

Client = External network.
Connection server goes through Security server. no Load balancer

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

VMware Technology Network
:
Digital Workspace
:
Horizon
:
Horizon Desktops and Apps
:
Vmware Horizon 7.11 with Horizon Client 5.4.2 runn.

Peakay

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Vmware Horizon 7.11 with Horizon Client 5.4.2 running windows 10 - Error: Timeout was reached

I have noticed a pattern with our environment that doesn't appear to happen always, but probably about 40% of the time.

this for me is occurring while running the client from home, connected via ethernet to my home router, then connecting to work VDI.

Vmware Tools in Guest OS 11.0.5 build 15389592

After 4 hours and while actively using my Horizon session, I am kicked from my Horizon session with the message "Error:Timeout was reached".

I am unable to reconnect for approximately 10 minutes

pool settings are set to 480 mins (8 hrs ) after disconnect, but I haven't disconnected.

global settings are set to never forcibly disconnect users

Is there a "forcibly logoff users" timeout setting somewhere?

this issue occurs about 4 hours after logging in at the beginning of the day (around 11:30am) and although I am normally logged in for about 9 hours, I have not seen this behavior in the afternoons.

Shreyskar

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Do you have any GPO in your AD for View agent or client which forces session timeout value?

Peakay

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

we do have view Policy in place, but nothing about log off or disconnect - is there one normally, do you know what it would be called?

this is all we have enabled

Shreyskar

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Hi Peakay , What protocol are you using? Does it happen with both pcoip/blast?

Peakay

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

we only use PCOIP

Shreyskar

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Thanks for the update. Are these RDS session Or normal desktop session. The reason I ask this because for RDS,we do have below GPO which controls session timeout for an active session:

Set time limit for active Remote Desktop Services sessions
Terminate session when time limits are reached

1.If you are not connecting to RDS based session, by default, a user's View session (PCoIP )will automatically be disconnected after 600min (10hrs). Not after the session has been 'idle' for ten hours.Event setting it to 'Never' makes it 1200min.

2. To effectively disable the session time out, enter 9999999 under 'Forcibly disconnect users', which equates to 19 years.

3. In this case you only few of your users might be getting logged off after 10hrs since not all of your users would be working a ten hour day on any regular basis, hence disconnect would be random in this case. Connection timeout time in the View admin page isn't an idle or inactivity timer, but rather it is an automatic session timeout.Set

4. If issue still persist, please follow VMware Knowledge Base and set cs-disconnectlegacyclientsessionsontimeout=0.

We are running VMware Horizon View VDIs for our users when they are remote, want to work from home, etc. We are on version 6.0.1 build-208845. We have this one user that always seems to have connectivity issues. The only way that he can get back into his VDI is if an administrator goes into the VMware Horizon View Administrator console and performs a 'Reset' on his session. This fixes him for the session, however when he goes to use it again the next weekend, or evening, its the same story. The logs on the console aren't very revealing, they show him attempt to sign-in, then attempt to access the VDI session, connect in successfully, then approximately 5-10 minutes later get dropped. The message in the Event log says "The pending session on machine VDI_MACHINE_NAME for user MY_DOMAIN\VDI_USER has expired."

Has anyone experienced this or possibly have a suggestion as to what could be causing this issue?

just another thought, looks like you are using persistent disks. have you detached the disk and rebuilt a new desktop? this should alleviate any possible machine issues

14 Replies

Is this user in the same pool as the rest? Does the same issue occur with the both PCoIP and RDP protocols? How about the client version, I'm assuming its updated?

Kind of a specific situation, but we had one user who would have this issue because they kept redirecting their USB monitor to the virtual desktop forcing an install of display link drivers which would kill the VDI session. Most likely not your issue but maybe its something the user is doing to cause it?

Summing the Horizon Guru.

just another thought, looks like you are using persistent disks. have you detached the disk and rebuilt a new desktop? this should alleviate any possible machine issues

JPo1215 wrote:

Is this user in the same pool as the rest? Does the same issue occur with the both PCoIP and RDP protocols? How about the client version, I'm assuming its updated?

Kind of a specific situation, but we had one user who would have this issue because they kept redirecting their USB monitor to the virtual desktop forcing an install of display link drivers which would kill the VDI session. Most likely not your issue but maybe its something the user is doing to cause it?

Sorry for the delay. Yes, same pool as the rest, kind of. We have several pools and there are 12 users in that pool. None of the other 11 users has complained about any VDI problems. All of the clients are on the same version.

JPo1215 wrote:

just another thought, looks like you are using persistent disks. have you detached the disk and rebuilt a new desktop? this should alleviate any possible machine issues

No, not yet, but rebuilding a new VDI sounds like a great idea. I'll try that! Thanks.

Check your Global Settings Session timeout.

Have you solved this issue. I also have the same issue with hundreds of users in different pools randomly disconnecting from their VM. Global settings session timeout are set to never.

I too have the same issue and our Global settings are set to NEVER as well. Have an open ticket with VMWare and nothing they have had me try has resolved the issue. We were running Horizon 5 for 3 years with no issues. This all started after the upgrade to Horizon 7.

Any luck? We are seeing this after updating to 7.0.3 from 7.0.0. VMware just keeps sending me KB articles to look at.

We are also seeing this after a 7.0.0 to 7.0.3 upgrade. Did you get any updates from VMware?

Nothing from VMware yet. They wanted us to send them a suspended VMs file that had the issue. I ended up monitoring the warnings and seeing one in that state. I had to put it in Maintenance Mode before it refreshed on me. Once that was done, i suspended it so I can grab the .vmss file. I sent that to them on Wednesday and as of yesterday (Friday), they were still reviewing them. Luckily, this doesnt apprear to be causing issues with any of our 1600 end users. Its more of an annoyance than anything. My guess is that there is a bug on the connection server side or on the agent. I will share what VM found when I hear back.

I think I might have found a workaround on the random disconnections.

I am almost certain that the disconnections has to do with something related to the network and not a bad configuration from the Horizon side.

I went through my pool settings again under Desktop Pool Settings under Remote Settings there is an option to "Automatically logoff after disconnect"; I had mine set to Immediately. I changed this setting to "After.. and put in 120 Minutes". My thought behind this was if a disconnection is occurring to the user's Vm even if this would be a second the Composer has a clear instruction to logout the user, therefore changing this setting would mean that if there will be a disconnection the Composer would wait 2 hours to logout the user and since the user comes back online right after it won't.

I know this does not give the answer to the disconnection issues, however at least it's not impacting the users.

Try it out and Let me know if it worked for you or not.

We had a similar issue where everyone would get disconnected around a certain time nearly every day in 3 different companies.

The times were different among the 3, but consistent within.

A VERY long story short: I was able to track down the cause, but never able to fully get to the why. And I could duplicate the issue.

We were using Samsung NC241 Zero Clients connecting to View 6 via PCoIP. It's could have started with View 5 and continued to View 6.

Certain users were pressing the soft off power button on the front of the device instead of logging off or pressing ctrl-alt-F12 to disconnect first. When this happened the "turned off" client would lock up the ports on the connection broker causing all other desktops to freeze and disconnect. After about 15 minutes (long enough for us to get in and see there was nothing wrong :P ), users could reconnect to their sessions and keep working.

Once we figured out that, just as a specific user left for the day, the problem occurred. We were able to isolate the source of the problem and replicate it.

If action was taken fast enough, other users didn't drop their connection: Press the soft off button. a few seconds later everyone's session locks up. disconnect the NIC or hard power off the unit and everyone's session sprang back to life.

When the issue happened the connection broker just stopped responding to any client traffic until the client timed out, was cut from the network or the broker service was restarted.

VMware, Samsung and Teradici were engaged and strangely we ended up in a Mexican stand off where no one would pull the trigger as they didn't want to be responsible for the blood bath :P

1st solution: We tracked down users leaving around the disconnect times and trained them to DISCONNECT (ctrl-alt-F12) and then turn the screen(unit) off. or just leave it and let it go to low power mode.

2nd solution: We were running the connection brokers in tunnel mode for both internal and external access. We added additional connection brokers and configured the "internal" brokers to not use tunneling, while tunneling the "external" brokers. I believe this was the final "solution" as misbehaving client connections could no longer lock up the connection broker's services. Though the problem probably still exists, I think it's isolated to the individual desktops and is recorded in the logs as a PCoIP session timeout warning or some such.

Note: This happened with certain users on certain client units on certain desktops/pools. UserA could cause the problem on unit1 in pool-a, while shifting a seat and connecting UserA on unit2 in pool-a would not be a problem when pressing the soft off button. Likewise, UserB sitting in the problem seat of unit1 in pool-a could not generate the issue. AND to make you even crazier UserA on unit1 in pool-b (roaming profiles and folders redirections, et al.) would have not issues when pressing the soft off button.

Читайте также: