Home > Blogs > VMware PowerCLI Blog

Obtaining Specific PowerCLI Versions from the PowerShell Gallery

The recommendation is to always be on the latest and greatest version of PowerCLI. However, whether it be for testing and validation or to possibly workaround an issue, there are instances where you may need to use an older version.

The PowerShell Gallery has the potential to make this process incredibly easy when using the RequiredVersion parameter for both Install-Module and Save-Module. These cmdlets download and/or install the indicated module at the specified version. The issue, especially with PowerCLI, comes in how the dependent modules are handled. This is because, in most cases, the module dependencies are specified to be obtained at a particular level or newer.

Example PowerCLI Dependency Listing:
PowerCLI Module Dependencies

This means if you want to download PowerCLI 6.5.4 with either the Install-Module or Save-Module cmdlets, the end result will not actually give you the requested version of PowerCLI. You would only receive the top-level VMware.PowerCLI module at version 6.5.4. All of the module dependencies which make up the PowerCLI 6.5.4 release will be at the latest and greatest version.

So, how can we properly download prior versions of PowerCLI?

Introducing Save-PowerCLI

Dimitar Milov, a PowerCLI engineer, came up with a function to address the issue and shared it in the comments on the PowerShell Gallery page for the VMware.PowerCLI module. From that point, I added a couple new features and shared it in both the PowerCLI Community repository and the VMware Code Sample Exchange.

Save-PowerCLI In Action

Demo: Save-PowerCLI Usage

Save-PowerCLI Code

Known Issues

There are a couple issues I’ve noticed when testing this against various versions of PowerShell.

  • Older versions of PowerShellGet (Example: 1.0.0.1) will fail because it can’t handle the formatting of one specific PowerCLI version.
    • Workaround: Update PowerShellGet. Example: Install-Module -Name PowerShellGet -Force
  • Newly released PowerCLI modules can be found downloaded, even if they did not exist at the time of the specific version release.

Summary

We always recommend how everyone should be on the latest and greatest version of PowerCLI. However, we also recognize that isn’t always possible. Whether it be for testing and validation, working around known issues, and so forth, there are reasons and needs to be able to obtain prior versions of PowerCLI from the PowerShell Gallery. The Save-PowerCLI function can streamline the download process of retrieving those specific versions of PowerCLI.

Let us know what you think of this function in the comments!

New Release: PowerCLI Preview for VMware Cloud on AWS

It’s a big week for PowerCLI! We’re closing out 2018 with several new releases. The new PowerShell DSC Resources for VMware came out last week. PowerCLI 11.1.0 was released earlier today. Now, we also have a brand-new Fling to help bridge the gap between the low-level cmdlets already available and the high-level cmdlets that are so easy to use. The PowerCLI Preview for VMware Cloud on AWS adds 14 new high-level cmdlets which are used in combination with the existing VMware.VimAutomation.VMC module.

What do I mean by ‘high-level’ cmdlets? There are generally two forms of cmdlets available through PowerCLI, high-level and low-level. High-level cmdlets abstract the underlying API calls and provide an easy to use and understand cmdlet, like Get-SDDC. Based on that, you can assume the output will be SDDCs within your VMware Cloud on AWS environment. However, every API call does not have a corresponding high-level cmdlet and that’s where the low-level cmdlets come into play. Low-level cmdlets interact directly with the API and therefore have complete coverage of the available API calls. An example of a low-level cmdlet would be Get-View, or in the case of the VMC module it would be Get-VmcService. More information about the low-level cmdlet usage of the VMC module is available in the following blog post: Getting Started with the VMware Cloud on AWS Module

Why is this being released as a fling? Much like the NSX-T preview module released earlier this year, we’re trying a new approach to creating cmdlets based on the APIs. Essentially, we take the VMC API swagger specification and programmatically create the entire module. It’s early in this new development process and we know there is the potential for issues and things that may or may-not make sense.

Another reason for it being a fling, we need your feedback! What cmdlets are you using the most? What should the output look like? What cmdlets aren’t working the way you think they should? What cmdlets are missing? As well as any other feedback you can come up with! The preference is to leave the feedback on the Fling’s comments page. However, if you post it as a comment here, I’ll make sure the right people receive it.

With that said, let’s get started using this new module!

Getting Started

Before we dive right in, the following section is going to be using a Windows environment. However, both the existing VMC module as well as the new VMC Preview module are multi-platform and can be used with PowerShell Core!

