Managing VMware View with PowerCLI

From vmWIKI
Jump to: navigation, search

Originating Author

Michelle Laverick

Michelle Laverick.jpg

Barry Coombs

Screen Shot 2014-04-28 at 09.41.39.png

Video Content [TBA]

Introduction to Managing VMware View with PowerCLI

Version: Horizon View 5.1

For a more complete review of all the View PowerCLI cmdlets with examples – check out the online document centre:

PowerShell and PowerCLI support were first introduced in VMware View 4.5. VMware’s adoption of Microsoft’s PowerShell has ripped through the VMware Community since its introduction in Vi3. It’s really great that VMware have chosen to adopt and embrace this technology, and PowerShell/CLI usage continues to grow – it’s become the de facto standard for any CLI based activity as new cmdlets are added to the pool on a yearly basis. Remember if you want to use this you will first need to install (Windows 7) or enable (Windows 2008 R2) Microsoft PowerShell to one of your View Connection Servers:


Once PowerShell has been installed you can then install the vSphere PowerCLI 5.0 extensions followed by the View snap-in. At the time of writing the cmdlets for View are in the form of a snap-in that has to be loaded into the PowerCLI environment. The snap-ins are currently held in:

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

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


One of the odd things about the View PowerCLI is, unlike any other PowerShell extensions from VMware, the View PowerCLI can only be natively executed on the Connection Server. However with that said, it is possible to carry out these instructions from a second machine using what’s called “remoting” in PowerShell, as if you were on the connection server itself – conceptually it’s not unlike using a graphic RDP session to connect from one system to another.

Put simply, you run the PowerShell command “Enable-PSRemoting” on the Connection Server, then on the management PC where PowerShell/PowerCLI has been installed run this command:

Enter-PSSession –Computername –credential (get-credential)

Once authenticated you can load up the View snap-in with the cmdlet:


For more instructions on this – see Alan Renouf’s “Using the View PowerCLI cmdlets from another machine”:

What follows below are some examples of the View PowerCLI cmdlets. I’m indebted to VMware’s “VMware View Integration Guide” which covers View PowerCLI. You might be interested to know the guide also covers customizing LDAP data in View, and its new integration with Microsoft 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 cmdlets “Get-ViewVC” can be used to retrieve information about the current vCenter connection with:



The “createRampFactor” and “deleteRampFactor” values represent the current settings for the “Max concurrent provisioning operations” and the “Max concurrent power operations” respectively.


Remove vCenter

It is possible to remove a vCenter listing from the View server with the cmdlets:

Get-ViewVC -serverName | Remove-ViewVC

However, the cmdlets will return an error and fail to complete if there is any desktop pool that utilitises the vCenter connection you are trying to remove. Additionally, any Transfer Server would also have to be placed in maintenance mode and removed. Transfer servers are virtual machines, and are automatically discovered by the vCenter and View servers relationship.


So to remove a vCenter reference you may have to remove the pools it offers as well and its references to Transfer Servers.

Add a vCenter to View

In a large environment you may have a number of vCenter servers to add into View. This can be achieved more efficiently using the Add-ViewVC cmdlets like so:

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

This would add in the vCenter and using the option –useComposer also enable the View Composer Linked Clones component, using the same credentials as the vCenter. Of course for this to work, View Composer would have to be installed to the vCenter in New Jersey.

Creating Desktop Pools

Using the Add-AutomaticPool and Add-AutomaticLinkedClonePool cmdlets you can create virtual desktop pools and linked cloned virtual desktop pools respectively. As you might imagine with all the settings in View the number of possible sub parameters is quite dizzying. This can be a problem when it comes to documentation like this guide – because the strings become very long and difficult to read. So what you will see is us putting a long command as a series of lines. To create a desktop pool you need to provide at least 6 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 by querying an existing pool with:

get-pool -pool_id “AcctsDesktopWin7”

This will give you an output like so:

pool: 0

pool_id: AcctsDesktopWin7


