Home > Blogs > VMware PowerCLI Blog

PowerCLI Docker Image Updated

With the official releases of PowerShell 6 Core and PowerCLI 10.0, I am happy to announce that the PowerCLICore Docker image has been updated with all the latest packages!

In the new build, we’re running the latest PhotonOS container, more streamlined than ever! Our PhotonOS team has been hard at work making it easy to install PowerShell on PhotonOS v2:

In addition to the latest PowerShell, we’re installing PowerCLI 10, PowerNSX, and PowerVRA from the Microsoft PowerShell Gallery, making future updates extremely easy!

The PowerCLI Example Scripts are in there too! The modules are installed and ready to use, and the example scripts from the community are in /root.

So what are you waiting for? Take it for a spin today!

New Release: VMware PowerCLI 10.0.0

We are only two months in to 2018, but it has already been pretty exciting from an automation standpoint. Let’s review some of the big news. Microsoft open-sourced and released PowerShell 6.0. They also made it available on a number of operating systems, from Windows to Linux to Mac OS. Then, PowerCLI hit 2,000,000 downloads from the PowerShell Gallery! Today, we are releasing VMware PowerCLI 10.0.0!

Let’s talk about the version change for a second. If you’ve been a PowerCLI user for a couple years, you have probably noticed quite the transformation here recently. One item of note was when the name was changed from vSphere PowerCLI to VMware PowerCLI. This was due to PowerCLI’s ability to manage more than just vSphere. With this release, we are taking that next step to remove ourselves from being in lockstep with vSphere’s versioning. Why did we go with 10? Well, PowerCLI recently celebrated its 10th birthday so it seemed like the perfect number!

Time to take a look at everything that’s new!

Multi-Platform Support

PowerCLI 10.0.0 adds support for Mac OS and Linux! The only pre-requisite is to have PowerShell Core 6.0 installed. The installation process is also the same:

PowerCLI 10 Install Example on a MacOS System

This release brings support for the following modules:

  • VMware.VimAutomation.Cis.Core
  • VMware.VimAutomation.Common
  • VMware.VimAutomation.Core
  • VMware.VimAutomation.Nsxt
  • VMware.VimAutomation.Vds
  • VMware.VimAutomation.Vmc
  • VMware.VimAutomation.Sdk
  • VMware.VimAutomation.Storage
  • VMware.VimAutomation.StorageUtility

Future releases of PowerCLI will continue to add support for the remaining modules.

Default Certificate Handling

This version changes the way certificates are handled when connecting to a vCenter server or ESXi host with the Connect-VIServer cmdlet. If your connection endpoint is using an invalid certificate (self-signed or otherwise), PowerCLI would previously return back a warning. The handling has been updated to be more secure and now return back an error.

If you are using an invalid certificate, you can correct the error with the ‘Set-PowerCLIConfiguration’ cmdlet. The parameter needing to be configured is ‘InvalidCertificateAction’ and the available settings are Fail, Warn, Ignore, Prompt, and Unset.

The following code will configure the ‘InvalidCertificateAction’ parameter to be Ignore:

Deprecated Cmdlets and Property

There are five cmdlets being deprecated. These cmdlets are found in the VMware.VimAutomation.Core module. They are:

  • Get-VMGuestNetworkInterface
  • Set-VMGuestNetworkInterface
  • Get-VMGuestRoute
  • New-VMGuestRoute
  • Remove-VMGuestRoute

These cmdlets are replaced with the use of the Invoke-VMScript cmdlet.

Sample code to change the IP Address of a Windows VM:

One other deprecation is to the Client property. If you have any scripts that are making use of the ‘Client’ property, you’ll want to get those updated to use the ServiceInstance managed object. More information can be found at the following: ServiceInstance

Resolved Issues

First, I want to thank the community for this section. There was an overwhelming amount of feedback that came in and I’m quite excited about how many items we were able to get resolved! Let’s check some of them out:

  • Piping the Get-Datacenter cmdlet output to Get-Cluster now works when more than one datacenter is present
  • Configuring manual MAC addresses with the New/Set-NetworkAdapter cmdlet now accepts all addresses, not just MAC addresses in the 00:50:56 range
  • VMs with snapshots can be Storage vMotioned to VMFS6 datastores without hitting a ‘redoLogFormat’ error
  • Lots of updates to the Get-TagAssignment cmdlet, including when connected to two vCenter Servers and also displays the Tag Category as expected


