Home > Blogs > VMware PowerCLI Blog

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

Wrap-Up

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, 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:

IT’S AWESOME!

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

Summary

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

Summary:

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

Summary

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.

New Release: PowerCLI 6.5.3

I’m excited to announce that it’s release day yet again! We have a great new update for you with PowerCLI 6.5.3! Just a few short months ago, two to be exact, the last version of PowerCLI was released. That release introduced a new parameter, some new content library functionality for ISOs, and even new support for certain features.

PowerCLI 6.5.3 comes packed with the following:

  • New module for NSX-T functionality
  • Addition of a ‘Create’ method for use with the ‘Get-*Service’ cmdlets
  • Several issues have been resolved

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

New NSX-T Module

PowerCLI 6.5.3 introduces a brand-new module in order to manage VMware NSX-T environments. NSX-T was announced this year at VMworld US. In a nutshell, NSX-T is the newest iteration of VMware’s multi-hypervisor NSX platform. It is also the key to multi-cloud, and container infrastructures!

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

  • Connect-NsxtServer
  • Disconnect-NsxtServer
  • Get-NsxtService

An example of connecting to an NSX-T server and listing the nodes included in the cluster:
NSX-T Module Example Usage

For more information on the NSX-T RESTful API, the API documentation can be viewed on the VMware Code API Explorer.

New Create Method Available

The other major update is around the addition of a ‘Create’ method to the Get-CisService and, newly released, Get-NsxtService cmdlets when used in conjunction with an object’s ‘Help’ property. This streamlines the creation of certain objects for a template-like experience. Those who have worked with specifications when using the ‘Get-View’ cmdlet will be quite familiar with how this ‘Create’ method will work and be interacted with. This method works against the following objects:

  • Parameter
  • Elements of a parameter (Limited to types: List, Set, Optional)
  • Key and value of parameters (Limited to types: Map)
  • Fields of a parameter (Limited to types: Structure)

Here’s an example on how the new ‘Create’ method can be used to create and apply settings to a specification in order to make a new VM while using the vSphere Automation SDK API:

Resolved Issues

This release of PowerCLI also contains some usage improvements to a handful of cmdlets.

  • New-TagAssignment: When connected to multiple vCenters and using string based inputs for the ‘Tag’ and ‘Entity’ parameters, the cmdlet has been updated to no longer throw an error of “The specified parameter ‘Tag’ expects a single value, but your name criteria ‘…’ corresponds to multiple values.”
  • Set-VMHostNetworkAdapter: When configuring an ESXi host’s virtual NIC to use an IPv6 address which is managed through a vCenter Server of version 6.5, the AutomaticIPv6 property has been corrected to no longer flip the switch to ‘True’.

Summary

We are continuing our commitment to getting the latest and greatest functionalities, performance improvements, and issue resolutions with this latest release of PowerCLI 6.5.3. After only 2 months, we have released a new module to manage NSX-T environments, added a new ‘Create’ method for use with the Get-CisService and Get-NsxtService cmdlets, and fixed a handful of issues with existing cmdlets.

Remember, updating your PowerCLI modules is now as easy as: Update-Module VMware.PowerCLI

For more information on changes made in VMware PowerCLI 6.5.3, 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.3 User’s Guide. For more information on specific cmdlets, see the VMware PowerCLI 6.5.3 Cmdlet Reference.

PowerCLI Support Breakdown

Is PowerCLI supported by VMware?
Can support requests be opened about PowerCLI through MyVMware?

Questions like these keep coming up at VMUG meetings and customer meetings. This shouldn’t be a secret! The 18 modules that are available for with the current release of PowerCLI 6.5.2 are covered under VMware’s Basic Support and Production Support scope.

With that said, there are some areas in need of clarification. The coverage areas are around the installation process and cmdlet failures. If you’re running into errors while installing or initializing PowerCLI, a support request can be opened. If you’re using a cmdlet and you’re hitting some form of error, where the command used to work or should work according to the documentation, a support request can be opened. VMware’s Global Support Services (GSS) will work to identify the issue with you.

