Urgent Help!!! one of my client meets - "the view agent reports that this desktop source is unable to accept connections"

[johnhu866]

Dear all,

one of my staff said she could not connect her desktop vm22 and the view client said "the view agent reports that this desktop source is unable to accept connections". my view administrator displays that “the pending session on machine xx for user xxx has been expired ” . but i then assigned another user to the same desktop, everything looks fine.

background:

1. I am using view 6.0.   

2. This user used to assigned another desktop vm06. it took a long long time (more than 30 minutes) to login (agent set not delete local persona) , This Morning when she tried to connect(already logged in before, here just reconnect),  she got "there is no available gateway for this display protocol". So i assigned her to another desktop vm22

Is there something wrong with this user account or something else. Need your help!!! Thanks in advance!

[BenoitCote]

Any news from anyone concerning this?

I also have an SR open with VMware, trying to escalate as high as we can, but as of yet, all the logs I sent them, they coudln't find anything in particular that was wrong.. even though you see the AGENT_ERR_LOGOFF_IN_PROGRESS all over the place. Hopefully this was fixed for some of you. If I do get some details from VMWare concerning this issue, I will post back here to let everyone know.

Thanks,

Benoit

[Spiffman192]

In the same place.  I installed the following in July:

Hypervisor: VMware vSphere 6.0

Broker: VMware Horizon 6.1.1 (Connection Server and Agent)

Clients: VMware Horizon View Software Clients dual monitor, Wyse P25 FW 4.8.0 dual monitor, Blast Client

Physical: UCS B200, VNXe3200

Pools:

     a:1vCPU/2GB, Win8.1, floating, linked clone

     b:1vCPU/2GB, Win8.1, dedicated, linked clone

     c:1vCPU/4GB, Win8.1, dedicated, linked clone

     d:1vCPU/2GB, Win8.1, floating, linked clone

There seem to be accompanying issues with corrupted Persona Management profiles for us, probably due to improperly disconnected sessions.  It's a bit of a mess as Outlook OSTs are pretty fussy with this.

Here's a rundown on what we've tried thus far:

• Disabled Windows Lock on idle, no improvement
• Extended SSO session timeout, no improvement
• Removed ability for clients to shutdown/restart in windows, no improvement
• Created script to disconnect session that triggers at screensaver, no improvement
• Originally, I had cloned image B to make C resulting in duplicate SIDs/GUIDs (bad, awful, naughty engineer).  Cleaned up that issue, no improvement.  In fact, sees worse.
• Upgraded to vSphere 6.0u1, View 6.2 composer, connection server, agents, clients, etc.  No improvement.  Seems even worse still.
• Removed AV in one pool to test improvement.  Definitely no improvement.

We're seeing 600+ warnings every morning for 75 initial users requiring multiple logins largely with AGENT_ERR_LOGOFF_IN_PROGRESS.  Users are also getting disconnected throughout the day while actively working. 

Now, I will say that this connection server still has a trusted cert.  But I don't see why that would be causing THIS issue.

My head hurts, and the brick wall still stands.  We're opening a case with support. 

[charvoworld]

Hi,

Recently i had same issue, i just reboot by all connection server. its working fine no issue till now. i had connection server and view agent communication delay issue. VMware support suggested me for reboot. you need schedule downtime for this, just power off all connection server one by one and once all connection server is powered off wait for a minutes and power On your primary connection server. once you primary connection server is powered ON properly with all services, go for next connection server like that power on all connection server.

Thnx,

Charvo Benjamin

[Jogabaer]

Finally we could solve this problem.

We found out that the logoff process was indeed hanging for the affected users. In these cases the well known screen "Waiting for background program to close" was shown.

The users themselves don't see this screen because the PCoIP connection was already closed so nobody can hit the "Do it" button to finish the logoff process. You can verify this by connecting using vSphere (Web-)Client Console and letting the user log in to his session.

A quick Google search led me to a registry value named AutoEndTasks which is supposed to kill stuck processes after a timeout without user interaction. I deployed that value to all VDI users. The rollout took 3 more days to reach all users.

Since then AGENT_ERR_LOGOFF_IN_PROGRESS disappeared completely.

The question remains why that error massively appeared after upgrading View.

Hope this helps you too!

[BenoitCote]

Hi Joga,

Just rebooted the whole environment and also tried the regkey on one specific pool. If I see a "lack" of warning messages coming for the pool with the new regkey, I will push the change to all our pools. We do have around 18 active pools, so I want to make sure it is making a difference in our case.

