Azure Arc Resource Bridge for SCVMM stuck in WaitingForHeartbeat

Question

I’m troubleshooting a failing Azure Arc Resource Bridge deployment for SCVMM and am looking for guidance on next steps.

• In Azure Portal, the Resource Bridge resource remains in WaitingForHeartbeat
• The deployment script does not complete and remains at “Waiting for control plane to be in running state”
• The appliance VM is created successfully and Kubernetes components appear to start, but the deployment never finishes

Environment details

• Single tenant, single subscription (development tenant)
• Deployment identity:
  • Global Administrator
  • Owner at subscription scope
• Required resource providers are registered
• SCVMM account used during deployment:
  • Administrator in SCVMM
  • Credentials verified (the template is deployed fine by the script and appliance boots up)
• Network environment:
  • No proxies
  • No SSL inspection
  • No Private Link configuration
  • Direct outbound internet access

Identity-related logs

From the ApplianceConnectAgent and related identity components, the following messages appear repeatedly:

In clusterIdentityCRDInteraction status not populated
GetTokenProvider().GetToken() error status not populated

SCVMM connectivity logs

From the capvmm-controller-manager logs during deployment, the appliance reports failures when attempting to connect to the SCVMM server. The following messages are observed:

MI_RESULT_FAILED
failed to create vmmserver session

I found this guide related to the MI_RESULT_FAILED error but the suggestion didn't help.

First guess is the managed identity isn't coming up because the appliance isn't able to get some sort of secret from VMM. I can't find anything wrong with my VMM server, I can powershell remote into it just fine from the management workstation. The management workstation used for deployment and the vmm server and the appliance are all in the same subnet with no microsegmentation or other L2 controls.

At this point:

• The appliance VM deploys
• Kubernetes initializes
• The control plane does not transition to Running
• The Azure Portal remains in WaitingForHeartbeat
• Identity-related components continue retrying with the messages shown above

Any ideas where to go from here? I feel like all the stars should be aligned with how straightforward my development environment is in this stage, and this being an appliance deployed with a provided script. I have all the logs pulled from the appliance with Azure cli if there's additional things to search for, let me know.

Thanks! Charles

Answer 1

Hello Charles Pickering The Arc Resource Bridge for SCVMM was stuck in WaitingForHeartbeat because the SCVMM provider could not establish a PowerShell remoting session over WinRM. The logs showed:

MI_RESULT_FAILED – New-PSSession failed with Authentication 'Negotiate'

This indicated a WinRM/Kerberos authentication issue, not SCVMM service reachability.

The root cause of the issue is Missing SPNs for the HTTP/WinRM service on the SCVMM service account. While the documented prerequisites mention SCVMM SPNs, Kerberos also requires SPNs for HTTP when using New-PSSession with Negotiate authentication.

Below are the resolution steps:

• Added SPNs for HTTP/WinRM on the SCVMM service account: setspn -S HTTP/<FQDN> setspn -S HTTP/<NetBIOS>
  • Verified WinRM listeners and authentication settings.
  • After updating SPNs, Kerberos negotiation succeeded, the SCVMM provider initialized, and the control plane transitioned to Running.
• If you see MI_RESULT_FAILED and Event ID 142 in WinRM logs during Arc SCVMM onboarding:
  • Check WinRM listener bindings (must include NIC IPs, not just loopback).
    • Validate Kerberos prerequisites.
    • SPNs for SCVMM and HTTP/WinRM
    • DNS resolution for FQDN
    • Time synchronization
    • Ensure WinRM ports (5985/5986) are reachable from the appliance.

If Arc Resource Bridge for SCVMM is stuck in WaitingForHeartbeat and logs show New-PSSession failures, don’t stop at SCVMM SPNs—also verify HTTP/WinRM SPNs for Kerberos.

Reference: https://learn.microsoft.com/en-us/azure/azure-arc/system-center-virtual-machine-manager/troubleshoot-scvmm

https://learn.microsoft.com/en-us/azure/azure-arc/system-center-virtual-machine-manager/support-matrix-for-system-center-virtual-machine-manager

Thanks,

Suchitra.

Answer 2

Hi ,

 

Thanks for reaching out to Microsoft Q&A.

In Arc Resource Bridge for SCVMM, WaitingForHeartbeat + MI_RESULT_FAILED means the appliance cannot establish a persistent VMM server session using WinRM with Kerberos/Negotiate, which is mandatory even if basic powershell remoting works. The mi does not fully come up until this succeeds, which is why clusterIdentity stays unpopulated.

Concrete things to check next (do not skip these):

SCVMM WinRM configuration

WinRM must be enabled and listening on HTTP (5985) on the VMM server.

  `winrm enumerate winrm/config/listener` on the VMM server.
  
     HTTPS-only WinRM or hardened WinRM configs break Arc RB.
     

1. Kerberos / SPN issues

Ensure the SCVMM service account has correct SPNs registered.

No duplicate SPNs for the VMM server name.

• Test from the appliance VM: --> Test-WSMan <VMMServerFQDN> ->This must succeed without prompting.

Time sync

  Even small clock skew between appliance, VMM, and domain controller will break Kerberos silently.
  
     Verify time sync on all three.
     
     Firewall
     
        Confirm 5985, 443, 80, and dynamic RPC ports are open both ways between appliance and VMM.
        
           Many dev environments miss return traffic.
           
           SCVMM version and patch level
           
              Arc RB is sensitive here. Ensure SCVMM is on a supported update rollup.
              
                 Older URs fail MI session creation.
                 

If Test-WSMan from the appliance fails or falls back to NTLM, that is your root cause. Until Kerberos WinRM works cleanly, the control plane will never reach Running and azure will stay in WaitingForHeartbeat.

 

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

Answer 3

The issue turned out to be missing SPNs, but NOT the SCVMM/ ones as documented. Adding SPNs for the HTTP/ WinRM service on the vmm service account resolved the issue.