Perhaps it is because I began my professional coding career writing device drivers for Unix systems in C, back in the 1980s on character based green screens (80 columns x 24 lines!), that I prefer managing IT systems from a command line over a GUI. I am not a masochist, I really do find a lot of operations easier and quicker from a PowerShell prompt than by using a (proprietary) user interface, even if it does run in a web browser.

PowerShell itself brings some additional, generic, benefits over something less modern like a command prompt (cmd). Note that the latter is not a "DOS" prompt – it might look like it but so can a PowerShell prompt and DOS days are long gone although it is still available for download from Microsoft, via Visual Studio Subscriber (formerly MSDN) downloads, and there has even recently been a new release of FreeDOS!

The PowerShell benefits include:

• Searchable command history, via ctrl+r, which persists across sessions and reboots as long as you have a persistent Windows user profile. If you have used a command line before, you should be able to find it again, changing parameters if necessary.
• Tab completion of cmdlets (PowerShell commands and functions), both the cmdlet and parameter names, coupled with approved verbs like get and set, means you only need to roughly know what the command is called or you can use Get-Command with wildcards.
• Ctrl+space – it is tab completion on steroids!
• Built in help for cmdlets or look them up online using the -Online parameter with Get-Help (or just type "Help" as PowerShell will look for a cmdlet prefixed with verb "Get" if what you specify is not a cmdlet, function, or alias in its own right)

PowerCLI is the name VMware have given their PowerShell modules – note the use of the plural as there are more than seventy separate modules which gives rise to a tip which is to only import the modules required rather than all of them since the latter can be time consuming. PowerCLI spans all of VMware’s products but in this article, I will just be covering vSphere although much of what is in here also applies to non-vCenter ESXi too.

Knowing how to drive VMware vSphere via PowerShell can make you a much more efficient admin and easily leads to automation where you can set tasks to run whenever you need them without any manual intervention – great when your change window is in the middle of the night.

In this first of a series of blog posts on VMware, we will cover the installation and connection aspects as these have a number of practical gotchas that may catch you out – so I’m hoping to make your transition to managing and controlling VMware as stress free, and quick, as possible.

Installing & upgrading PowerCLI

You might have thought that this would be a one sentence section – Install-Module (with -Scope as required to install for all users if running elevated) – but there are some gotchas that I will put here to help save people time and frustration if they hit the issues.

Recent versions of PowerCLI have caused this error:

This is because the certificate provider VMware used to sign the modules has changed and PowerShell does not seem to cater for this. This can be fixed by using Uninstall-Module or deleting the folders for the VMware modules e.g. in "$env:ProgramFiles\WindowsPowerShell\Modules"

If you already have the Microsoft Hyper-V PowerShell module installed, you will get this error:

Using -AllowClobber will not overwrite the Hyper-V, so it can still be used, but you need to be careful that you execute the correct cmdlets such as Get-VM. This can be done in several ways:

• Remove-Module -Name Hyper-V -ErrorAction SilentlyContinue
• VMware.VimAutomation.Core\Get-VM (module qualification)
• "Import-Module -prefix vmware_" and run Connect-VMware_viserver, Get-VMware_vm and so on

If you need to install the modules on a non-Internet connected machine, copy the module folders from a machine which is connected and has already installed the required modules.

Connecting

We connect to one or more VMware vCenter or VMware ESXi servers using the Connect-VIserver cmdlet. If no credentials are explicitly passed as parameters, pass through authentication will be attempted as the user running the cmdlet. If this is not possible, the preference is to use the -credential parameter rather than passing credentials in clear text since these will be persisted, insecurely, in the PowerShell history file.

A number of warnings may be displayed which can be suppressed beforehand, individually, via Set-PowerCLIConfiguration and -Force can be specified to Connect-VIserver which suppresses all user interface prompts.

Credentials can be stored using the New-VICredentialStoreItem cmdlet and they will be automatically passed to Connect-VIserver when there is a stored credential for that server. Note that passwords can be retrieved from these stored credentials but only when running as the user that created them on the machine where they were created.

Connect-VIserver returns a connection object so test that this is not $null before continuing with operations.

Do not forget to call Disconnect-VIserver, with the same server(s) parameter or pipe in the connection object returned by Connect-VIserver, when finished. You may want to also specify -confirm:$false since by default it will prompt for confirmation.

If you have multiple VMware vCenters, you can specify the -AllLinked parameter to connect to them all such that operations run against all of them by default but if they are not linked, you can still connect to them all in one call to Connect-VIServer by specifying them as a comma separated list to the -Server parameter, which is presented as an array to the cmdlet. In fact, we can easily tell the type of a particular parameter without having to resorting to RTFM by getting a list of all the parameters by typing the cmdlet name followed by the minus sign and hitting ctrl space. Cursor keys then allow you to have to the parameter you are interested in, and it will show the type in the bottom left like this:

Be careful if you connect to a vCenter and an ESXi server directly as you may get duplicate objects returned.

Conclusion

In this post you have seen how you can install the VMware PowerCLI module and connect to VMware vCenter or VMware ESXi and some of the gotchas you may hit. In the next, exciting, episode I will show you the many kinds of operations that can be performed once connected.

Related links

• ScriptRunner ActionPacks for VMware
• Setting up a VMware vSphere PowerCli Module (from our Trial Guide) 
• Link to VMware PowerCLI Documentation
• ScriptRunner: Try out our Software for free and download the Trial Version