First, we’ll need to head out to the VMware Flings site, browse for the fling and download the zip file. Direct link: PowerCLI Preview for VMware Cloud on AWS

Next, extract the module and place it into one of your $PSModule directories. Better yet, do it with PowerShell:

We can then verify the module was placed in the proper location and is available for us to use:

VMCPreview Module Install Process

Note: If you don’t see those two modules, you probably need to install the latest version of PowerCLI. Walkthroughs on how to do that are available:

Now that we can see the module, I would suggest browsing through the new cmdlets available. We can do that with the following command:

Listing the available commands

One last step before starting to use the new cmdlets, we need to authenticate to the VMware Cloud on AWS service. This requires the Connect-VMC cmdlet, which is available as part of the VMware.VimAutomation.VMC module, and our Refresh Token from the Account section of the VMware Cloud on AWS Cloud Console. We can then authenticate with the following command:

We are now authenticated and ready to start pulling information from the environment. Following along with the prior blog post, let’s start by pulling information about our organization. We can do that with the Get-Organization cmdlet.

Get-Organization Usage

We can clean up the output through the use of the Select-Object cmdlet with the following command:

Get-Organization Details

Another item we looked at in the last blog post, and the next logical step, SDDCs. The Get-Sddc cmdlet can be used, however it does require the addition of an Organization ID. I’ll store the Org ID from the prior step in a variable named orgId and then just jump to the cleaned-up view by using the following command to list the SDDC/s in the Org:

SDDC Example Output

Last thing I want to cover, these cmdlets make use of objects just like standard PowerCLI cmdlets do. Specific to the SDDC, we can access additional information such as what AWS Region and Availability Zone/s are in use, NSX information like the Manager URL (which will be important in a later blog post), and what the vCenter URL is. All of that information happens to be available in the ResourceConfig property of an SDDC. We can retrieve that information with the following command:

Additional SDDC Object Information

Summary

There’s a great new fling available called the PowerCLI Preview for VMware Cloud on AWS. This fling adds an additional 14 high-level cmdlets for VMware Cloud on AWS, like Get-Organization and Get-Sddc, which means that automating VMware Cloud on AWS has never been easier!

As with all of our Flings, please leave feedback on the Comments section! We want to know what you think. What cmdlets are you using the most? What should the output look like? What cmdlets aren’t working the way you think they should? What cmdlets are missing? As well as any other feedback you can come up with!

New Release: PowerCLI 11.1.0

As 2018 comes to a close, we have one more release for you in the form of PowerCLI 11.1.0! If you’re keeping track, that brings us to 6 official PowerCLI releases in the 2018 calendar year. To quickly summarize 2018: PowerCLI has gone multi-platform, added 2 new modules, added 25 new cmdlets, and supported new VMware product versions faster than ever! There were also quite a few other updates that involve PowerCLI, such as the Fling modules containing high-level cmdlets for NSX-T and VMware Cloud on AWS, the Code Capture addition to the HTML5 Web Client Fling, and the brand-new PowerShell DSC Resources for VMware!

PowerCLI 11.1.0 comes with the following updates:

  • Added support to the SRM module for MacOS and Linux
  • Added support for SRM 8.1
  • Updated 2 Storage module cmdlets
  • Updated DeployAutomation and ImageBuilder module dependencies

Let’s take a look at some of the updates.

Site Recovery Manager Module Updates

The VMware.VimAutomation.SRM module is the newest module to be converted to for multi-platform support. That means this module can now be used with PowerShell Core on MacOS and Linux! This module has also received updates to support Site Recovery Manager 8.1. More information on this new version of SRM can be found at the following: VMware Site Recovery Manager 8.1 Release Notes

PowerCLI and SRM Compatability

Storage Module Updates

The VMware.VimAutomation.Storage module received a couple updates to fix some issues. The Get-VsanDisk cmdlet has been updated to now also list the vSAN disk where the Witness Component resides. An update has additionally been made to the Start-SpbmReplicationTestFailover cmdlet so that it no longer requires the VvolId parameter.

Summary

PowerCLI 11.1.0 has been released and completes the 6th release of the year! This new release includes support for Site Recovery Manager 8.1, as well as converting the SRM module over for multi-platform support. Two storage cmdlets have been updated to fix some reported issues. Lastly, some dependencies for the DeployAutomation and ImageBuilder modules have been updated.

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

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

Example: Update-Module -Name VMware.PowerCLI

Let us know in the comments what you’re most excited about!

New Community Module for Tag Management

