Azure AD Connect: Top 10 Production Mistakes to Avoid

Azure AD Connect, now Microsoft Entra Connect Sync, sits between on-premises Active Directory and Microsoft Entra ID. This article examines ten production mistakes that architects, DevOps/SRE engineers, and administrators should review together.

About the author: Raghavendra is a solutions architect and Lead DevOps/SRE engineer focused on cloud architecture, platform operations, and production reliability.

Azure AD Connect deserves the same change discipline as the applications that depend on it. An OU cleanup, a user recreation, or an unreviewed failover can affect identities well beyond the server where the change started. These ten mistakes are worth checking before the next production change.

1. Treating OU changes as routine directory housekeeping

An organizational unit rename can look harmless in an Active Directory change ticket. The synchronization consequences deserve their own review.

When you explicitly select an OU for synchronization, Connect records its distinguished name. Rename that OU and the name changes. During a subsequent full import, Connect can reevaluate its scope and treat its objects as out of scope. Previously synchronized objects can then be deleted from Entra ID. Microsoft documents this behavior in its filtering guidance.

Moving a user into an excluded OU also has deletion implications. It is not a way to pause updates while preserving the cloud account unchanged.

Before reorganizing OUs, identify affected synchronized objects and control exports while reviewing the change. Reselect renamed OUs in the Connect wizard, perform the required import and synchronization steps, and inspect pending exports before releasing them.

For troubleshooting, compare the user's current distinguished name with the selected scope. Check recent OU changes before investigating credentials or connectivity.

The change request should state how many cloud objects are expected to be added, updated, or deleted. “No impact expected” needs evidence.

2. Disabling deletion protection to clear an alert

The status stopped-deletion-threshold-exceeded means a safety control intervened. Treating it as an obstacle can turn a configuration error into a deletion incident.

Connect enables accidental-deletion protection by default, blocking an export containing more than 500 deletions. That threshold is configurable. A smaller organization should assess whether 500 is remotely appropriate for its normal operations.

A July 2024 Microsoft Q&A report describes 1,000 accounts accidentally created and subsequently removed with PowerShell. The administrator reported hitting the 500-object threshold and an unhealthy Connect status. The thread does not establish a tenant-wide sign-in outage; it does demonstrate how an account cleanup can interrupt exports.

Investigate through Synchronization Service Manager: select the Entra connector, open Search Connector Space, choose Pending Export, and filter for Delete. Review the actual objects and reconcile them with the approved change.

If the deletions are unintended, correct the scope or source data and reevaluate pending exports. For approved bulk deletions, follow Microsoft's controlled procedure and restore protection afterward.

Keep the accidental-deletion documentation in the runbook. This control does not replace reviewing smaller, potentially damaging deletion batches.

3. Assuming a successful export means clean identity data

A user can exist in Entra ID while an expected email alias is missing. That distinction matters when someone points to a successful synchronization run and closes the ticket.

Duplicate userPrincipalName or proxyAddresses values can cause provisioning conflicts. Microsoft's duplicate-attribute resiliency can quarantine a conflicting value while allowing the rest of an object to synchronize. Export success therefore does not prove that every intended attribute reached the cloud.

Start with the disputed value. Search across relevant users, groups, and contacts in the source directories and tenant. Identify which object should own it. An abandoned contact or an old account can be as relevant as the user reporting the problem.

Correct the value in the authoritative directory, then verify both the resulting cloud attribute and the provisioning-error state. Repeated sync cycles cannot decide which identity legitimately owns an address.

Microsoft explains the behavior in duplicate-attribute resiliency. Use that alongside the synchronization-error reference.

For onboarding and migrations, make uniqueness checks part of acceptance criteria. A created account with the wrong sign-in name is an incomplete delivery.

4. Recreating users or changing anchors without an identity plan

Deleting and recreating an AD account with the same username does not recreate the same identity. The new object can have a different source anchor.

