Solution for "Already Used" state

[PaulWoodhouse]

Hi all

There's been quite a few posts here recently about the "Already Used" state some VMs in Linked Clone pools can end up in. I think we've developed a solution.

The problem appears to occur when a user in an Automated, Linked Clone Pool with the "Refresh OS disk on Logoff" option enabled hits the Shutdown option in Windows rather than logoff. We mitigate the risk of this by setting a GPO to make the default shutdown option "logoff" but there's no hope for some users .

My solution uses the View PowerCLI to find machines with this state and trigger a refresh. We run this script on one of our connection servers overnight via a Windows scheduled task to make sure any VM's that have found themselves in this state are OK by the time the users arrive in the morning, there's no reason it couldn't be scheduled to run more often. Typically in our environment we're only seeing a couple of VM's getting like this a day but I could see how it'd be more a problem in a larger deployment.

The problem is there's no one command you can run in the PowerCLI to return VMs with this state, instead the script has to go into the View ADAM database and iterate through all the VMs finding those machines that have the attribute "pae-dirtyfornewsessions" set to "1". These typically are the machines that are in the "Already Used" state.

This runs fine on for us on a Windows 2008 R2 x64, View 5.0 Connection server. Note this is my first attempt at a "long" powershell script i.e. more than a couple of lines so forgive me it it's not as efficient as it could be!

Usual disclaimers apply, use this at your own risk etc etc. This was written for our View 5.0 environment and is untested on any other version. Hopefully View 5.1 will resolve this issue or at least allow us to query it better from the PowerCLI.

See attached.

[mittim12]

Paul, thanks for the work and solution for this problem.   I've converted this post into a document available in the VMware View Manager forum.  The documents have less traffic than forum post so it should remain highly visible for most visitors to the forum.  

[BMC2]

First off thanks for the fix. I was able to use the script you created and it is working, but only when in the Powershell console. When I try to Schedule it with Task Scheduler I get the following errors:

The term 'Get-RemoteSession' is not recognized as the name of a cmdlet, Function, script file, or operable program.

The term 'get-desktopvm' is not recognized as the name of a cmdlet, Function, script file, or operable program.

Any ideas?

[RyanChristopher]

@BMC2: Not sure if you were able to resolve this or not, but to run powershell via Task Scheduler you need to include the switch -ImportSystemModules in the Add arguments (optional) field. The command would look something like: "PowerShell" -ImportSystemModules "c:\PSScripts\test.ps1"

There might be another way, but that's what we did to resolve the issue you described. If you look at the shortcut to your PowerShell console it should have both -ImportSystemModules and -NoExit as arguments, so that's why the modules are available in the console.

Hope that helps.

[RyanChristopher]

Thank you for your explanation as to why this was happening. We too were having issues along the same lines as you.

If I can make a quick suggestion that might work better in some cases, rather than writing/using a PowerCLI script and scheduling the refresh of these VMs.

For our non-persistent automated linked-clone desktop pool, we simply applied a GPO that disables the ability to shutdown the VM by the user. I noticed that you already have a GPO to make the default option on the Start Menu "Logoff", so why not take this a step further and also enable Remove and prevent access to the Shut Down, Restart, Sleep, and Hibernate commands from the Start Menu as well?

That way the user won't even have the ability to shutdown the VM in the desktop pool in the first place.

It may not work for everyone, and depends heavilty on how you have GPOs setup in your AD environment, but might be another option.

[gmtx]

+1 for the GPO removing the options completely. That's what we did and the problem has disappeared.

Geoff

[Amievil]

someone resolved this problem without workarounds?

[RyanChristopher]

I'm not sure what you mean by workarounds.

Most of the Already Used issues we had before have been resolved using the GPOs to only allow the user to logoff of the VM from the Start Menu. I will say, though, that I still run across this issue from time to time, just not as often. I'm not sure if there's still another reason why this issue shows up but at least it's not as noticeable as before.

It would be nice for VMware to add an option that would determine desktops in the Already Used state and automatically perform tasks on it (e.g., refresh, recompose, delete, etc.). Perhaps in a future release.

[gstrouth]

It was added in 5.1.2, check out the release notes

[Erossman]

My customer get this issue in the latest Horizon 7.0.2 again.

Is the KB https://kb.vmware.com/kb/1000590 still suitable for this release?

Any others tips what can be the reason of that? It's a floating pool with W2k8 R2 as a desktop OS. But there is a manually user assignment and the pool is not configuried to "delete or refresh after log off".

Regards,

VM-Master