Managing VMware View 4.5 virtual desktops with PowerCLI

VMware View 4.5 supports PowerShell-based extensions, PowerCLI, to manage virtual desktop environments. Here are some useful cmdlets for creating virtual desktop pools.

VMware's adoption of Microsoft's PowerShell for VMware Infrastructure 3 is great for the VMware community because

the PowerShell extension PowerCLI is becoming the de facto standard for any command-line interface-based activity, and new cmdlets are added each year.

There are many reasons to use PowerShell with VMware View, including speed, portability and ease of use. For example, PowerShell cmdlets can be saved as .PS1 files, edited and easily modified. If you are creating many virtual desktop pools, the cmdlets and scripting can be used to build a consistent layout to your View environment.

The PowerShell cmdlets are also easy to modify to work against other installations and sites. In addition, if you frequently destroy and rebuild your environment, using PowerShell scripts to reset and rebuild your environment is faster than using the Web-based administration tools.

If you want to use the new View cmdlets, you need to first install (or enable, in the case of Windows 2008 R2) Microsoft PowerShell on your View Server system. The new View 4.5 cmdlets run only locally on the View Connection Server, which is a bit disappointing. Most administrators would expect to run these cmdlets from a management system with VMware PowerCLI also installed.

The cmdlets for View are in the form of a snap-in that has been loaded into the PowerCLI environment. These are currently held in:

C:\Program Files\VMware\VMware View\Server\extras\PowerShell

The snap-in is installed by merely running the .PS1 file called add-snapin.ps1. Running the PS1 file adds shortcuts to your start menu, so when a View PowerCLI session starts, the appropriate snap-ins are loaded into the environment.

Below are some examples of the View PowerCLI cmdlets from VMware's "VMware View Integration Guide," which covers the PowerCLI. The guide also covers customizing Lightweight Directory Access Protocol (LDAP) data in View and its new integration with Microsoft System Center Operations Manager (SCOM).

Managing vCenter to View Connections
If you have an environment that is already configured, you can use various cmdlets to manage the relationship between vCenter and View.

List vCenters
The cmdlet "Get-ViewVC" can be used to retrieve information about the current vCenter connection with:

Get-ViewVC -serverName

The result of this cmdlet is visible in the screen grab below (Figure 3).

The "createRampFactor" and "deleteRampFactor" values at the bottom represent the current settings for the "maximum concurrent provisioning operations" and the "max concurrent power operations," respectively. These can be configured through the View Web administration pages, as seen below (Figure 4).

If you have multiple vCenter servers listed in View, you can use the asterisks as wild cards to list all vCenters configured for View.

Get-ViewVC -serverName *

In addition to using Get-ViewVC to add vCenter references into View, it is possible to remove a vCenter listing from the View server with the Remove-ViewVC cmdlet and the Get-ViewVC cmdlets.

Get-ViewVC -serverName | Remove-ViewVC

Warning: These cmdlets will return an error and fail to complete if there are any desktop pools that use the vCenter connection you are trying to remove. Also, any Transfer Server has to be placed in maintenance mode and removed.

The Transfer Server is a new role in View 4.5 that is designed to speed up the "local mode" or "offline desktop" feature. The Transfer Server is installed into a virtual machine and is automatically discovered by the vCenter and View servers' relationship.

To remove a vCenter reference, you may have to remove the pools that it offers and its references to Transfer Servers. If you have a number of vCenter servers to add into View, use the Add-ViewVC cmdlets in the following manner:

Add-ViewVC -serverName -username corp\administrator -password vmware -description "Connection to New York vCenter" -createRampFactor 5 -deleteRampFactor 5 -useComposer $true

This adds the vCenter and uses the option –useComposer. It also enables the View Composer Linked Clones component, using the same credentials as the vCenter.

Creating virtual desktop pools
You can create virtual desktop pools and linked-clone virtual desktop pools with the Add-AutomaticPool and Add-AutomaticLinkedClonePool cmdlets, respectively.

As you might imagine, with all the settings in View, the number of possible subparameters is quite dizzying. This can be problem when it comes to documentation because the strings become very long and difficult to read, so I express a long command as series of lines.

To create a desktop pool, you need to provide at least six parameters:

  • -pool_id                                  Internal name of the pool
  • -displayName                         As it is shown to end user
  • -vmFolderPath                       Path to the folder to hold desktop
  • -resourcePoolPath                Path to the Resource pool
  • -templatePath                        Path to the Template           
  • -customizationSpecName   Guest Customization used

