PowerCLI script to report VMtools version(s)

UPDATE 2018-02-05: I have just been told about very nice PowerCLI command-lets allowing to manage VMtools.  Leveraging command-lets Get-VMToolsInfo, Get-VMToolsGuestInfo and Get-VMByToolsInfo is definitely the better way then my script below. All VMtools management command-lets are available on GitHub here
https://github.com/vmware/PowerCLI-Example-Scripts/blob/master/Modules/VMToolsManagement/VMToolsManagement.psm1

But if you are interested in my approach and simple script below I will be more than happy if it helps you.

###################################################################

This week I had a talk with one of my customers about VMtools versions and benefits of VMtools updates/upgrades. Few months ago I wrote another blog post discussing centralized version of VMtools repository (aka shared productLocker) so you can read it here.

Nevertheless, in large environments with multiple vCenters and thousands of VMs it is pretty handy to have single report with all VMtools versions to be able to asset and plan potential VMtools update/upgrade.

The problem with VMtools versions is that APIs reports just a single integer number of VMtools identification like 9354, 10246, etc. These numbers are also visible as Tools version on NGC/VI Client. However, vSphere admins are more familiar with human readable VMtools version also visible in guest OS which looks like 8.3.19, 9.4.6, 10.0.8, etc. For all VMtools version numbers and mapping you can check text file at https://packages.vmware.com/tools/versions

I have invested an hour or so to write simple PowerCLI script reporting VMtools identification and also human readable version for all VMs in particular vCenter or even across multiple vCenters. I have also included VM hardware version which can be handy information as well.

