Azure Arc Connectivity Issue: Outbound Proxy Handshake Failure

Juliet Temichel 40 Reputation points
2026-07-13T14:55:51.7566667+00:00

OS: Windows Server (Various editions)

Deployment: Edge/Branch Office sites

Management Framework: Azure Arc (Centralized Patching)

Network Constraint: Outbound proxy utilized for traffic egress

Symptoms: Intermittent and persistent disconnection from the Azure control plane.

=> Failure of centralized patch compliance workflows. We suspect an outbound proxy handshake failure or interruption. We request specific debug/log analysis steps to validate proxy handshake status and seek guidance on isolating proxy-related TCP/TLS handshake errors versus agent-side timeouts.

Windows for business | Windows 365 Enterprise
0 comments No comments

Answer accepted by question author
Harry Phan 32,265 Reputation points Independent Advisor
2026-07-13T15:27:27.44+00:00

Hi Juliete,

Start by validating Azure Arc agent connectivity on the affected server with azcmagent show and review the Connected Machine Agent logs under C:\ProgramData\AzureConnectedMachineAgent\Log\. Enable verbose logging if needed and look for connection failures, proxy authentication errors, TLS certificate validation failures, and timeout-related AZCM error codes.

To isolate proxy-related issues, confirm the agent's configured proxy settings using azcmagent config list and verify that outbound HTTPS (TCP 443) connectivity to all required Azure Arc endpoints succeeds through the proxy. Azure Arc communicates exclusively over HTTPS/TLS, so TLS inspection, certificate substitution, or blocked service tags can cause intermittent disconnects.

If the logs show connection resets, SSL/TLS validation errors, proxy authentication failures, or handshake termination immediately after the CONNECT request, focus on the proxy infrastructure. If instead you see successful TLS establishment followed by heartbeat failures, request timeouts, or delayed responses, the issue is more likely agent-side, endpoint filtering, or network latency affecting Azure control-plane communication.

For deeper validation, collect a simultaneous network trace (netsh trace start capture=yes) and proxy logs during a disconnect event. Correlating the Arc agent timestamp with the TCP session lifecycle will clearly distinguish a proxy/TLS handshake failure from an application-layer timeout within the Azure Connected Machine agent.

Harry.

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.