AADDS109 fires every day and clears itself - backend maintenance or something on our end?

Question

We've had AADDS109 ("Resources for your managed domain cannot be found") on our Entra Domain Services managed domain every day for about 5 days. It comes up as Critical, then clears on its own after 5-6 hours and health goes back to OK. Next day it's back.

What I've checked:

• Network diagnostics under Diagnose and solve problems: all checks pass
• Entra Connect sync from on-prem AD is healthy, no sync errors
• Activity log on that resource group for the last 7 days: no delete operations I can attribute to anyone on our side
• Confirmed 'AzureADDS' exists in our subnets under our VNET resource group

I've read the AADDS109 section of the troubleshoot-alerts doc. The documented remediation is to delete the managed domain and recreate it, or open a support case. Deleting isn't on the table, this is production for around 60 users and we'd lose our OUs and custom DNS records.

What I'm trying to establish:

1. Is a daily fire-and-clear pattern consistent with backend maintenance on our instance, specifically the Entra DS domain controller OS upgrade rollout? I've found several threads where AADDS109 appeared during the Server 2019 to 2022 upgrades and cleared on its own, and it looks like a 2022 to 2025 wave is in progress now. Is there an active rollout against our replica set?
2. If it is maintenance, is there anything we need to do, or is the alert cosmetic and safe to ignore until it stops?
3. If it isn't maintenance, what else would make the alert fire and clear on a daily cycle with nothing in the activity log? I'd rather not sit on a Critical alert for weeks on the assumption it's benign.

Also, does a self-clearing alert like this still count toward AADDS600 (unresolved health alerts for 30 days)? My understanding is that one can block security updates on the DCs, which is the part I actually care about.

Happy to send tenant and domain details by private message if that gets this looked at properly.

Answer 1

Hello Matt G

Greetings! Thanks for raising this question in Q&A forum.

I understand your concern, especially since this is a production Microsoft Entra Domain Services environment. A recurring AADDS109 alert that automatically clears after several hours is not typical for a permanent configuration issue. Since your network diagnostics are healthy, synchronization is working, and there are no corresponding delete operations in the activity logs, this pattern could indicate a transient service-side condition rather than a customer-initiated change.

1. Continue monitoring the affected managed domain and record the exact start and end times of each AADDS109 occurrence.
2. Review the managed domain resource and virtual network configuration during the alert window to confirm the required resources remain present while the alert is active.
3. Since the alert has been occurring daily for several days and clears without intervention, I recommend opening a Microsoft support case rather than recreating the managed domain. Recreating a production domain would be a significant operation given your OU and DNS customizations.
4. When opening the case, provide the managed domain details, alert timestamps, and note that the issue self-recovers after approximately 5-6 hours each day. This will allow the support team to check for backend maintenance activities, upgrade operations, or platform-side events affecting the managed domain.
5. Regarding AADDS600, Microsoft Support would be the best source to confirm how recurring self-resolving alerts are evaluated, as that determination depends on the underlying health state recorded by the service.

At this point, the next action is owned by Microsoft Support. They can review backend telemetry and determine whether the recurring AADDS109 alerts are related to platform maintenance, upgrade activity, or another service-side condition not visible in tenant logs.

If this answer helps you kindly accept the answer which will help others who have similar questions

Best Regards,

Jerald Felix.