So initial PowerCLI code is below and the latest version will always appear on github here.

 ######################################################################################################################################  
 # Author: David Pasek  
 # E-mail: david.pasek@gmail.com  
 # Twitter: david_pasek  
 # Creation Date: 2016-11-25  
 #  
 # Use case:  
 #  Key use case of this script is to report VMtools from all VMs in vCenter  
 #  
 # Disclaimer:  
 #  Use it on your own risk. Author is not responsible for any impacts caused by this script.   
 ######################################################################################################################################  
 #   
 # CHANGE FOLLOWING VARIABLES BASED ON YOUR SPECIFIC REQUIREMENTS   
 # vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv  
 #  
 # Report type - table, grid, file, csv-file  
  $REPORT_TYPE = "csv-file"  
 # Report file name without file extension. Extension is automatically added. File is created in current working directory.   
  $REPORT_FILE_NAME = "report-vmtools"  
 ######################################################################################################################################  
 Clear-Host  
 # We need VMware PowerCLI snapin  
 $o = Add-PSSnapin VMware.VimAutomation.Core  
 $o = Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false  
 # Connect to vCenter  
 Write-Host "Connecting to vCenter ..."  
 $VC = Read-Host "Enter one vCentre Server or multiple vCenter servers delimited by comma."  
 Write-Host "Enter vCenter credentials ..."  
 $CRED = Get-Credential  
 Connect-VIServer -Server $VC -Credential $CRED -ErrorAction Stop | Out-Null  
 # Add new property (ToolsVersion) to VM  
 New-VIProperty -Name ToolsVersion -ObjectType VirtualMachine -ValueFromExtensionProperty 'Config.tools.ToolsVersion' -Force | Out-Null  
 # Initalize report  
 $Report = @()  
 foreach ($vm in Get-VM) {  
  # Numbers mapping is from https://packages.vmware.com/tools/versions  
  Switch ($vm.ToolsVersion) {  
      7302 {$GuestToolsVersion = "7.4.6"}  
      7303 {$GuestToolsVersion = "7.4.7"}  
   7304 {$GuestToolsVersion = "7.4.8"}  
   8192 {$GuestToolsVersion = "8.0.0"}  
   8194 {$GuestToolsVersion = "8.0.2"}  
   8195 {$GuestToolsVersion = "8.0.3"}  
   8196 {$GuestToolsVersion = "8.0.4"}  
   8197 {$GuestToolsVersion = "8.0.5"}  
   8198 {$GuestToolsVersion = "8.0.6"}  
   8199 {$GuestToolsVersion = "8.0.7"}  
   8290 {$GuestToolsVersion = "8.3.2"}  
   8295 {$GuestToolsVersion = "8.3.7"}  
   8300 {$GuestToolsVersion = "8.3.12"}  
   8305 {$GuestToolsVersion = "8.3.17"}  
   8306 {$GuestToolsVersion = "8.3.18"}  
   8307 {$GuestToolsVersion = "8.3.19"}  
   8384 {$GuestToolsVersion = "8.6.0"}  
   8389 {$GuestToolsVersion = "8.6.5"}  
   8394 {$GuestToolsVersion = "8.6.10"}  
   8395 {$GuestToolsVersion = "8.6.11"}  
   8396 {$GuestToolsVersion = "8.6.12"}  
   8397 {$GuestToolsVersion = "8.6.13"}  
   8398 {$GuestToolsVersion = "8.6.14"}  
   8399 {$GuestToolsVersion = "8.6.15"}  
   8400 {$GuestToolsVersion = "8.6.16"}  
   8401 {$GuestToolsVersion = "8.6.17"}  
   9216 {$GuestToolsVersion = "9.0.0"}  
   9217 {$GuestToolsVersion = "9.0.1"}  
   9221 {$GuestToolsVersion = "9.0.5"}  
   9226 {$GuestToolsVersion = "9.0.10"}  
   9227 {$GuestToolsVersion = "9.0.11"}  
   9228 {$GuestToolsVersion = "9.0.12"}  
   9229 {$GuestToolsVersion = "9.0.13"}  
   9231 {$GuestToolsVersion = "9.0.15"}  
   9232 {$GuestToolsVersion = "9.0.16"}  
   9233 {$GuestToolsVersion = "9.0.17"}  
   9344 {$GuestToolsVersion = "9.4.0"}  
   9349 {$GuestToolsVersion = "9.4.5"}  
   9350 {$GuestToolsVersion = "9.4.6"}  
   9354 {$GuestToolsVersion = "9.4.10"}  
   9355 {$GuestToolsVersion = "9.4.11"}  
   9356 {$GuestToolsVersion = "9.4.12"}  
   9359 {$GuestToolsVersion = "9.4.15"}  
   9536 {$GuestToolsVersion = "9.10.0"}  
   9537 {$GuestToolsVersion = "9.10.1"}  
   9541 {$GuestToolsVersion = "9.10.5"}  
   10240 {$GuestToolsVersion = "10.0.0"}  
   10245 {$GuestToolsVersion = "10.0.5"}  
   10246 {$GuestToolsVersion = "10.0.6"}  
   10247 {$GuestToolsVersion = "10.0.8"}  
   10249 {$GuestToolsVersion = "10.0.9"}  
   10252 {$GuestToolsVersion = "10.0.12"}  
   10272 {$GuestToolsVersion = "10.1.0"}  
   0   {$GuestToolsVersion = "Not installed"}  
   2147483647 {$GuestToolsVersion = "3rd party - guest managed"}  
      default {$GuestToolsVersion = "Unknown"}  
      }  
  $vminfo = New-Object -Type PSObject -Property @{  
             Name = $vm.Name  
     VMhardwareVersion = $vm.Version  
           ToolsVersion = $vm.ToolsVersion  
           GuestToolsVersion = $GuestToolsVersion  
      }  
  $Report += $vminfo  
 }  
 # Show report  
 Switch ($REPORT_TYPE) {  
      "grid"   { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | Out-GridView }  
   "file"   { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | Out-File -FilePath "$REPORT_FILE_NAME.txt" }  
   "csv-file" { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | export-csv "$REPORT_FILE_NAME.csv" }  
   default  { $Report | select Name,VMhardwareVersion,ToolsVersion,GuestToolsVersion | Format-Table }  
 }  
 Disconnect-VIserver -Server $VC -Force -Confirm:$false  

The script can be configured for different report types by changing variable $REPORT_TYPE

Following report types are supported:

• Standard PowerShell table report to output terminal (table)
• PowerShell GridView (grid)
• Standard text file including same content as table (file)
• Comma separated values file (csv-file)

Different sample reports are visible in screenshots below

CSV-FILE

FILE

GRID

