Suspected: stale Entra Cloud Sync agent blocking SSPR Password Writeback

Question

Suspected: stale Entra Cloud Sync agent blocking SSPR Password Writeback

Mike D 0

Hello,

We recently decommissioned an on-premises Microsoft Entra Connect Cloud Sync provisioning agent server. This has left the agent object listed as "Inactive" in our Entra tenant dashboard. Our active sync configurations and object deltas remain 100% functional on our remaining surviving active agent machine.

However, we think our tenant-wide Self-Service Password Reset (SSPR) Password Writeback gateway may have halted routing due to this overall agent cluster status error, as our Entra audit logs show a status of OnPremisesAgent: None for recent password change attempts.

To try and restore the SSPR path and remove the dead server from our dashboard without waiting out the full 10-day automatic inactivity purge window, we attempted to remove the stale agent object via the Microsoft Graph Beta endpoints.

When issuing a DELETE request against the agent reference paths, the Graph API blocks the transaction and returns this error payload:

{
  "error": {
    "code": "DeleteAgentRef_NotImplemented",
    "message": "Deleting agent ref is not supported.",
    "innerError": {
      "request-id": "[REDACTED-REQUEST-ID]",
      "client-request-id": "[REDACTED-CLIENT-REQUEST-ID]"
    }
  }
}

Environment Context

Active Sync Engine: Microsoft Entra Connect cloud sync (Provisioning Agent)
Stale Agent Machine Status: Inactive (Decommissioned)
API Behavior: DELETE on /beta/onPremisesPublishingProfiles/provisioning/agentGroups/{group-id}/agents/{agent-id}/$ref explicitly returns DeleteAgentRef_NotImplemented.

Because the API layer appears to block manual removal of these provisioning schema objects, we seem to be stuck waiting for the 10-day automatic backend clean-up timer to clear our SSPR writeback path.

Requested Assistance

Can you please confirm that password writeback is effectively disabled when any agent in the group is inactive? If so, could a Microsoft Support Engineer please engage with me via a secure private message to collect my actual Tenant ID, Service Principal ID, and Agent GUID? We would appreciate assistance from the backend engineering team to help us safely evict or purge the stale agent ID to see if it restores our SSPR writeback functionality. I have a paid Developer Support plan.

Thank you.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Mike D 0 Reputation points

2026-08-18T23:37:09.44+00:00
Additional diagnostic context, in case useful:

Before suspecting the agent status specifically, we ruled out several other possible causes with direct evidence, in case useful context for whoever picks this up:

AD-side writeback permissions confirmed sufficient via AWS Support's own empirical validation against a matching test AWS Managed Microsoft AD directory (Reset Password, pwdLastSet, and lockoutTime correctly scoped on the target OU; Unexpire Password confirmed present via the default Authenticated Users grant on the domain object — no explicit grant needed)

Both writeback toggles confirmed enabled: Set-AADCloudSyncPasswordWritebackConfiguration -Enable $true, and the Entra admin center's "Write back passwords with Microsoft Entra Connect cloud sync" checkbox

Minimum password age confirmed 0 in the relevant on-premises Fine-Grained Password Policy

Ruled out AdminSDHolder / protected-group exclusion for the test user (adminCount not set, no group memberships)

Confirmed the test user's on-premises sync link itself is healthy via Graph (onPremisesSyncEnabled: true, valid onPremisesImmutableId, onPremisesDistinguishedName correctly populated, recent onPremisesLastSyncDateTime)

Confirmed the active agent is otherwise fully healthy — Get-AADCloudSyncToolsJobStatus shows the general AD→Entra provisioning job as Active/Succeeded with real, current sync activity throughout

Live agent-side trace evidence: we captured a live trace (Export-AADCloudSyncToolsLogs -TracingDurationMins 12) bracketing an actual test password reset, with confirmed real-time log flushing verified throughout the capture (not a buffered/post-hoc write). The agent registers a passwordWriteback scenario handler at startup (TrustedPartyRequestProcessor: Registered scenario handler for: TrustedPartyName 'syncfabric', ScenarioName 'passwordWriteback') and correctly processes other request types (ScenarioName 'aadprovisioning') during the same window. However, the trace shows zero invocation of the passwordWriteback handler at any point, despite the reset completing (logged in the Entra audit log as OnPremisesAgent: None) well inside the capture window — roughly 2 minutes after the reset was initiated, with 10+ minutes of capture remaining afterward.

This is what led us to suspect the stale/inactive second agent registration specifically — everything else that could plausibly explain a silent, no-error failure has now been ruled out with direct evidence.

Environment recap: AWS Managed Microsoft AD, provisioning agent on Windows Server 2022 (EC2), Entra Cloud Sync (not classic Entra Connect), single active agent following the inactive agent's decommission.

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.