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.'
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
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.!!!!
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
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?
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