• Intro
• Identifying a failing Arc Resource Bridge
• Deployment failure at “Deploy the Arc Infrastructure Management Components”
• Try upgrading the ARB first (previously healthy clusters only)
• Collecting ARB logs
  • Locating the ARB IP and cloud agent
  • Prerequisites
• Providing the logs to Microsoft Support

Intro

If the Arc Resource Bridge (ARB) on Azure Local is in a failing state — for example showing WaitingForHeartbeat or Offline in the Azure Portal — and you have exhausted the usual remediation steps, you will likely need to open a support ticket with Microsoft. Microsoft Support will almost always ask for ARB logs as part of the initial triage.

In this article I will walk through how to identify a failing ARB and how to collect the logs using the az arcappliance logs hci command. This applies both to a previously healthy ARB that has entered a failing state, and to an initial Azure Local deployment that fails at the Deploy the Arc Infrastructure Management Components step — as long as the ARB VM was created before the failure.

Identifying a failing Arc Resource Bridge

The first sign is usually that operations from Azure Portal against resources on your Azure Local stack stop working — deploying VMs, managing AKS Arc clusters, or other Arc-enabled workloads fail with connectivity errors.

To confirm the state of the ARB, open the Azure Portal and navigate to your Azure Local resource. Under Arc Resource Bridge you should see the current status. A healthy ARB shows Online. If you see WaitingForHeartbeat or Offline outside of an active deployment, something is wrong.

You can also verify from the Azure Local stack itself. Open Windows Admin Center or Failover Cluster Manager and look at the ARB VM — it should be in a Running state on one of the nodes.

The ARB VM being Running in the cluster but still showing WaitingForHeartbeat in the portal is a common pattern. It means the ARB VM is powered on, but the internal services or connectivity to Azure are not working as expected.

HINT

WaitingForHeartbeat is fine if an ARB deployment is actively in progress. It is only a problem if the ARB has previously been in a healthy Running state and has now regressed to WaitingForHeartbeat or Offline.

Deployment failure at “Deploy the Arc Infrastructure Management Components”

The az arcappliance logs hci command is equally useful during an initial Azure Local deployment that fails partway through. If the deployment gets stuck or fails at the Deploy the Arc Infrastructure Management Components step, the ARB VM is typically already present in the cluster at that point — meaning the log collection command can reach it.

To verify the ARB VM exists, open Failover Cluster Manager on one of the nodes and check Roles. If you see an entry with a name like <clustername>-arcbridge in a Running or stopped state, the VM is there and the logs can be collected.

HINT

If the deployment failed before the ARB VM was created at all, there is nothing for the command to connect to. In that case, collect the deployment logs from the Azure Portal (Azure Local → Deployments) and provide those to Microsoft Support instead.

Once you have confirmed the ARB VM is present, run the same az arcappliance logs hci command described below — the parameters and paths are identical.

Try upgrading the ARB first (previously healthy clusters only)

Before collecting logs and opening a support ticket, it is worth attempting a manual ARB upgrade if the cluster has previously been in a healthy state. Upgrading the ARB can resolve situations where the ARB VM is running but the internal components are outdated or in a degraded state.

I have written a separate article that walks through how to run a manual MOC ARB upgrade, including how to remediate common pre-upgrade issues using the Support.AksArc PowerShell module: Azure Local – MOC ARB update failed doing solution upgrade

HINT Skip this step if the ARB has never successfully deployed — a manual upgrade requires a functional enough ARB to connect to. In that case, go straight to log collection.

Collecting ARB logs

Microsoft provides a dedicated command for collecting ARB logs on Azure Local. Run the following from a node in the cluster (or from a machine with the Azure CLI and the arcappliance extension installed, with access to the cluster network):

az arcappliance logs hci `
  --ip 192.168.0.232 `
  --kubeconfig "C:\ClusterStorage\Infrastructure_1\Shares\SU1_Infrastructure_1\MocArb\WorkingDirectory\Appliance\kubeconfig" `
  --loginconfigfile "C:\ClusterStorage\Infrastructure_1\Shares\SU1_Infrastructure_1\MocArb\WorkingDirectory\Appliance\kvatoken.tok" `
  --cloudagent "azhcickj02.az.local" `
  --out-dir "C:\temp\arb-logs"

Here is what each parameter means:

• --ip — the IP address of the ARB VM. This is the appliance IP assigned during deployment.
• --kubeconfig — path to the kubeconfig file for the ARB appliance. This is always located in the ARB working directory under MocArb\WorkingDirectory\Appliance\.
• --loginconfigfile — path to the kvatoken.tok file, also in the ARB working directory. This is the token used to authenticate with the cloud agent.
• --cloudagent — the FQDN or hostname of the cloud agent (MOC CloudAgent). This is the name of your failover cluster object (the name our our Azure Local instance)
• --out-dir — the local directory where the logs will be written. Create this directory before running the command if it does not already exist.

Note that the paths for --kubeconfig and --loginconfigfile follow this pattern for Azure Local:

C:\ClusterStorage\<InfraVolume>\Shares\<ShareName>\MocArb\WorkingDirectory\Appliance\

Adjust the volume and share name to match your environment.

Locating the ARB IP and cloud agent

If you are unsure of the ARB IP or cloud agent name, you can retrieve them with:

Get-MocConfig

Look for cloudFqdn (this is your --cloudagent value) and ipAddressPrefix or the appliance VM IP in the output.

Alternatively, check the ARB VM IP directly from Failover Cluster Manager or from the ARB VM network adapter settings.

Prerequisites

Make sure you have the arcappliance Azure CLI extension installed:

az extension add --name arcappliance

Or update it if already installed:

az extension update --name arcappliance

Providing the logs to Microsoft Support

After the command completes, zip the contents of --out-dir and upload the archive to your support case via the Azure Portal (Support + troubleshooting → your open case → File upload).

The log bundle contains diagnostic output from the ARB VM itself, the MOC stack, and connectivity information that Microsoft Support uses to identify the root cause.

Final remark: if the ARB is in a failing state after a previously successful deployment, do not attempt to redeploy it without first consulting Microsoft Support or reviewing the available self-service remediation steps in the Azure Local documentation. Redeploying the ARB incorrectly can leave the environment in a harder-to-recover state.