displayName: Accounts Desktop - Windows 7

enabled: true

folderId: /

deliveryModel: Provisioned

multiSessionAllowed: true

userResetAllowed: true

assignOnFirstLogon: true

desktopSource: SVI

powerPolicy: RemainOn

vc_id: de48f01b-80c9-4105-9c7c-328a197bfb67


parentVMPath: /NYC DataCenter/vm/Virtual Desktops/AcctsParentVM

parentVMSnapshotPath: /Base Snapshot

parentVMSnapshotMOID: snapshot-953

refreshPolicy: type=Never;

persistentDiskSpecs: [DiskSize=4096;DiskUsage=SystemDisposable;UseSparse=true;MountPoint=*;]

datastoreSpecs: [Conservative,OS,data]/NYC DataCenter/host/AMD Hosts/Cluster1/acctsvirtualdesktops

usevSphereMode: true

composer_ad_id: 2cb74a72-1eb5-4b2c-8290-4bd4ba56c576


composerDomainUser: corp\administrator

organizationalUnit: OU=Accounts,OU=View Desktops

provisionEnabled: true

provisionSuspendOnError : true

postProvisionState: READY

startClone: true

calculatedValues: true

deletePolicy: Default

headroomCount: 1

maximumCount: 4

minimumCount: 1

datastorePaths: /NYC DataCenter/host/AMD Hosts/Cluster1/acctsvirtualdesktops

datastoreDisplayPaths: /NYC DataCenter/host/AMD Hosts/Cluster1/acctsvirtualdesktops


resourcePoolPath: /NYC DataCenter/host/AMD Hosts/Cluster1/Resources/Virtual Desktops/Accounts Desktop

resourcePoolDisplayPath : /NYC DataCenter/host/AMD Hosts/Cluster1/Resources/Virtual Desktops/Accounts Desktop

vmFolderPath: /NYC DataCenter/vm/Virtual Desktops/AcctsDesktopWin7

vmFolderDisplayPath: /NYC DataCenter/vm/Virtual Desktops/AcctsDesktopWin7

namePrefix: acctsdesktop

persistence: NonPersistent

autoLogoffTime: Never

poolType: SviNonPersistent

markedForDelete: 0

protocol: PCOIP

allowProtocolOverride: true

flashQualityLevel: NO_CONTROL

flashThrottlingLevel: DISABLED

Notice how the paths to various vCenter inventory locations begin with a leading / character such as “/NYC DataCetner/Host/AMD Hosts…”. That had us stumped for days.

It’s possible to see some of these settings in the graphic UI as well. If you look at the “vCenter Settings” on the properties of an existing virtual desktop:


Whilst the get-pool cmdlets is helpful for learning more about the parameters, you can get tripped up with these if you are not careful. For example to list all the pools configured with Microsoft RDP as a default the cmdlet would be:

Get-Pool -protocol RDP

Now you would think to change it, it would be –protocol PCOIP. WRONG! Actually, the flag is –defaultProtocol PCOIP when use the cmdlet to create a new virtual desktop pool. Elsewhere in the list of attributes there is the option to set allowProtocolOverride $false. This works perfectly fine. So the attribute names on list – well sometimes they work and sometimes they don’t. Nice!

Creating Pools

One of our first examples of pools was a manual pool where an existing single VM is given to a specific user or even a group of users. This used to be referred to as a personal desktop in previous releases but was depreciated as a feature and a concept in View 4.5.

Creating Manual Pools (Personal Desktop)

It possible to create manual “pools” from existing virtual desktops that you have created before the introduction of VMware View. Earlier in this book we showed how you could still effectively create a “personal desktop” by using this option. To do the same with the View PowerCLI, you use the Add-ManualPool cmdlets, together with Get-DesktopVM to find the existing VM with vCenter.

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

The –isUserResetAllowed $true value controls whether the user can reboot their virtual desktop using the View Client toolbar, as such it’s an optional component.

