This is a continuation of a series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article continues to discuss troubleshooting the Azure Arc resource bridge with a few more cases.

The resource bridge is designed to host other Azure Arc services. It supports VM self-servicing and management from Azure, for virtualized Windows and Linux virtual machines hosted in on-premises environment. It comes with a management Kubernetes cluster that requires no user management. In this sense, it is a virtual appliance.

Logs can be collected for further investigation, and this is probably the foremost resolution techniques. The collection is done with the az arcappliance logs command which must be run from the client machine from which the Azure arc resource bridge was deployed. The path to the kubeconfig must be provided.

Networking issues manifest when the resource bridge is unreachable. The resource bridge runs a Kubernetes cluster and its control plane requires a static ip address which is specified in the infra.yaml file. Rebooting an Azure arc resource bridge or VM can trigger an IP address change, resulting in failing services but rebooting the Azure arc resource bridge VM should help recover its IP address.

 Updating the Azure Arc resource bridge requires deleting it and redeploying it because all the parameters are specified at the time of creation. If the wrong location or subscription is specified during the resource creation, it fails. Recreating the resource without redeploying leaves it is a suspended state. Deleting and then updating the appliance yaml file followed by redeploying the resource bridge is recommended.

During the createConfig or run command execution, there will be an interactive experience which shows the list of VMWare entites where the user can select to deploy the virtual appliance. This list shows the user created resource pools along with the cluster resource pools but the default host resource pools are not listed. When the appliance is deployed to a host resource pool, there is no high availability if the hardware fails. It is therefore recommended that the appliance not be redeployed to a host resource pool.

Azure Arc must be configured for proxy to connect with the Azure services. The configuration is handled automatically but proxy configuration of the client machine is not handled by the resource bridge. There are two certificates required to redeploy the Azure Arc resource bridge behind an SSL proxy. First, the SSL certificate for the proxy so that the host and guest can handshake with it and second the SSL certificate of the Microsoft downloaded servers.  Adding the certificate to the trust stores is required for the clients to connect.

Authentication handshake failures may not always occur due to certificates.  Certificates-signed-by-an-unknown-authority error can be displayed when the arcappliance commands are run using a remote PowerShell. Since it is not supported by the Azure Arc resource bridge, those commands must be run locally on a node in the cluster. The RDP or the console session will help with these.