Desktops with status ALREADY_USED, eventviewer show BROKER_POOL_COMANAGER_REQUIRED

[Mickeybyte2]

Hi,

I've been investigating a problem we have with desktops that go into status ALREADY_USED.

First things first, our setup:

- VMWare Horizon View 7.1, running on ESXi 6.5 hosts and 6.5 vCenter

- 2 desktop pools (linked clones, non-persistent, 1 based on W2K8R2 server, the other one based on W2K16 server, total of 160 desktops, all provisioned upfront)

- redirected folders & roaming userprofiles with Persona Management (seperate location for both pools because different OS)

- Single Horizon View connection server

Problem:

After provisioning all desktops are available. Each day 2 or 3 desktops go into "ALREADY_USED" status. By the end of the week we have over 10 desktops from both pools that are not available any more because of their "ALREADY_USED" status. Restarting those desktops makes them available again, but I want to find the root cause of the problem

Users are not complaining they get an error or so that causes this.

What I've already done:

- Checked Horizon Admin log database based on the desktop name and then searching within the last timeframe of that desktop. The only possible clue I can find (besides logon, logoff, connect, reconnect, ... the normal stuff) is an "AUDIT_FAIL" event some minutes after the last event entry concerning the specific desktop stating "BROKER_POOL_COMANAGER_REQUIRED" Unable to launch from Pool <desktop pool> for user <DOMAIN\USER>: No co-management availability for protocol PCoIP.

- search the Internet for "ALREADY_USED" status, but no more than "to protect the user settings/data in case of a failure the desktop is place in this status". What I want to know is why this is happening. Searching for "BROKER_POOL_COMANAGER_REQUIRED" only gives me results of the Horizon manual stating this as a possible event without any further explanation.

Hope someone in here can shed a light on this?

Thanks a lot,

Michiel.

[AlexLSx7]

We are having an occasional issue where machines go into Already Used state, but the VM usually crashes and the user will lose their session before it gets to that point.

[Lieven · Accepted solution]

Set the LDAP attribute to pae-DirtyVMPolicy=2 in the ADAM database.

Look at my blogpost at https://www.ituda.com/vmware-horizon-view-already-used-status-and-pae-dirtyvmpolicy/ about this problem

[Mickeybyte2]

Lieven,

Thanks for the quick reply.

I saw your blog when I first started looking into this problem, but didn't want to implement it back then. I wanted to find the reason why it happened and how to prevent it. Seems like there's no way to prevent it from happening as you state that it can happen because of HA events.

So I changed the the policy on one of the two desktop pools now and I'll see what happens during the next days.

Michiel.

[BenFB]

I would try to fix the root issue for this. There are security implications of setting pae-DirtyVMPolicy=2 that could lead to compromised credentials or data.

I have a floating pool of 75 x Windows 10 linked clones that refresh on log off and I've never seen this. I did however used to see this back in the Horizon 5.3.x days. I noticed you are still running 7.1 which I would recommend upgrading. If the issue persists you should work with VMware support.

[Mickeybyte2]

Ben,

I totally agree with you, however I haven't found any possible solution, not even a clue on where to start looking for the cause of this.

Contact with VMWare support is not possible for me unfortunately, I'm only the Horizon administrator. All contact with VMware is done through our partner (which doesn't think of this problem as a priority...)

So if I need to choose between manually refreshing those desktops every week, or automatically, the choice is easy 🙂

The upgrade to the latest version is planned in the near future. Hopefully it will solve the problem.

Michiel.