One easy way to learn the parameters is to query an existing pool with the following:

 get-pool -pool_id "SalesGroupWin7"

This will give you an output like this:

pool                      : 1
pool_id                                : SalesGroupWin7
description                             :
displayName                        : Sales Group Windows 7 Desktop
enabled                                  : true
folderId                                  : /
deliveryModel                         : Provisioned
multiSessionAllowed               : false
userResetAllowed    : false
assignOnFirstLogon                 : true
desktopSource                         : VC
powerPolicy                            : RemainOn
vc_id                      : efad478d-d82f-434f-9bf3-65defceb263b
vcServerName                          :
provisionEnabled     : true
provisionSuspendOnError          : true
postProvisionState    : READY
startClone                                : true
calculatedValues                        : false
deletePolicy                              : Default
headroomCount        : 25
maximumCoun        : 50
minimumCount        : 10
datastorePaths        : /NYC DataCenter/host/AMD Cluster1/virtualmachines
datastoreDisplayPaths                  : /NYC DataCenter/host/AMD Cluster1/virtualmachines
customizationSpec                    : Virtual Desktop Deployment -- Windows 7 Enterprise N -- 64-bit
resourcePoolPath                      : /NYC DataCenter/host/AMD Cluster1/Resources/Virtual Desktops/Sales Desktops
resourcePoolDisplayPath              : /NYC DataCenter/host/AMD Cluster1/Resources/Virtual Desktops/Sales Desktops
templatePath                            : /NYC DataCenter/vm/_Templates/win7x64
templateDisplayPath                    : /NYC DataCenter/vm/_Templates/win7x64
vmFolderPath         : /NYC DataCenter/vm/Virtual Desktop Pools/SalesGroupWin7
vmFolderDisplayPath                   : /NYC DataCenter/vm/Virtual Desktop Pools/SalesGroupWin7
namePrefix                                  : salesdesktop
persistence                                  : Persistent
autoLogoffTime         : Never
poolType                                    : Persistent
markedForDelete        : 0
protocol                                      : PCOIP
allowProtocolOverride                   : true
flashQualityLevel                          : NO_CONTROL
flashThrottlingLevel                      : DISABLED

You can also see these paths to learn the conventions on existing desktop pool under the Settings tab.

The get-pool cmdlets are helpful for learning more about the parameters, but you can get tripped up with these if you aren't careful. For example, "Get-Pool -protocol RDP" will list all the pools configured with Microsoft Remote Desktop Protocol by default. You'd think it would be "–protocol PCOIP" to change it. Wrong! Actually, the flag is "–defaultProtocol PCOIP". Elsewhere in the list of attributes is the option to set "allowProtocolOverride $false". This works perfectly fine. The attribute names on list above sometimes work, but sometimes they don't. Nice!

Creating manual virtual desktop pools
One of my first examples of pools in my guide to View 4.5 is a manual pool – where a single virtual machine (VM) is given to specific user or even a group of users. This was called an "individual desktop" in previous releases but was depreciated as a feature in View 4.5. However, it's still possible to create this configuration using the graphical user interface (GUI) and cmdlet.

It is also possible to create manual "pools" from existing virtual desktops that you have created. I previously explained how you could still effectively create a "personal desktop" using this option. To do the same with the ViewCLI, use the Add-ManualPool cmdlets with Get-DesktopVM to find the existing VM with vCenter.

Get-ViewVC -serverName | Get-DesktopVM -name mikel | Add-ManualPool -pool_id mgl_win7desktop -displayName "Mike's Windows 7 Desktop" -isUserResetAllowed $true

(The –isUserResetAllowed $true value is an optional component that controls whether the user can reboot their virtual desktop using the View Client toolbar.) component

Creating dedicated virtual desktop pools
It's also possible to create a dedicated virtual desktop pool. This pool type is "sticky," meaning that when users connect for the first time, they are allocated a virtual desktop that becomes their permanent, dedicated desktop.

With this desktop type, you can ask View to create bundle of virtual desktops based on your requirements. To do this, specify parameters such as the friendly name for the pool and its unique ID. In addition, tell View which folder, resource pools and data store you want to hold the virtual desktops. Using a numerical system, you can indicate how many VMs you want and how many will be held in reserve waiting for users to connect.