vSphere tags, in my opinion, are one the unsung heroes when it comes to VMware environment management. They’re extremely versatile. They can be used as labels. They can be used to group similar objects and/or multiple object types together. They can be used to apply policies. There are third party products also using them. I’ve seen lots of companies use them in lots of creative ways. However, automating their usage can be slow in some environments and not available at all in larger environments.

There’s a new module in the PowerCLI Community Repository to help against some of those issues. This new module, named VMware.Community.CISTag, makes use of the vSphere REST API to manage tags in a more performant manner.

The VMware.Community.CISTag module includes the following advanced functions:

Function Name Synopsis
Get-CISTag Gathers tag information from the CIS REST API endpoint
Get-CISTagCategory Gathers tag category information from the CIS REST API endpoint
Get-CISTagAssignment Displays a list of the tag assignments from the CIS REST API endpoint
New-CISTag Creates a new tag from the CIS REST API endpoint
New-CISTagCategory Creates a new tag category from the CIS REST API endpoint
New-CISTagAssignment Creates new tag assignments from the CIS REST API endpoint
Remove-CISTag Removes a tag from the CIS REST API endpoint
Remove-CISTagCategory Removes tag category information from the CIS REST API endpoint
Remove-CISTagAssignment Removes tag assignments from the CIS REST API endpoint

There are also some requirements that are needed in order for this module to work:

  • vCenter 6.0 or newer
  • PowerCLI 6.5.3 or newer
  • Active vCenter CIS service connection, using Connect-CISServer
  • Preferred: Active vCenter connection, using Connect-VIServer

Let’s take a quick look at how to get started using this 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 VMware.Community.CISTag 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.

Module Overview

The functions are written in a very similar format to the existing PowerCLI Tag cmdlets. If you’ve ever used the existing tag cmdlets, these operate in a very similar fashion and offer a very similar response. However, there are some changes that you should be aware of. The PowerCLI Tag cmdlets generally work with objects, whereas these functions work with names or IDs. This means you should test these new functions thoroughly before updating any existing scripts and/or workflows. Making use of Get-Help will greatly aide in the transition.

Overall, I noticed some good performance increases as well.

Example: Comparing an environment with 400 tags assigned, saw an improvement of roughly 25%
Performance test of listing tag assignments

There are some other features that have been added which can be used to achieve even more performance. The first, by using an object’s ID whenever possible. Most of the functions also feature TagId and ObjectId which can be referenced instead of the name parameters. This helps by cutting down on the amount of additional calls which are being made to translate a name into an ID value.

The second way to see even more performance improvement is through the usage of bulk actions. This applies specifically to the TagAssignment functions. The underlying API method allows multiple tags to be assigned or removed from a single object or a single tag can be assigned or removed from multiple objects. Therefore the New-CISTagAssignment and Remove-CISTagAssignment functions accept strings or arrays for Tag or Entity properties. There’s also the ability to further speed up the process by using object IDs too.

Example: Comparing the difference between the bulk assignment of a single tag against multiple VMs. Top example is name based, the bottom example is ID based.
Bulk action performance results

The last big note on improvements for this module, I have yet to run into any timeout issues, maximum results errors, and so forth.

Example: Comparing an environment with 1400 tags assigned, where the Get-TagAssignment cmdlet fails while the Get-CISTagAssignment succeeds
Example comparison with 1400 tags assigned

Summary

The CISTag module is a great new resource for anyone automating tag usage within their vSphere environment. By switching to the tagging methods available in the REST API, we’ve seen performance improvements, the ability to overcome timeout errors, and more!

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 Desired State Configuration Resources for VMware

Today, we are happy to announce a brand-new and open-sourced way to manage your vSphere environment. The Desired State Configuration (DSC) Resources for VMware allows partners, automation engineers, DevOps teams, and system administrators a new way to apply standard configuration management processes through PowerShell DSC and PowerCLI!

Let’s take a walk through how we can get started using these DSC resources and apply our first configuration!

Desired State Configuration Resources for VMware Overview

PowerShell DSC has been out for a while, since Windows Server 2012 R2 as a matter of fact. To summarize in a single sentence: PowerShell DSC can manage and monitor a system’s configuration based on what’s known as configuration files, which happen to be written as PowerShell code. This is all made possible thanks to the Local Configuration Manager (LCM). LCM is the “engine” running locally on each of the target nodes that takes the configuration file, interprets it, and applies all the configured parts. These parts include a system’s configuration, in what manner the configuration is refreshed, and how often it is refreshed, just to name a few.