There are some areas of PowerCLI where GSS does not have the ability to support. These areas are around any guidance for custom scripts and/or advanced functions. VMware does have the ability to offer vSphere SDK Developer Support Service. If you are in need of this service, I would recommend speaking to your VMware account team.

Now that we have the groundwork laid, let’s discuss a little further how to make a support request regarding a PowerCLI issue.

Ask the Community

We’re talking support requests in this blog post, but… Have you asked the community? PowerCLI has a very active community which can be accessed in many ways. First, there’s fantastic PowerCLI VMTN Community that’s open and available to search through and ask questions. It even just recently hit 12,000 discussions! Then, there’s the VMware Code slack channel on PowerCLI is constantly one of the busiest channels in the Slack team and has over 500 members! There’s also Twitter and using the PowerCLI hashtag.

Support Request Creation

In order to help streamline the process of creating a support request to VMware, I’ve compiled some helpful suggestions from both customers whom have submitted support requests and the GSS representatives whom may respond to these support requests.

First and foremost, when creating a support request, you’ll notice there isn’t a “PowerCLI” support section. The best thing to do here is create a support request for product that’s having issues. Example: If it’s a VMHost cmdlet failure, create an ESXi support request.

Isolate the Issue

When creating the support request, only include the specific cmdlet which is not operational. Make sure to also include the output from running the cmdlet, such as the exact error message wording. Also, where possible, attempt to use the ‘Verbose’ parameter to help generate additional informational output.

Example: Using the Verbose parameter

User Resolve-Error

If you are receiving an error, try to make use of the following function after receiving the error:

The Resolve-Error function’s output helps to provide as much context about the error as possible. For more information about it’s origin and usage, please refer to the following: Microsoft PowerShell Blog: Resolve-Error

Include All Version Information

Including all of the necessary version information is a very important step. Part of this would include PowerShell version, PowerCLI module versions, vSphere version, and so forth.

PowerShell information can be found using the built-in variable: $PSVersionTable

Example: Obtaining the version of PowerShell

PowerCLI module version information can be found with the following command: Get-Module –Name VMware*

Example: Listing Modules with Get-Module

If your PowerCLI session is connected to your vSphere environment, obtaining the vCenter version can be done with the following command: $global:DefaultVIServer | select Name,Version,Build

Example: Obtaining the version of vCenter

If you happen to be running into a vSAN PowerCLI issue, obtaining the vSAN version can be obtained through the new Get-VsanView cmdlet. An example command:
(Get-VsanView -Id "VsanVcClusterHealthSystem-vsan-cluster-health-system").VsanVcClusterQueryVerifyHealthSystemVersions((Get-Cluster).Id) | select VcVersion

Example: Obtaining the version of vSAN Cluster

If you happen to be running into a vRealize Operations Manager (vROps) PowerCLI issue, obtaining the vROps version can be a bit tricky. This is because it involves accessing the underlying API. This can be done in two command lines though:
$OmServer = $global:DefaultOMServers[0].ExtensionData
$OmServer.GetCurrentVersionOfServer() | select ReleaseName

Example: Obtaining the current version of vROps

Last one, if you happen to be running into a Horizon View PowerCLI issue, obtaining the Horizon View version can also be a little tricky. However, it can be obtained in two command lines:
$hvserver = $global:DefaultHVServers[0].extensiondata
$hvserver.ConnectionServer.ConnectionServer_list().General | select Name,Version

Example: Obtaining the version of Horizon View Server

Additional Information

Feel free to include any additional information which may help bring the support request to resolution. One example, screenshots are always helpful. If the error involves any variables or pipeline input, include the output for those items as well.

Summary

VMware PowerCLI is supported by VMware and support requests can be opened! VMware supports both the installation process and cmdlet usage. However, to make the support process easier:

  • Open a support request for the product area where the failure is occuring
  • Isolate the problem to the usage of a particular cmdlet
  • When dealing with an error, include the output from the Resolve-Error function
  • Include the versions of all related products (PowerShell, PowerCLI, vSphere, etc)
  • Include any variable and/or pipeline input being referenced

    • Also, don’t hesitate to ask the community! There’s a terrific wealth of knowledge who are eager to help!

