During my recent presentation at the 20th VMUGBE+ session, I showed different ways to run View PowerCLI cmdlets and scripts.
Several of the methods I showed, are already discussed on other blogs (to which I will include the links of course), but there is a new PowerShell feature that hasn’t been used until now (afaik).
And since I never found a complete overview of all the available methods, I decided to create this post.
Method 1 – On a Connection Server
Method 1A – From the View PowerCLI prompt
This is the most straightforward method, and also the first one shown in the View documentation. You start a View PowerCLI session through the provided Start menu shortcut, or you start a plain PowerShell session and make sure the VMware.View.Broker PSSnapin is loaded.
Note that the View PowerCLI PSSNapin has a problem when you use it in a PowerShell v3 (or higher) engine. A bypass for this problem is to start the PowerShell engine in Version 2 mode.
One way of doing that is by adding a parameter to the View PowerCLI shortcut in the Start menu. The following short script will update the Start menu entry to do this.
1 2 3 4 5 6 7 8 9 10 11 12 |
$extraArgument = "-version 2 " if($PSVersionTable.PSVersion.Major -gt 2) { $relativePath = "VMware\View PowerCLI.lnk" $shell = New-Object -com "WScript.Shell" $start = $shell.SpecialFolders.item("AllUsersPrograms") $shortcut = $shell.CreateShortcut("$($start)\$relativePath") if($shortcut.Arguments -notmatch $extraArgument){ $shortcut.Arguments = "$($extraArgument)$($shortcut.Arguments)" $shortcut.Save() } } |
The shortcut will have an extra argument, the Version parameter, after you run the script on your Connection server.
A short demo of this
Method 1B – As a PowerShell background job
An alternative, that uses the same concept, is to run your View PowerCLI cmdlets and script as background jobs, and use the PSVersion parameter.
This method was described by Andre Leibovici in his How to use VMware View PowerCLI with PowerShell 3.0 post.
A short demo of this method
The major disadvantage of this method in all it’s forms, is that you are logging on to a Connection Server and running your script interactively on the server. Something that might not be permitted in a production environment.
Another disadvantage, is that while you are running in a Version 2 engine, you will not have access to any of the PowerShell v3 (or higher) cmdlets.
Method 2 – Remote Session
The first mention of using a PowerShell Remote Session to run View PowerCLI cmdlets and scripts comes from Alan Renouf in his Using the View PowerCLI cmdlets from another machine post.
Andre Leibovici did a post on this concept later on in his Remote use of VMware.View.Broker PowerCLI post. The great novelty that he introduced there, was that he uses PowerCLI’s Invoke-VMScript cmdlet to configure the winrm settings on the Connection server.
But neither of these posts seems to mention that you need PowerShell v1 or v2 on the Connection Server. And with the New-PSSession cmdlet you do not have the option to pass a Version parameter.
In PowerShell v4 the PSSessionConfiguration concept was introduced. With the Register-PSSessionConfiguration cmdlet you create and register a session configuration on a computer. With this we can solve the requirement that the View PowerCLI PSSnapin needs PowerShell v1 or v2.
We can define a PS v2 configuration on the Connection Server remotly like this. Note that this assumes that remote sessions to the Connection server are already configured. If not, you can use Andre’s PSRemoteSession-Configure function to do that.
1 2 3 4 |
$PS2 = {Register-PSSessionConfiguration -Name PS2 -PSVersion 2.0 -Confirm:$false} $session = New-PSSession -ComputerName view1 Invoke-Command -Session $session -ScriptBlock $PS2 Remove-PSSession -Session $session |
Once this session configuration is defined, we can run our View PowerCLI cmdlets and scripts like this
1 2 3 4 |
$session = New-PSSession -ComputerName view1 -ConfigurationName PS2 Invoke-Command -Session $session -ScriptBlock {Add-PSSnapin VMware.View.Broker} Invoke-Command -Session $session -ScriptBlock {Get-Pool} Remove-PSSession -Session $session |
A short demo
No more holding back on your PowerShell updates on the Connection servers.
A closing thought; the fact that the View PowerCLI PSSnapin officially still requires PowerShell v1, is to say the least annoying. Perhaps the team that develops the View PowerCLI PSSnapin could put PowerShell v4 support, and a few other improvements I will gladly share with them if needed, on their New Year’s resolution list 😉
Enjoy !
Ashish Srivastava
Hi,
In Horizon View, i am trying to pull get-desktopvm using VMInvoke command from powerCLI using different admin account under domain controller. (please disregard default admin, it works with default admin but i don’t want to go with default one)
but i am getting error like “NODE manager not running ” & “View Server connect FAILED”.
i have given full admin rights to new user account, but no joy.
here is script data.
#$DRVM = “Horizon_View6_35”
$ScriptBlock = [scriptblock]::create(‘
add-pssnapin vmware.view.broker
get-desktopvm
‘)
$HZNuser = “XYZ”
$HZNpass = “XYZ”
Invoke-vmscript -vm $DRVM -scripttext $scriptblock -guestuser $HZNuser -guestpassword $HZNpass
i am getting below error.
VM : VDI_HorizonXX
ExitCode : 0
ScriptOutput : get-desktopvm : View Server connect FAILED
At line:3 char:1
+ get-desktopvm
+ ~~~~~~~~~~~~~
+ CategoryInfo : NotInstalled:
(vmware.view.pow…ts.GetDesktopVM
:GetDesktopVM) [Get-DesktopVM], Exception
+ FullyQualifiedErrorId : Node Manager not
running,vmware.view.powershell.
cmdlets.GetDesktopVM
Thanks,
Ashish
Yvan Comte
Hi Luc
I am struggling with automating the removal with deletion of a View Machine from View cmdlet. This is available from the /admin View GUI and it delete completely a View machin inclusing in the vsphere environment. I am simply not able to find the right command (e.g. remove-desktopVM)
Thanks for any hints
yvan
Bertram
Hi Luc,
that post is very helpful. I have an other question. Do you have experience with the commands for adding an RDSH to Horizon View. We tested the Add-TerminalServerPool and Get-TerminalServer in new or existing environments, but we neither were able to add a terminal server nor to get information about an existing RDSH. Is there a known issue using this commands?
Bert