Creating a Dedicated Pools

To create a dedicated pool you use the Add-AutomaticPool cmdlets. As you can see it’s an extremely long command string. We have introduced breaks into the string to assist in its readability. Some of the most common errors with these commands is the path statements containing typos or point to objects by the wrong name. For example in below it failed for us because the name of our template was win7en32 not win7en64, and couldn’t find the datastore called “studentvirtualdesktops” because we’d umounted it!

Get-ViewVC -serverName | Add-AutomaticPool -pool_id StudentsGroupWin7 -displayName "Students Windows 7 Desktop" -namePrefix "students"

-vmFolderPath "/NYC DataCenter/vm/Virtual Desktops"

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

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

-dataStorePaths "/NYC DataCenter/host/AMD Hosts/Cluster1/studentvirtualdesktops"

-customizationSpecName "Windows 7"

-maximumCount 10 -headroomCount 5 -minimumCount 2


Hopefully, most of the above make sense. I’ve asked for a pool with an internal ID of StudentsGroupWin7 and friendly name of Student Windows 7 Desktop, and when they are sysprep’d they will be given a NetBIOS name of students1,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 location in vCenter needed for a virtual desktop pool to be created. The last three parameters control the sizing of the desktop pool with a maximum of least 10 virtual desktops and no more. The default is that this would be a dedicated pool and provisioning would begin as soon as entering the command.

Important: Hopefully, you can see there’s a limitation here. The cmdlets for View currently don’t allow me to use the whole PowerCLI cmdlets. So I could not replace the line -resourcePoolPath "NYC DataCenter/host/AMD Cluster1/Resources/Virtual Desktops/Sales Desktops" with get-resourcepool “Sales Desktops”

TIP: If you are experimenting with the View PowerCLI and creating pools, you may not kick off a full blown provisioning process with every attempt you try, especially if the systems storage backend is limited in capacity or IOPS. You can switch off automatic provisioning by using the -isProvisioningEnabled $false parameter. This is the same as removing the checkbox when you run through the GUI Wizard.


Creating a Floating Desktop Pools (with Automatic Deletes)

If I wanted a “floating” pool that deleted the virtual desktop when the user logged out – I would add the – persistence and –delete policy flags to a similar command like so:

Get-ViewVC -serverName | Add-AutomaticPool -pool_id StudentsGroupWin7 -displayName "Students Windows 7 Desktop" -namePrefix "students"

-vmFolderPath "/NYC DataCenter/vm/Virtual Desktops"

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

-templatePath "/NYC DataCenter/vm/_Templates/win7en64" -dataStorePaths "/NYC DataCenter/host/AMD Hosts/Cluster1/studentvirtualdesktops"

-customizationSpecName "Windows 7"

- persistence NonPersistent – deletePolicy DeleteOnUse

Creating Linked Cloned Pools

I’ve got something here. But it errors.

Get-ViewVC -serverName | Get-ComposerDomain -domain CORP | Add-AutomaticLinkedCLonePool -pool_id SalesGroupWin7 -displayName "Sales Windows 7 Desktop" -namePrefix "sales" -vmFolderPath "/NJ DataCenter/vm/Virtual Desktops" -resourcePoolPath "/NJ DataCenter/host/Intel Hosts/Cluster1/Resources/Virtual Desktops/Sales Desktops" -parentVMPath "/NJ DataCenter/vm/Virtual Desktops/SalesParentVM" -parentSnapshotPath /AutoPoolSnapshots/parent1_snapshot -datastoreSpecs [Aggressive,os,data]/NJ DataCenter/host/Intel Hosts/Cluster1/sales -dataDiskLetter "D" -dataDiskSize 100

Updating Pool Settings

All the off “add-“ style cmdlets which are used to add pools of various types each come with their own “Update-“ style cmdlets which are used to modify the pool or pools after they have been defined such as the Update-AutomaticPool, Update-AutomaticLinkedCLonePool and Update-ManualPool. Let’s say you want to change the default away from PCoIP Protocol, and to set Microsoft RDP as the standard – and at the same time disable the user’s ability to choose the protocol on a Automatic Pool. The command would be like this:

