Home > Blogs > VMware PowerCLI Blog > Tag Archives: PowerShell

Tag Archives: PowerShell

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!

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:

PowerCLI 6.5.1 Installation Walkthrough

We released PowerCLI 6.5.1 two weeks ago and the response has been incredible! The VMware.PowerCLI module is closing in on 4,000 downloads from the PowerShell Gallery and we’ve received a ton of good feedback.

There seems to be quite a few questions and comments over this new installation method so I created a walkthrough video to illustrate the process for PowerShell version 5.0 as well as for versions 3.0 and 4.0. We’ve also collected the most common errors and issues during the installation process and included troubleshooting steps for those below.

Walkthrough Video

Common Troubleshooting Steps

If there happens to be an issue during the installation process, here’s a couple of the top tips we have seen on working around them:

  • The process cannot access the file ‘C:\Users\…\AppData\Local\Temp\…’
    • Ensure previous versions of PowerCLI are uninstalled and all PowerShell sessions are closed.
    • Verify the file isn’t being blocked by an antivirus software.
  • A command with name ‘verb-noun’ is already available on this system.
    • This is due to a module already available on the system containing that cmdlet. The more common example modules include FailoverClusters and HyperV.
    • Append “-AllowClobber” to the Install-Module command line.
      Example: Install-Module –Name VMware.PowerCLI –Scope CurrentUser –AllowClobber
  • No match was found for the specified search criteria and module name ‘VMware.PowerCLI’
    • This could be due to a lack of connectivity to the PowerShell Gallery.
    • If a proxy can be used, the “Install-Module” cmdlet can configure proxy connectivity with the “Proxy” and “ProxyCredential” parameters.
      Example: Install-Module –Name VMware.PowerCLI –Scope CurrentUser –Proxy ‘http://my.proxy.company.com’
  • Could not get response from query ‘https://www.powershellgallery.com/api/v2/package/VMware.VimAutomation.Core/…’
    • This warning is just indicating there is an issue establishing connectivity to the PowerShell Gallery. Retry the installation at a later point in time and it should succeed.

Summary

We are really excited about this release and what this means for the future of PowerCLI! Upgrade to PowerCLI 6.5.1 today, and keep that feedback rolling in!

Thoughts around PowerCLI and the Powershell Gallery

I am *very* excited to share some thoughts and possibilities for PowerCLI.

Packaging and Installation are big areas we have been looking at. We have heard loud and clear that our customers wanted to embrace modules and in our recent releases we have moved away from snapins into modules. We’re now looking at how we package the modules and deliver them to our users.

One possibility would be releasing PowerCLI exclusively from the Powershell Gallery, the central repository for Powershell modules. The benefits of this would be great, as it provides easy installation and upgrade, follows Powershell patterns for modules, and most importantly would allow us to deliver PowerCLI to multiple platforms, such as Linux and MacOS.

Here is an idea of what we are currently thinking:

  1. You would need to make sure you have the latest Powershell. WMF 5.1 is required for the PowershellGet cmdlets, which includes install-module. (You may want to do this now!)
  2. Make sure $env:PSModulePath includes C:\Program Files\WindowsPowerShell\Modules . This is only precautionary because it should already be set, but you should check anyway.
  3. Prior to installation of the PowerCLI from the Microsoft Gallery you would need to uninstall any previous version of PowerCLI that was installed by MSI.
  4. You would no longer have PowerCLI shortcuts on your desktop. PowerCLI would be immediately available when you run powershell, no Import-Module required. If you really miss the icon, find me at a conference and I’ll give you a sticker! 🙂
  5. Installation of PowerCLI on machines that cannot access the Powershell Gallery can be done by saving the module to a thumb drive or network share accessible to the installation target and dropping the files in the module folder of the destination computer or using Install-Module with a path to the downloaded file.
  6. We are thinking about using Update-Module in the future to make geting the latest bits faster and easier!

I understand that change can be hard, so I’m giving you the opportunity to tell us why (or why not) a Powershell Gallery installation/update would not work for you.

Regarding the results from the survey we recently held, an extremely high percentage of the respondents prefer the Gallery installation for ease of installation and updates. Still, there were a few respondents that had some concerns that I want to address here.

  1. “The Powershell Gallery is not as secure as downloading an MSI from vmware.com” – This is not true. We digitally sign all PowerCLI files as we always have, guaranteeing authenticity. PowershellGet has built-in verification of the digital signature, and will not install unsigned modules unless you explicitly skip the publisher check.
  2. “This makes offline installation/upgrades much harder” – So far, I’ve identified two different methods of offline installation and both require less steps (and ZERO mouse clicks). Method one uses Save-Module to copy to a network drive accessible by the ‘offline’ machine. You could also save to a USB drive or any other storage location that your installation target can access. Method two uses Invoke-WebRequest to download the package and can again be saved to a location of your choosing. Either of these options are still far easier than the current process.