What PowerCLI Version Am I On Anyways?

When PowerCLI was converted to modules, it introduced the ability to pick and choose which modules are loaded. Taking it a step further, it also allowed users to specify which versions of those modules are loaded. Historically, PowerCLI was released as one large ‘bundle’ of modules, and was not a great release practice. This meant that even though most modules were not touched, we were still required to go through our release processes to get them out the door. This is not scalable when trying to get features to you more frequently.

With modules in the Powershell Gallery, we can now release individual modules asynchronously from other modules. The first release to really take advantage of that is PowerCLI 6.5.2. For those whom have already updated their VMware.PowerCLI module from the Microsoft PowerShell Gallery, you noticed there were only 3 modules which were updated and needed to be downloaded.

The Better Way

In prior releases, we could use the ‘Get-PowerCLIVersion’ cmdlet and receive a high-level look at the overall PowerCLI version which was installed. Previously, our versioning scheme was not supported in PowerShell, so it took a cmdlet to print the version out (Example: VMware PowerCLI 6.5 R1). That is gone now. We’ve made the change to semantic versioning in 6.5.1. This means there will be no more R1, R2, or R3 releases!

Starting with PowerCLI 6.5.2, the process to get module versions has changed. Running the ‘Get-PowerCLIVersion’ cmdlet now results in a warning message indicating that it is deprecated and to use the ‘Get-Module’ cmdlet instead.

Example of the deprecation notice for Get-PowerCLIVersion

Using Get-Module

There are a couple ways to use the ‘Get-Module’ cmdlet to help us determine our versioning. The reason for that is because the ‘Get-Module’ cmdlet only shows the modules which have been imported.

The first way is to get the overall PowerCLI version, which is dependent on the ‘VMware.PowerCLI’ module. We can determine the version by first importing the module (if it’s not already imported) and then running the following command:
Get-Module -Name VMware.PowerCLI | Select-Object -Property Name,Version

Example: Obtaining the version of the VMware.PowerCLI module

From the above example, we can see that we’re using PowerCLI version 6.5.2.

Another way is to just reference the modules which have been loaded automatically. I have an example where we connect to our vCenter Server and then run the following command to find the versions of all the PowerCLI modules which are in-use:
Get-Module -Name VMware.* | Select-Object -Property Name,Version

Example: Obtaining the version of PowerCLI when using module autoloading

From the above example, we see that we’re only using a single PowerCLI module and it happens to be versioned at 6.5.2.

Running a couple additional, random, commands, we re-run the above command and see there’s now a bit more of a mix amongst our loaded modules.

Example: Obtaining the version of active PowerCLI modules

Summary

The new method to obtain what version of PowerCLI you’re using is through the ‘Get-Module’ cmdlet. This update was made for many reasons. This new method takes advantage of how our the PowerCLI modules can be loaded independently of each other on an as needed basis. It also takes advantage of how the PowerCLI module releases can now be done asynchronously from each other. Lastly, since we’ve changed the PowerCLI versioning over to align with the standard PowerShell versioning, there’s no need for a custom cmdlet anymore!

If you’re using ‘Get-PowerCLIVersion’ in your scripts or modules, make sure you’re aware of this and update your resources to reflect this change!

Updating PowerCLI through the PowerShell Gallery

PowerCLI 6.5.2 has been released! This is the second release of PowerCLI to the PowerShell Gallery, so it’s time to figure out how to update your PowerCLI versions to the latest and greatest.

We’ll cover a couple scenarios:

  • Updating from PowerCLI 6.5.1, installed online from the PowerShell Gallery
  • Updating from PowerCLI 6.5.1, installed offline from the PowerShell Gallery
  • Updating from PowerCLI 6.5 R1 or prior

