PowerCLI: Check NTP status on numerous ESXi hosts

I was recently tasked with configuring and checking the NTP status on a large number of ESXi hosts over a dozen different networks/vCenters. I used Host Profiles to configure NTP but wanted a way to check the time on the hosts after the profile was pushed out due to complicated network firewall rules in place.

Use connect-viserver to connect to a vCenter server before running the script. This script will prompt you to enter a filename for the CSV output. The CSV contains hostname, status of the NTP service, the startup policy for the service, a list of the NTP servers configured, and the current time of the host.

cls
$input = Read-Host "Path for CSV Output"
$AllMembers = @()

foreach($myHost in (Get-VMHost)) {
$serviceStatus = Get-VMHostService $myHost | Where-Object {$\_.key -eq "ntpd"} | select Policy, Running

$myView = Get-View $myHost.Extensiondata.ConfigManager.dateTimeSystem

$ntpServers = Get-VMHostNtpServer $myHost

$allmembers+=new-object psobject -Property @{
Host = $myHost.Name;
StartupPolicy = $serviceStatus.Policy;
Status = $serviceStatus.Running;
ReportedTime = $myView.QueryDateTime();
NTPServers = $ntpservers.ToString();
}

}
$allmembers | Select-Object "Host", "Status", "StartupPolicy", "NTPServers", "ReportedTime" | export-csv -notypeinformation -path $input

Windows 10 Calculator and VMware’s article on an optimized Windows 10 image.

Several months ago, VMware released a great article (here) on creating an optimized Windows 10 image for VDI environments. One issue with the article is that they have a ‘scorched earth’ policy in regards to Windows 10 UWP apps – that is – they all get removed if you follow the guide. This is not acceptable to most customers, as the majority still want the Calculator app on their VDI image.

I spent many hours researching methods to add the calculator back in, and found many blog articles with commands that simply didn’t work.

I came across a blog article on how to add apps back after they were removed using the method VMware details, but it required downloading a 4GB file from the Microsoft VLSC.

This method worked, but it wasn’t ideal for the situation.

I’m a PowerShell novice, but I figured there had to be an easier way. There is.

VMware’s guide has you run the following commands:

Get-AppxPackage -AllUsers | Remove-AppxPackage

Get-AppxProvisionedPackage -online | Remove-AppxProvisionedPackage -online

We’ll add some qualifiers to exclude the Windows Calculator… the new commands are:

Get-AppxPackage -AllUsers | where {$_.Name -notlike "Microsoft.WindowsCalculator"} | Remove-AppxPackage

Get-AppxProvisionedPackage -online | where {$_.DisplayName -notlike "Microsoft.WindowsCalculator"} | Remove-AppxProvisionedPackage -online

If you need to exclude multiple apps, it would look like this:

Get-AppxPackage -AllUsers | where {$_.Name -notlike "Microsoft.WindowsCalculator"} | where {$_.Name -notlike "Microsoft.WindowsStore"} | Remove-AppxPackage

Get-AppxProvisionedPackage -online | where {$_.DisplayName -notlike "Microsoft.WindowsCalculator"} | where {$_.DisplayName -notlike "Microsoft.WindowsStore"} | Remove-AppxProvisionedPackage -online

There may be a more elegant way to do this, but it’s simple and works. I hope this saves you some time.

How to clear the VMware Verify configuration from your on-premise VIDM

VMware Verify uses a cloud service (Authy) to provide its functionality.  If you have a cloud hosted VIDM, your VMware Verify authentication adapter (MFAAdapter) comes pre-configured.    On the other hand, with on-premise VIDM, you are required to obtain a token from VMware support to enable the feature.

I found myself in a situation where the incorrect token was provided, and it needed to be replaced with a different one.  Unfortunately, once you enter the token in the UI and hit save, there is no easy way to clear it out and enter a different one.

The solution is to make an API call and delete the configuration for the MFAAdapter.

In this walkthrough I’ll be using the Postman app to make the API calls.  The VIDM version used in this example is 3.3.

The first step will be validate that we can authenticate and retrieve the current configuration using the GET command.  You’ll need to login to the VIDM web admin console (https://fqdn-of-vidm/SAAS/login/0) so we can obtain the value of the HZN cookie.

We’ll use Chrome as the example, but you can likely obtain the value in other browsers following a similar process.

Launch Postman and create a basic request.

Change the request type to GET
Enter the URL as https://fqdn_of_vidm/SAAS/jersey/manager/api/mfa/
Click “Headers”

Open Google Chrome, and login to the VIDM admin interface using the credentials for the built-in “admin” account.
Open the “Developer Tools” menu (F12 on a Windows PC)

Select “Application” and then expand the “Cookies” section.
Click on the URL that corresponds to the VIDM you logged into.
On the right side, copy the value of the HZN cookie to the clipboard.

Back to Postman.  You should still be on the headers page.  In the first row, type in “Authorization” as the key.  For the value, enter HZN and paste the value that you copied to your clipboard (note the space in-between)

Click Send

You should receive a reply that contains the VMware Verify key that you previously entered in the admin interface.  If you receive an error, you may need to disable SSL certificate validation within the Postman app as I did in the lab environment.

Important: Before issuing any delete commands, make sure you have a backup of the VIDM appliances and database!

When you are ready, change the GET to DELETE and click send.

You’ll notice that the output looks the same as before.  Don’t worry, that’s expected.

Go back to the VIDM admin console and pull up the settings for the VMware Verify authentication adapter.  The field for the Security token is back and ready for proper configuration!