Conclusion

In my prior life as a customer, I could only dream of installation and upgrades being this easy. By releasing to the gallery, it would not only make *that* dream come true, but would also give us the ability to accelerate our releases to get improvements out for you to enjoy much sooner.

Added to this we would be bringing PowerCLI back in line with the PowerShell patterns and ensuring future powershell enhancements made around modules and module tooling could easily be consumed with PowerCLI.

I hope you join with me in the excitement of the amazing opportunities we have with PowerCLI!

What are you excited or concerned about with a Powershell Gallery release? Let us know in the comments here!

 

Help Shape PowerCLI’s Future – Poll

Community feedback has always played an important role in how PowerCLI has evolved and improved. Whether it’s the desire to convert from snapins to modules, adding additional functionalities to existing cmdlets, or creating brand new cmdlets and modules, the feedback we receive has always been extremely important.

This time we have an ask to help shape the future of PowerCLI’s packaging, installation, and upgrade process in the form of an online poll available here: https://www.surveymonkey.com/r/HGQDJFQ

Giving a little context around the poll, there have been a lot of asks around getting PowerCLI into the PowerShell Gallery. The PowerShell Gallery is an online repository containing an amazing amount of PowerShell modules and scripts. The PowerShell Gallery allows users the ability to search, install, update, and uninstall these resources directly from a PowerShell session.

Taking a look at how we distribute PowerCLI today, this move would have some major impacts. Instead of logging into my.vmware.com then downloading and installing PowerCLI through an MSI, users could simply open PowerShell and run:

Updating would change as well, as users could then run:

With the changes in these installation methods, it would also mean the start menu and desktop shortcuts would no longer be automatically created at time of install.

Last big impact would be to offline installations. Since the PowerShell Gallery is an online repository, users would have to access the gallery using a system that has internet access, running a command that looks something like the following, and then completing the install by copying the module over to the offline system where it can now be imported:

The last question is optional and is asking for an email address since we’ll have some goodies available as giveaways!

If you’d like some additional information about the PowerShell Gallery, see the following link: https://msdn.microsoft.com/en-us/powershell/gallery/psgallery/psgallery_gettingstarted

Here’s a link to the survey: https://www.surveymonkey.com/r/HGQDJFQ

Again, thanks to everyone for helping make PowerCLI awesome!

Spotlight on the Move-VM Cmdlet including PowerCLI 6.5 Enhancements

VMware PowerCLI 6.5’s release introduced a lot of new cmdlets and improvements to existing cmdlets. One of my favorite improved cmdlets has to be Move-VM. Move-VM was already a very versatile cmdlet before this new release. It could be used to move a VM between hosts, datastores, resource pools, clusters, to new folders, to a vApp, and so forth. Now, with PowerCLI 6.5 R1, Move-VM can move VMs between vCenters! We can even take that a step further, Move-VM can move VMs to vCenters which are not linked together by SSO domain. That’s something that cannot be done by the web client!

Let’s start by taking a look at the newest addition to the cmdlet, migrating VMs between vCenters.

Cross vCenter vMotion

Cross vCenter vMotion was introduced with vSphere 6.0. It’s proved to be a great feature that opens up new options in flexibly managing a vSphere environment. One of the limitations in using cross vCenter vMotion by way of the Web Client is that it can’t migrate VMs between SSO domains. This is where the usage of PowerCLI is hugely beneficial because PowerCLI allows users to fill that gap. The key to PowerCLI being able to overcome that limitation is due to its ability to connect to multiple vCenter servers at the same time.

In order to perform a cross vCenter vMotion, there are a couple parameters that are needed:

  • Active Connection to both Source and Destination vCenters
  • Source vCenter
    • VM
    • VM’s Network Adapter/s
  • Destination vCenter
    • Destination ESXi Host
    • Destination Datastore
    • Destination PortGroup/s

Here’s some example code on how that can be accomplished:

I also want to filling in a couple informative gaps in the above code:

  • Due to the cross vCenter vMotion functionality being added in as part of vSphere 6.0, it can only be performed against vCenter servers of 6.0 and newer.
  • The destination parameter only accepts an individual ESXi host. A workaround could look like the following code:
  • The datastore parameter only accepts an individual datastore. A workaround could look like the following code:

Multiple NIC VM vMotion

