Windows Admin Center via Azure Arc returns AadTimeoutAction on /manifest.json - one server not working while others with identical configuration work fine

Endika Garay 20 Reputation points

Environment:

  • Windows Server 2016 Standard (OEM license)
  • Server on-premises (Proxmox VM)
  • Connected to Azure via Azure Arc (agent version 1.64.03414.2961)
  • WAC extension version 0.76.0.0
  • Location: West Europe

Problem description:

Windows Admin Center is installed via Azure Arc extension on a server. When trying to connect from the Azure Portal, it shows "File not found" error. We have 10+ other servers with identical configuration where WAC works perfectly.

What works:

  • https://[server-ip]:6516/api?checkavailability=true returns HTTP 200 with correct CORS JSON
  • Azure Arc agent status: Connected
  • Port 6516 registered in Arc incomingconnections.ports
  • SSL certificate (arc.waconazure.com) correctly bound to port 6516
  • RBAC role "Windows Admin Center Administrator Login" correctly assigned
  • WAC service running

What fails:

  • GET /manifest.json returns HTTP 302 redirect to /?redirect=https://[fqdn]/manifest.json
  • Following the redirect returns HTTP 404
  • Accessing /manifest.json via FQDN directly returns: {"error":{"code":"UnauthorizedAccessError","message":"...","actionCode":"AadTimeoutAction"}}

HAR analysis:

On working servers: /manifest.json returns HTTP 200 directly.

On EXT-DOC-01: /manifest.json returns HTTP 302 → redirect → HTTP 404.

What we have tried:

  • Reinstalling the AdminCenter extension multiple times
  • Deleting and recreating the Arc resource
  • Re-assigning RBAC roles
  • Verifying cipher suites (no restrictions)
  • Verifying time synchronization (NTP synchronized correctly)
  • Copying WAC catalogs from working server
  • Clearing WAC certificates and rebinding

appsettings.json (same as working servers):

  • TokenAuthenticationMode: AadSso
  • EndpointFqdn: localhost
  • ServiceFqdn: [correct arc.waconazure.com FQDN]

Question:

Why does WAC redirect /manifest.json to AAD login on this specific server when the configuration is identical to other working servers? Is there any way to reset the AAD authentication state for a specific Arc resource without opening a paid support ticket?

  1. Bharath Y P 9,730 Reputation points • Microsoft External Staff • Moderator

    Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

    If you have any further questions or need additional clarification, feel free to reach out. Thanks!

Sign in to comment

Answer accepted by question author

Sina Salam 30,166 Reputation points • Volunteer Moderator

Hello Endika Garay,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Windows Admin Center via Azure Arc returns AadTimeoutAction on /manifest.json - one server not working while others with identical configuration work fine.

Regarding your explanations, the failure could be a broken or stale Azure Arc + Windows Admin Center Entra/AAD SSO identity state on the affected server, not by the WAC listener, RBAC assignment, SSL binding, or port 6516. Because, the evidence is that the local WAC health endpoint works, but /manifest.json is redirected into an AAD flow and fails with UnauthorizedAccessError / AadTimeoutAction, which means the Azure Portal cannot complete the WAC AadSso token flow for this specific Arc machine. Windows Admin Center in Azure depends on the Azure Arc connectivity platform, HIMDS, extension state, and the Arc machine identity, not only the local WAC service.

The best practice and reliable resolution is to perform a full Arc/WAC identity reset on the affected server:

  • Remove the Windows Admin Center / AdminCenter Arc extension.
  • Disconnect the Azure Connected Machine Agent to clear the local Arc state.
  • Uninstall and reinstall the Azure Connected Machine Agent.
  • Reconnect the server to Azure Arc as a fresh Arc-enabled server.
  • Reinstall Windows Admin Center from the Azure Portal.
  • Reassign Reader and Windows Admin Center Administrator Login at the affected Arc machine scope.
  • Validate that /manifest.json now returns HTTP 200.

Understand that simply deleting/recreating the Azure Arc resource or reinstalling only the WAC extension may leave stale local Arc identity, extension, or source-ID state behind. Microsoft documents stated that the supported cleanup process is to remove extensions, disconnect Arc, clear local state, and reinstall when a full reset is required. - https://learn.microsoft.com/en-us/azure/azure-arc/servers/prerequisites, https://learn.microsoft.com/en-us/azure/azure-arc/servers/uninstall-agent

After the full Arc/WAC reset, the WAC AadSso path should be rebuilt cleanly and /manifest.json should load successfully from the Azure Portal. If it still fails after the reset, the remaining root cause is outbound network/proxy/WebSocket blocking specific to this VM, and the next validation must be against Azure Arc and WindowsAdminCenter network requirements. - https://learn.microsoft.com/en-us/azure/azure-arc/servers/network-requirements, https://learn.microsoft.com/en-us/azure/azure-arc/servers/troubleshoot-vm-extensions

Use the below resource links for more reading and steps:

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

0 comments No comments
Sign in to comment