To create a dedicated pool, use these Add-AutomaticPool cmdlets:

Get-ViewVC -serverName | Add-AutomaticPool -pool_id SalesGroupWin7 -displayName "Sales Windows 7 Desktop" -namePrefix "salesdesktop"

-vmFolderPath "NYC DataCenter/vm/Virtual Desktop Pools"

-resourcePoolPath "NYC DataCenter/host/AMD Cluster1/Resources/Virtual

Desktops/Sales Desktops"

-templatePath "NYC DataCenter/vm/_Templates/win7x64"

-dataStorePaths "NYC DataCenter/host/AMD Cluster1/virtualmachines"

-customizationSpecName "Virtual Desktop Deployment -- Windows 7 Enterprise N -- 64-bit"

-maximumCount 10 -headroomCount 5 -minimumCount 2

Above, I asked for pool with an internal ID of "SalesGroupWin7" and friendly name of "Sales Windows 7 Desktop." When Microsoft's System Preparation Utility is run on them, they will be given a NetBIOS name of "salesdesktop1," "2," "3" and so on. The rest of the syntax -- "-vmFolderPath," "-resourcePoolPath," "-templatePath," "-dataStorePaths" and "–customizationSpecName" -- are just path statements to the relevant objects and the location in vCenter where virtual desktop pools are created.

The last three parameters control the sizing of the desktop pool with a maximum of 10 virtual desktops. This would be a dedicated pool, and provisioning would begin as soon as the command is entered.

Note: If you are familiar with VMware PowerCLI, you will notice a limitation here. The cmdlets for View currently don't allow me to use all the PowerCLI cmdlets. So I can't replace the line -resourcePoolPath "NYC DataCenter/host/AMD Cluster1/Resources/Virtual Desktops/Sales Desktops" with get-resourcepool "Sales Desktops".

If you are experimenting with the ViewCLI and creating pools, you might kick off a full-blown provisioning process, especially if the systems storage back end is limited in capacity or IOPS. In that case, you can switch off automatic provisioning with the -isProvisioningEnabled $false parameter. This is the same as removing the checkbox when you run through the GUI wizard.

Floating virtual desktop pools
It is also possible to create a "floating" virtual desktop pool type within View. With the floating type, users are randomly allocated virtual desktops from the pool, and when they logout, they relinquish ownership of the virtual desktop to View so it can be allocated to another user.

The idea here is to only run enough virtual desktops to accommodate the maximum number of virtual desktop used during peak daily connections (your concurrency requirement). That way, you won't have virtual desktops waiting around for users to connect, wasting memory and CPU resources.

Another option with the floating desktop pool is to have the virtual desktop deleted and new one created whenever the user logoffs. This ensures that users always receive a clean, well-performing machine.

To create a "floating" pool that deletes virtual desktops when users logout, add the – persistence and –delete policy flags to a similar command, like so:

Get-ViewVC -serverName | Add-AutomaticPool -pool_id Student -displayName "Student Desktop" -namePrefix "student"

-vmFolderPath "NYC DataCenter/vm/Virtual Desktop Pools"

-resourcePoolPath "NYC DataCenter/host/AMD Cluster1/Resources/Virtual Desktops/Student Desktops"

-templatePath "NYC DataCenter/vm/_Templates/win7x64"

-dataStorePaths "NYC DataCenter/host/AMD Cluster1/virtualmachines"

-customizationSpecName "Virtual Desktop Deployment -- Windows 7 Enterprise N -- 64-bit"

-maximumCount 10 -headroomCount 5 -minimumCount 2

- persistence NonPersistent – deletePolicy DeleteOnUse

The –persistence flag is used to indicate that this pool is a "floating" type, and the –deletePolicy ensures that the virtual desktop is destroyed once the user logoffs.

Virtual desktop pools using Linked Clones
So far I've created different types of pool with different settings using the standard deployment process based on vCenter templates and guest customizations. But there are more efficient methods that utilize VMware "Linked Clones."

With a linked clone enabled desktop pool, View creates snapshots  called "replicas" from Parent VMs, which are made unique by differences or deltas. These differences can be very small, so the deployment process is much faster, and it reduces disk usage because it doesn't require expensive array-based de-duplication features.

To create a linked clone enabled virtual desktop pool you can use the parent VMPath and –parentSnapshotPath parameters.

