How to reset an Azure Migrate OVA virtual appliance

One of the common questions I’ve been asked by my colleagues who are a part of an on-premise migration to Azure project is how to reset an Azure Migrate Appliance, which has already been configured and registered with an existing Azure Migrate Project. A typical scenario where this may be necessary can be for organizations that did not have any Azure tenant setup and in order to generate an assessment report for the client, the consultant uses their own organization’s tenant. From there, an assessment can be created for the client, obtain approval and proceed with the migration. The challenge that comes when it is time to migrate is that the assessment and evidently the associated tenant is incorrect. Navigating to the Azure Migrate Appliance’s configuration webpage does not provide a way to change the configuration as shown in the screenshot below:

https://localhost:44368

To reset an Azure Migrate OVA virtual appliance configured for VMware vSphere is actually quite simple. Begin by navigating to the following path on the deployed Azure Migrate Windows OVA appliance:

C:\ProgramData\Microsoft Azure\Config\

Then proceed to open the following file in the directory:

appliance.json

Search for the following line:

“IsApplianceRegistered”: “True”,

Change the value of True to False and save the file:

“IsApplianceRegistered”: “False”,

While I’ve found that the majority of the times I’ve done this does not require a restart, I would advise to restart the virtual machine anyways.

The Azure Migrate Appliance will now be reset to the unconfigured state:

You’ll be able to log into a different tenant after setting up the prerequisites:

 

Deploying Azure Migrate appliance on VMware vSphere 6.7 fails with "Unable to process template"

Problem

You attempt to set up the Azure Migrate appliance to perform an assessment on a VMware vSphere 6.7 environment by downloading the OVA appliance from Azure:

MicrosoftAzureMigration.ova

… but notice that the process fails in the vSphere client with the error message:

Unable to process template.

Solution

One of the common causes of this issue is if you are using Internet Explorer as your browser and the following is a version that would display this error:

Internet Explorer 11
Version: 11.3383.14393.0

One of the quickest way to get around this is to use Google Chrome:

 

vCenter settings of a VMware Horizon View desktop pool displays the error message: "Cannot find host or cluster for this desktop pool."

Problem

You’ve noticed that one of the vCenter settings of a VMware Horizon View desktop pool displays is highlighted in red:

Clicking into the vCenter Settings tab displays the following error message:

Cannot find host or cluster for this desktop pool.

Clicking on the Browse… button for the Host or cluster setting displays the following error message:

Solution

The reason why the pool exhibits this behavior is because the configured vCenter settings no longer match the vCenter currently hosting the virtual desktops. A common issue I’ve come across in environments is when the Datacenter or the Cluster object has been renamed and no longer matches what was originally configured and reference within VMware Horizon View. Logging onto the vCenter hosting the virtual desktops show the following:

Putting the vCenter and View configuration tab side by side shows how the vCenter Datacenter object is now named Wellesley House while the one in View is named Wesley House:

The quickest way to resolve this issue is to rename the object in vCenter to match VMware Horizon View’s configuration but if this is going to be a permanent change then the alternative is to edit the VMware Horizon View ADAM database to correct the issue as demonstrated in the following KB:

Provisioning a pool on VMware View generates error: Resource Cluster 'vcenter/host/clustername/Resources' not found for pool (2127993)

https://kb.vmware.com/s/article/2127993

Begin by logging onto one of the VMware Horizon View connection server and launching ADSIedit then click on Action and Connect to…:

Fill in the fields in the Connection Settings as such:

Name: View ADAM Database

Select or type a Distinguished Name or Naming Context: dc=vdi,dc=vmware,dc=int

Select or type a domain or server: localhost:389

Navigate into the database and select the OU=Server Groups object to list the desktop pools:

Right click on the desktop pool and select the properties option:

Locate the following attributes:

pae-VmTemplateName < this is the Template configuration

pae-VmPath < this is the VM folder configuration

pae-VmResourcePool < this is the Resource pool configuration