Today, we release PowerCLI 10.0.0. This release adds support for PowerShell Core 6 which can be run on Linux and Mac OS systems. There are also a handful of VMGuest related cmdlets which have been removed from the release. Their functionality can be replaced with the usage of Invoke-VMScript. Lastly, there have been several corrections. Many of which are thanks to our amazing community for bringing them to our attention.

Remember, updating your PowerCLI modules is now as easy as:

For more information on changes made in VMware PowerCLI 10.0.0, including improvements, security enhancements, and deprecated features, see the VMware PowerCLI Change Log. For more information on specific product features, see the VMware PowerCLI 10.0.0 User’s Guide. For more information on specific cmdlets, see the VMware PowerCLI 10.0.0 Cmdlet Reference.

Getting Started with the VMware Cloud on AWS Module

VMware Cloud on AWS is a new on-demand service that enables you to run applications across vSphere-based environments plus access to a broad range of AWS services. PowerCLI already helps to automate your VMware Cloud on AWS tasks! This includes tasks such as creating SDDCs, adding or removing ESXi hosts, managing firewall rules, and so forth.

The VMware Cloud on AWS (VMC) module was released as a low-level, API access only, module and will feature the following cmdlets:

  • Connect-VMC
  • Disconnect-VMC
  • Get-VmcService

Let’s take a look at how we can get started using this new module.

Getting Started

When getting started with the VMC module, we’ll notice immediately that it has a little different authentication process than the other PowerCLI connection cmdlets. This module requires you first acquire the OAuth Refresh Token from the VMware Cloud Console:
Example: VMware Cloud on AWS Console - OAuth Refresh Token

Copy the refresh token, open a new PowerShell session, and connect to the VMC service with the following command:

Now that we are connected, let’s start by doing some discovery. The more you work with this module, and the VMC API as a whole, the more you’ll notice the need to be able to easily recall the organization (Org) ID. Therefore, let’s start by looking into how we can discover information about our org. First, we want to figure out what the service is itself with the ‘Get-VmcService’ cmdlet. Notice that we can use the standard PowerShell filtering and wildcard usage to help make the discovery process a bit simpler. Example code:

Next, we’ll make use of the ‘Get-Member’ cmdlet which will show us the available properties and methods for each issued command. We can pipeline the return from the ‘com.vmware.vmc.orgs’ service to the ‘Get-Member’ cmdlet and discover there’s a ‘Get’ and a ‘List’ method available. Since we don’t have any current information about the Orgs within this environment, we’ll opt for the ‘List’ method. Example code:

Example: Service and Org Discovery

Now that we have our org information, the next thing we will want to discover is information about the org’s SDDC. That information can be found with the following commands:

Example: SDDC Discovery

Notice, there’s quite a bit of information to parse through. Let’s look at a simple way to pull out some information about the SDDC’s ESXi hosts. Example code:

Example: ESXi Host Information

VMware Cloud on AWS uses NSX under the covers to provision all of the networking. Therefore, we will also want to have an understanding of the Edge nodes that are available in the environment. This information is actually in a separate service. Remembering what we’ve done previously, here’s some example code to discover some basic information about the SDDC’s Edge nodes:

Example: NSX Edge Discovery

Another good area to be aware of in your SDDC are the firewall rules. These are also easily retrievable through the ‘Get-VmcService’ cmdlet as well. Example of the firewall rules associated with the edge-2 node:

Example: Firewall Rule Discovery

Last example, let’s do something exciting! How about we automate the creation of an SDDC? This is going to require quite a bit of what we’ve learned so far, plus some new tricks. We can find the ‘Create’ method against the com.vmware.vmc.orgs.sddc service. We see that input requires the Org ID and an ‘sddc_config’ input. This is where it gets tricky.

If we remember back in the PowerCLI 6.5.3 release, there was the addition of the ‘Create’ method to a couple cmdlets. This method is also available with the ‘Get-VmcService’ cmdlet. The whole point of this method is to allow us to create a specification in an easy manner. For this example, we’re reference the ‘sddcSvc’ variable, the ‘Help’ property, then the create property. This shows us a property of ‘sddc_config’. This is the specification we’ll need to use. The ‘sddc_config’ property has this ‘Create’ method available so we can automatically build out the specification. Pretty simple, right?

We’re not quite done quite yet though. Each SDDC can have multiple VPC subnets. Therefore, we also need to populate the spec’s customer_subnet_ids list object with the ‘Add’ method.

Example code:

Example: SDDC Creation

The output above from our last create method is a task object. There’s a service for those too! Since the call we made is asynchronous, you can also have a bit of fun and build a progress checker as well!