The above is important because the DSC Resources for VMware operate a little differently than a standard DSC configuration. The DSC Resources for VMware make use of a proxy LCM host. This is because the LCM cannot run on the VCSA (both vCenter and PSC based appliances) nor can it run on ESXi hosts. An important note about this proxy LCM host, it has to be Windows PowerShell based. Furthermore, only PowerShell 5.1 and PowerCLI 10.1.1 or newer will be supported.

Desired State Configuration Resources for VMware

This first release of the DSC Resources for VMware will be able to manage a couple different areas for both vCenter and ESXi hosts. They are as follows:

  • vCenterStatistics
    • Level
    • PeriodLength
  • vCenterSettings
    • EventMaxAge
    • TaskMaxAge
    • Logging Level
  • VMHostNtpSettings
    • NTP Server
    • NTPD Service Policy
  • VMHostDnsSettings
    • HostName
    • DomainName
    • Address
  • VMHostSatpClaimRule
    • RuleName
    • Transport
    • Description
  • VMHostTpsSettings
    • ShareScanTime
    • ShareForceSalting

Installation Overview

We now know what it is and what it can do, how about the installation? On the designated proxy LCM system, we will want to download the module from GitHub and make it available in one of our designated PSModulePath directories. The zip file is available through the following link: Desired State Configuration Resources for VMware

Here’s some code that can streamline the download and initialization process:

After we have installed the module we should be able to list the newly acquired module and import it into our active PowerShell Session:

Example: Importing the VMware.vSphereDSC Module

We can also verify the DSC resources we have available:

Example: Output of available DSC Resources

Next, we need to make sure the proxy LCM system can understand the DSC configuration files. This is done through the Windows Remote Management service. We can setup the WinRM service or verify that the WinRM service is setup with the following code:

In my environment, this system already had WinRM setup so I received the following message:
Example: Windows Remote Management Configuration

We should now be all set to start setting up DSC resources in our environment!

Managing an ESXi Host’s NTP

The DSC Resources for VMware repository has some pre-created configuration files which can be sourced to create the MOF file. The MOF file, which stands for Managed Object Format, is the output from a configuration file which has been compiled by the LCM. These configuration files are located in the repo at the following location: \Source\VMware.vSphereDSC\Configurations In my environment, I’ve created my own fork of the repository and cloned it to my local system where I’ll be referencing the files.

In our example, we’re going to setup DSC to manage an ESXi host’s NTP configuration. We can see some parameters and some settings by opening the VMHostNtpSettings_Config.ps1 file that’s located in the ESXiConfigs directory.

Input Type Input Name Input Description
Parameter Name Resource Name
Server Server Host Name
User ESXi host username
Password ESXi host password
Setting NtpServer NTP server/s the host will use
NtpServicePolicy Status for the NTPD service

For my lab environment, I’m going to update the NtpServer values and accept the service policy setting of ‘automatic’. I’m also going to apply this configuration at the ESXi host level, so my host name and server name will match.

We can do this with the following commands:

As part of the output, we should see the following MOF file having been created:
Example: Configuring and creating MOF file

We can then test the MOF file against our host with the following command:

Added to the output, I have also included another PowerShell session which is polling the host for the current NTP server/s and service policy:
Example: Pre-DSC Configuration

In the above example, notice the ‘InDesiredState’ property with a value of False.

Now, we’re ready to start applying our configuration. We do this with the following command:

After a few moments, we’re ready to check the current DSC configuration with the following command:

Again, I’ve added a second PowerShell session to show the current status of the host:
Example: Post DSC Configuration Status

For reference, this is the code I’m running to show the current status of the host’s NTP configuration:

In some later blog posts, we’ll take a look at some of the other areas of this module including applying configurations to multiple hosts, applying vCenter settings, applying values to multiple hosts in a vCenter, and some ways to apply better security practices to both the credentials and the MOF.

Summary

PowerCLI is back with a brand-new feature, Desired State Configuration Resources for VMware! These resources allow PowerCLI to make use of PowerShell DSC to define the configuration of a desired node. The DSC Resources for VMware can define ESXi host settings such as NTP servers, DNS servers, and TPS share scan times. We can also define vCenter settings such as statistics level and logging level. As an additional benefit, these resources are also open-source and community contributions are absolutely welcome!

Check out the Desired State Configuration Resources for VMware on GitHub and let us know what you’re looking forward to using DSC on most in your vSphere environment!

