Share via

Azure Connected Machine Agent update 1.56 creates issues for IIS App Pool Identities

Mark Stuart 0 Reputation points
2025-09-23T00:47:29.5066667+00:00

A production server my company has installed the Azure Connected Machine Agent recently updated the agent to version 1.56.

We use the agent for IIS sites to have a Managed Identity when connecting to an Azure App Configuration resource for loading sensitive values for our sites.

A couple of hours after the Arc Agent was installed, some of these sites App Pools were recycled. When they were restarted some of them were not able to access the C:\ProgramData\AzureConnectedMachineAgent\Tokens folder and therefore could not start.

All the effected sites are running using App Pool Identities. I confirmed that all the App Pool Identities were still members of the "Hybrid agent extension applications" group, confirming all the security ids were still valid.

Some odd behaviour observed is that only 3 of the sites seemed to be effected, while others could start, and therefore access the tokens folder.

This was the exception being thrown

MSAL.NetCore.4.73.1.0.MsalServiceException:

ErrorCode: managed_identity_request_failed

Microsoft.Identity.Client.MsalServiceException: Access to the path 'C:\ProgramData\AzureConnectedMachineAgent\Tokens\443864d5-d293-4b3a-a7cc-440f32d8dc2d.key' is denied.

The effected sites had the same configuration as the others and the App Pool Identities they were running under were members of the "Hybrid agent extension applications" group.

What I'm looking for are instances of other users having similar issues, and hopefully remediation steps, or further troubleshooting steps I could try to find the root cause of the issue.

For now I've assigned the IIS_IUSRS group read access to the tokens folder. While this works, it's a sub-optimal solution.

I have managed to replicate the issue on a non production server and it does seem related to the 1.56 update.

Azure Arc
Azure Arc

A Microsoft cloud service that enables deployment of Azure services across hybrid and multicloud environments.

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Amira Bedhiafi 41,386 Reputation points MVP Volunteer Moderator
    2026-04-21T13:38:36.99+00:00

    Hello Mark !

    Thank you for posting on MS Learn Q&A.

    This doesn't look like a simple app misconfiguration because when I check the docs and the broader 1.56 incident, I would treat this as either a 1.56 Windows regression affecting HIMDS or token access paths or an ACL or inheritance issue on the individual token files not just the tokenfolder itself and that would also explain why only some app pools failed while others with the same configuration still worked.

    I found this old thread :

    https://learn.microsoft.com/en-us/answers/questions/5558004/arc-service-fail-after-upgrade-to-v1-56

    You can compare ACLs on the folder and on the actual .key files for a working site versus a failing site and the exception you shared is on a specific file so folder membership alone may not prove the file inherited the expected ACEs.

    You can verify also if the failing worker process token actually contains the group SID at runtime because group membership on the identity object is one thing and the running w3wp.exe token is what matters.

    You can review also Arc HIMDS logs and Windows events around the recycle time because it can be related to HIMDS agent failure and azcmagent check --include-all --verbose helped confirm the problem.

    I would avoid keeping IIS_IUSRS on the token folder long term unless you have no alternative because MS model is to scope access through hybrid agent extension apps and not broad IIS worker access.

    0 comments

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.