Here’s some example code I tossed together while waiting on the SDDC to deploy:

Example: SDDC Creation Progress Output


VMware Cloud on AWS is a fantastic new service that enables you to run applications across vSphere environments as well as accessing a broad range of AWS services. Within this service, PowerCLI is one of the best ways to automate your VMware Cloud on AWS tasks! In this blog post we covered how to discover the available services, explore was methods are available as actions against each of those services, and how to start interacting with those services. We obtained detailed information about our organization, that org’s SDDC and its accompanied configuration including firewall rules, and then had some fun while deploying a brand new SDDC!

Check PowerCLI’s functionality in your own VMware Cloud on AWS environment today and let us know your feedback!

PowerCLI Beta

The PowerCLI Beta containing support for MacOS and Linux is LIVE!

How to participate:

  1. Log in to the VMware Community and read this first!
  2. Join the Community discussions in the beta forum
  3. Join us on VMware {Code} Slack in the #PowerCLI channel!

That’s it for now! Happy Automating!


Windows Defender reports false positive for PowerShell Modules

Over the weekend, Microsoft released a Windows Defender signature file that falsely reports many PowerShell modules, including PowerCLI as containing a virus.

This is a FALSE POSITIVE widely affecting the PowerShell community.


There is no official statement from Microsoft yet, but the PowerCLI community on VMware {Code} has been working overtime! Here’s what you need to do to get back to automating:

  1. Update Windows Defender Signatures to the latest (>= 1.261.424.0 1.261.459.0).
  2. If your PowerShellGet module was affected, you may need to download manually from Github (https://github.com/PowerShell/PowerShellGet)
    1. Update: Kevin Marquette has a pretty good workaround for PowerShellGet, which reverts back it back to
  3. Release the affected files from Quarantine, or reinstall PowerCLI (Install-Module VMware.PowerCLI -scope CurrentUser -force)

This story is still developing, so I will update as the info comes in.

This is a great time for a shout out to the PowerCLI community on VMware {Code}. Special thanks to the PowerCLI users that have been working on this over the weekend and this morning: Luc Dekens, Edgar Sanchez, Wouter Kursten, Scott Haas, and John Kavanagh

You can join the VMware {Code} Slack by signing up here: https://code.vmware.com/join


PowerCLI Offline Installation Walkthrough

Can you believe it? PowerCLI is closing in on a year of being in the PowerShell Gallery! We’re up to 20 different modules and, wait for it, over 2,000,000 downloads of those modules!

VMware Profile on PowerShell Gallery

As exciting as that is, there’s still quite a few questions on how to install PowerCLI to systems that do not have internet access. We’re going to take a much closer look at that with this post.

Preparing the Offline System

First things first, we need to uninstall any prior instance of PowerCLI that was installed by way of the MSI. This can be done by:

  • Open the Control Panel
  • Look beneath the ‘Programs’ section, select ‘Uninstall a Program’
  • Select ‘VMware PowerCLI’, click ‘Uninstall’

Uninstalling Prior PowerCLI Versions

One last thing to check, ensure there is no folder containing PowerCLI as part of the title in the following directory: C:\Program Files (x86)\VMware\Infrastructure\

We can verify whether such a folder exists or not with a oneliner:

Accessing the PowerCLI Modules

We’re now ready to download the PowerCLI modules. This task will require a system with internet access. This section has a couple of variables which depend on the version of PowerShell available on your online system and whether or not you’ve ever accessed the PowerShell Gallery previously by way of the PowerShellGet module.

The easiest way to figure out which version of PowerShell you have is by using the PSVersionTable variable. Based on the output of that, follow the set of instructions below that matches the output.

PowerShell PSVersionTable Output

Online System with PowerShell 5.x:

  • Open PowerShell
  • Use the ‘Save-Module’ cmdlet to download the PowerCLI modules locally. Example:

    • If requested, update the NuGet provider
    • If requested, trust the ‘Untrusted repository’ that is named PSGallery
      Note: This is a local system trust, not something that has something to do with an SSL certificate
  • Copy those downloaded module folders to a location that can be made accessible to the offline system.
    Example: USB Flash Drive, Internal File Share, etc.

Online systems with the older PowerShell versions of 4.0 or 3.0, may need to have an additional module installed to access the PowerShell Gallery. The module is called ‘PowerShellGet’. We can verify whether the online system has the ‘PowerShellGet’ module available with the following command:

If there’s a response, you have it already! If there’s no output, you’ll need to make it available. Depending on the output, follow the instructions below.

Online System with PowerShell 4.0 or 3.0 with the PowerShellGet module:

  • Open PowerShell
  • Use the ‘Save-Module’ cmdlet to download the PowerCLI modules locally. Example:

    • If requested, update the NuGet provider
    • If requested, trust the ‘Untrusted repository’ that is named PSGallery
      Note: This is a local system trust, not something that has something to do with an SSL certificate
  • Copy those downloaded module folders to a location that can be made accessible to the offline system.
    Example: USB Flash Drive, Internal File Share, etc.

Online System with PowerShell 4.0 or 3.0 without the PowerShellGet module:

  • Download and install the ‘PowerShellGet’ module by way of the PackageManagement PowerShell Modules MSI.
  • Open PowerShell
  • Use the ‘Save-Module’ cmdlet to download the PowerCLI modules locally. Example:

    • If requested, update the NuGet provider
    • If requested, trust the ‘Untrusted repository’ that is named PSGallery
      Note: This is a local system trust, not something that has something to do with an SSL certificate
  • Copy those downloaded module folders to a location that can be made accessible to the offline system.
    Example: USB Flash Drive, Internal File Share, etc.

Save-Module Example and associated output

Adding PowerCLI to the Offline System

It’s now time to put the PowerCLI modules on to the offline system. To take advantage of the magic that is module auto-loading, we’ll want to copy and paste those downloaded folders in one of the locations listed in the PSModulePath variable.

By default, the PSModulePath variable contains the following directories:

  • $home\Documents\WindowsPowerShell\Modules
  • $pshome\Modules

When everything is all said and done, you should have one of the directories listed above looking a bit like this:
Directory Structure with PowerCLI Modules on the Offline System

That’s it! Open a PowerShell session and start using your PowerCLI commands as you did before!

Wait… It’s Not Working For Me!

What happens when you go through the above instructions and it’s not working?

The most common scenario we’ve come across is where the ‘Save-Module’ cmdlet was used with an online system that has PowerShell version 5.x. When this happens, there are an additional level of folders created between the top-level module folder and the module files themselves. This is extremely beneficial because we can then have multiple versions of the same module available on the local system. The issue though, older versions of PowerShell do not recognize those folders and therefore cannot load the modules.

When I say issue, I truly mean it. Jake Robinson, the PowerCLI Product Manager, actually created a GitHub issue for PowerShellGet calling out this problem: Offline installation of modules from Save-Module does not work on PS <5.x

Good news though, there are a couple workarounds available!

First option: Upgrade your version of PowerShell on the offline system to 5.x with Windows Management Framework 5.0.
Second option: Find an online system that has PowerShell versions 4.0 or 3.0 installed and use ‘Save-Module’ on that system.

Those two options are simple enough, but generally in an ‘easier said than done’ manner. With that said, I’m very excited to show off a third option. This option doesn’t require installing any software or powering on that older VM you hadn’t decommissioned quite yet. This option is a simple script that is run on the offline system. The script simply looks for the folders that already exist in any of the PSModulePath listed directories, searching specifically for PowerCLI module folders, and then removes that additional nested level of version-based folders.

The script is openly available on the PowerCLI Community Repository and is named: PowerCLI_FixNestedFolders.ps1

Here’s an example of the script in action:
Fixing the nested PowerCLI folders on older versions of PowerShell

Here’s an example of the results: (Left is the before, right is the after)
Directory Structure Before, left, and After, right


PowerCLI has seen a lot of success on the PowerShell Gallery. A set of modules with over 2,000,000 combined downloads is pretty impressive! However, there’s still a lot of questions over the installation process for systems that are offline. This blog post walked us through the offline installation process, covers the most common issue users hit, and provides a new solution to help overcome that issue.

Don’t delay, upgrade your version of PowerCLI on all your systems to ensure you’re getting access to the most up-to-date features, performance improvements, and bug fixes today!

Powershell Core 6.0 Released

It’s an exciting time for infrastructure automation!

PowerShell Core 6.0 enables us to use the same amazing automation framework on Mac and Linux, opening the door for many more automation opportunities in your infrastructure. I want to personally congratulate everyone at Microsoft and the PowerShell community that made this dream a reality. The amount of effort that went into this was truly amazing and we’re excited to be a part of it!

For over ten years, the PowerCLI team has been iterating on our modules as new PowerShell functionality was created, and I am excited to say we’re about to take another big leap. A little over a year ago, we released a fling called PowerCLI Core, which was a great proof of concept that we could get PowerCLI to run on Mac and Linux. Since that time, we’ve been in very close communication with the PowerShell team about porting PowerCLI. The PowerShell team has been a great partner in listening and responding to feedback from the PowerCLI team on the porting experience, and I am happy to say were are very, very close.

Coming Soon…

Our next release is currently in closed alpha, and I am excited to announce we will have an open beta beginning on Feb 1 Feb 2, 2018. My goal with the open beta is to give you the opportunity to get started with PowerCLI on the OS of your choice, while also allowing us to hear your feedback and put the final polish on the release. More information about the open beta will be available very soon.

The early feedback on the next release of PowerCLI is already coming in, and the critics say:


Important Notes about the Upcoming Release

The next release of PowerCLI supports PowerShell 3,4, 5.x, and Core 6.0 on Windows, and PowerShell Core 6.0 on Ubuntu 16.04, CentOS 7, and MacOS 10.12. We’ll continue to add more as we have the opportunity to add testing for these operating systems.

Finally, there are a number of deprecated cmdlets and parameters that we’ll be removing in this release, so make sure you have your deprecation warnings turned on in your current version so you know what will be removed.

VMware Tools Community Module Introduction

VMware Tools is a collection of in-guest drivers and agents that optimize performance and increase the manageability for VMs within vSphere environments. Guess what, PowerCLI provides a way to automate the management of the VMware Tools lifecycle! Even better, a new module was recently entered into the PowerCLI Community Repository to help make those management tasks even easier than before!

The module includes a collection of over 10 different advanced functions! These include the following:

Get-VMByToolsInfo Retrieves the virtual machines with specified VMTools info.
Get-VMToolsGuestInfo Retrieves the guest info of specified virtual machines.
Get-VMToolsInfo Retrieves the VMTools version and build number info of specified virtual machines.
Get-VMToolsInstallLastError Retrieves the error code of last VMTools installation on specified virtual machines.
Get-VMToolsUpgradePolicy Gets the VMTool’s upgrade policy of specified virtual machines.
Invoke-VMToolsListProcessInVM Lists the running processes in the virtual machine.
Invoke-VMToolsUpgradeInVMs Upgrades VMTools to the version bundled by ESXi host.
Invoke-VMToolsVIBInstall Installs VMTool VIB in specified ESXi hosts.
Set-VMToolsUpgradePolicy Sets the VMTool’s upgrade policy to either “manual” or “upgradeAtPowerCycle” of specified virtual machines.
Update-VMToolsConfInVM Updates the tools.conf content in guest OS.
Update-VMToolsImageLocation Updates the /productLocker link in an ESXi host directly

Let’s take a look at how to get started using this great module.

Accessing the Module

There are a couple ways to get access to this great module, all of which go through the PowerCLI Community Repository. One of the easiest ways is to load up the repository’s page, click on the green ‘Clone or download’ button, then clicking on ‘Download ZIP’. This downloads the entire contents of the repository to your local system.

Download PowerCLI Community Repository to Local System

Once the download is complete, unzip the files and browse to the ‘Modules’ directory. We are now going to copy the VMToolsManagement folder and paste it in one of the directories that are listed in the PSModulePath variable. Doing this allows the module to be available for automatic importing by your PowerShell session!

By default, the PSModulePath variable contains the following directories:

  • $home\Documents\WindowsPowerShell\Modules
  • $pshome\Modules

In my environment, I have placed the module in the first of the above options. This is also where my PowerCLI modules are available.

Extracted Module Placed in a PSModulePath sourced location

One item to keep in mind, the ‘Update-VMToolsImageLocation’ does require the usage of an ESXi host’s SSH service. Therefore, the SSH service on the ESXi host must be running as well as having an SSH library on your local system.

Module Usage

There are a couple functions that make it really easy and straight forward to retrieve VMware Tools information from VMs in the environment. These functions accept VM input from either direct VM parameter usage or pipeline. Here’s example output from the following advanced functions:

  • Get-VMToolsInfo
  • Get-VMToolsGuestInfo
  • Get-VMToolsInstallLastError

Example of retrieving VMware Tools information from a VM

There’s a very versatile function which allows us to query our environment for specific information about the state of VMware Tools on our VMs. This advanced function is ‘Get-VMByToolsInfo’ and has a couple nice parameters to help us out. The first parameter is ‘Tools Version’ which displays only VMs which contain the specified version. The next parameter is ‘ToolsRunningStatus’ which displays only VMs which are of the specified running state. The last parameter is ‘ToolsVersionStatus’ which displays only VMs that are of a certain status. The last two parameters feature tab complete functionality for each of their inputs.

Here are examples of a couple commands I ran within my environment:
Example of retrieving VMs by VMware Tools configuration

Let’s move on past simply retrieving information now. There are two functions which allow us to both retrieve and manage the upgrade policy for VMs. This can be done with the following advanced functions:

  • Get-VMToolsUpgradePolicy
  • Set-VMToolsUpgradePolicy

The Set-VMToolsUpgradePolicy allows us to modify the upgrade policy for a VM with the ‘UpgradePolicy’ parameter. This parameter also allows for tab completion between the two accepted policies. Here’s an example of those two functions in action:
Example of configuring the VMware Tools Upgrade Policy for a VM

We also have the ability to change the VMware Tools logging level. This is something that is normally done internally on the guest system but, through the magic of PowerCLI, we can now do this remotely with the ‘Set-VMToolsConfInVM’ advanced function! This function features a ‘LogLevel’ parameter which handles the changing of log level. Tab completion is available for this parameter as well. Additional information about configuring these settings can be found in KB 1007873. One note about this function, be aware of what the permissions are on the local system. Certain OSes can be touchy about modifying files within the folders where these configuration files are held.

Example of modifying the VMware Tools logging level

This module wouldn’t be complete without the ability to also upgrade a system’s VMware Tools too! This is accomplished with the ‘Invoke-VMToolsUpgradeInVMs’ advanced function. Here’s an example of it in action:
Example of upgrading the VMware Tools on a specified VM

Lastly, there are two functions that help to manage VMware Tools’ accessibility directly from ESXi hosts! The ‘Update-VMToolsImageLocation’ advanced function allows us to change the location of where VMware Tools are stored for ESXi hosts. For example, we could store the VMware Tools and floppy files on a datastore instead of the local system! One other nice feature of this function, there is no reboot required for the configuration update to go into effect. Then, there is the ‘Invoke-VMToolsVIBInstall’ advanced function. This function allows us to install and make available updated versions of VMware Tools out of the normal ESXi update lifecycle.

Here’s an example of updating an ESXi host with a newer version of VMware tools by way of a VIB:
Example of updating the VMware Tools version that's available on the ESXi host


The VMToolsManagement module is a terrific resource for any administrator needing to get quick and easy access to manage the lifecycle of VMware Tools in their environment. This module comes packed with over 10 different advanced function to handle a majority of the tasks admins face.

Head out to the PowerCLI Community Repository, download it, and let us know in the comments how you’re putting it to use in your environment!

Getting Started with the PowerCLI Module for VMware NSX-T

PowerCLI 6.5.3 was released a few short weeks ago and one of the biggest additions was the module to manage VMware NSX-T! This version of NSX provides network virtualization to not only VMware environments, but also multi-cloud and multi-hypervisor environments too.

Before diving into the module itself, there are a couple things we should cover first. This module was released as a low-level, API access only, module. That means the module comes with the following cmdlets: Connect-NsxtServer, Disconnect-NsxtServer, and Get-NsxtService. The first two cmdlets should be fairly straight forward, but the third is where it gets interesting. The Get-NsxtService cmdlet allows us to have full access to NSX-T’s public API! This module also gives users the capability to use a ‘create’ method to create PowerShell objects. These objects can then be modified and used as input back to the endpoint. This really helps simplify and streamline the interaction between PowerCLI and the NSX-T API endpoint!

For more information about the NSX-T 2.0 release, see the Network Virtualization blog: NSX-T 2.0 is Here!
For more information about the NSX-T 2.0 API, see the VMware Code API Explorer

Getting Started

First things first, open up a PowerShell session and authenticate to your NSX-T Manager with the ‘Connect-NsxtServer’ cmdlet.

Output Example:
Connect-NsxtServer Example

We are now ready to start exploring the NSX-T API with the ‘Get-NsxtService’ cmdlet. Running that cmdlet as is will return every named call for the NSX-T API, so this may be a little overwhelming at first. To make this easier, remember to reference the API Explorer as well as PowerShell’s ‘where-object’ cmdlet to help filter the names for what you need.

Example: Getting NSX-T Manager Information

For the first example, we are looking for information about the NSX-T Manager node. Searching through the VMware Code API Explorer for NSX-T for ‘nsx manager appliance’, we see a ‘GET’ method against ‘/node’ that is probably the most relevant call.

NSX-T API Explorer Example

To consume this in the PowerCLI module, we will use the ‘Get-NsxtService’ cmdlet to search for a name that ends in ‘node’ with the following code:

We can then save that service in a variable to easily reference for future commands:

We can now explore the methods available by piping the ‘nodeSvc’ variable to PowerShell’s ‘Get-Member’ cmdlet. Example:

There, In the output from ‘Get-Member’, we will see a ‘get’ method. We’ll want to perform that with the following code:

Combined Command Example:

Output Example:
NSX Manager Node Information Retrieval Example

Example: Retrieve Transport Zone Information

In our second example, we will retrieve information about the configured Transport Zones. We can do this as easily as we did the NSX Manager node. Referring back to the VMware Code API Explorer for NSX-T, we can search through the available namespaces for ‘transport zones’. We’ll find one in particular that has a description of ‘List Transport Zones’.

Based on that information we can infer that the service name is going to end in ‘zones’. We’ll run the following command to find the service:

We’ll then store the ‘com.vmware.nsx.transport_zones’ service into a variable. We’ll pipeline that variable to the ‘Get-Member’ cmdlet to find the available methods we can use. An example:

This service offers a couple methods which could fit our scenario of retrieving information about the environment’s Transport Zones. The methods available are a ‘get’ and a ‘list’. In order to perform the ‘get’, we would need to have the ID. Since we don’t have that information yet, we’ll run the ‘list’ method and store that into a variable with the following command:

Refering to the ‘tZones’ variable we can see some information, but the info about the Transport Zones themselves are within the ‘results’ property. We can refer back to the ‘tZones’ variable but specifying the ‘results’ property and find the information we’re looking for.

Combined Command Example:

Output Example:
Transport Zone Example

Example: Logical Switch Management

We have now covered much of the basics on how to get started, so let’s start doing some other tasks. In this example, we are going to list out the Logical Switches and then create a new one!

First, we’ll retrieve information about our existing Logical Switches using the knowledge we built from the first two examples. This can be done with the following commands:

Referring back to the output from the ‘Get-Member’ cmdlet, we noticed a ‘create’ method was available. This is where the ‘Help’ property is going to become very important. We can obtain some additional information about the requirements of the ‘create’ method by calling the variable’s ‘help’ property. We can also target the help for our example by further calling the ‘create’ property. We can do that with the following command:

The output includes a lot of valuable information such as the required and optional parameters, expected output, potential errors, and so forth. The last property, ‘logical_switch’, is the important one. We can refer to this as the structure the ‘create’ method is looking for. We can take that a step further and actually create a specification based off of that information as well with the command:

Checking the output of the variable ‘logSwitchSpec’ we can now see a PowerShell object that can be modified to be included as part of our ‘create’ action. The required parameters are the Logical Switch name, Transport Zone ID, and admin state. However, since this is an overlay logical switch, we can also specify the replication mode as noted in the ‘Help’ output. We can make those modifications with the following commands:

Lastly, we will run the original ‘create’ method against the ‘logSwitchSvc’ variable. Example command:

Combined Command Example:

Example Output:
Logical Switch Creation Example

Example: IP Pool Management

The last example will be taking a look at managing IP Pools.

Much like the prior examples, we’ll start by retrieving information about the existing IP Pools with the following commands:

However, we’d like the output to be a little more readable and include information which is nested within a property. This can be accomplished by using PowerShell’s ‘Format-Table’ cmdlet. We will take the ipPools variable output and pipeline that into the ‘Format-Table’ cmdlet. There we can use the ‘property’ parameter to specify only the properties that we are concerned with viewing.

Command Example:

Output Example:
IP Pool Information Retrieval Example

With our custom output, we realize there happens to be an IP Pool which doesn’t have any IPs assigned to it. We’ll want to remove that IP Pool so someone doesn’t try to use it. Performing a ‘Get-Member’ against the ipPoolSvc variable, we see there’s a ‘delete’ method we can use to remove that unneeded IP Pool. To find more information about what the method requires, we can call the ipPoolSvc’s ‘Help’ property and even further specify the ‘delete’ property. There we can see the IP Pool’s ID is the only required input while the ‘force’ input is optional. We are then ready to use the ‘delete’ method with the following commands:

Output Example:
IP Pool Removal Example


PowerCLI 6.5.3 introduced a great new module to manage VMware NSX-T environments. In the NSX-T module’s current release, it has three cmdlets to connect and disconnect from the NSX Manager while the third is used to interact directly with the NSX-T API. This blog post went through several examples including retrieving information about the NSX Manager node, Transport Zones, Logical Switches, and IP pools. We then took a look at using the API access to create a logical switch and remove an IP Pool.

Let us know in the comments how you’re using the NSX-T module to manage your environment!

New Release: VMware PowerCLI 6.5.4

It feels just like yesterday that we released PowerCLI 6.5.3. Shockingly, it was less than a month ago when we released the brand-new module to help manage and automate your NSX-T environments. Yet, we’re back with another brand-new module to manage VMware Cloud on AWS environments as well as a bunch of new and updated storage cmdlets too!

PowerCLI 6.5.4 features the following:

  • New module for VMware Cloud on AWS functionality
  • 14 new cmdlets added to the Storage module
  • Several cmdlets have also been improved in the Storage module

Let’s take a closer look at each of these.

New VMware Cloud on AWS Module

VMware Cloud on AWS (VMC) initial availability was announced earlier this year at VMworld US. PowerCLI already works with the vSphere infrastructure out of the box. How about managing the VMC service itself? Doing tasks such as creating SDDCs, adding or removing ESXi hosts, and so forth. PowerCLI 6.5.4 makes all of that possible!

This module is being released as a low-level, API access only, module and will feature the following cmdlets:

  • Connect-VMC
  • Disconnect-VMC
  • Get-VmcService

Note: The VMC API is currently available as a “Technical Preview” and therefore the namespace and functionality provided by the module may change in the future.

When we get started with the VMC module, we’ll notice immediately that it has a little different authentication process than the other connection cmdlets. This module requires you first acquire the OAuth Refresh Token from the VMware Cloud Console:
VMware Cloud Console OAuth Refresh Token

Copy the refresh token, open a new PowerShell session (after having updated to PowerCLI 6.5.4), and connect to the VMC service with the following command:

Now that we are connected, we can then display some information about the current Organization with the following commands:

Example Output:
Example: Connecting and Listing Current Org

One other thing you probably want to do is retrieve information about the Org’s SDDC. That information can be found with the following commands:

Example Output:
Example: Retrieving an Org's SDDC Information

New Storage Module Cmdlets

The Storage module has added a ton of functionality around vSAN encryption. PowerCLI can now manage Key Management Servers (KMS), configure KMS clusters, manage certificates, and even start the vSAN encryption process on a cluster! There are also a couple of other cmdlets available to repair vSAN objects, obtain evacuation plan information, and manage vSAN rebalance cluster actions.

Here’s a list of all the new cmdlets available:

  • Add-KeyManagementServer
  • Get-KeyManagementServer
  • Set-KeyManagementServer
  • Remove-KeyManagementServer
  • Get-KmsCluster
  • Set-KmsCluster
  • New-KmipClientCertificate
  • Get-KmipClientCertificate
  • Start-VsanEncryptionConfiguration
  • Get-VsanEvacuationPlan
  • Repair-VsanObject
  • Start-VsanClusterRebalance
  • Stop-VsanClusterRebalance
  • Get-VsanRuntimeInfo

Taking a look at some of these new cmdlets in action:

Improved Storage Module Cmdlets

Last, but not least, there are some cmdlets that have received updates for additional functionality. Here’s a list of the improved cmdlets:

Cmdlet Added Functionality
Get-VsanTest Displays vnic and pnic vSAN Stats
Start-VsanClusterDiskUpdate Parameter: EraseDisksBeforeUse
Reformats the vSAN disk with encryption settings
Get-VsanClusterConfiguration Displays the Silent Health Check Statuses and Resync Throttling Configuration of a vSAN Cluster
Set-VsanClusterConfiguration Parameter: AddSilentHealthCheck & RemoveSilentHealthCheck
Allows for Management of vSAN Health Check Silencing Actions
Parameter: ResyncThrottlingMbps
Configures Throttling of vSAN Resync Traffic
Parameter: WitnessHost
Replaces the Witness Host in a Stretched Cluster
Test-VsanClusterHealth Additionally Displays Encryption Health Results


PowerCLI 6.5.4 brings some fantastic updates to your PowerShell console and only a month after the last update! This release allows you to manage your VMware Cloud on AWS Org, SDDC, and more directly from PowerCLI. There are also a lot of storage improvements to make automating vSAN clusters a breeze and more secure with 14 new cmdlets and several other having been improved upon.

Updating to PowerCLI 6.5.4 is just as easy as:

For more information on changes made in VMware PowerCLI 6.5.4, including improvements, security enhancements, and deprecated features, see the VMware PowerCLI Change Log. For more information on specific product features, see the VMware PowerCLI 6.5.4 User’s Guide. For more information on specific cmdlets, see the VMware PowerCLI 6.5.4 Cmdlet Reference.