Hopefully we get this figured out.. Still waiting for news from Engineering on our end but the feeling is we have a better chance of fixing it at this point. 😕

I can already see it.. stealth update View 6.2.1 with a "random disconnects" fixed in it... or so I can dream.

[brickleberry]

"but the feeling is we have a better chance of fixing it at this point. :/"

^ this is a sad fact.

what good is the paid support?

shame on vmware.

[Ray_handels]

Hey all,

We still face this issue to this day with View 6.1 installed and have had numerous phone calls and webex sessions with VMWare but still no go.

We did set the Autoendtask setting through a preference mode policy setting for the users but still see the exact same issue. We've decided to remove the machines after logoff and do this right after the machine is logged off. So a user can't reconnect to a disconnected machine

What we see happening know is that a user logs in (this all goes well, we can see this in logging), then gets a desktop assigned, logs in and within the same second gets the disconnect. He then tries to log  back in but off course gets messages that the machine is in a logoff process. He gets this error message a few times and after that, voila, he gets a new machine assigned and can log in succesfully.

This is truly driving me nuts. I have no idea why the disconnect is triggered almost instanty. At first we thought it was the pcoip_server_win32 process that crashed after the machine started up but it seems that this process is only started after the user logs on. I've send numerous logs to VMware but they are unable to find a solution whatsoever... If anyone has some goods ideas, please let me know... Looking at more than 2000 errors in your logfile doesn't make you quite confident about the entire enviorenment.

[chulerico]

guys,

any update.

thanks

Sam

[Ray_handels]

We did seem to be able to find soemthing regarding the black screen at logon (which is still one of our biggest concerns).

It seems that when you are using vGPU it is best to set the default video card (Which VMware still uses and is being contacted when you log in) needs to be set to "Auto-detect Settings". We set this to 64 MB because we thought it wouldn't be used after all so why go for to many VGA memeory right?

Anyone else had any real progress or an update off the agent??

[h3nkY]

What has been found by Jogabaer is significant. The logoff process seems stuck.

When you find user is unable to connect, please open problematic VM using vSphere client and let me know what showing in Windows.

Also, it is helpful if you attach agent debug logs so I can quick scan on it.

Thanks,

Henky

[h3nkY]

Searched and found similar issue in our bug report. But to confirm they are similar issues, your agent debug logs and screenshot on vSphere client is important.

Thanks,

Henky

[Ray_handels]

What loggings and screenshots do you mean? We send a multitude of log files your way (we do have an open ticket of this) and I have never heard of it being a bug.

The SR is 15738724408 so if you want to you can have a look.

And what should I be seeing in vSphere then? Or in the agent debug log?

[Ray_handels]

Hey h3nky,

Did you have time to check and see bug reports? Still seeing this issue in our enviornment.

[nevgeo1]

Hi

Was this issue fixed. As we are facing the same issue in our environment.

[madmanc]

Hi All
Seeing the same issue, all running 6.2.1
will look at some of the suggestions and reply back with any findings.
James

[h3nkY]

We just released 6.2.2 last week and it contains similar issue I mentioned.

Is it possible to repro the issue using 6.2.2 agent?

[pmaguerreiro]

I have the same problem.

Any one already teste the 6.2.2 to check if it is fixed?

Best regards,

PG

[Ray_handels]

Nope not really.. Didn;t even had time to check release notes.. It's just out for about 6 days .

Other issue is that this doesn't occur all the time. So even if I was to install this version in our test enviornment. I would still need some way to reproduce this.

For us it won't be until a few months for we actually get time to test this unfortenately.

[tjbailey]

We're seeing similar issues after our 6.1 to 6.2 upgrade.  Honestly, it could be a coincidence, but maybe not after reading through this thread.  We're running vCenter 6 U1, vSphere 5.5 U3, Horizon 6.2.  Since the upgrade we've noticed that when users logoff it'll randomly get hung up which prevents them from logging in again (I've attached a screenshot as an example) and we've been placing these sessions into Maintenance Mode which allows the user to log back in to a new session while allowing us to troubleshoot.  In the user context there's only two processes running:  dwm.exe and taskhost.exe.  Killing dwm.exe does nothing, but killing taskhost.exe allows the logoff to complete.

[h3nkY]

There is a vhub deadlock issue when race-condition occurs and it has been fixed in 6.2.2.

Please try 6.2.2 on your issue as the symptom is similar.