Home > Blogs > VMware PowerCLI Blog > Monthly Archives: January 2018

Monthly Archives: January 2018

Windows Defender reports false positive for PowerShell Modules

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

This is a FALSE POSITIVE widely affecting the PowerShell community.

https://social.technet.microsoft.com/Forums/en-US/40fa56dd-b73f-456a-9d97-cdb4500bc7ed/latest-updates-indicated-peasectoa-infection-?forum=WindowsDefenderATPPreview

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

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

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

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

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

 

PowerCLI Offline Installation Walkthrough

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

VMware Profile on PowerShell Gallery

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

Preparing the Offline System

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

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

Uninstalling Prior PowerCLI Versions

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

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

Accessing the PowerCLI Modules

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

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

PowerShell PSVersionTable Output

Online System with PowerShell 5.x:

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

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

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

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

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

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

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

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

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

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

Save-Module Example and associated output

Adding PowerCLI to the Offline System

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

By default, the PSModulePath variable contains the following directories:

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

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

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

Wait… It’s Not Working For Me!

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

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

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

Good news though, there are a couple workarounds available!

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

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

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

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

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

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!

If you’re looking to install PowerCLI and have direct internet access, use the following link: PowerCLI – Online Walkthrough
If you’re looking to install PowerCLI on a MacOS based system, use the following link: PowerCLI – MacOS Installation Walkthrough

Powershell Core 6.0 Released

It’s an exciting time for infrastructure automation!

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

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

Coming Soon…

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

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

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!