pae-VmDatastore < this is the Datastores configuration

Next, manually type in the correct string mapping to the objects in vCenter (do not simply clear them as you will not be able to load any of the settings for the pool):

With the configuration updated, the pool should no longer display an error message:

VMware vSphere 6.5 CPU per socket calculation

I’ve recently had a developer ask me why the socket calculation in VMware vSphere 6.5 is seemingly so different than the legacy 5.5 environment he was used to and I found it difficult to verbally walk him through the changes so I went ahead and quickly wrote up an explanation, which I thought would be useful to blog in case I need to explain it again in the future.

First off, the following VMware blog does a great job with explaining this but I try not to respond to people with a link as they may feel I haven’t put much effort into an answer.

Virtual Machine vCPU and vNUMA Rightsizing – Rules of Thumb
https://blogs.vmware.com/performance/2017/03/virtual-machine-vcpu-and-vnuma-rightsizing-rules-of-thumb.html

Here is the write up I sent:

The following are the two parameters we are presented with when attempting to allocate processors and cores to the VM:

CPU

Cores per Socket

The CPU value is used to determine the total amount of cores that we want to present to the VM.

The Cores per Socket is a setting we use to determine the amount of physical sockets that VM would have.  By this, I mean that if we wanted the VM to have, say, 10 cores of processing power, we can use either of the three settings:

Option #1

CPU: 10

Cores per Socket: 1

The above would yield a socket configuration of 10:

Option #2

CPU: 10

Cores per Socket: 5

The above would yield a socket configuration of 2:

Option #3

CPU: 10

Cores per Socket: 2

The above would yield a socket configuration of 5:

The Cores per Socket actually has no bearing on the amount of usable cores available to the VMs as it is used to determine how many sockets are presented to yield the amount of cores available.

With the above in mind, it is not possible to have a Cores per Socket value that is higher than the CPU value because that would equate to a total amount of cores that is higher than the CPU value or the last socket would need to have zero cores for math to work.  The following are options help demonstrate this:

Note how the maximum value allowed for Cores per Socket is always equal to or less than value of the CPU.

If I took the last example of having 16 for the value of CPU and configuring 8 cores per socket then that configuration would consist of 2 physical sockets with 8 cores each totaling 16 CPUs:

You’ve probably already noticed but the math is basically CPU divide by Cores Per Socket.

This has been a significant change to what was previously used to in version 5.5 (the above is 6.5) where the calculation makes more sense to many who have used that environment:

Notice how the way the older version calculates the cores is simply Number of virtual sockets multiple by the Number of cores per socket.

Attempting to use VMware vSphere PowerCLI's Connect-VIServer to a vCenter instance fails with: "The underlying connection was closed: An unexpected error occurred on a send."

Problem

You have VMware vSphere PowerCLI version 5.1.0.4977 installed:

You attempt to connect to a vSphere vCenter 6.7:

… using the Connect-VIServer cmdlet but it immediately fails with:

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Connect-VIServer vCenter.contoso.local

Connect-VIServer : 2/22/2019 11:41:37 AM Connect-VIServer The underlying connection was closed: An unexpected error

occurred on a send.

At line:1 char:1

+ Connect-VIServer vCenter.contoso.local

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: (:) [Connect-VIServer], ViError

+ FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_WebException,VMware.VimAutomation.ViCore.Cmdl

ets.Commands.ConnectVIServer

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI>

Solution

The reason why this error is thrown is because vCenter 6.7 only has TLS 1.2 enabled while TLS 1.0 and 1.1 is disabled by default so the older PowerCLI version installed, which attempts to connect via a one of the lower TLS versions will fail. The proper method of resolving this issue is to upgrade the old PowerCLI version to the latest one with the cmdlet Install-Module -Name VMware.PowerCLI as shown in the following PowerShell Gallery:

https://www.powershellgallery.com/packages/VMware.PowerCLI/11.1.0.11289667