The source anchor links an on-premises object to its cloud identity. Depending on the deployment, user anchoring can involve objectGUID or ms-DS-ConsistencyGuid. Determine what your environment actually uses before a forest migration, recovery, or Connect rebuild.

An InvalidSoftMatch error can indicate that a matching cloud object already has a different immutable identity. Clearing identifiers or forcing a match without proving ownership is a poor incident shortcut. Microsoft's design concepts and matching guidance explain the mechanics and restrictions.

In a November 2021 user report, two accounts were moved outside synchronization scope and restored as cloud-only users. The administrator then reported Error 114 and export errors. The author confirmed a resolution, but the thread's historical commands should not become a generic recovery procedure today.

Record the source object, cloud object ID, anchor, and intended ownership before making changes. For accidental AD deletion, evaluate restoring the original object through the AD Recycle Bin instead of creating a replacement.

5. Troubleshooting password failures with object-sync results

“The user synchronized successfully” does not explain why their new password fails.

Object synchronization and password hash synchronization have separate scheduling processes. The default object/attribute cycle runs every 30 minutes; password hash synchronization runs every two minutes. Neither interval is an end-to-end recovery guarantee.

First establish the user's authentication method: password hash synchronization, pass-through authentication, or federation. Then establish whether the problem affects one user, one domain, or everyone.

For password hash synchronization, the Connect wizard's troubleshooting task checks feature enablement, staging status, domain connectivity, connector-account permissions, and heartbeat events. Use the password troubleshooting guide, rather than assuming another object-sync cycle will repair the password path.

Authentication availability also needs a separate recovery plan. With password hash synchronization, authentication can continue using already synchronized credentials without contacting on-premises AD. Pass-through authentication has different dependencies. Enabling password hash synchronization as a backup does not make PTA failover automatic.

Microsoft's authentication-method guidance documents that manual transition. Test the transition and its prerequisites before calling it a continuity strategy.

During an incident, examine Entra sign-in results alongside synchronization evidence. A Conditional Access failure requires a different investigation from a password synchronization failure.

6. Calling a staging server a tested recovery solution

A second VM is only useful if it can take over with the correct configuration.

Staging mode continues imports and synchronization but suppresses scheduled exports. It does not run password hash synchronization or password writeback. Configuration changes on the active server must also be maintained on the staging server.

Before promotion, verify configuration parity, recent synchronization, deletion protection, and pending exports. Put the old active server into staging mode first. If it is unreachable, isolate or shut it down so it cannot unexpectedly resume exporting.

Only one Connect Sync server should actively export for this deployment. Microsoft's staging and disaster-recovery procedure describes the supported transition.

Password synchronization can also need time to catch up after promotion. Do not announce recovery solely because object exports resumed.

A useful failover exercise measures how long it takes to restore a new-user change, a group update, and a password change. Record who can promote the server, where the procedure lives, and what happens if that person is unavailable.

The recovery objective should describe restored identity functions. “The replacement server started” is too weak.

7. Editing built-in rules without preserving the intended behavior

A local rule change can solve today's ticket and disappear during an upgrade.

Microsoft warns that changes to default synchronization rules can be overwritten. Deleting an unwanted built-in rule is also unreliable because an upgrade can recreate it.

Follow the supported customization approach. Attribute-flow overrides generally belong in a custom rule with higher precedence. Where a built-in rule must be replaced, use the documented copy-and-disable procedure. Do not clone every rule indiscriminately; Microsoft's configuration guidance distinguishes these cases.

When an attribute behaves unexpectedly, inspect its source value, inbound flow, metaverse value, and outbound flow. The metaverse is the synchronization engine's combined representation of connected identities. Rule precedence helps explain which value wins.

Keep a record of the business requirement, scope, precedence, expected output, and rollback for each customization. Export custom rules and keep the staging server aligned.

