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!

[Ray_handels]

Hey H3nky,

Our VMWare engineer told us that this was only an issue for people using a cloud service. We are not using cloudservices and all servers are on site.

That being said, we still have the AGENT_ERR_REQUEST_OVERLAP issue in our enviornment. Once in a while (mostly 1 machine a day on average) goes berserk and starts to throw out this error message almost a hundred times. It really hogs up the events in the Horizon View Administrator. Eventually the machine just time out and the machine is being reset. Any possible solution would be nice.

As far as the black screen at logon goes it seems to be resolved for us with Tech support help.

What happens is when you use vGPU (and only vGPU is my guess) you need to access the machine using PCoIP before sealing.

We used RDP (direct connection in vSphere doesn't work with vGPU installed) to log into our golden image while documentation states that you need to use the Direct Connection Agent.

We now installed this agent in our golden image, connect to it using the Horizon View client and the black screens are gone.

[h3nkY]

No. That is not true.

The bug was in virtual hub driver and it's a component of View agent regardless using cloud pod or not.

[Akraz]

Hi, my environment is currently on 6.2.2 build-3508079. and all my floating pools are plagued with hanging logoff sessions. When i console into the trouble VM guest to see what is going on, it is just a frozen background wallpaper with no taskbar, icons, or functionality. I have to force Power off the machine to kick off the user's hung session.

We have been receiving this AGENT_ERR_LOGOFF_IN_PROGRESS since 6.1.1.

This issue unfortunately still persists in 6.2.2.

I have had a ticket open with VMWare since forever it seems and they have me creating pool after pool all with different configurations, with/without persona, with/without certain apps, with/without windows updates,group polices... etc etc... i am getting very tired of all this re-creating images and recomposing and supplying dumps and dumps of logs over and over again.

I also added in the HKU/.Default/Control Panel/Desktop AutoEndTasks string and this still does not fix the problem.

[h3nkY]

Hi Akraz,

I'm sorry to hear the problem you are facing.

#1 To know what exactly happening when logoff session is hanging, can you suspend the VM before powering it off and collect .vmss file?

     Note, in some version of ESXi you may need to collect .vmem file also. Please upload these files to your support ticket.

#2 Can you please let me know your ticket number? I may able to track your ticket.

Thanks.

[chulerico]

facing similar issue, but I'm my case luckily only happening on one pool, it was getting real bad, after updating everything vmware tools 10, windows etc, now i'm only getting it on one or two machines at day, but these are enough to general thousands of logs warnings.

connecting to vsphere, vm is waiting for user to log off/shutdown making the choice, and machine carries on.

hope there is a fix soon, support wasn't really helpful, pointing toward AV and pool settings which don't seem to be the case

issue seems to start around 6.1.1

thanks

Sam

[tjbailey]

When we upgraded from 6.1 to 6.2 we did the infrastructure side first (Composer, Connection servers, Security servers) then a week later upgraded the agent to 6.2.  Since then we've ran into the issue (no changes to the gold images other than the View and agent upgrades).  We'll be upgrading to 6.2.2 in the next few weeks and I'll report back the results.

[screenbert]

We've started having the same issues also. We're going to try to 6.0.1 agent since we have that downloaded and then we'll try shutting down the connection servers and restarting 1 at time, 5 minutes apart.

[screenbert]

The 6.0.1 agent didn't work, but reverting to an older snapshot did work. The older snapshot is running 6.2 agent. We've installed some software since that snapshot, but we're still investigating.

[tjbailey]

Honestly, I'm not having a warm and fuzzy about 6.2.2 either.  We have a new environment for a different VDI implementation where everything is running 6.2.2 and I just experienced an issue where I did a simple disconnect and couldn't log back in.  From the Horizon client I got:

All available desktop sources for this desktop are currently busy.  Please try connecting to this desktop again later, or contact your system administrator.

Within "Events" of the View Administrator portal I saw entries stating "unable to launch from Pool xxxx for user xxx: Machine xxxx is not ready to accept connections".  When I remotely restarted the "VMware Horizon View Agent" service on that machine I was able to log back in ok.

I have a ticket open with VMware, but I've only received questions from them and no real help yet.  Our 6.2 to 6.2.2 upgrade is taking place Saturday so we'll see what happens.

[h3nkY]

Hi tjbailey,

May I know your ticket number so I can help.

[tjbailey]

Ticket number is 16925705303

[h3nkY]

What I'm seeing in your support ticket is the logoff process was waiting for "Task Host Window". I guess you are using Windows 10 since I see many times that Windows 10 always blocks logoff process until this "Task Host Window" ends.

I suggest you to open support ticket with Microsoft and tell them if there is any workaround to forcing logoff without waiting for "Task Host Windows" ends for long time.

[it_team_mufg_br]

Hi h3nkY,

why vmware don't put the stop process (vmware process.. .agent, etc)  after the lsass.exe (windows process) ?

The stop order may at least enable the user to force the stop process manually as the agent will be up and so the screen.

We are having the same issue, this thread is opened since May/2015 without a solution????

I will try the AutoEndTask, does anyone have another - forever - workaround?

[tjbailey]

Not an acceptable answer.  As we stated, this issue didn't start until the Horizon upgrade from 6.1 to 6.2.  I'm currently in the process of upgrading to 6.2.2, but cannot update the agent in the pools until 4/18 so it'll be a bit until we see whether 6.2.2 does in-fact fix the issue.  Our pools are Windows 7 w/SP1 x64.

As it_team_mufg_br stated, can VMware put a feature into the product where either it'll automatically kill processes after lsass.exe closes or have a feature similar to Citrix XenApp (and maybe XenDesktop, but can't say) where you can specify processes to kill on logoff.  In our XenApp environment we heavily utilize this feature for some applications that are not exactly programmed the best by the vendor.

[h3nkY]

Hi it_team_mufg_br,

When the session ends, windows will broadcast (NOT sequentially) exit process notification and wait for couple of seconds before terminating them forcefully. The last process will be csrss.exe which manages all the processes in the session.

But, the applications still have a chance to request back to the windows to not terminating them. If this kind of application exists then you'll hit this issue since windows will wait until the application tells the windows that it's ready to end.

The PCoIP is the process which runs in user session and it must ends when received exit broadcast notification.

[it_team_mufg_br]

Hi h3nkY,

thanks for your clarification!

So the question now is why it was not happening in version 5?

Is there any target date to the engineers solve it?

AutoEndTasks is helping a lot here!

[tjbailey]

Our VMware engineer got back to us after we went through the process of generating a .vmss file for analysis.  They ran Windows debugger and found this:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 80, {4f4454, 0, 0, 0}

Probably caused by : ntkrnlmp.exe ( nt!KiInterruptDispatchNoLock+163 )

Followup:     MachineOwner

Now trying to figure out exactly what is causing this process to crash...

[tjbailey]

Hm, we haven't tried AutoEndTasks.  We set "WaitToKillAppTimeout", but unfortunately this hasn't been helping out.  We're doing the 6.2.2 agent upgrade on Monday and if this doesn't help I'll give AutoEndTasks a shot.  Did you follow this article and set the value to 1?

https://technet.microsoft.com/en-us/library/cc978604.aspx

[chulerico]

have to tried this key too, please let me know how it goes

by the way just saw this vmware kb2145020

"User encounters the error message "You are currently being logged off from an existing session" when trying to log back in to a desktop after logging off. The root cause is that on the desktop machine, Internet Explorer has the browser extension Symantec Vulnerability Protection installed."

wish it were the case for us, but we don't use Symantec products.

Sam

[tjbailey]

Just a quick update...AutoEndTasks did not fix the issue.  We have a ticket opened up with Microsoft and they're saying that there could be an orphaned lock holding onto the taskhost.exe process.  We're continuing to work on the issue and hope to have some more information in the next few weeks.