Improving PowerCLI Support with Get-ErrorReport

I am always surprised at the shock some people have when it comes to PowerCLI being supported by VMware! We highlighted this in a prior blog post: PowerCLI Support Breakdown However, in that blog post, there was one item that wasn’t covered which can really help streamline the process of receiving support. This item is a cmdlet by the name of Get-ErrorReport and it received a big update as part of PowerCLI 11.

Let’s walk through an example of creating a PowerCLI support bundle using Get-ErrorReport.

Receiving an Error

The first thing we need to do is receive an error! In this case, I’ll be using a known issue with the Move-VM cmdlet which occurs when attempting to move a VM into a vApp.

Example: Generating an error

The error we received was:

This is a pretty straightforward issue where the Move-VM cmdlet is not operating in the way which was been documented. We can now open a support request!

PowerCLI Support Bundle

Normally, when you open a support request, the first ask is for a support bundle from either the vCenter, an ESXi host/s, or even all of the above. Since this is a PowerCLI issue, those standard support bundles may not help. Plus, some of the more advanced PowerCLI troubleshooting options are not easy, or not readily available, in most environments. One example of which would be to use a tool like Fiddler or Wireshark to sniff the network traffic in order to determine what API methods are being used under the covers and hopefully identify the issue.

Instead of going through the process of installing Fiddler or Wireshare, we can retrieve all the required information by making use of the Get-ErrorReport cmdlet!

The Get-ErrorReport cmdlet has a couple important parameters we’re going to be making use of:
Note: If you’ve used Get-ErrorReport before, these parameters have changed

Destination Location of where the PowerCLI support bundle will be placed
IncludeServerLogs Specify whether we want to pull logs from the connected server
ProblemDescription Provide a description and/or support number
ProblemScript Scriptblock which contains the cmdlet causing the error

Continuing with our Move-VM example, we can use the following code to create our support bundle:

Example: Get-ErrorReport command being run

We can now take that output and upload it to our support request!

Support Bundle Examination

If you happen to be curious about what information is contained within the support bundle, like I was, we can unzip the bundle and read through the contents fairly easy. Note: this section is purely educational as the support engineer will handle the actual diagnosis.

The support bundle contains the following files:

  • PowerCLI-Main-Log.svclog
  • Powershell-Debug-Stream.txt
  • Powershell-Error-Stream.txt
  • Powershell-Info-Stream.txt
  • Powershell-Verbose-Stream.txt
  • Powershell-Warning-Stream.txt

The contents of those files should be fairly straight forward, with the exception of the first one. The PowerCLI-Main-Log.svclog is a collection of diagnostic traces. These traces contain all of the pertinent information about the cmdlets being used, how it is being interpreted by PowerShell, and then the underlying call to the vCenter. The svclog file can be opened with the Microsoft Service Stack Trace Viewer. This application is available as part of the Windows SDK, available here: Windows SDK Archive

The following screenshot is a look at the actual exception being returned by the API service:
Example: Reading the svclog exception

We can see the server response was an internal server error, which has a status code of 500. We can then further read through the individual trace to see the properties and methods being used. We also have the option to look at the traces before and after the call happened to see each of the steps being performed as part of the code entered in our $errorCode scriptblock.

Summary

PowerCLI is supported by VMware and the Get-ErrorReport cmdlet was recently improved in PowerCLI 11. The upgrade helps to streamline the support experience by creating a PowerCLI support bundle which can be provided to VMware support. This support bundle includes all of the required environmental information that VMware support will need to start troubleshooting the issue being reported.

The next time you need to open a support ticket on PowerCLI, make sure to use Get-ErrorReport and let us know your feedback!

Updating PowerCLI Local OS Support

VMware PowerCLI has gone through quite a few changes over the past couple years. This includes what operating systems (OS) PowerCLI can run on! The most significant update was the addition of MacOS and Ubuntu. However, as the PowerCLI team continually evaluates which OSes we should support, there are also times where OSes need to be removed. With that said, in a future release, PowerCLI will be deprecating local OS support for Windows 7 and Windows Server 2008 R2.

It is important to note that this update will not impact whether or not PowerCLI can operate on those deprecated OSes. We are simply removing them from our testing process.

With that said, in a future release of PowerCLI, the local OS support will be updated to be the following:

OS Type Version (64-Bit)
Server Windows Server 2016
Server Windows Server 2012 R2
Workstation Windows 10
Workstation Ubuntu 16.04
Workstation MacOS 10.12