1 additional answer

  1. Bharath Y P 9,730 Reputation points • Microsoft External Staff • Moderator

    Hello Endika, On one specific Arc-enabled server (EXT‑DOC‑01), Windows Admin Center in the Azure portal fails with"File not found", and the HAR trace shows:

    • GET /manifest.json > HTTP 302 > /?redirect=https://[fqdn]/manifest.json > HTTP 404
    • Direct FQDN call returns UnauthorizedAccessError with actionCode: AadTimeoutAction
    • Yet the local data-plane is healthy: :6516/api?checkavailability=true = HTTP 200, cert bound, port registered, agent Connected, RBAC assigned, appsettings.json identical to the 10+ working servers.

    The critical signal is this: the failure is in the Microsoft Entra (AAD) authentication leg of the WAC reverse-proxy session, not in the local WAC service or the network path. The 200 on /api?checkavailability=true proves the WAC web service and certificate are fine; the 302 > login > 404 on /manifest.json proves the auth middleware is refusing to serve authenticated content and is bouncing you into an AAD sign-in flow that has nowhere valid to land.

    For Windows Admin Center (WAC) via Azure Arc, the Azure portal doesn’t connect directly “to your server” over inbound ports. Instead, the Hybrid Connectivity layer establishes a reverse-proxy session and generates a short-lived URL that the portal uses to reach WAC on the configured port (default 6516).

    In other words, WAC access from the Azure portal depends on the Arc reverse-proxy/session path behaving correctly. The docs also call out that inbound connectivity being redirected by another service (example: Azure Firewall) is not supported, and troubleshooting typically focuses on HIMDS + WAC extension/service + reverse-proxy port configuration + outbound connectivity.

    In your case:

    • /manifest.json behaves differently on one server (returns 302 → redirect → 404 vs 200 elsewhere)
    • Direct access triggers UnauthorizedAccessError with AadTimeoutAction

    That points to an authentication flow / token / session expectation problem on that one host, even if the WAC extension installation and most settings match.

    The docs you provided don’t include a supported “reset Entra/AAD authentication state for a single Arc resource” operation for WAC specifically. However, they do provide a safe set of troubleshooting steps that target the components involved in establishing and serving the WAC session.

    **What to try (useful steps from the docs)

    1) Restart HIMDS (Hybrid Connectivity service) on the affected server

    The WAC troubleshooting guide specifically recommends:

    • Restart the HIMDS service:
    • Restart-Service -Name himds

    This can resolve issues where the Arc-side session/proxy flow is misbehaving.

    2) Confirm the WAC extension + required services are running

    Per the WAC via Arc troubleshooting guidance:

    • Ensure the Windows Admin Center service (ServerManagementGateway / Windows Admin Center) is running.
    • Ensure the AdminCenter extension version is 0.0.0.169 or higher (the doc calls out a minimum version for certain connectivity behaviors).

    Because you already have reinstall attempts, the key value here is to re-check the extension version currently installed on the failing host right after restart.

    3) Verify the reverse-proxy port is enabled for Arc incomingconnections.ports

    Even though you believe port 6516 is registered, the recommended troubleshooting step is explicit:

    • Run:
      • azcmagent config list
      • Confirm the port used by WAC is present under:
        • incomingconnections.ports (preview)

    If it’s missing, set it:

    • azcmagent config set incomingconnections.ports <port>

    4) Verify outbound connectivity to the WAC/Arc endpoints from the server

    The docs list required outbound endpoints, including:

    • *.wac.azure.com or the WindowsAdminCenter ServiceTag
    • *.waconazure.com (also mentioned in the WAC troubleshooting section)
    • pas.windows.net
    • *.servicebus.windows.net

    Also, the WAC troubleshooting section suggests a connectivity test from the VM:

    • Invoke-RestMethod -Method GET -Uri https://<your_region>.service.waconazure.com

    This matters because if the auth/session components can’t reach needed endpoints, you can end up with inconsistent auth errors/timeouts on one host.

    5) Double-check “unsupported inbound redirection” patterns

    From the Arc/WAC troubleshooting guidance:

    • Inbound connectivity being redirected by another service is not supported (example: Azure Firewall redirecting traffic).

    If the failing host is subject to any special network/security appliance behavior on inbound paths (even if you think you only rely on outbound reverse proxy), that can cause one host to deviate.

    About “resetting AAD authentication state”

    From the provided documentation set, there isn’t a documented, supported command like “reset AAD authentication state for this Arc/WAC resource.”

    So the closest supported approach (based on what the docs do recommend) is to reset the components that participate in the WAC session:

    • restart himds
    • confirm incomingconnections.ports
    • confirm WAC service is running and extension version meets minimum
    • confirm outbound connectivity to the required endpoints

    If the issue persists after the above, the docs for WAC in Arc indicate collecting logs (portal + azcmagent logs) and then escalating. They also mention support can be opened, but they don’t provide a “self-service only” resolution for this exact auth timeout/redirect behavior.

    References:

    Hope this helps. If the information was useful, please consider accepting the answer and upvoting. Feel free to reach out if you need any further assistance. Thank you.

    0 comments No comments
    Sign in to comment
Sign in to answer

Your answer