Hope this helps some other folks in VMware community. Any feedback or feature requests are welcome.

Related links:

• VMware Tools 10 and "shared productLocker"
• VMware Tools 10.0.8 is now GA
• Powershell Script Upgrade VMware tools without a reboot - looks interesting but I did not test it so far.

How to change default policy of VMware Virtual Distributed Switch (VDS)

The main advantage of VMware virtual distributed switch (VDS) over VMware virtual standard switch (VSS) is the centralized configuration which is pushed to ESXi hosts. This centralized management provides uniform virtual switch configuration across all ESXi hosts in VDS scope. Virtual switch specific settings can be generally reconfigured for each port-group. In other words, port-group is a virtual switch construct which defines how particular group of ports will behave. Port-groups inherit default settings from virtual switch.

So far so good. However, VDS and SVS differ. In VDS, you can change default settings of the switch and all port-groups on that particular switch inherit these settings. However, this is not possible on VDS. Actually, it is not possible through vSphere Client. Through, GUI you can change just settings of particular port-group as you can see on screenshot below.

DVS port-group various settings.

It is very annoying and time consuming to change settings for each port-group manually. There is also very high probability of inconsistent settings across port-groups. To mitigate challenges described above, you can leverage PowerCLI and change default VDS settings (policy) as you can see in the example below. This will change default VDS settings and all new port-groups will be configured consistently and as required by particular design.

PowerCLI script below shows how to change default settings for traffic Shaping (in/out) and uplink teaming policy to LACP. This particular example shows how to configure LAG teaming with IP src/dst load balancing but any other teaming and load balancing can be used as well.

 $vDSName = “vDS01”  
 $vds = Get-VDSwitch $vDSName  
 $spec = New-Object VMware.Vim.DVSConfigSpec  
 $spec.configVersion = $vds.ExtensionData.Config.ConfigVersion  
 $spec.defaultPortConfig = New-Object VMware.Vim.VMwareDVSPortSetting

  
 $inShapingPolicy = New-Object VMware.Vim.DVSTrafficShapingPolicy  
 $inShapingPolicy.Enabled = New-Object VMware.Vim.BoolPolicy  
 $inShapingPolicy.AverageBandwidth = New-Object VMware.Vim.LongPolicy  
 $inShapingPolicy.PeakBandwidth = New-Object VMware.Vim.LongPolicy  
 $inShapingPolicy.BurstSize = New-Object VMware.Vim.LongPolicy  
 $inShapingPolicy.Enabled.Value = $true  
 $inShapingPolicy.AverageBandwidth.Value = 1000000000  
 $inShapingPolicy.PeakBandwidth.Value = 5000000000  
 $inShapingPolicy.BurstSize.Value = 19200000000  
 $inShapingPolicy.Inherited = $false  

 $outShapingPolicy = New-Object VMware.Vim.DVSTrafficShapingPolicy  
 $outShapingPolicy.Enabled = New-Object VMware.Vim.BoolPolicy  
 $outShapingPolicy.AverageBandwidth = New-Object VMware.Vim.LongPolicy  
 $outShapingPolicy.PeakBandwidth = New-Object VMware.Vim.LongPolicy  
 $outShapingPolicy.BurstSize = New-Object VMware.Vim.LongPolicy  
 $outShapingPolicy.Enabled.Value = $true  
 $outShapingPolicy.AverageBandwidth.Value = 1000000000  
 $outShapingPolicy.PeakBandwidth.Value = 5000000000  
 $outShapingPolicy.BurstSize.Value = 19200000000  
 $outShapingPolicy.Inherited = $false  

 $uplinkTeamingPolicy = New-Object VMware.Vim.VmwareUplinkPortTeamingPolicy  
 $uplinkTeamingPolicy.policy = New-Object VMware.Vim.StringPolicy  
 $uplinkTeamingPolicy.policy.inherited = $false  
 $uplinkTeamingPolicy.policy.value = “loadbalance_ip”  
 $uplinkTeamingPolicy.uplinkPortOrder = New-Object VMware.Vim.VMwareUplinkPortOrderPolicy  
 $uplinkTeamingPolicy.uplinkPortOrder.inherited = $false  
 $uplinkTeamingPolicy.uplinkPortOrder.activeUplinkPort = New-Object System.String[] (1) # designates the number of uplinks you will be specifying.  
 $uplinkTeamingPolicy.uplinkPortOrder.activeUplinkPort[0] = "LAG01"  

 $spec.DefaultPortConfig.InShapingPolicy = $inShapingPolicy  
 $spec.DefaultPortConfig.OutShapingPolicy = $outShapingPolicy  
 $spec.DefaultPortConfig.UplinkTeamingPolicy = $uplinkTeamingPolicy  

 $vds.ExtensionData.ReconfigureDvs_Task($spec)  

