'Machine not ready to accept connections' after logoff and logon

[mrstorey]

Hi,

If a user logs off from a view desktop and immediately logs back on (before composer has has chance to refresh and return it to the pool - around 2-3mins), they are not allocated a new desktop and are instead given the error 'Unable to launch from Pool <pool> for user <user> : machine is not ready to accept conections.'

Pool Setup:

- View 5.1.2 Connection Server and agents.

- View 5.2 client for Windows.

- Floating pool, linked clones, Windows 7 x64.

- Power policy                - Power off

- Logoff after disconnect      - Immediately

- Allow multiple sessions per user - Yes

- Delete Refresh desktop on logoff - Immediately

- Number of spare powered on desktops - 10

Scenario:

User connects and authenticates to a connection server, and is allocated a desktop from a floating pool. 

User is logged in to the desktop successfully, does some work and logs out using their preferred method (we don't restrict how they end their session)

User realises they've forgotten something, and immediately tries to reconnect to a desktop in the pool.

User re-loads the View client, authenticates, and the only option available to the user is to 'reconnect to desktop',

Connection attempts fail with the error 'Unable to launch from pool <pool> for user <user> : machine is not ready to accept

connections.

User gets fustrated and gives up.

-----------

It seems that users aren't able to establish a connection to a new desktop until the refresh operation of their old desktop is complete? 

I've experimented with 'Delete of refresh desktop on logoff' and power policy pool settings, but it still behaves the same - the user is

given errors on every connection attempt until the deskop they were using has been logged off / refreshed / returned to

the pool.

I was hoping that the pool setting 'Allow multiple sessions per user' would allow anyone to immediately reconnect to a

desktop regardless of what state their /previous/ desktop was in?  There's plenty of 'available' machines in the pool,

but the connection server doesn't want to allocate one of them.

Any ideas why?

Thanks,

Alex

[gmtx]

I'm occasionally seeing the same behavior with a "Refresh on Logoff" pool, and if I watch the destop state in View Manager when it happens, the VM with the behavior does take a while before View recognizes that the user has logged off.

In one particular instance a VM was taking a really long time to show no user connected, so I opened a console window on the VM and saw that it was "Logging Off...", and eventually it really did. I still haven't found a reason why this intermittently happens (persona manager syncing, maybe?), or a solution, so if you come up with something please update the thread.

Geoff

[dmadilicutty]

If you can find answer to this, please post.  I have the identical view configuration as you.  In our environment, the same error occurs to about 30 users per day.  We have 1000 concurrent users, so 30 isn't that bad as far as percentages go...but still.

I've recomposed after installing(reinstalling) VMtools and the view agent.  Still happens.

We've checked all ports at the firewall level, the ports are not being blocked.

We have bounced the Connection brokers, security, and replica boxes... still happens.

I've checked DNS/domain connectivity on the funky VM's... everything is perfect.

Please post an answer if you find one.!!!!

[mrstorey]

I'm starting to wonder this is behaviour by design - I just didn't expect it to work in this way.

I would like View to *always* allocate a new desktop to a user regardless of how long their previous session is taking to clear down.

Throwing errors indicating there are no desktops is fustrating when you have plenty of machines available.

If we're alone with this issue then I guess I'll see if support can explain whats happening.

Thanks,

Alex

[gmtx]

Waiting until the previous VM is logged off before allowing a new connection does make sense if your are using Persona Management (we are). Hopefully VMware can figure out what's causing the occasional slow logoffs, but they're tough to troublshoot in non-peristent environments as the logging effectively gets destroyed when the VM refreshes. What I have been able to see by connecting to the event logs on a "stuck" VM in the logoff state is problems getting the profile to unload - Windows still thinking it's in use and waiting for it to free up before completing the logoff. A persona management issue perhaps?

[mrstorey]

Ok - mystery solved.

Logged a call with support and had a call back literally minutes later.

GTMX was on the right track - the issue relates to Persona Management syncing back to the profile store.

View won't allow another desktop session until the previous one has closed / finished syncing, because Persona Mgmt doesn't support concurrent sessions.

They're sending me a feature request form, which I guess at the very least I could suggest a slightly better error message in this scenario - maybe something that says 'Please wait while your profile is synchronized".

The current errors suggest there are no machines available, and I fear people would incorrectly assume the environment is under-resourced or licensed.

Anyway - good work VMware support, lets see if product development are able to enhance Persona Mgmt later down the line.

Thanks,

Alex