Get-ViewVC -serverName | Add-AutomaticPool -pool_id AcctsGroupWin7 -displayName "Accounts Windows 7 Desktop" -namePrefix "acctsdesktop"

-vmFolderPath "NYC DataCenter/vm/Virtual Desktop Pools"

-resourcePoolPath "NYC DataCenter/host/AMD Cluster1/Resources/Virtual Desktops/Accounts Desktops"

-parentVMPath "NYC DataCenter/vm/Parent VMs/winxpSP3-parentVM"

-parentSnaphotPath /AutoPoolSnapshots/parent1_snapshot -datastoreSpecs [Aggressive,os,data]/NYC DataCenter/host/AMD Cluster1/virtualmachines -dataDiskLetter "D" -dataDiskSize 100

The dataDiskLetter and–dataDiskSize values allow you to control the size of the separate virtual disks, which optionally make up a linked-clone desktop.

These optional virtual disks let you redirect temporary files, such as Windows page file, and the user's profile to other locations with the virtual desktop. This can be helpful when you recompose, refresh or rebalance the virtual desktop. These options also allow users' virtual desktops to be reset quickly, without undoing any changes in their environment.

At some point, you might want to change the settings of your virtual desktop pools. All the off "add-" style cmdlets, which are used to add pools of various types, come with their own "Update-" style cmdlets to modify pools after they have been defined, such as the Update-AutomaticPool, Update-AutomaticLinkedCLonePool and Update-ManualPool.

So, if you want to change the default from PC over IP to Microsoft's Remote Desktop Protocol and simultaneously disable the users' ability to choose the protocol of an Automatic Pool, this is the command:

Update-AutomaticPool -pool_id SalesGroupWin7 -displayName "Sales Windows 7 Desktop"

-dataStorePaths "NYC DataCenter/host/AMD Cluster1/virtualmachines"

-allowProtocolOverride $false -defaultProtocol RDP

It is also relatively simple to delete pools using the View cmdlets. You can either run-list the pool from View or log off existing users and delete the pool and all its VMs.

Remove-Pool -pool_id SalesGroupWin7

-DeleteFromDisk $true -TerminateSession $true

Managing user assignments
After creating virtual desktops pools, you need to allocate users to virtual desktops.

The cmdlets are pretty limited in terms of discovering more about your users and groups in Active Directory (AD). For example, it only queries AD for users and their group memberships, and it doesn't allow for querying groups. If you want really powerful AD cmdlets, that's what the Microsoft PowerShell is for. Nonetheless, if you want to know more about a specific user via the View cmdlets, use the following:

Get-User -name mikel -domain corp -includeGroup $true

So to add the MikeL user to his personal desktop, you can use this command:

Get-User -name mikel –domain corp | Add-PoolEntitlement -pool_id mgl_win7desktop

(At the time of writing, "– corp\mikel," "corp/mikel" and "" each creates an error. The official documentation that I'm working from indicates that "corp\mikel" should work, but it doesn't. As you can see above, "name <username> -domain <domainname>" does work).

To assign a group of users to a pool, use the same syntax:

Get-User -name "Sales Group" –domain corp | Add-PoolEntitlement -pool_id SalesGroupWin7

If you wish to remove all the entitlements to a specific pool, use:

Get-PoolEntitlement -pool_id SalesGroupWin7 | Remove-PoolEntitlement

You can generate a report of the current entitlements on a pool with the Get-PoolEntitlement cmdlets:

Get-PoolEntitlement -pool_id SalesGroupWin7

If you want a complete report of all the pools and their current assignments, use "Get-PoolEntitlement -pool_id *".

Once users have connected to virtual desktops, you can get list of currently connected users with what's shown in Figure 11.

Notice how the info shows a "clock skewed." The time on the virtual desktop was 12:18, but it was actually 13:19 when I took the screen grab.

As you can see, View 4.5 hosts a whole series of PowerShell extensions to help you to manage your environment. The downside is that it doesn't integrate fully with the much larger VMware PowerCLI for vSphere4. As such, it feels like it has been developed independently of the more widely used command-line interfaces. So there is some tidying up to be done to make the PowerCLI of vSphere4 and the new View 4.5 interfaces to work together in harmony.

For more information, check out my latest guide to Administering VMware View 4.5, available for download from, and all royalties will be donated to UNICEF.

This was first published in January 2011

Dig deeper on VMware virtual desktop software



Enjoy the benefits of Pro+ membership, learn more and join.

1 comment


Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: