AADDS109 alert persists despite healthy environment (Japan East / Entra Domain Services)

AADDS109 is not documented in the provided material, but similar critical alerts for Microsoft Entra Domain Services (such as AADDS100, AADDS103, AADDS110, AADDS112, AADDS116, and AADDS600) follow a consistent pattern:

• A critical health alert means the platform believes it cannot fully monitor, manage, patch, or synchronize the managed domain.
• Some alerts are explicitly marked as unrecoverable and require deletion and recreation of the managed domain (for example, AADDS100 and AADDS110).
• Other alerts are caused by configuration or policy issues on dependent resources (for example, AADDS116) and must be fixed by adjusting those resources.
• If critical alerts remain unresolved, AADDS600 indicates that the managed domain can eventually be suspended and even deleted if the condition persists.

Given that:

• The alert is critical and the “Last detected time” keeps updating, and
• All visible resources and basic functionality appear healthy,

this situation matches the general pattern where the platform’s internal checks detect a problem that is not obvious from basic connectivity or resource existence alone. It can be due to:

• A platform-side inconsistency in the internal resources or metadata used to manage the domain, or
• A policy or configuration on one of the AADDS-related resources that blocks required platform operations, even if normal traffic and authentication still work.

Because AADDS109 is not listed in the public “Troubleshooting alerts” set and the environment is production-like with an active support plan, the recommended path is:

1. Use Domain Services health to confirm all visible alerts
   • In the Microsoft Entra admin center, open the managed domain and review all health alerts as described in the health article. Ensure there are no additional alerts (for example, policy-related like AADDS116) that might explain the behavior.
2. Check for restrictive policies on AADDS resources
   • For the managed domain’s network components (virtual network, subnet, NICs, load balancer, public IP, NSG), review operation logs and any applied policies.
   • If any policy is blocking platform operations, relax or adjust it as described for AADDS116 (edit the policy so it is less restrictive on AADDS components).
3. Engage Azure Support for backend investigation
   • Since the alert is critical, persists, and is not covered by the documented alert list, and the subscription has an Azure Developer Support Plan, open an Azure support request specifically for this AADDS109 alert.
   • Provide the alert ID, region, replica set, and the fact that all visible resources and diagnostics are healthy.
   • Support can check internal platform state and confirm whether this is:
     • A transient or platform-side issue (for example, internal resource or metadata inconsistency), or
     • A hidden configuration/policy problem that requires a specific corrective action.
4. Monitor for AADDS600
   • Until the root cause is clarified, monitor for AADDS600 (“Unresolved health alerts for 30 days”). If it appears, it indicates that unresolved alerts are blocking critical security updates and may lead to suspension, so the support case becomes urgent.

In summary, a persistent, updating critical alert like AADDS109, with no obvious resource deletion and normal day-to-day operation, strongly suggests either an internal platform inconsistency or a subtle configuration/policy issue rather than a simple, user-visible deletion. Given the lack of public documentation for AADDS109 and the production-like nature of the environment, resolving this requires an Azure support case so the platform team can inspect and correct the underlying state.

References:

• Known issues: Common alerts and resolutions in Microsoft Entra Domain Services
• Check the health of a Microsoft Entra Domain Services managed domain