Reassociate Hyper-V Host in SCVMM after In-Place OS Upgrade (Without Losing VM Tags)

Question

Reassociate Hyper-V Host in SCVMM after In-Place OS Upgrade (Without Losing VM Tags)

Redecker, Alexander 0

Hello All, now question but a solution if it is interesting for you!

Problem Description:
After performing an in-place operating system upgrade on a Hyper-V host (e.g., Windows Server 2016 to Server 2022/2025), the host status in System Center Virtual Machine Manager (SCVMM) often changes to "Needs Attention" or "Not Responding." The "Reassociate" button in the SCVMM console is greyed out. Pushing a standard reassociation or using Add-SCVMHost fails with CredSSP/WinRM multi-hop errors, even if CredSSP is locally enabled.

The standard Microsoft recommendation is to remove the host from SCVMM and re-add it. However, doing so wipes out all custom VM tags, causing massive manual re-tagging overhead in production environments.

The No-Data-Loss Solution: The host can be cleanly reassociated without losing any metadata or VM tags by manually stripping the broken agent on the host side while keeping the VMM database object intact, followed by a programmatic reassociation.

Step 1: Uninstall the VMM Agent locally on the upgraded Host

Do NOT delete the host from the SCVMM console. Instead, log onto the upgraded Hyper-V host and open an elevated PowerShell window to remove the agent cleanly via its MSI product ID:

powershell

Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -like "*Virtual Machine*"} | ForEach-Object { $_.Uninstall() }

Verwende Code mit Vorsicht.

Step 2: Verify the Agent is removed

Ensure the previous command returned no errors and the agent package is completely gone:

powershell

Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -like "*Virtual Machine*"}

Verwende Code mit Vorsicht.

(Optional but recommended: Reboot the Hyper-V host at this point to clear out locked WMI namespaces).

Step 3: Force Reassociation from the VMM Management Shell

Open the VMM Management Shell on your SCVMM server. Run Add-SCVMHost and explicitly pass $true to the -Reassociate parameter. This forces SCVMM to push its fresh agent package onto the host and marry it back to the existing database entry:

powershell

$Credential = Get-Credential
Add-SCVMHost -ComputerName "yourhost.domain.local" -Credential $Credential -Reassociate $true -VMHostGroup "All Hosts"

Verwende Code mit Vorsicht.

Result: The host successfully returns to "Responding" status. Because the host object was never deleted from the VMM database, all VM tags, custom fields, and metadata remain perfectly intact.

0 comments

3 answers

Your answer

Answer 1

The described approach aligns with how SCVMM handles host reassociation and host objects in the database, but there are important supported methods and best practices to consider from official guidance.

SCVMM supports reassociating hosts without deleting them, which preserves metadata such as VM tags:

In the VMM console, select Fabric > Servers > All Hosts.
Ensure the Agent Status column is visible. If not, right-click a column heading and select Agent Status.
Refresh the host group. Hosts that need reassociation show Host Status = Needs Attention and Agent Status = Access Denied.
Right-click the host and select Reassociate.
In the Reassociate Agent page, provide appropriate credentials and select OK. The Agent Status transitions to Reassociating, then to Responding when successful.
Refresh the host; Host Status should display OK. After reassociation, updating the VMM agent on the host may be required.

This UI-based reassociation works specifically to keep the existing host object and its associated metadata (including VM tags) intact, avoiding the data loss that occurs when removing and re-adding the host.

If the host has been restored or the VMM server has changed (for example, after restore to a different computer), SCVMM also supports reassociation during host add:

When adding a Windows server as a Hyper-V host (Fabric > Add Resources > Hyper-V Hosts and Clusters), in Host settings > Host group, select the target host group.
If the host is already associated with a different VMM management server, select Reassociate this host with this VMM environment. This moves the host to the current VMM server without recreating the host object, again preserving metadata.

If host status remains Needs Attention or Not Responding after an OS upgrade, supported troubleshooting steps include:

Checking host health via Host Properties > Status to see detailed error categories.
Verifying the VMM service account is a member of the local Administrators group on the host (or that the computer account is, if VMM runs under Local System), and adjusting Group Policy if a Restricted Groups policy removed it.

Increasing WinRM quotas on the VMM server and Hyper-V hosts:

  winrm quickconfig
  winrm set winrm/config @{MaxTimeoutms="1800000"}
  winrm set winrm/config/Service @{MaxConcurrentOperationsPerUser="1500"}
  winrm set winrm/config/winrs @{MaxConcurrentUsers="100"}
  winrm set winrm/config/winrs @{MaxProcessesPerShell="100"}
  winrm set winrm/config/winrs @{MaxShellsPerUser="100"}

  set-item "WSMan:\localhost\Plugin\WMI Provider\Quotas\MaxConcurrentOperationsPerUser" 400

Then restart WinRM and WMI or reboot.

For untrusted/workgroup hosts, ensuring LocalAccountTokenFilterPolicy is set to 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
If WMI corruption exists after OS changes, rebuilding the WMI repository on the host by recompiling MOF files, then refreshing the host in VMM.

All of these methods are designed to restore host communication and allow reassociation while keeping the existing host entry, avoiding removal/re-add operations that would drop associated metadata.

References:

Answer 2

Hi Redecker, Alexander,

Your strategy is the correct approach, but the method used to remove the local agent requires a critical adjustment. You must strictly avoid using the Win32_Product management instrumentation class to remove the software. Querying that class triggers a mandatory Windows Installer consistency check across every application on your server, which can severely degrade host performance, reset application configurations to defaults, and cause unexpected production outages.

To achieve a clean removal without triggering a system-wide installer validation, you should utilize the standard PackageManagement modules built into modern PowerShell. Using the Get-Package cmdlet filtered for the Virtual Machine Manager agent and piping that output to the Uninstall-Package cmdlet provides a safe and direct uninstallation. Alternatively, you can pull the application uninstallation string directly from the local machine registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and execute it silently. This specific registry key simply stores the exact uninstall commands for all installed software, allowing you to bypass the heavy system overhead associated with querying Windows Management Instrumentation.

Once the corrupted agent is safely removed from the upgraded host, your method of forcing the reassociation via the management shell is perfectly executed. Invoking the Add-SCVMHost cmdlet with the reassociate parameter set to true bypasses the graphical console's reliance on the broken local instrumentation. This command forces the management server to push a fresh agent package down to the host, rebuild local trust relationships, and seamlessly marry the new operating system instance to the existing SQL database record, ensuring all custom virtual machine tags and metadata remain completely intact.

Hope this answer has brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VPHAN

Answer 3

Hello All,

i also now have the same Topic for Clusternodes get InPlace Upgrades.
The described procedure does not work for Clusternodes (in Case that SCVMM say message like it is a part of a Cluster).

But i also find a Procedure which is near the same steps and work for me.

Uninstall VMM Agent like is described
Install VMM Agent manual again on the Clusternode (vmmAgent.msi) you can find it in VMM ISO or on SCVMM Server in following location "C:\Program Files\Microsoft System Center\Virtual Manager\Agents" and just klick through install default.
After refresh Clusternode in SCVMM it looks like SCVMM reassociate the Host automatically (on my Environment).
If you have installed Update Rollup in your Environment and install the Agent from Base SCVMM ISO the Agents needs an Update "Update Agent is available" in Fabric View

After this procedure Clusternode looks fine again in SCVMM.

Thanks and best regards