If you’re interested in more information about the PowerCLI testing process, I would highly recommend checking out the following VMworld session recording: Development at VMware: A Look at How PowerCLI Has Evolved Over the Years

New Release: PowerCLI 11.0.0

PowerCLI has been moving at quite the rapid pace over the last 2 years. In 2018, we’ve been releasing roughly every other month to make sure we get the latest features, performance improvements, and updates available as quickly as possible. Well, it’s been two months and we’re not going to break this trend. Today, we are releasing PowerCLI 11.0.0!

PowerCLI 11.0.0 comes with the following updates:

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

Let’s take a more in-depth look at some of these updates.

New Security Module

There has been a tremendous amount of improvements around security for vSphere lately. The new VMware.VimAutomation.Security module ensures you have the ability to automate these new features.

The Security module includes the following cmdlets:

  • Get-SecurityInfo
  • Get-VTpm
  • Get-VTpmCertificate
  • Get-VTpmCSR
  • New-VTpm
  • Remove-VTpm
  • Set-VTpm
  • Unlock-VM

Also, thanks to the Security module (with a little help from the Storage module), several other cmdlets are receiving enhancements as well:
New-VM has added the following parameters:

  • KmsCluster
  • StoragePolicy
  • SkipHardDisks
  • StoragePolicy
  • ReplicationGroup
  • StoragePolicyTarget

Set-VM has added the following parameters:

  • DisableEncryption
  • KmsCluster
  • SkipHardDisks
  • StoragePolicy

Set-VMHost has added the following parameter:

  • KmsCluster

Set-HardDisk has added the following parameters:

  • DisableEncryption
  • KmsCluster
  • StoragePolicy

New-HardDisk has added the following parameters:

  • KmsCluster
  • StoragePolicy

Host Profile Updates

There have been a lot of requests coming in for updates to the set of cmdlets available to manage Host Profiles. The VMware.VimAutomation.Core module has some updates you’ll want to check out!

The following cmdlets have been added to help manage Host Profiles:

  • Get-VMHostProfileUserConfiguration
  • Set-VMHostProfileUserConfiguration
  • Get-VMHostProfileStorageDeviceConfiguration
  • Set-VMHostProfileStorageDeviceConfiguration
  • Get-VMHostProfileImageCacheConfiguration
  • Set-VMHostProfileImageCacheConfiguration
  • Get-VMHostProfileVmPortGroupConfiguration
  • Set-VMHostProfileVmPortGroupConfiguration

Storage Module Updates

The VMware.VimAutomation.Storage module has grown by leaps and bounds in the last couple releases. This release adds two new cmdlets and quite a few updates to existing cmdlets. Some of the improvements include an update to support predefined time ranges when using Get-VsanStat. Get-VsanDisk has some additional properties which are returned, such as: capacity, used percentage, and reserved percentage. Also receiving an update is the Get/Import/Export-SpbmStoragePolicy cmdlets, as they now support storage policy components.

The following cmdlets have been added to help automate vSAN:

  • Get-VsanObject
  • Get-VsanComponent

More details on these updates for vSAN can be found on the Virtual Blocks blog, by Jase McCarty: More vSAN Cmdlets in PowerCLI 11!

vCloud Director Updates

This update is another direct result from feedback. There has been an impressive amount of people requesting updates to the VMware.VimAutomation.Cloud module. With this release, we are updating the module to support vCloud Director 9.5. There are also a couple of new cmdlets being added.

The following cmdlets have been added to help automate vCloud Director networking:

  • Get-EdgeGateway
  • New-OrgVdcNetwork
  • Remove-OrgVdcNetwork
  • Set-OrgVdcNetwork

Other Improvements and Updates

There are also a handful of updates which are all due to community feedback! There has been an update to the output when using New-VM combined with the ‘Confirm’ parameter so that the output matches that of the created VM. An update to Get-View has been added to help resolve a Vim error being received when the ‘Property’ parameter was specified. Another fix was when Get-VM would result in an error of ‘Value cannot be null’. The last big issue, there has been an update to the way Get-NetworkAdapter outputs a NSX-T logical network backed portgroup.

Summary

PowerCLI 11.0.0 has been released and there are a ton of fantastic new additions. Over 20 new cmdlets have been added to help automate vCloud Director networking, virtual TPM settings, Host Profile configurations, and VMware Cloud on AWS networking. More than 10 cmdlets have been enhanced to add newly released features. Plus, a handful of updates to improve the overall quality and reliability.

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

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