Update-AutomaticPool -pool_id SalesGroupWin7 -displayName "Sales Windows 7 Desktop" -dataStorePaths "NYC DataCenter/host/AMD Cluster1/virtualmachines" -allowProtocolOverride $false -defaultProtocol RDP

Deleting Pools

It is also possible to delete pools using the View PowerCLI. It’s a relatively simple process, the main question is whether you merely want to unlist the pool from View, or whether you actually want to logoff existing users, and delete the pool and all the VMs as well.

Remove-Pool -pool_id SalesGroupWin7 -DeleteFromDisk $true -TerminateSession $true

Managing User Assignments

Add & Remove User and Group Assignments

Now we have a good handle on creating virtual desktops of the various types, its time to consider allocating the user assignments that would actually allow the desktop to be accessible. In terms of discovering more about your users and groups in AD the ViewCLI is pretty limited. For example it only queries AD for users, and their group membership – it doesn’t allow for querying groups, to check membership lists. I guess this isn’t the end of the world, if you want really powerful AD cmdlets that’s what the Microsoft PowerShell is for. Nonetheless, if you did want to know more about a specific user via the ViewCLI you could use the following:

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


To add the MikeL user to his personal desktop you can use:

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

At the time of writing – corp\mikel, corp/mikel, currently all create an error. The official documentation that I’m working from indicates corp\mikel should work but it doesn’t. However as you can see from above –name <username> -domain <domainname> does work.

To assign a group of users to a pool, it’s 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 you would use:

Get-PoolEntitlement -pool_id SalesGroupWin7 | Remove-PoolEntitlement

Viewing User & Group Assignments

The Get-PoolEntitlement can be used to print a report of the current entitlements on a pool.

Get-PoolEntitlement -pool_id SalesGroupWin7

Of course if you wanted a complete report of all the pools and their current assignments you could simply use:

Get-PoolEntitlement -pool_id *


Managing User Sessions

You can get a list of currently connected users by using the

Get-RemoteSession -username *


Notice how the info shows a “clock skewed”. This was because the some of the hosts within the cluster had NTP configured but had not started properly. Therefore there was clock drift between the connection server and the virtual desktop.

To query for user by name we use the following syntax:

Get-RemoteSession -username\mikel


Whilst VMware’s use of PowerCLI is generally welcome, this implementation for View leaves a lot to be desired. At times it feels more like a command-line tool that you would get from the vCLI or from ESX console – rather than being a genuine implementation of a PowerShell environment. It’s our hope that VMware will invest further R&D in it to make it as functional as their PowerCLI for vSphere5. In the meantime in the absence of any other automation for View, it’s the best thing around at the moment.

Our next chapter is an overview of VMware’s application virtualization technology – ThinApp. If you think about it, this whole book has focused on the process of putting together a virtual desktop infrastructure – without looking at the most important thing – the applications the users will run within it. Of course, there’s nothing stopping you installing software to your core template or parent VM in a linked clone. We feel increasingly that the virtual desktop or Windows is merely a container; a shell from within which you can run applications. The less you install to this container, and the more you merely stream applications to it the better. This is part of an increasing move to “layering” the desktop environment – separating out the OS, Apps and the User Persona – essentially virtualizing the components that make up the desktop. This should allow for great flexibility, compatibility and portability. As the desktop as user world becomes less significant having your applications ThinApp’s makes them accessible through other methods such as ThinApp Factory and VMware Horizon Application Manager.

We will use the ThinApp chapter as a jumping off point to look at the future of application delivery using a raft of new technologies from VMware. Some of these are very new, or even yet to be released. But they are a tantalizing vision of how we might be delivering applications later in this decade. In fact we might begin to see virtual desktops as merely a stepping-stone to this new approach.