Managing User Assignments in VMware View Dedicated Pools

Chris Wahl · Posted on

Within VMware View exists two different user assignment types for desktop pools: dedicated and floating. These types handle how a desktop is chosen for a particular user when they connect to the desktop pool.

  • Dedicated – A desktop is assigned to a specific user, and will not be shared with any other user. Dedicated desktops have a 1:1 relationship with a user.
  • Floating – A desktop has no assigned user, and can be used by any user who is entitled to the pool, so long as that particular desktop is available for use (no other session is currently in progress).

Assigning Desktops

It may be worth noting that dedicated assignments can be managed by View (default behavior) so that when a user connects to a pool for the first time, View finds an available, unassigned desktop and creates an assignment. The alternative is requiring a View Admin to manually assign a user to a desktop, which would prevent a user from using a pool that did not contain a desktop assigned to their login.

In a floating pool, no assignments take place, so the concept of assigning desktops is not applicable. This is typically used in conjunction with task worker pools that are delivering applications and are not focused on a personalized user experience.

In the example below, I’ll first entitle the dedicated desktop pool in my lab to the WahlNetwork lab user, and then log in once to become assigned to the first available desktop, Home-001.

Step 1 – Entitle the User

Here I have edited the entitlements for my lab pool called “Home” and entitled the AD account “WahlNetwork” to use the pool.

Step 2 – Assign a Desktop

Because this lab pool is using automatic assignment, all I have to do is connect into the pool once and I will be assigned to a desktop.

The alternative would involve a View Admin selecting a desktop and doing a manual assignment. I have not encountered anyone scripting this piece, as manual assignment is usually put in place to force an Administrator to be involved in the process for a specific reason. Otherwise, just use automatic assignments in View.

Here we can see the two desktops in this lab pool, both with no user assigned.

Once I log into the pool, this changes.

As you can see, I am now assigned Home-001. Notice that the desktop is available – I’ve already logged off the desktop, but am still assigned this desktop for the next time I connect in. If I still had a session open with the desktop, the status would be “connected” (active session) or “disconnected” (disconnected session).

Unassigning Desktops

The trickier part of desktop assignments are when it comes to performing unassignments. Let’s pretend that the WahlNetwork user miraculously wins the lottery (fingers crossed) and quits his job, thus the corporate HR department has taken care of terminating his employee AD account. However, he still has an assigned desktop in a dedicated pool because View does not watch for this sort of activity.

Note: Removing desktop pool entitlements or deleting AD accounts does not unassign a user from a desktop! Cleanup in View is still necessary.

Here is the high level, generic process for removing an employee AD account:

  1. The user account in Active Directory is removed or disabled (depending on the corporate retention policy).
  2. If the dedicated pool was entitled to the user specifically, the account remains entitled. However, if a group is entitled to the dedicated desktop pool, this is irrelevant (as other members of the group are still active).
  3. The specific desktop that the user was assigned to remains assigned to that account.

Out of those three steps, #2 may possibly require cleanup action, and #3 always requires cleanup action.

The question becomes, how do you update your process to handle such a cleanup?

Assignment Cleanup Part 1: Using the View Administrator GUI

Removing assignment is relatively straight forward within the View Administrator. Find the desktop that the user was assigned to, click it, and then choose  “Unasign User…”

You will be prompted to confirm that you wish to continue with this action.

Assignment Cleanup Part 2: Using PowerCLI

I’m a huge advocate of PowerCLI, but am generally disappointed with how it works with View. Unlike the server world, View PowerCLI is installed on the Connection Servers, and must be run from one. I’m assuming this is because there is no connection cmdlet to a Connection Server. Even if you copy the View PowerCLI files to your workstation and load them (which does work) the commands will fail with an “unauthorized connection attempt” error.

Note: If you know of a way to make this work outside of a Connection Server, please share. 🙂

RDP into a Connection Server (or use the vSphere Client Console if you wish) and find the View PowerCLI shortcut in the start menu under the VMware folder.

You should be greeted with a friendly screen that says “Welcome to VMware View PowerCLI”. If you get any errors that state the pssnapin for VMware.View.Broker could not be loaded due to security reasons, make sure to set the appropriate level of ExecutionPolicy. Here is the command:

Set-ExecutionPolicy RemoteSigned (Reasonably safe in production)

Alternatively

Set-ExecutionPolicy Bypass

Step by Step Method

In this example, I want to unassign my WahlNetwork user from the desktop Home-001. First, let’s pretend I did not know what desktop I was assigned to. To find it, use this command:

ForEach ($vm in (Get-DesktopVM)) {If ($vm.user_displayname -match "WahlNetwork") {Write-Host $vm.Name}}

The resulting answer of this script is Home-001, which gives me a human readable name for the desktop that I’m assigned to. Unfortunately, the only arguement that the Remove-UserOwnership cmdlet (command used to remove the user assignment) accepts is machine_id, which is a long face-roll style name.

So, I’ll need the machine_id of the VM.

ForEach ($vm in (Get-DesktopVM)) {If ($vm.user_displayname -match "WahlNetwork") {Write-Host "Desktop $($vm.Name) with MachineID of $($vm.machine_id)"}}


Now we’re getting fancy!

 

Here’s the final piece – the removal of the user assignment.

Remove-UserOwnership -machine_id af883dbe-6f3b-4d36-8d76-86062e5f7347

Be warned that there is no confirmation, nor a WhatIf arguement, for this cmdlet. It just executes and returns nothing if it was successful.

Single Script Method

I showed you how to remove assignment step by step, here is a brief script that would do the entire thing.

$name = Read-Host "Enter the AD account that should be removed from assignment"
$pool = Read-Host "Enter the View desktop pool name to search"
Write-Host "Searching for $name in $pool ..."
$success = 0
ForEach ($vm in (Get-DesktopVM -pool_id $pool))
	{
	If ($vm.user_displayname -match $name)
		{
		Remove-UserOwnership -machine_id $vm.machine_id
		Write-Host "$name has been unassigned from a desktop named $($vm.Name) in pool $pool"
		$success = 1
		}
	}
If ($success -eq 0) {Write-Host "Could not find $name in $pool"}

[symple_box color=”black” fade_in=”false” float=”center” text_align=”left” width=””]You can find all of my various PowerShell scripts in my GitHub repository[/symple_box]

Thoughts

Hopefully this has given you some tools to use in the VMware View world, as well as some information on how things work for user assignments. I’m rather disappointed with how PowerCLI works in the View world, as it’s typically inconvenient (at the very least) to connect to a View Connection Server, and sometimes not even possible depending on your server security access in a corporation. I’d like to see that improved, although perhaps I’m a small minority, but then again maybe I’m wrong and there is a way to do this remote? I’d rather be wrong – feel free to comment either way. 🙂