Update-Module VMware.PowerCLI

Let us know in the comments what you’re most excited about!

PowerCLI at VMworld EMEA 2018

VMworld Barcelona

The schedule builder is live, so that means VMworld EMEA is almost here! Earlier this year, at VMworld US, we had an amazing amount of PowerCLI and automation-based sessions and we’re bringing a bunch of them to Barcelona! There are more sessions than last year, a re-vamped PowerCLI Hands-On-Lab including an expert-led Hands-On Lab, a solid set of community sessions, and the return of the fantastic Hackathon event. If you haven’t already registered, the time is quickly ticking away!

Make sure to add the following sessions to your schedule and catch up with the PowerCLI team and the amazing PowerCLI community members!

Sessions

Session: DEV3504BE – Development at VMware: A Look at How PowerCLI Has Evolved Over the Years
Date: Tuesday, Nov 6, 5:00 p.m. – 6:00 p.m.
Speakers: Kamen Nikolov & Kyle Ruddy
Kamen and Kyle will give attendees a behind the scenes look into the PowerCLI development process and the many ways PowerCLI has evolved over the last 10+ years.

Session: VIN1992BE – A Deep(er) Dive with PowerCLI 10
Date: Thursday, Nov 8, 9:00 a.m. – 10:00 a.m.
Speakers: Luc Dekens & Kyle Ruddy
Luc and Kyle will take a look at the more advanced use-cases when using PowerCLI to automate actions in your environment. From proper object handling to diagnosing speed issues to debugging and more, this session is going to be a deep dive into the “what’s possible” with PowerCLI.

Session: HCI2522BE – Getting Started with vSAN Automation
Date: Thursday, Nov 8, 3:00 p.m. – 4:00 p.m.
Speakers: Alan Renouf & William Lam
Alan and William show attendess how to get started automating all the aspects of vSAN with tools such as PowerCLI and the vSAN management SDKs.

Session: NET1642BE – NSX-PowerOps: Day2 Ops, NSX Health, Security, and Automated Documentation
Date: Thursday, Nov 8, 12:00 p.m. – 1:00 p.m.
Speakers: Hammad Alam & Puneet Chawla
Hammad and Puneet will discuss a community-built tool, NSX-PowerOps, which uses tools like PowerCLI and PowerNSX to create documentation of your environment.

Session: VIN2527BE – Top 10 Automation Requests and How You Can Save Time
Date: Tuesday, Nov 6, 2:00 p.m. – 3:00 p.m.
Speakers: Alan Renouf & William Lam
Alan and William walk through the top ten automation requests and how to complete them in a variety of languages, including PowerCLI.

VMware {code} Power Sessions

Session: CODE5609E – It’s Magic! Automating VMware Cloud on AWS
Date: Wednesday, Nov 7, 1:30 p.m. – 2:00 p.m.
Speaker: Adam Osterholt
Adam discusses how to start interacting with the VMware Cloud on AWS APIs with PowerCLI to automate your scalable, highly resilient, infrastructure in the cloud.

Session: CODE5606E – Building a Front-End for PowerCLI Scripts
Date: Wednesday, Nov 7, 2:30 p.m. – 3:00 p.m.
Speaker: Lino Telera
Lino will show how one could interact with their PowerCLI scripts using middleware and frontend frameworks.

Session: CODE5629E – vSphere Integration and Automation: Choose Your Tool
Date: Wednesday, Nov 7, 3:30 p.m. – 4:00 p.m.
Speaker: Ivaylo Ivanov
Ivaylo will walk attendees through a comparison of the numerous ways users can choose to automate their vSphere environments.

vBrownBag Sessions

Session: VMTN5507E – Dev 4 the Ops Team
Date: Wednesday, Nov 7, 2:30 p.m. – 2:45 p.m.
Speaker: Chris Bradshaw
Chris will walk through the importance of having some form of coding experience and some easy ways to start, using none other than PowerCLI.

Hands on Labs

Lab: SPL-1911-05-SDC_E – VMware vSphere Automation – PowerCLI
Date: Anytime the HOL area is open and available
Get hands-on with VMware PowerCLI. Gain familiarity with the tool, and then dive deeper into the functionality available with real world examples. Both new and experienced users are sure to learn something new about automating their environments.

Session: ELW-1911-05-SDC_E – Expert-Led Workshop – VMware vSphere Automation – PowerCLI
Date: Tuesday, Nov 6, 2:00 p.m. – 3:30 p.m.
Speaker: Howard Shoobe
Howard will show attendees how to get hands-on with VMware PowerCLI. You will gain familiarity with the tool, and then dive deeper into the functionality available with real world examples.