If you look at the example code above, specifically at the network pieces, you’ll notice that it only focuses on moving a VM with a single NIC. However, both the NetworkAdapter and PortGroup parameters accept arrays. This means that you can pass multiple objects to those parameters.

One key thing to note is that the first item in each array will be referenced together, then the second items will be referenced together, and so on and so forth. If there are multiple network adapters and only one portgroup specified, the network adapters will all be assigned to the same portgroup. If there is only a single network adapter and multiple portgroups specified, the command will error out.

Here’s an example of doing a Cross vCenter vMotion on a VM that has multiple NICs:
Move-VM with Multiple Network Adapters

Conclusion

The above examples are just the tip of showing just how versatile the Move-VM cmdlet really is. Let us know how you’re using Move-VM in your environment in the comments below!

For more information on its use in your environment, see the PowerCLI cmdlet reference on Move-VM.

Saying Farewell to Snapins!

One of the key improvements to the VMware PowerCLI 6.5 R1 release is the absence of PowerShell snapins. All of the remaining snapins have been converted to modules!

Snapin History

If you don’t know why this is such a big deal, let me take a second to cover some history on snapins. Going back to the days of PowerShell version 1, snapins were the only way to extend the shell, or add additional features and functionalities. The issue with snapins begin due to how they can only be written in a .NET programming language and then have to be assembled before being handed off to the user. Then, once the user has them, the issues continue due to the snapins having to be installed and registered to each individual system a user wishes to use them on. Snapins also lack the ability to explicitly define dependencies, this causes issues for a product like PowerCLI which is comprised of several individual components.

PowerShell version 2 introduced modules, which resolved a majority of those issues. Modules can still be written in any .NET programming language, or can even be written in PowerShell itself! Modules are mobile and don’t require any registrations. Once the modules are in hand, they can be referenced automatically by placing them in one of the proper folders or by specifying the directory path to where they reside for each system requiring access.

Finding Snapins

This change in architecture introduces an issue for already created scripts which are trying to load the old VMware snapins. Instead of performing something that looks like:

Add-PSSnapin –Name VM*

We’re recommending a replacement from that command to this command:

Get-Module –ListAvailable VM* | Import-Module

We’re not going to leave the rest to you to handle. There’s some functions which have been added to the PowerCLI Community Repository which will point out which scripts contain that line. There’s also a function which can comment out that line and add the new recommended command. These functions are available within the Update_PowerCLI_Scripts.ps1 script.

The first function is “Get-PowerCLISnapinUse” and will show what scripts (.ps1 extensioned) include the string “Add-PSSnapin*VM*” and will display the file name, line where the string resides, path to the directory, and the full path of the file.

Get-PowerCLISnapinUse Example Output

The second function is “Update-PowerCLISnapinUse” and is based around adding the new Import-Module command and commenting that string out.

Results from using Update-PowerCLISnapinUse

Additionally, if you’ve already updated your version of PowerCLI, you may have noticed the installation directory has changed as well. If you have the “Initialize-PowerCLIEnvironment” script hardcoded into your scripts, there are also some functions to handle that as well. The functions for that are done by way of “Get-PowerCLIInitialization” and “Update-PowerCLIInitialization”. These functions work similarly to the above, however the “Update-PowerCLIInitialization” function just updates the directory path and does not comment anything out.

Conclusion

VMware PowerCLI moving over to be completely modules is a huge accomplishment in this newest release. As always, it’s backwards compatible and we recommend upgrading to the latest version.

You can find the PowerCLI 6.5 Release 1 download HERE.

PowerCLI Core Fling – Available For Download!

I am extremely excited to announce that the PowerCLI Core Fling has been released and is available for download!

Before getting to the download link, let’s cover a couple things first.

This release is based on, and requires, Microsoft PowerShell Core and .NET core. If you do not already have it installed, see the accompanied documentation for a walkthrough on getting started.

Feedback is very much welcomed. Please use the Fling site’s comment section to submit feedback. Keep in mind, we improve the product based off of your feedback, so please do let us know!

Enough suspense, the PowerCLI Core Fling is available here: https://labs.vmware.com/flings/powercli-core

Check out this demo of the install process on a Linux system:

Enjoy, and don’t forget the feedback!

VMworld Sneak Peek: INF8038 – Getting Started with PowerShell and PowerCLI

VMworld US 2016

VMworld Session INF8038 is going to be great regardless of whether you’re new to PowerShell or just in need of a refresher. The session will be packed full of information from getting your PowerShell profile setup to understanding the difference between a module and a snap-in, then starting down the path of using logic statements and even creating your own scripts.

Check out this video by Chris Wahl to get a sneak peek on what to expect:

Don’t forget to register for the session by way of the VMworld Content Catalog!