VMware Distributed Port Group Configuration Report Using PowerCLI

From time to time we need to check that VMware Distributed Port Groups are following our standard configuration. If there is only a few port group this can be done manually but in my case I need to check a few hundred.

Since there are so many I wanted to make a script that will export the configuration of each port group and out put to a CSV.

In this post we will be going through using PowerCLI to report on the configuration setting for all distributed virtual switch port groups.

I used the PowerCLI developer doc to find the required commands to check each port group configuration settings and policies.

https://developer.vmware.com/docs/powercli/latest/products/vmwarevsphereandvsan/categories/vdport/

First we need to get the list of Distributed Virtual Switches (VDS)

Once we have the list of switches we can use the below command to return all port groups.

Get-VDPortgroup -VDSwitch switchname

Next we can take one port group and start to view the properties to get the required info.

The below will view the general port group settings like VLAN, port bindings and Numbers or ports.

Get-VDPortgroup -Name portgroupname |fl

To view the override policy use the below command.

Get-VDPortgroup -Name portgroupname | Get-VDPortgroupOverridePolicy

To view the teaming policy use the below.

Get-VDPortgroup -Name portgroupname | Get-VDUplinkTeamingPolicy

For team policies the name in PowerCLI is different than in the web UI, the below table will match up the names

LoadBalancingPolicyLoad balancing
LoadBalanceLoadBasedRoute Based on Physical NIC Load
LoadBalanceSrcMacRoute Based On Source MAC Hash
LoadBalanceSrcIdRoute Based On Originating Virtual Port
ExplicitFailoverUse Explcit Failover Order
LoadBalanceIPRoute Based on IP Hash

To view the security policy use the below.

Get-VDPortgroup -Name portgroupname | Get-VDSecurityPolicy

Now that I have all the different policy and configuration settings I can create the script.

I will be using a hash table for all export the configuration and policy settings.

The full script can be download from my GitHub repository link below.

https://github.com/TheSleepyAdmin/Scripts/blob/master/VMware/Network/VMwarePortGroupConfig.ps1

The script can be run to either output the configuration details to the PowerShell console using the below command.

.\VMwarePortGroupConfig.ps1 -VCServer vCenter

The second option is to export to CSV file by using the -ReportExport parameter.

.\VMwarePortGroupConfig.ps1 -VCServer vCenter -ReportExport .\

The below is what the CSV output should look like.

Upgrading VMware vCenter Server Appliance from 7.0 to 8.0

With the release of VMware vCenter Server Appliance 8.0 (vCSA), I wanted to upgrade my lab setup to the latest release to check out some of the new features.

In this post we will go through the process, this is be the same process as previous version of vCSA just some of the wizard screen have changed slightly.

Before starting the upgrade process make sure you have a valid backup and I also take a snapshot of the existing vCSA just incase there are any issues.

First, we need to download the vCSA ISO,

https://customerconnect.vmware.com/downloads/info/slug/datacenter_cloud_infrastructure/vmware_vsphere/8_0

Next, I usually rename the existing VCSA to _old as I want to deploy to the vCenter with the same name.

Next, we can mount the vCenter ISO to launch the installer.exe.

Next on the install select upgrade.

The introduction will warn that if using an external PSC it will be converged as external PSC are being deprecated.

Next accept the end user agreement.

Put in the details for the existing Appliance.

We will have to put in the details of the existing vCenter or ESXi host. My vCSA is installed on a standalone ESXi host, so I used those details.

If there is a cert warning accept to continue.

Enter the details for the target server where the new vCSA is going to be deployed to.

Enter the existing vCenter server name (as long as you renamed the VM name first)

Select the VM size.

Select the datastore to use.

Next, we need to select the network and give the vCSA a temporary IP, this is to allow it to be contactable so that the data migration can happen. After the data migration the original IP will be moved to the new vCSA.

Now review the deployment details.

Click finish to start the deployment.

Once the deployment is completed, we can start stage 2.

Click continue

Next we will go through stage two of the upgrade.

First part will verify the connection and run pre-checks for any issues.

Review these result to confirm there will be no issues. .

Select what data to move.

Tick to join customer experience or not and continue.

Review the settings and confirm everything is correct.

Click finish to start the data transfer.

The data migration can take a while depending on the amount of data to be moved.

Once completed we can now logon to the vCSA and confirm that we are running vCenter 8.0.

Patching VMware vCenter 7.0 Server Appliance Using CLI

There are a few different way’s to update to vCenter server appliance (VCSA). In this post we will be going through using CLI method to apply vCenter patches. Before updating VCSA make sure you have a current backup and take a snapshot before proceeding in case of any issues with the update.

First we need to connect to the vCenter server using SSH. I will be using the inbuilt OpenSSH feature in PowerShell but you can use what ever SSH client you prefer.

To enable SSH on vCenter logon to the management page using the vCenter URL with port 5480 (https://vcenter.domain.local:5480).

Go to Access and click edit to enable SSH Login.

vCenter Management UI

Next we need to connect to the vCenter server using ssh.

vCenter SSH Login

Next we can run the below command to view the vCenter update history

software-packages list --history
Patch List

We can use the below command. This will list the current update settings, if the vCenter server has no internet access then you could update the URL to use an internal web site that contains the update files.

update.get
Update configuration

We will be using the default URL from the update.get command when running the update

software-packages install --url https://vapp-updates.vmware.com/vai-catalog/valm/vmw/8d167796-34d5-4899-be0a-6daade4005a3/7.0.3.00100.latest/ --stage --acceptEulas

This command will download, stage the update and install.

Update staging

Once stage the update will then start to install.

Update Installing

The update can take awhile to complete.

Update Completion

Once the update has completed, vCenter should reboot if required to complete the install.

When the appliance boots backup we can re-connect to confirm we are now running on the updated VCSA version.

vCenter SSH Login

Create Local ESXi Account Using PowerCLI

In this post we will be going through creating local ESXi account using PowerCLI.

Recently I have had to create local account to allow a monitoring tool to pull information from all ESXi hosts.

We want to automate the user creation and assign the required permissions so that they only have the permission required for a limited time.

First we need to connect to the ESXi Host using PowerCLI

Connect-VIServer
Connection to vCenter

To check what account already exist use the below.

Get-VMHostAccount
List Accounts

To create a new account we will use the New-VMHostAccount command

New-VMHostAccount -Id accountname -Password password -Description Account Description
Create new account

Next we need to assign the required permissions. We can list the current roles using

Get-VIRole
List VMware Roles

We also need an entity to set the permission or the command will error out.

Permission

To list the entity use the

Get-Folder
List Folder

Select the entity that will have the role applied. In this case we will be applying to the root object so it applies to all objects on the host and will assigning the admin role.

New-VIPermission -Entity (Get-Folder root) -Principal accountname -Role Admin
Set Permission

To remove the account use the below command.

Get-VMHostAccount -User account name | Remove-VMHostAccount -Confirm:$false

Once we have the commands, we can create the script to automate the account creation and role assignment to configure multiple hosts.

Account Creation Script

The scripts uses EsxiHost as the heading for the CSV if you want to use something different the script will need to be updated.

Below is the script running against my test hosts.

.\Create-LocalESXiUser.ps1 -ESXiHostList .\EsxiHosts.csv -ESXiUser useraccount -ESXipass password -ESXiNewUser accountname -ESXiUserPass accountpass -ESXiPermission Permission -ESXiUserdesc "Account Description"
Account creation script

This process can also be used to update the permission for a specific account.

Updating permissions

To download the full script use the below link to github.

https://github.com/TheSleepyAdmin/Scripts/blob/master/VMware/Config/Account/Create-LocalESXiUser.ps1

Configure SNMP On VMware ESXi Using PowerCLI

In this post we will be going through deploying new SNMP configuration to a list of ESXi hosts using PowerCLI. We can add SNMP using ssh and esxcli commands but this will required SSH to be enabled and connecting to each host.

We can use Set-VMHostSNMP command to set the SNMP configuration by conecting to the host using connect-viserver which uses https to connect and does not required SSH to be enabled.

First we need to connect to the ESXi host

Connect-VIServer -Server esxihost.domain.local

use a local account like root to connect

PowerCLI SNMP Command

If you get a certificate error and can’t connect you might need to update the PowerCLI Configuration or install the root cert to trust the self singed cert of the ESXi hosts.

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false

Once connected we will be using the below set of command to configure the SNMP settings.

Get-VMHostSnmp | Set-VMHostSnmp

https://developer.vmware.com/docs/powercli/latest/vmware.vimautomation.core/commands/set-vmhostsnmp/#Default

First we will enabled and set the community string

Get-VMHostSnmp | Set-VMHostSnmp -Enabled:$true -ReadOnlyCommunity communityname

PowerCLI SNMP Command

Next we will set the target that traps will be sent.

Get-VMHostSnmp | Set-VMHostSnmp -TargetCommunity communityname -TargetHost snmp.domain.local -TargetPort 162 -AddTarget
PowerCLI SNMP Command

To test I have setup snmp on Ubutu

Ubuntu SNMP check

Now that we have set of command we can create the script. I will be doing a loop through each host and configuring the SNMP.

I also added in some if statement to check if SNMP is already enabled and to check if the target host matches the one that is set in the parameters.

SNMP Script

The full script can be downloaded from the below github link.

https://github.com/TheSleepyAdmin/Scripts/blob/master/VMware/Config/SNMP/Set-ESXiSNMP.ps1

Below is an example of what the csv file should look like if you want to use a different heading the script will need to be updated.

Each of the values will be called as parameter to allow easy re-use below is an example of the SNMP script running against my test hosts.

Using PowerCli can be a quicker way to set and enabled SNMP on a list of hosts rather than having to SSH and use esxcli command. This can also be used to update the existing SNMP configuration to a new traps target.

Allow External Access to vCenter Using Azure Application Proxy

With some of the recent critical vulnerability’s for both VMware and Log4j vulnerability this is has shown again that having vCenter open on the internet is not a good idea as it leave a big target for hackers to try exploit.

There are several ways to avoid having vCenter directly available on the internet, in this post we will be going through publishing using the Microsoft Azure Application Proxy. This will be using Azure AD as an authentication source and we can add addtional security like MFA.

First before we can use the Azure Application Proxy we need to make sure we have an Azure subscription and the appropriate license types. The application proxy is available for users that have either a Azure AD P1 or P2 license.

Once all the pre requisite are meet we can install the Azure Application Proxy, we will be using a Windows Server 2019 VM.

For Windows Server 2019 we need to disable http2 protocol, to disable run the below command from PowerShell.

Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\' -Name EnableDefaultHTTP2 -Value 0

To download the installer, logon to the Azure portal > Azure Active Directory > Application proxy.

Once downloaded run the installer on the server that will be used for the app proxy. To register the connector the minimum rights is to be part of the application administrator role in Azure.

During the install we will be prompted to enter details for an account that has the correct permissions.

The install can take a minute or two to finish.

Once the install has completed the Azure Application proxy connector should show in Azure.

Now that we have the proxy connected to Azure, we will need to register the enterprise application.

Go to Azure AD > Enterprise applications > create your own application

Give the application a name and click create.

Next

  • Give the app a name
  • Add in the internal URL for vCenter
  • Set external URL this can either be an msappproxy.net address or custom domain named
  • Set the pre authentication to either Azure AD or passthrough (to use MFA or conditional access policy set to Azure AD)
  • Set the connector group

I left the addtional settings as the defaults. If the internal and external URL are different (its recommend from Microsoft to use the same DNS address), then to allow the redirect set the translate URLs in > Application Body to yes so allow link translation from the external to internal URL.

Click create, the app can take a few minutes provision.

We can restrict access to the app by using security groups or induvial users access.

Once we have setup the access group we can now connect to the external URL.

If the internal application is using an self singed cert or un trusted certificate authority, then the cert will need to be add to the trusted root cert store on the application proxy server.

This is the TLS error:

There should also be event log 13001 log under Applications and Services Logs/Microsoft- AAD Application Proxy Connector/Admin.

Download the root CA cert from vCenter and install to the trusted root on the server that has the Azure Application Proxy connector installed.

The second option is to use a custom SSL cert for vCenter, I have done a previous post on how to install a custom cert.

Set Custom SSL Certificate on VMware vCenter 6.7 Appliance using Windows CA

After this has been completed the page should now load without issue using the external Azure msapproxy address.

If the application proxy is set to use pre authentication then users will be redirected to the sign in page for Azure and be subject to any conditional access policies.

When connecting from an account that has not been give access rights they will not be able to connect.

The VMware remote console does not work using the Azure Application proxy as it requires both port 443 and 902, the application proxy can’t connect on 902 so the connection fails.

VMware List All Port Groups and Associated VM’s Using PowerCLI

During a recent project we have been starting to use network segregation to give more security and control instead of using a flat network.

This has lead to VM’s being broken up in to there own VMware port groups and segregated VLAN’s.

There are now old port groups that have had all VM’s removed, so we wanted to report on any port groups that have no VM’s associated so that they can be removed as we will hit a issue with max VLAN limit per physical interface.

The quickest way I could think of to create the report was to use PowerCLI, in this post we will go through the process and commands used to create the report.

First we need to connect to vCenter using PowerCLI

We will be using a few different commands in the script.

First we will need to get list of port groups will only be getting distributed port groups as we don’t use standard port groups.

Get-VDPortgroup

Second part of the script is to get the port group view using get-view

Get-View -ViewType Network -Property Name -Filter @{"Name" = "portgroup name"}

We will be using UpdateViewData to add some addtional values to the view to make the script quicker and easier to read see below link for more details on UpdateViewData.

https://blogs.vmware.com/PowerCLI/2011/08/optimize-the-performance-of-powerclis-views.html

To find the properties we wanted to report on we used

Get-VM -Name VMName | Get-View

Use Get-VIObjectByVIView to get the host information.

$vm = Get-VM -name VMName | get-view
(Get-VIObjectByVIView $vm.runtime.host).name

I want to report on the VM name, Host, Cluster and PowerState.

Below we will get the view for the port group and update the view with the additional details that I want in the report.

$networks = Get-View -ViewType Network -Property Name -Filter @{"Name" = "portgroup name"}

$networks | ForEach-Object{($_.UpdateViewData("Vm.Name","Vm.Runtime.Host.Name","Vm.Runtime.Host.Parent.Name","vm.Runtime.PowerState"))}

We can run the below to check if the addtional information has been added to the veiw

$networks.LinkedView.vm.name

Once we have the view working and adding the properties we want we can start to create the full script.

The full script can be copied from the below github link.

https://github.com/TheSleepyAdmin/Scripts/blob/master/VMware/Network/VMware_PortGroupReport.ps1

There are two parameters in the script.

To just output to the console screen use -ConsoleOnly parameter.

To export to csv use the -ReportExport parameter.

Below is a example of the exported csv.

VMware PowerCLI Module 12.4 Update Error

With the release of VMware PowerCLI 12.4 I was updating the module on my LAB servers so I could check out the new command.

When upgrading I was getting the below error which is due to VMware changing the certificate authority used to publish the new module.

Authenticode issuer ‘E=noreply@vmware.com, CN=”VMware, Inc.”, O=”VMware, Inc.”, L=Palo Alto, S=California, C=US’ of the new module ‘VMware.VimAutomation.Sdk’ with version ‘12.4.0.18627054’ from root
certificate authority.

In the release notes from VMware there is a know issue with the certificate. The fix is to remove and re-install the module.

https://blogs.vmware.com/PowerCLI/2021/09/powercli-12-4-whats-new.html

I though I would do a quick post on this incase anyone doesn’t know the process.

To check where the module is installed run the below command.

Get-Module -ListAvailable VMware.PowerCLI
This image has an empty alt attribute; its file name is image-21.png

In my case the module was installed in C:\Program Files\WindowsPowerShell\Modules.

Next we need to remove the old modules, below is a list of the folders that make up the VMware PowerCLI 12.0 module.

After removing the folder we now have to install the new module using Install-Module

Install-Module VMware.PowerCLI

Once completed we should now have PowerCLI version 12.4

Using VMware PowerCLI Get-EsxCli

In this post we will be going through using the PowerCLI Get-EsxCli commandlet, which is used to call EsxCli command from PowerShell instead of having to SSH directly to the the ESXi host.

This can be useful when trying to gather information from multiple hosts instead of connecting on to each host with SSH or updating configuration settings.

First step is to connect to vCenter, once connected we can run the Get-EsxCli command and this will return the list of namespaces that can be use to gather information or set configuration settings.

We will be using -V2 as this sets Get-EsxCli to use version 2 interface as version 1 is being deprecated and will be removed in a later version.

Get-EsxCli -VMHost esxihost -V2

We can set the Get-EsxCli command to a variable so that we can call the namespaces, below will call the network namespace, once called there will be a list of addtiaonl namespaces that can be called.

$vmhostesxcli = Get-EsxCli -VMHost esxihost -V2
$vmhostesxcli.network

Once we select a namespace there should also be a list of methods that can be called these can be used to run specific actions like list or get to return information.

To list all nic’s we can call the nic and then list namespace

$vmhostesxcli.network.nic.list.invoke()

To gather info on details like driver version we can use the get method, in v1 you use to be able to call the nic name directly but if you try this in v2 the below error will be returned.

If specified, the arguments parameter must contain a single value of type Hashtable.

This is due to the method requiring a hash table parameter. If we call the help method it should return the valid parameters. If the parameter has a hyphens remove this or the command wont work.

For the nic namespace the parameter is nicname and needs to be called as a hash table.

$vmhostesxcli.network.nic.get.invoke(@{nicname="vmnic1"})

There might be some namespaces that have multiple properties like driverinfo under nic, these can be called by adding the property like below.

$vmhostesxcli.network.nic.get.invoke(@{nicname="vmnic1"}).DriverInfo

Now that we have the command we can start to build out a script to export information.

In this case we will be getting all hosts, listing all NIC’s and getting the drivers info.

The above shows that Get-EsxCli can be very good for retrieving information, if we wanted to set a configuration we can use similar command syntax but use the set method.

In this case we will update the Power policy settings on all host, we could do this manually by going to the Configure > Hardware > Overview > Power Management one each host and update the power policy settings

but doing this on a larger cluster is a lot of effort. To update using PowerCli we can first create the script to report on the current host power policy.

To update the policy settings we will use the set method like the below.

$vmhostesxcli.hardware.Power.policy.set.Invoke(@{id="1")})