Before an upgrade or migration, test representative identities: ordinary employees, contractors, disabled accounts, and users with exceptions. A rule that works for one sample account has not demonstrated that it works for the population it controls.

8. Giving the sync server ordinary application-server security

Connect belongs to the identity control plane. Administrative access to it deserves tighter control than access to a general-purpose utility server.

Microsoft recommends hardening Connect as a control-plane asset. Restrict administration to tightly controlled groups, use protected administrative access, and avoid installing unrelated tools that expand its attack surface.

Review effective access, not just the named server owner. Check local administrators, management agents, service identities, and the systems that can execute privileged actions on the host. Include configuration exports and recovery material in the access review.

Keep tenant recovery independent of synchronized identities. Microsoft's emergency-access guidance calls for at least two cloud-only emergency accounts, with appropriate protection, monitoring, and regular validation.

A practical review asks whether the team can administer Entra ID if AD, federation, or synchronization is unavailable. It also asks whether an unrelated server administrator can gain control of Connect through shared management permissions.

Those two questions expose dependencies that a routine Windows patching checklist can miss. Assign an owner to close the findings and verify access again after remediation.

9. Assuming auto-upgrade removes version-management work

Auto-upgrade does not mean every deployment is running the latest release. Microsoft documents eligibility restrictions and notes that not every release is distributed through auto-upgrade.

As checked on November 2, 2026, Microsoft's release history lists 2.6.92.0, released September 23, 2026, as its latest release. It also requires 2.6.84.0 or later and application-based authentication by April 7, 2027 to avoid synchronization interruption when legacy authentication is retired.

Do not turn either number into a permanent baseline. Assign someone to review release notes, retirement dates, prerequisites, and known issues.

There is a concrete reason to read the details: Microsoft documents synchronization failures on versions 2.5.190.0 and 2.6.1.0 after upgrades involving a previously modified miiserver.exe.config. Older builds also have Synchronization Service Manager restrictions.

Before upgrading, capture configuration, identify customizations, and review the destination build's issues. Afterward, verify imports, exports, password synchronization, and any writeback functions you actually use.

Keep the change open until those checks pass. A successful installer exit is only one acceptance criterion.

10. Monitoring the service while nobody owns delayed identity changes

An ADSync service that is running tells you little about whether a new employee can work.

Monitor synchronization outcomes: the age of successful exports, unresolved object errors, unexpected deletion batches, password-sync health, and delivery of alerts. Microsoft's Connect Health guidance is a starting point; its sync-error report updates every 30 minutes, so it is not a real-time incident trace.

When troubleshooting, start in the Operations tab. A completed run with errors needs investigation. Trace an affected object through connector space, the metaverse, and the outbound connector to find where its expected state stops progressing. Microsoft's object troubleshooting guide provides the sequence.

Agree on service objectives for provisioning, ordinary updates, and urgent offboarding. Give each alert a responsible team and escalation route. An alert delivered to an unattended mailbox is not an operational control.

Use a controlled test identity to verify an approved change reaches its destination, with cleanup included. During incidents, preserve the first error and recent change history before repeatedly restarting services.

The useful operational question is whether the intended identity change reached the right account, within the time the business needs.

Before your next production change

Azure AD Connect deserves a named service owner, reviewed changes, and a recovery procedure the team has actually practiced. The installation is only the beginning of that responsibility.

Start by reviewing your own environment against these ten mistakes. Can you explain every pending deletion? Does the staging server reflect the current configuration? Has anyone tested whether password synchronization recovers after a failover? Who responds when an export fails outside business hours?

Any unanswered question belongs in the operational backlog, with an owner and a deadline. Prioritize gaps that could delete identities, prevent administrative access, or leave recovery dependent on one person.

For the next OU change, upgrade, or server replacement, put the expected identity changes and recovery steps directly into the change record. Give the reviewer enough evidence to challenge the plan before it reaches production.

The standard to aim for is straightforward: know what will change, verify what changed, and be prepared to recover when the result differs.