Updating from PowerCLI 6.5.1, Online

This will be the easiest update process PowerCLI has ever offered! Open a PowerShell session, type the following command:
Update-Module -Name VMware.PowerCLI

Update Module Example

That’s it, you’re now running the latest and greatest PowerCLI release!

However, if you happen to have run into the following error it’s possible that PowerCLI was installed by the offline method:
Update-Module : Module ‘VMware.PowerCLI’ was not installed by using Install-Module, so it cannot be updated.

There’s two main ways to resolve this:
Option 1. Remove the PowerCLI modules from where they currently reside
1a. Run the following command:
Get-Module VMware.* -ListAvailable
1b. There should be a ‘Directory’ label at the top of the response. Browse to that directory and remove all the directories starting with ‘VMware.*’

Example Usage of Get-Module

1c. Perform the following command:
Install-Module -Name VMware.PowerCLI -Scope CurrentUser

Option 2. Use the force… And by that, I mean perform the Install-Module command with the ‘Force’ parameter
2a. Perform the following command:
Install-Module -Name VMware.PowerCLI -Scope CurrentUser -Force

Updating from PowerCLI 6.5.1, Offline

This process will work exactly the same as the installation process.

1. From a computer that has internet access, run the following command:
Save-Module -Name VMware.PowerCLI -Path C:\Path\To\Desired\Folder
2. Take the downloaded modules and make them available to the offline system
3. Copy and replace the individual PowerCLI module folders to the location where the prior modules were placed.

Copying over the PowerCLI modules after saving them locally

Updating from PowerCLI 6.5 R1 or prior releases

If you happen to be running an older version of PowerCLI which involved an MSI installer, we can verify that by running the following command:
Get-Module VMware* -ListAvailable

Example on showing a list of available PowerCLI modules

If the majority of PowerCLI modules are versions listed at 6.5.0 or older, as shown above, proceed through the following steps.

PowerCLI 6.5 R1 (or older) Uninstallation Steps:
1. Uninstall PowerCLI through the Control Panel
2. Browse to the following directory: C:\Program Files (x86)\VMware\Infrastructure\
3. If there is a ‘vSphere PowerCLI’ directory, delete it

Uninstalling Prior PowerCLI Versions

PowerCLI 6.5.2 Online Installation
This works exactly the same as how the installation did for PowerCLI 6.5.1.

Within a PowerShell session, type the following command: $PSVersionTable

PSVersion Table Sample Output

If the PSVersion is a Value of 5.0 or above:
1. Run the following command:
Install-Module -Name VMware.PowerCLI –Scope CurrentUser
2. If asked to update ‘NuGet Provider’, choose ‘Y’ to install and import the newer version.
3. If asked to ‘install modules from an untrusted repository’, choose ‘Y’ to accept.

Install Module usage to PowerCLI 6.5.2

If the PSVersion is a Value of 4.x or 3.x:
1. Install a current version of PowerShellGet through one of the following two options:
1a. Install Windows Management Framework 5.1
1b. Install PackageManagement PowerShell Modules
2. Run the following command:
Install-Module -Name VMware.PowerCLI –Scope CurrentUser
3. If asked to update ‘NuGet Provider’, choose ‘Y’ to install and import the newer version.
4. If asked to ‘install modules from an untrusted repository’, choose ‘Y’ to accept.

PowerCLI 6.5.2 Offline Installation
1. From a computer that has internet access, run the following command:
Save-Module -Name VMware.PowerCLI -Path C:\Path\To\Desired\Folder
2. Take the downloaded modules and make them available to the offline system
3. Copy and replace the individual PowerCLI module folders to one of the following locations:
3a. Local User Usage: $home\Documents\WindowsPowerShell\Modules
3b. All User Usage: $pshome\Modules

Example file structure for an offline PowerCLI Installation

The PowerCLI Installation Walkthrough Video also works in this scenario too. However, following the instructions in the video will now result in PowerCLI 6.5.2 being installed:

New Release: VMware PowerCLI 6.5.2