Below are the 4 different power policy’s.

IDPower Policy
1High Performance
2Balanced
3Lower Power
4Custom

We can then take the above and create a re-usable script to report or set the power policy on all host in one go.

To download a copy of the either of the above script use the below link to my Github these can be used as reference if you want to create your own scripts for other settings.

https://github.com/TheSleepyAdmin/Scripts/tree/master/VMware/EsxCli

Upgrading VMware Tools Different Methods

Keeping VMware tools updated is an import task to improve performance and keep up with security / bug fixes. VMware tools are not required for a VM to run but are used to enable VMware features.

VMware tools can be upgrade in a few different methods. In this post we will go through some of these different methods these range from completely manual by upgrading to fully automated using VM options, scripting or application deployment.

First method is to manually mount the tools on the VM by right clicking and then install in the guest OS, this is the slowest method and is fine if there is a few VM to upgrade but not really great at scale.

Second method is to set the VMware tools to check for upgrades during power on. This method can be good when doing OS patching as when patching a VM the tools will also be upgraded.

To enabled this either edit the VM setting and go to VM Options > VMware tools > Tools Upgrade

To enabled on multiple VM’s we can use PowerCli to bulk update the VM options.

To view the current upgrade policy we can use

(Get-VM VMName  | Get-View).config.Tools

To update the VM Option using PowerCli we can create a new VM configuration and then apply to a list of VMs in a text file using a loop. To set the upgrade policy back to manual just update tools upgrade policy from upgradeAtPowerCycle to manual.

$VMs = Get-Content C:\Temp\VMs\VMware_Tools_Upgrade.txt
$Toolsconfig = New-Object VMware.Vim.VirtualMachineConfigSpec
$Toolsconfig.tools = New-Object VMware.Vim.ToolsConfigInfo
$Toolsconfig.tools.toolsUpgradePolicy = "upgradeAtPowerCycle"

foreach ($VM in $VMs) {
Write-Warning "Setting VM Tools to Upgrade on PowerOn for $VM"
(Get-VM -Name $VM | Get-View).ReconfigVM($Toolsconfig)

 }

vCenter should show the tasks that where run to update the VM option.

Now when the VM’s reboot they should auto upgrade to the newest version.

Third method is to use a script to update the tools. This can be used when we want to have more control over when VMware tools are upgrade.

This can be done by using the VMware PowerCli Update-Tools command

For one VM we could use

Update-Tools VMName

Below is an example of using a text file with VMs names. I used the no reboot parameter to stop the VM from rebooting after the tools are updated.



$VMs = Get-Content C:\Temp\VMs\VMware_Tools_Upgrade.txt
foreach ($VM in $VMs) {
Get-VM -Name $VM  | Update-Tools -NoReboot
}