The alternate solution is to force the .NET to use the appropriate TLS version for connecting to the vCenter:

Enabling the TLSv1.1 and TLSv1.2 protocols for PowerCLI (2137109)
https://kb.vmware.com/s/article/2137109

· For 32-bit processes, change the following registry key value to 1.

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\[.NET_version]
Value: SchUseStrongCrypto (DWORD)

· For 64-bit processes, in addition to the above registry key, change the following registry key value to 1.

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\[.NET_version]
Value: SchUseStrongCrypto (DWORD)

This workaround was handy for the project where the environment did not allow me to download or install any binaries on the endpoint I was using but I did find that the workaround with vSphere PowerCLI 5.1.0.4977 would only work with the 32-Bit version:

Adding the two registry keys in did not allow the 64-Bit version to connect.

Additional information - Invalid server certificate

Note that if you attempt to use the IP address of the vCenter to connect then you will receive the following error indicating that the certificate being presented is invalid:

PS C:\users\tluk\Downloads\vCheck-vSphere-master\vCheck-vSphere-master> Connect-VIServer 10.10.10.24

Connect-VIServer : 2/22/2019 3:47:15 PM Connect-VIServer Error: Invalid server certificate. Use

Set-PowerCLIConfiguration to set the value for the InvalidCertificateAction option to Prompt if you'd like to connect

once or to add a permanent exception for this server.

Additional Information: Could not establish trust relationship for the SSL/TLS secure channel with authority

'10.10.10.24'.

At line:1 char:1

+ Connect-VIServer 10.10.10.24

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : SecurityError: (:) [Connect-VIServer], ViSecurityNegotiationException

+ FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_CertificateError,VMware.VimAutomation.ViCore.

Cmdlets.Commands.ConnectVIServer

It is best practice to have a trusted certificate installed and to connect with the FQDN of the vCenter but if you do not meet either of the criteria then you can configure PowerCLI to ignore the certificate error with the following cmdlet:

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false

Scope ProxyPolicy DefaultVIServerMode InvalidCertificateAction DisplayDeprecationWarnings WebOperationTimeout

Seconds

----- ----------- ------------------- ------------------------ -------------------------- -------------------

Session UseSystemProxy Multiple Ignore True 300

User Ignore

AllUsers

Alternatively, if you want to install the self-signed certificate on the device that you are initiating the connection from so you can connect via the FQDN, you can use the same instructions I provided in the solution of one of my previous blog posts to download and install the certificate into the trusted store:

Attempting to upload a file onto a datastore with vSphere Client 6.5 fails with: "The operation failed."
http://terenceluk.blogspot.com/2018/11/attempting-to-upload-file-onto.html

Attempting to upload a file onto a datastore with vSphere Client 6.5 fails with: "The operation failed."

Problem

You attempt to upload a file onto a datastore in a vSphere 6.5 environment with the vSphere Client but notice that it fails with the error message:

Clicking onto the Details… link beside The operation failed. reveals the following message:

The operation failed

The operation failed for an undetermined reason. Typically this problem occurs due to certificates that the browser does not trust. If you are using self-signed or custom certificates, open the URL below in a new browser tab and accept the certificate, then retry the operation. https://esxi07.domain.com If this does not resolve the problem, other possible solutions are shown in this KB article: http://kb.vmware.com/kb/2147256

You proceed to view the certificate with the browser and install it into the Local Computer Trusted Root Certification Authorities but the upload continues to fail:

Solution

Other than issuing a certificate from a trusted authority such as an Enterprise CA or public CA, you can quickly get around this by browsing to the webpage of the vCenter and download the self-signed certificate via the Download trusted root CA certificates link at the bottom right corner:

The download.zip file will contain a certs folder with a subfolders representing different operating systems such as Linux, Mac and Windows.  Open the appropriate operating system folder:

Then proceed to install the root certificate onto the desktop launching the vSphere Client:

Browsing back to the vCenter’s root website should no longer present a certificate warning:

… and datastore uploads should now work.