Another example reconfigures default DVS policy to VMware Load Based Teaming (aka LBT).

 Import-Module VMware.VimAutomation.vds  
 $vDSName = “test”   
 $vds = Get-VDSwitch $vDSName   
 $spec = New-Object VMwareåç.Vim.DVSConfigSpec   
 $spec.configVersion = $vds.ExtensionData.Config.ConfigVersion   
 $spec.defaultPortConfig = New-Object VMware.Vim.VMwareDVSPortSetting  
 $uplinkTeamingPolicy = New-Object VMware.Vim.VmwareUplinkPortTeamingPolicy   
 $uplinkTeamingPolicy.policy = New-Object VMware.Vim.StringPolicy   
 $uplinkTeamingPolicy.policy.value = “loadbalance_loadbased”   
 $spec.DefaultPortConfig.UplinkTeamingPolicy = $uplinkTeamingPolicy  
 $vds.ExtensionData.ReconfigureDvs_Task($spec)  

VDS supports following teaming policies (source: vSphere Documentation)

• failover_explicit
• loadbalance_ip
• loadbalance_loadbased
• loadbalance_srcid
• loadbalance_srcmac

Please, note that examples above have to be altered to fulfill your particular needs but now you should have a pretty good idea how to change the default DVS.

PowerCLI - Recent servers file is corrupt

This is just short post because I have experiences PowerCLI warning "Recent servers file is corrupt" depicted below.

 PS C:\Users\Administrator> C:\Users\Administrator\Documents\scripts\Cluster_hosts_vCPU_pCPU_report.ps1  
 WARNING: Recent servers file is corrupt: C:\Users\Administrator\AppData\Roaming\VMware\PowerCLI\RecentServerList.xml  
 UTC date time: 04/15/2016 12:32:52 Cluster: Cluster ESX name: esx01.home.uw.cz.Name pCPUs: 2 vCPUs: 19 vCPU/pCPU ratio: 9.5  
 UTC date time: 04/15/2016 12:32:52 Cluster: Cluster ESX name: esx02.home.uw.cz.Name pCPUs: 2 vCPUs: 12 vCPU/pCPU ratio: 6  

Google returns just one result here.

The solution to get out warning message is fairly simple.

Just remove corrupted file  C:\Users\Administrator\AppData\Roaming\VMware\PowerCLI\RecentServerList.xml which will be created during the next PowerCLI run.

Hope this helps some other folks.

ESXi host vCPU/pCPU reporting via PowerCLI to LogInsight

Some time ago I had a discussion with one of my customers how to achieve vCPU/pCPU ratio 1:1 on their Tier 1 cluster. Unfortunately, there is not any out-of-the box vSphere policy to achieve it. You can try to use vSphere HA Cluster admission control with advanced settings to achieve such requirement but it is based on CPU reservations in MHz so it would be tricky settings anyway with some additional risks for example after physical server hardware replacement.

At the end of the day we agreed that the goal can be achieved by Monitoring and Capacity Planning process. One can probably leverage VMware vRealize Operations Manager (aka vROps) or similar monitoring platform but because my customer does not have vROps and I'm not vROps expert I realized there is very simple alternative.

Let's leverage PowerShell/PowerCLI to report vCPU/pCPU ratio of ESXi hosts. 

As you can see in the script below it is pretty easy task to prepare PowerCLI report however the question is how to visualize it and send alerts in case of exceeded threshold.

And that's another simple idea. Why not leverage vRealize LogInsight?

