PowerCLI 11.0 is Out – Easy Update and Features Galore!

PowerCLI fans unite and celebrate as the launch of the latest edition is now public.  If you’re a reader of my blog then there is a good chance you probably found me from PowerShell or PowerCLI  content which also is a hint of much more to come in the next while.

The first thing you will want to do as the new release is out is to make sure you get your install up to date.  If you haven’t already deployed PowerCLI using the modular approach and get past a couple of common gotchas with these blogs.

This is the list of added goodness as shared from the official PowerCLI blog on the update

  • Added a new Security module
  • Added new cmdlets for Host Profiles
  • Added a new cmdlet to interact with NSX-T in VMware Cloud on AWS
  • Support for vSphere 6.7 Update 1
  • Support for NSX-T 2.3
  • Support for Horizon View 7.6
  • Support for vCloud Director 9.5
  • Multiplatform support for the Cloud module
  • Updated the Get-ErrorReport cmdlet
  • Removed the PCloud module
  • Removed the HA module

These are handy as you get rolling with the most recent versions of vSphere and if you are a vCloud Director fan.  The security updates are probably the most prominent with the update to adding more with both native vSphere 6.7 Update 1 and the vSphere Platinum edition.

Running the Update using Update-Module in PowerShell

This example here shows how to easily update using PowerShell Module management which I’m showing from a Mac OSX installation.

You want to check to see which version you have first which is done using the Get-Module -Name VMware.PowerCLI first:

That confirms our current version.  This happens to be running 10.1.1 before the update.  All you have to do to get the latest update is run the Update-Module -Name VMware.PowerCLI and walk through the prompts. You will be asked about whether to trust the repository or not (spoiler alert:  you have to say Yes)

NOTE: If you’re reading this after future updates beyond 11.0 then you will get the latest edition available at that time from the PSGallery.

Here’s a quick 2 minute video to show you the install in action!

Happy Scripting!

Using VMware PowerCLI with Self-Signed TLS/SSL Certificates on vCenter

PowerCLI is one of the more popular scripting environments for VMware administrators and architects around the world, with good reason. It’s also something that newcomers to VMware environments often shy away from when errors are encountered.

Hoping to save you some time and a few clicks by sharing the most common first error that admins may bump into.  Many VMware vCenter environments are using self-signed TLS (aka SSL) certificates.  This is very common, especially with home labs.

My PowerCLI Won’t Connect to vCenter!!

The default configuration for PowerCLI is to require the use of a secure channel and to verify the certificate chain.  When first connecting to your vCenter without a certificate, or with a self-signed certificate, the command is super simple:

Connect-VIServer -Server YOURSERVERFQDN

Here is what happens:

The clear error condition shows that states “Could not establish trust relationship for the SSL/TLS secure channel with authority” for the FQDN (Fully Qualified Domain Name) of my vCenter server.

There is a simple fix for this.  The caveat with this fix is that you must be aware that you are enabling connections from PowerCLI to unsigned certificates.  As long as you are able to trust the target environments, this setting should be agreeable.  It must be noted just for the sake of proper security practices which should require the use of publicly signed or internally signed and validated TLS certificates.

Fixing TLS Errors for PowerCLI with the Ignore InvalidCertificateAction option

The configuration that needs to be set is the InvalidCertificateAction parameter.  When set to the default it will deny access.  The parameter must be changed by setting InvalidCertificateAction to Ignore which does not do a certificate check before performing actions using TLS.

The command is as follows:

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -confirm:$false

The resulting table shows the new parameter set as Ignore and now the Connect-VIServer will succeed even with our self-signed or invalid TLS certificate in place:

Hopefully this saves you some difficulty if the issue has stopped your PowerCLI from working as expected.

Installing PowerCLI 6.5.x on Windows Server 2012 R2 after Find-Module Error

Now that PowerCLI is part of the PowerShell Gallery, you can install it using the native module installer…but there’s a catch. Windows Server 2012 R2 requires a couple of minor updates to get this process underway. You’ll know really quickly if you open up your PowerShell terminal or PowerShell ISE (as Administrator) and try the following command:

Find-Module -name VMware.PowerCLI

The issue is easily solved be deploying a more recent installer for the PackageManagement PowerShell Modules. Download the installer using this link and run the install:


Select the Download within the page once you’re there:

Choose the x64 version (assuming you’re running a 64-bit OS):

Run through the installation and accept the defaults. Nothing significant to worry about with this file as it’s a necessary update for what we need to do.

If you run the Find-Module command again, you’ll see a much better result. You’ll be prompted to update your NuGet components which are used to pull resources from the PowerShell Gallery. Accept the update and then we can keep going:

Time to get back to the issues. Just relaunch your PowerShell terminal or ISE as an Administrator. We are running as Administrator so that we install the module for all users of the server. If you only want to run for your user then run your PowerShell session as your regular user and add -scope CurrentUser to the Install-Module command. Run the following to install for all users:

Install-Module -name VMware.PowerCLI

Now we have to import the module into our session using the Import-Module -name VMware.PowerCLI command:

Just like that, you’re up to date and running the latest and greatest PowerCLI goodness. Happy scripting!

PowerCLI: Enabling and Disabling SSH on vSphere hosts

I’m all about running PowerCLI to replace GUI management. Every once in a while there is a requirement to access the ESXCLI on my vSphere hosts, and this is a classic task that is a multi-click process and if you’re using the old 4.x or 5.0/5.1 web client, you may find the process very tedious.

PowerCLI to the Rescue

My suggestion is that the first window you should open up on your workstation each day, and that is the PowerCLI shell to do your VMware administrative work. Here is a great way to use that nifty little shell.

First, let’s walk through the process that we need to follow.

  1. Attach to your vCenter server
  2. Query your cluster to find the hosts
  3. On each host, enable SSH by starting the TSM-SSH service

On paper, it looks pretty easy. The surprising thing is that in PowerCLI it is just as easy as that 3 point list. Even more exciting is the fact that we are going to use the magic of the pipeline to create a one-liner for the whole process.

So for item number one you will most likely do this when you launch your PowerCLI shell. This is done with the Connect-VIServer CmdLet:

Connect-VIServer <yourvCenterHost>


This will prompt you for credentials as you can see here:


Now we are authenticated and we can move to step 2 which is to query the cluster. The Get-Cluster CmdLet is just what the doctor ordered:

Get-Cluster -name <yourclustername>


This returns the name of the cluster and nothing more. So let’s add in a pipe to a Get-VMHost CmdLet to get back a list of our vSphere hosts in that cluster:

Get-Cluster -name <yourclustername> | Get-VMHost


Alright, we have gotten to this point which is where it gets a little tricky. Now we have to turn on the TSM-SSH service on each host, but because we have our hosts in a pipeline, we need to get a little bit fancy.

Starting SSH with PowerCLI on One Host

We have to walk before we run, so the first thing we need to do is understand how to turn on SSH on one host, and then we can use that method to apply to each host from the query that we got from step 2.

This section has some challenges because we are going to do a Start-VMHostService using results from a Get-VMHostService using results from a Where clause query. That’s a bit weird sounding, so let’s just get to the code and it should make sense.

Start-VMHostService -HostService ($_ | Get-VMHostService | Where { $_.Key -eq “TSM-SSH” } )

Hopefully it makes sense when it’s written out like that. The command blocks are in parentheses which should help to differentiate each section. The great thing about PowerCLI and PowerShell is that you can run a CmdLet and pipe content into it from another query and you can even nest queries which is both awesome and confusing.

With our nice nested query in place, we just have to make this run for each of our hosts in the cluster that we queried. Hmmm…how would we do this for each of the hosts (HINT: The CmdLet is right there for us!)

Gluing it all together with our ForEach Loop – The Final One-Liner

The command line has come together easily now in bits and pieces. The last step is to put it all together into a single command line:

Get-Cluster | Get-VMHost | ForEach {Start-VMHostService -HostService ($_ | Get-VMHostService | Where {$_.Key -eq “TSM-SSH”})}

Make sure that you keep track of the opening and closing brackets there because some of them are curly and some are round brackets.

Let’s see the results!


Reversing the Process to Stop the SSH Services

Using the very same logic, we can replace the Start-VMHostService CmdLet with the Stop-VMHostService CmdLet and the SSH services will be stopped which is the default configuration for our vSphere hosts.

Get-Cluster | Get-VMHost | ForEach {Stop-VMHostService -HostService ($_ | Get-VMHostService | Where {$_.Key -eq “TSM-SSH”})}

One More Thing


If you ran the Stop-VMHostService one-liner you will notice that you are prompted in the shell to confirm the action for each host:


Assuming you know what it is that you are doing with this process, there is one simple parameter to drop into the command line on the Stop-VMHostService section which is -Confirm:$FALSE as we see here:

Get-Cluster | Get-VMHost | ForEach {Stop-VMHostService -HostService ($_ | Get-VMHostService | Where {$_.Key -eq “TSM-SSH”}) -Confirm:$FALSE}


Now that we have that command together, we can start and stop SSH on our clustered hosts with ease. You can also do the same for a list of non-clustered hosts by removing the Get-Cluster and the first pipe symbol.

Happy SSH-ing!