Hackathon

And last, but certainly not least, the VMware {code} Hackathon! If you’ve never been or haven’t heard of it, this is a fantastic event to get involved with other community members to do some coding in a cool location! There’s no requirement to even know how to code.

Session: CODEHACK – VMware {code} Hackathon
Date: Monday, Aug 27, 6:30 p.m. – 11:30 p.m.
Join VMware {code} for the third annual hackathon!

Summary

If you’re looking for PowerCLI content, VMworld EMEA is the place to be! With 5 sessions, 4 community sessions, multiple meet the experts, and several hands-on activities, there’s something for everyone regardless of skill level. Make sure you’re registered for VMworld and get these sessions added to your schedule today!

Discovering VMs with Specific VMware Tools Versions

A recent knowledge base (KB) article was released regarding an issue impacting a specific version of VMware Tools. The KB in question is 57796, which describes the possibility of a guest level network connectivity issues or even a purple diagnostic screen (PSOD).

Before getting to the discovery process, I want to cover some of the specifics for this KB. I do this because we’re going to need to be aware of these as we build out our one-liners and the subsequent reporting script.

The issue in the KB may be found when combined with the following:

  • VMware Tools version 10.3.0
  • ESXi 6.5 Hosts
  • VM Hardware 13
  • Windows Server 2012 or newer -OR- Windows 8 or newer

Now that we know what we’re looking for, lets cover some methods we’ll be using to make this easier.

Properties, Hash Tables, and More

Since we’re going to be focused on VMs, we’ll be making use of the Get-VM cmdlet. However, the information we need isn’t available as part of the cmdlet’s default response. We’ll need to choose specific VM properties to display.

Discovering those properties can be done in a couple different ways. If we just want to find out what properties are available and how they’re defined, we can use the Get-Member cmdlet. If we want to find out the values for all of those properties, we can use the Format-Table cmdlet. Both of these cmdlets can be used in the same way, by using the Get-VM cmdlet and passing the output to the desired cmdlet with a pipeline.

Example Code:
Show Properties for Virtual Machine Objects

In this case we’re going to be referencing the ‘Name’ property and an additional property which is available as part of the listed ‘Guest’ property, which is actually defined as an object. The property we’re looking for in the Guest object is named ‘ToolsVersion’.

We can output these specific properties using the Select-Object cmdlet. In order to properly display the ‘ToolsVersion’ property, we’ll be using a hash table to create a calculated property. The hash table is created with an ampersand and curly brackets. We can establish the calculated property with ‘name’ and ‘expression’ values.

Listing VMs and their VM Tools Versions

First things first, let’s figure out how to display our VMs’ names and their VM Tools version using the Select-Object cmdlet and a calculated property for the Tools Version.

Example Code:

PowerCLI - Get VMs and list Name and Tools Version

Listing VM Specific Information from the KB

In the example above, we can see there’s one particular VM which may be impacted by the KB. So, the next step is to obtain the rest of the information about each of the VMs.

We’ve already obtained the VM’s name and VMware Tools version properties. Now we need to figure out the ESXi host version, VM Hardware version, and what OS is in use.

The ESXi host version can be found using the VMHost property. This property returns the full ESXi host object. Since we’re working with the full object, we can return the ‘Version’ property by way of the calculated property method we used previously.

The VM Hardware version can be found by referencing the ‘HardwareVersion’ property.

The last property we’re interested in is the OS type. This too is available as a sub-property to ‘Guest’. There’s a couple to choose from, but for this example we’ll start with the ‘GuestFamily’ property.

Example Code:

Obtain requisite information for each VM per the KB

Listing Only Applicable VMs

For our last example, let’s take this process a step further and display only the susceptible VMs.

We’ll do this with the Where-Object cmdlet. We’ll use this cmdlet, in combination with a script block, to validate that each of those properties match those items listed in the KB.

We’ll be validating the following properties:

ToolsVersion 10.3.0
VMHostVersion 6.5.0
HardwareVersion vmx-13
GuestFamily windowsGuest

Example Code:

View only potentially impacted VMs

Summary

Knowledge Base article 57796 details a specific issue which has the potential to impact environments. We can use PowerCLI to easily poll our environment to obtain, and even isolate, the specific VMs which may be impacted.

Let us know in the comments how you’re building on what’s available here to create reports and even remediations!