WilliamLam.com

VCSA 7.0 Update 2 Upgrade Issue - Exception occurred in install precheck phase

by // 34 Comments

Like most folks, I was excited about the release of vSphere 7.0 Update 2 and I was ready to upgrade my personal homelab, which was running on vSphere 7.0 Update 1c. However, after starting my VCSA upgrade in the VAMI UI, it quickly failed with the following error message: Exception occurred in install precheck phase

Given the release had just GA'ed less than an hour ago and everyone was probably hammering the site, I figured I would wait and then try again.

[Read more...]

Quick Tip - Using ESXi to send Wake-on-Lan (WoL) packet

by // 1 Comment

The ability to power on a system over the network using Wake-on-Lan (WoL) can be extremely useful, especially if you are not physically near the system or after a power outage. I personally have been using the wakeonlan utility on my macOS system for several years now.

The syntax is super easy, you just provide the MAC Address of your system:

wakeonlan 54:b2:03:9e:70:fc
Sending magic packet to 255.255.255.255:9 with 54:b2:03:9e:70:fc

I recently came to learn that ESXi itself has the ability to send a WoL packet from the ESXi Shell! This could be handy without having to install WoL client, especially if you have access to an ESXi host.

vsish -e set /net/tcpip/instances/defaultTcpipStack/sendWOL 192.168.30.255 9 54:b2:03:9e:70:fc vmk0

This uses the not supported vsish CLI to send WoL packet. The first argument is the network broadcast address, so if you have a network of 192.168.30.0/24, then the address would be 192.168.30.255. The second argument is a value of 9, which is probably related to the magic packet as you can see the same value from the wakeonlan utility abvoce. The third argument is the MAC Address of the system and finally the fourth and final argument is the ESXi VMkernel interface to send the packet out of.

Decoding Services Roles/Permissions from a VMware Cloud Services Platform (CSP) Token

by // 1 Comment

To programmatically access the various VMware Cloud Services (CSP) such as VMware Cloud on AWS as an example, a user must first generate a CSP Refresh Token using the CSP Console.


When creating a new CSP Refresh Token, you have the option to scope access to a specific set organization roles and service roles which will enable you to limit the permissions of this token to specific CSP Services. In the example below, I have created a new token which is scoped to the organization owner role along with two VMware Cloud on AWS Service Roles: Administrator (Delete Restricted) and NSX Cloud Admin to be able to grant access to a VMware Cloud on AWS SDDC.


One common issue that I see folks run into when working with some of the CSP Services including VMware Cloud on AWS from a programmatic standpoint is that they did not properly create a token with the correct permissions which usually will lead to some type of invalid request.

For popular services like VMware Cloud on AWS, it is usually pretty easy to track down, especially if the user who is using the CSP Refresh Token is the same person who created it. However, if you are not the person who created the original token or if you have forgotten or you may have access to multiple token, it can be a little bit difficult to troubleshoot.

The good news and probably lesser known detail about how CSP Refresh Tokens work is that you can actually decode these tokens to understand what specific scopes were used to create the initial token. Below are two methods to decode these tokens, both CSP Refresh Tokens (generated from the CSP UI) as well as CSP Access Token, which is returned when you request access providing your CSP Refresh Token.

[Read more...]