If we check vCenter we should see the upgrade task start

The last method I would use would be an application deployment tool to push out the latest VMware tools.

I use Microsoft Endpoint Configuration Manager for most of my deployment so this will be where I will be creating the deployment package.

Mount the VMware tools on on of the VMs and copy the install files.

Open the ConfigMgr console > Software Library > Application Management > Application

Create a new application and set to manual specify.

Add in the application details.

Add a new Deployment Type

Set type to manual specify.

Give the deployment a name

I used the document for the command line switches for the tools upgrade its for version 5.5 but the same switches worked.

https://docs.vmware.com/en/VMware-vSphere/5.5/com.vmware.vmtools.install.doc/GUID-CD6ED7DD-E2E2-48BC-A6B0-E0BB81E05FA3.html

Add the path to the copied install files, install command line switches and the uninstall command line (not required)

Command line: setup.exe  /S /v “/qn REBOOT=R

Next set a detection method this can be either MSI install code if available but I used file version for the vmtoolsd.exe.

below is what the detection clause should look like.

Set the install behavior to Install for system and logon requirement to Whether or not a user is logged on.

I didn’t set any requirements or dependencies. Review the summary page and then complete the application wizard.

Once completed the wizard will go back to the create application wizard.

Follow the wizard and complete.

Now that the application is create we can deploy out to the required VM’s.

Right click and go to deploy.

Select the device collection that will be used to put VMs that will have there tools upgraded.

Add the application to the required distribution points so that content is transferred.

There are two install type available or required. To force the install use required.

For scheduling I setup as soon as possible but this can be set to what ever time the application should start to install.

I left user experience and alerts as default and completed the deployment wizard.

Once the application deployment has been assigned to the client the app should now show in software center on the client and start the upgrade.

After the upgrade completes the version of VMware tools should be 11.3 and will prompt for reboot if required.

These are the main way I manage VM tools upgrades, I usually try to use VM options for most severs as it works well and requires the least manual intervention to keep VMware tools up to date.