The past couple releases have introduced some new and exciting modernizations for PowerCLI. We’ve moved from Snapins to Modules, leaving behind registry settings and the need for an installer and making packaging much easier. We then introduced you to PowerCLI installation through the Microsoft PowerShell Gallery, making installation and updates a single command.

All of these lead up to us delivering more frequent releases and more timely features and bugfixes. Only three months ago, we introduced PowerCLI 6.5.1, and today we’re delivering 6.5.2, cutting our release time in half from the past. We still have a lot of work to do on our processes, but we look forward to delivering frequent, high quality releases of the best automation library for VMware!

PowerCLI 6.5.2 has some great improvements. They come in three main areas:

  • Addition of the ‘InventoryLocation’ parameter to the following cmdlets: Move-VM, Import-VApp, New-VApp
  • Ability to mount a Content Library sourced ISO with the New-CDDrive cmdlet
  • Updated Support Around Experimental Features

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

New Parameter: InventoryLocation

The main purpose of the ‘InventoryLocation’ parameter is to specify a folder the VM or vApp should be placed during their related actions. The expected input for this parameter is a type of ‘FolderContainer’. Previously, the only option was ‘Destination’ and it accepted a folder, ESXi host, cluster, or resource pool. The issue was only one item could be specified at a time. Therefore, this addition is nice because it reduces the total number of steps needed to either move a VM between vCenter Servers or when deploying a new VM/vApp.

First example, moving a VM between vCenter Servers. By default, the VM would be moved to the root of the Datacenter in the ‘VMs and Templates’ view. Technically, it would be moved to the ‘vm’ folder but that’s hidden from the GUI view. This new parameter allows us to skip the follow-up ‘Move-VM’ command and place the VM in the proper folder at time of the migration.

Cross vCenter vMotion Example using Inventory Location Parameter

Second example, creating a new VM by importing a vApp. As with the previous example, this cuts down the steps in deploying this VM and streamlines the process.

Import-VApp example while using the Inventory Location parameter

Using Content Library Sourced ISOs

The ‘New-CDDrive’ cmdlet has a new parameter by the name of ‘ContentLibraryIso’. This allows us to mount an ISO which has been presented through vSphere’s Content Library. Here’s an example:

Example usage of the New-CDDrive cmdlet and Content Library ISOs

vSphere’s Content Library is a great resource and I’m really happy to be able to take better advantage of it through PowerCLI!

Experimental Feature Updates

If you’ve had the chance to read through our documentation, perhaps you’ve noticed a couple of the features or parameters which were marked as experimental. Several of these have been tested and we have been able to remove the functionality’s ‘experimental’ messaging.

Some Examples:

  • Set-HardDisk -ZeroOut: This parameter can be used to zero out a disk when the PowerCLI session is connected directly to the ESXi host.
  • New-HardDisk -AdvancedSetting: The experimental part of this parameter was centered around the Storage Distributed Resource Scheduler (SDRS) rule association.
  • New-VM -AdvancedSetting: The experimental part of this parameter was centered around the SDRS (SDRS) rule association.
  • Install-VMHostPatch: The whole cmdlet was experimental and has been approved for supported usage.

Summary

PowerCLI 6.5.2 is the first of our change to having more frequent releases. While these iterative releases may not be as packed full of new features as all the prior releases, we are able to provide new functionality and resolve any issues faster than prior versions. Some proof of that is the addition of the ‘InventoryLocation’ parameter to several cmdlets, the ‘ContentLibraryIso’ parameter to the New-CDDrive cmdlet, and taking several features and cmdlets from experimental to supported!

Don’t wait, Update-Module today!

Update Module Example

For information on the Microsoft PowerShell Gallery update process, see the following blog: Update PowerCLI From the PowerShell Gallery

For more information on changes made in VMware PowerCLI 6.5.2, including improvements, security enhancements, and deprecated features, see the VMware PowerCLI Change Log. For more information on specific cmdlets, see the VMware PowerCLI 6.5.2 Cmdlet Reference.