All my readers most probably know what VMware's LogInsight (LI) is but just in case - LI is highly available and scalable syslog server appliance which main business value is an excellent reporting capabilities from unstructured data. I don't want to describe LogInsight in this blog post but another interesting feature of LI besides syslog messages it also accepts JSON messages sent via API. For more details look here.

So the whole solution is conceptually pretty easy. Bellow is the high level process.

1. PowerCLI : Go through each ESXi and calculates vCPU/pCPU ratio
2. PowerCLI : Compose a message including vCPU/pCPU ratio together with additional context information like timestamp, cluster name, ESXi name, number of vCPU and pCPU
3. PowerCLI : Send the message to LogInsight via REST API
4. LogInsight : Prepare custom analytics and create Dashboard
5. LogInsight: Create alert to send e-mail message or trigger web hook when threshold is exceeded    

The latest script version is at GITHUB. Below is complete PowerCLI script ...

 #################################  
 # vCenter Server configuration  
 #  
 $vcenter = “vc01.home.uw.cz“  
 $vcenteruser = “readonly“  
 $vcenterpw = “readonly“  
 $loginsight = "192.168.4.51"  
 #################################  
   
 $o = Add-PSSnapin VMware.VimAutomation.Core  
 $o = Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false  
   
 #################################  
 # Connect to vCenter Server  
 $vc = connect-viserver $vcenter -User $vcenteruser -Password $vcenterpw  
   
 #################################  
 # Send Message to LogInsight  
 function Send-LogInsightMessage ([string]$ip, [string]$message)  
 {  
  $uri = "http://" + $ip + ":9000/api/v1/messages/ingest/1"  
  $content_type = "application/json"  
  $body = '{"messages":[{"text":"'+ $message +' "}]}'  
  $r = Invoke-RestMethod -Uri $uri -ContentType $content_type -Method Post -Body $body  
 }  
   
 #################################  
 # Count vCPU/pCPU Ratio  
 foreach ($esx in (Get-VMHost | Sort-Object Name)) {  
  $pCPUs = $esx.NumCpu  
  $vCPUs = ($esx | get-vm | Measure-Object -Sum NumCPU).Sum  
  $CPU_ratio = $vCPUs / $pCPUs  
  $date = (Get-Date).ToUniversalTime()  
  $cluster_name = get-cluster -VMHost $esx  
   
  $message = "UTC date time: $date Cluster: $cluster_name ESX name: $esx.Name pCPUs: $pCPUs vCPUs: $vCPUs vCPU/pCPU ratio: $CPU_ratio"  
  Write-Output $message  
  Send-LogInsightMessage "192.168.4.51" $message  
 }  

 disconnect-viserver -Server $vc -Force -Confirm:$false  

The PowerCLI script running in my home lab generate messages depicted below ...

 PS C:\Users\Administrator\Documents\scripts> .\Cluster_hosts_vCPU_pCPU_report.ps1  
 UTC date time: 04/06/2016 12:49:32 Cluster: Cluster ESX name: esx01.home.uw.cz.Name pCPUs: 2 vCPUs: 18 vCPU/pCPU ratio: 9  
 UTC date time: 04/06/2016 12:49:33 Cluster: Cluster ESX name: esx02.home.uw.cz.Name pCPUs: 2 vCPUs: 12 vCPU/pCPU ratio: 6  

I use scheduled tasks to send these messages periodically to LogInsight. You can see LogInsight messages in screenshot below ...

LogInsight Interactive Analysis

It is very simple to create dashboard from the analytic ...

LogInsight vCPU/pCPU Dashboard

And the last task is to create alert in LogInsight when vCPU/pCPU ratio is higher then 1 or you can be informed little bit earlier so you can set an alert when ratio is higher then 0.8 ...

Pretty easy, right?
Hope this helps broader VMware community.

And as always, any comments and thoughts are very welcome.

What's new in PowerCLI 6.3 R1?

PowerCLI 6.3 R1 introduces the following new features and improvements:

Get-VM is now faster than ever!

The Get-VM Cmdlet has been optimized and refactored to ensure maximum speed when returning larger numbers of virtual machine information. This was a request which we heard time and time again, when you start working in larger environments with thousands of VMs the most used cmdlet is Get-VM so making this faster means this will increase the speed of reporting and automation for all scripts using Get-VM. Stay tuned for a future post where we will be showing some figures from our test environment but believe me, it’s fast!

