Delayed Refresh on Logoff in 6.2

[jeniferslabaugh]

Hi everyone,

Since moving a client to View 6.2 (from 5.3.2), they are complaining that View is slow to put a VM in maintenance mode for refresh after logoff.  This is in a floating pool set to logoff immediately on disconnect and refresh immediately on logoff.  If a user logs off of a VM, and logs in to another one in another room fairly quickly, they get logged in to the new session on the original VM but with keyboard and mouse not working.  They should be getting a new VM at that point. 

They are working around the issue by turning off the endpoint (zero client) and staying logged out for five minutes while the original VM goes into maintenance mode.

They did not have this issue with 5.3.2.  Has anyone seen this, or does anyone know why there might be a difference with the new version?  Thanks in advance.

[nzorn]

I'm on 6.0.1 and we're not seeing this issue.  I'm afraid to upgrade to 6.2 after hearing about these various issues though...

Have you heard about the printer bug in 6.2 that VMware calls a feature?

Physical computer with View Client that has Adobe Acrobat installed will have an Adobe PDF printer, and if your VM has the Adobe PDF printer installed as well then upon log off or disconnect that Adobe PDF printer is now deleted from the VM!

[Erossman]

Hi jeniferslabaugh,

I have actually a similar issue. Sometimes a user logs off but it will take 1-2minutes until the vm change to maintenance mode.

During this time window (logoff - start maintenance mode) the user is unable to log in to the same floating pool.

We use AppVolumes and UEM.

Did you find a solution?

Regards,

VM-MASTER

[jeniferslabaugh]

Hi Erossman‌, I did not ever find a resolution for my issue.  In fact, I had a support case open with VMware for over three months with no resolution.  To be fair, this was partially because of my client's limited ability to help them troubleshoot and the fact that I'm not on-site.  But VMware's attitude seemed to indicate they didn't think there was a systemic issue and nothing had changed from one release to the next that would cause this, and their suggestions were lackluster or things we'd already tried and ruled out.  I was really disappointed.  Sorry I don't have a better answer for you.

[Erossman]

thanks for your answer.

I will do some additional tests tomorrow. Maybe I find something regarding this issue.

Do you use Horizon 6.2.1 too?

[jeniferslabaugh]

You're welcome.  They are on 6.2.0.

[larsonm]

Are you using App Volumes 2.10 with Horizon View 6.2?  If so, is the App Volumes Integration Service still installed on the Connection Server?  I was experiencing this issue, and found that after removing the old App Volumes Integration Service the issue went away.

As good measure, you may benefit from removing the View Agent and App Volumes agent from the parent, and reinstalling the View Agent first, and then the App Volumes agent.  Per documentation, the order is important.

[Erossman]

Hi larsonm,

yes, we use AppVolumes 2.10 and Horizon 6.2.1.

The integration Service is not installed on the connection server. But we have some smaller delays during logon with assigned appstacks (more than one). But this is a known bug in ESX 6.0 U1.

I also tried to installed app volumes agent and horizon agent in the correct order. But this doesn't change anything. the issue still exist during logoff.

It's also happened if I have no appstacks assigned. It does not happened during every logoff. this is a bit queer for me.

Most time of logging off it works perfect. I see immediately that the vm switch to the maintenance mode, so the user is able to login again to an other desktop.

As I saw with horizon 7 there is already a similar issue --> https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=21446... 

[VDIMega]

I'm experiencing the same thing in 6.2.1.  I have one pool set to log off an hour after disconnect to compensate for this, but it doesn't help with users that ACTUALLY logoff/reboot instead of just disconnecting.  There's no way to set a refresh delay after a direct logoff.

Has anyone found a fix for this?

[tjbailey]

We had a similar issue with one of our pools and all we did was power the gold image on, power it off, take a snapshot and recomposed the pool.  For whatever reason it fixed the issue.  Since our upgrades from 6.1 -> 6.2 then 6.2 -> 6.2.2 we've run into all kinds of quirky issues that it makes me wish I would've just stayed on 6.1.

[tjbailey]

BTW, this is just one possible fix.  We now have a smaller pool with the same delay and cannot get it to properly work no matter what we do.  The user logs off and there's a good at least 1-2 minutes before View kicks in placing it into Maintenance Mode to start the refresh process.  Really frustrating!

[larsonm]

Are you using McAfee MOVE? 

One thing we did was update VMware Tools to 10.0.8, which seemed to help remediate the issue. 

[VDIMega]

I'm not using McAfee MOVE.  I'll try changing the Tools version.  I'm on 10.0.0.3.x right now.

[Erossman]

My Client also don't use McAfee AV. They use Sophos AV for vShield

We will upgrade VMware Tools next week to 10.0.0.8 because of the vShield Endpoint performance Issue.

I hope it will also solve delay refresh on logoff.

[Ray_handels]

Have you guys tried adding the AutoEndTasks registry key?

What could happen is that, during logoff, an application is still open asking the operating system to log off but because the user already disconnected he or she can't asnwer that question anymore.

Also, there is a known bug in Appvolumes 2.9 not detaching writable volumes and appstacks quite well.. Still the machine should not be available at all anymore instead of being able to log onto it even though the machine is loging off..

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

[tjbailey]

The pool we were experiencing the issue with has been fixed with 10.0.8 (now running 10.0.9 due to the potential PSOD).  Thanks for posting this!