New-ContentLibrary access

New in this release we have introduced a new cmdlet for working with Content Library items, the Get-ContentLibraryItem cmdlet will list all content library items from all content libraries available to the connection. This will give you details and set you up for deploying in our next new feature…. 

The New-VM Cmdlet has been updated to allow for the deployment of items located in a Content Library. Use the new –ContentLibrary parameter with a content library item to deploy these from local and subscribed library items, a quick sample of this can be seen below:

$CLItem = Get-ContentLibraryItem TTYLinux
New-VM -Name "NewCLItem" -ContentLibraryItem $CLItem -Datastore datastore1 -VMHost 10.160.74.38

Or even simpler….

Get-ContentLibraryItem -Name TTYLinux | New-VM -Datastore datastore1 -VMHost 10.160.74.38

ESXCLI is now easier to use

Another great feature which has been added has again come from our community and users who have told us what is hard about our current version, the Get-Esxcli cmdlet has now been updated with a –V2 parameter which supports specifying method arguments by name.

The original Get-ESXCLI cmdlet (without -v2) passes arguments by position and can cause scripts to not work when working with multiple ESXi versions or using scripts written against specific ESXi versions.

A simple example of using the previous version is as follows:

$esxcli = Get-ESXCLI -VMHost (Get-VMhost | Select -first 1)

$esxcli.network.diag.ping(2,$null,$null,“10.0.0.8”,$null,$null,$null,$null,$null,$null,$null,$null,$null)

Notice all the $nulls ?  Now check out the V2 version:

$esxcli2 = Get-ESXCLI -VMHost (Get-VMhost | Select -first 1) -V2

$arguments = $esxcli2.network.diag.ping.CreateArgs()

$arguments.count = 2

$arguments.host = "10.0.0.8"

$esxcli2.network.diag.ping.Invoke($arguments)

Get-View, better than ever

For the more advanced users out there, those who constantly use the Get-View Cmdlet you will be pleased to know that a small but handy change has been made to the cmldet to enable it to auto-complete all available view objects in the Get-View –ViewType parameter, this will ease in the use of this cmdlet and enable even faster creation of scripts using this cmdlet.

Updated Support

As well as the great enhancements to the product listed above we have also updated the product to make sure it has now been fully tested and works with  Windows 10 and PowerShell v5, this enables the latest versions and features of PowerShell to be used with PowerCLI.

PowerCLI has also been updated to now support vCloud Director 8.0 and vRealize Operations Manager 6.2 ensuring you can also work with the latest VMware products.

More Information and Download

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

You can find the PowerCLI 6.3 Release 1 download HERE. Get it today!

Performance Data charts for datastore LUNs report the message: No data available

Performance Data charts for datastore LUNs are extremely useful to have clue to understand storage performance trend.

However sometimes you can see message like this

"Performance Data charts for datastore LUNs report the message: No data available"

I didn't know the root cause. Recently colleague of mine told me he has found what is the root cause which is described at VMware KB 2054403.

Workaround is to not use network virtual adapter E1000E. If you have larger environment it's not big fun to search these adapters. My colleague wrote useful PowerCLI one-liner to find VM with E1000E which should be manually changed. Here is the my colleague's script:

Get-VM | Get-NetworkAdapter | Where-object {$_.Type -like "Unknown" -or $_.Type -like "E1000E" } | Select @{N="VM";E={$_.Parent.Name}},Name,Type | export-Csv  c:\VM-Network_Interface.csv -NoTypeInformation 

He asked me to share this information with community so enjoy it.

PowerCLI One-Liners to make your VMware environment rock out!

Christopher Kusek wrote excellent blog post about PowerCLI useful scripts fit single line. He call it one-liners. These one-liners can significantly help you on daily vSphere administration. On top of that you can very easily learn PowerCLI constructs just from reading these one-liners.

http://www.pkguild.com/2013/06/powercli-one-liners-to-make-your-vmware-environment-rock-out/

VMware PowerCLI - prepare environment after installation

Set-ExecutionPolicy RemoteSigned
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore