On 30 September 2026, directory synchronization stops on every server below one version number. Reading which version you are on takes about a minute.
Microsoft has set a hard date. Servers below Microsoft Entra Connect Sync 2.5.79.0 lose all synchronization services that day, and keep losing them until somebody upgrades. The version everyone will quote you as the answer retires 23 days later. Here is the whole picture from Microsoft's own pages.
- The exact wording, carried on three Microsoft Learn pages
- Why the minimum version is the wrong thing to install
- What a stopped sync does to an account you disabled on Friday, by sign-in method
What actually happens on 30 September 2026
Microsoft has been hardening the way Microsoft Entra Connect Sync authenticates to Microsoft Entra ID. Part of that work is a back-end service change, and the client half of it shipped in version 2.5.79.0 in May 2025. On 30 September 2026 the back-end side switches over. A server carrying the client half keeps synchronizing. A server below it does not.
Microsoft states the consequence in one sentence, in an identical box, on three separate pages of its own documentation, and states the same requirement in its own words on a fourth:
Mandatory Upgrade Required: All synchronization services in Microsoft Entra Connect Sync will stop working on September 30, 2026 if you're not on at least version 2.5.79.0. In May 2025, we released this version with a back-end service change that hardens our services. Upgrade before this deadline to avoid any service disruption.
One sentence repeated across three pages is worth noticing. Most Microsoft deadlines live in a single blog post that later gets superseded, which is exactly the trap that caught the SMTP AUTH timeline earlier this year. This one sits in the reference documentation, the how-to documentation and the release notes at once, and the most recently updated of the four pages was revised on 28 August 2026. It is not a stale draft.
The outage is recoverable, and that is the part people misread
This is not a one-way retirement. You can fix it afterwards. What you cannot do is fix it automatically, and Microsoft is specific about the shape of the gap:
If you're unable to upgrade by the deadline, you can restore the impacted functionalities by upgrading to the latest version. However, all synchronization services will fail during the period between September 30, 2026, and when you upgrade.
So the length of the outage is set by how long it takes somebody to notice. That is the whole risk. A directory sync failure does not announce itself to users the way a mail outage does. Nobody calls the help desk to say their manager attribute is stale. The people who would notice first are the ones onboarding a new hire, and they will read it as a provisioning delay rather than an outage.
Who is actually exposed
Microsoft has been auto-upgrading Connect Sync and Connect Health since September 2023, and says plainly that customers who were auto-upgraded are not affected by the service change. The exposed population is narrower and definable: servers where auto-upgrade was switched off, where it failed quietly, or where the configuration was never eligible for it. Microsoft notes that not all Connect configurations are eligible, and separately that auto-upgrade itself requires version 2.3.20.0 or higher to function.
That last detail is the sharp one. The servers furthest behind are the servers auto-upgrade cannot rescue, because the mechanism that would have saved them is itself too old to run.
Read the number before you plan anything
Two places report the installed version, and a third tells you which server's version you should be reading. Start on the server: the number that matters is the one on whichever machine is actually active.
On the sync server itself
Open Microsoft Entra Connect from the Start menu. The version appears in the wizard. It is also listed under Programs and Features alongside every other installed application, which is the faster route if you are already on the console.
In PowerShell, if you would rather not click
The ADSync module ships with the product and reports the installed build without opening the wizard. This matters when the server is remote, or when you want the answer for several servers at once and do not want to log into each.
In the Microsoft Entra admin center, to find out which server to check
This one corroborates rather than reporting the installed build. The Microsoft Entra Connect area shows sync status and the last sync time for the tenant, which is how you confirm which server is actually the active one. That is the question that catches organizations running a staging server they had forgotten about, and it decides which machine steps 1 and 2 should be run on.
Check every server, not the one you remember
An organization that has ever done a swing migration has more than one Connect server, and the staging one is frequently a version behind. It is harmless while it stays in staging mode. It stops being harmless the moment somebody promotes it during an incident, and discovers that the server they just made active is below the minimum.
Microsoft is direct about the related hazard: a decommissioned sync server left on the network or powered up again by mistake tends to overwrite Microsoft Entra data with its old information, and can cause attribute values to revert on every sync cycle, which by default is every 30 minutes. If you find an old server during this check, finish the job and remove it.
What your version number means for 30 September
| Band | On 30 September 2026 | What else is true about it | Verdict |
|---|---|---|---|
| Below the minimum anything under 2.5.79.0 |
All synchronization services stop, and stay stopped until the server is upgraded. | If the build is also below 2.3.20.0, auto-upgrade cannot reach it, so nothing will fix this on its own. | Act now |
| At or above the minimum, but not current 2.5.79.0 up to the newest release |
Synchronization continues. The deadline is met. | Several supported builds sit here and they are not equivalent. The minimum itself, 2.5.79.0, retires on 23 October 2026, 23 days after the deadline it satisfies, and carries a defect Microsoft documents in its release notes. Both are covered below. Check the release history for the retirement date of whichever build you land on. | Meets the letter |
| Current recommended build 2.6.84.0 as of 5 September 2026 |
Synchronization continues. | Released 7 July 2026. Microsoft's note on it: this release includes security fixes and it recommends upgrading as soon as possible. Separately, version 2.6.79.0 was recalled after an issue was found post-release, and anyone who installed it should uninstall and move to 2.6.84.0. | Current |
Version numbers change. The point of the table is the shape rather than the specific build: check the release history for the current version at the time you actually do the work, and do not assume the number in any article, including this one, is still the newest one when you read it.
The offboarding gap this deadline reopens
What stops when directory synchronization stops
"All synchronization services will fail" is an accurate sentence and a quiet one. It becomes concrete once you look at what Connect Sync actually carries. Microsoft publishes the full attribute list, and three entries on it decide how much this matters to a regulated institution.
accountEnabled: the one that should worry you
Microsoft's attribute reference lists accountEnabled with the comment "Defines if an account is enabled". It appears in the synchronized set for every workload on that page: Microsoft 365 Apps for enterprise, Exchange Online, SharePoint Online, Teams, Azure Rights Management, Intune, Dynamics, third-party applications, and Windows 10 devices.
That attribute is how disabling an account in on-premises Active Directory becomes disabling an account in Microsoft 365. When synchronization is down, the checkbox gets ticked on-premises, the runbook gets signed off, and the change never reaches the cloud directory.
Whether the person can still sign in depends on how your tenant authenticates, and Microsoft documents this directly rather than leaving it to inference. Its guidance on choosing a hybrid authentication method says:
Currently, password hash synchronization doesn't immediately enforce changes in on-premises account states. In this situation, a user has access to cloud apps until the user account state is synchronized to Microsoft Entra ID. Organizations might want to overcome this limitation by running a new synchronization cycle after administrators do bulk updates to on-premises user account states. An example is disabling accounts.
In normal operation that gap is short. Microsoft's own comparison table puts it at up to a 30 minute delay for disabled accounts under password hash synchronization. The point of this page is what happens to that delay when the synchronization cycle it depends on has stopped: the limitation stops being a delay and starts being a state.
| Your sign-in method | Where authentication happens, per Microsoft | Disabling the AD account while synchronization is stopped |
|---|---|---|
| Password hash synchronization | "In the cloud, password hash is synchronized and Microsoft Entra ID validates credentials" | Sign-in continues. Microsoft supports the disabled-account state here with "up to 30-minute delay", and that delay is the synchronization cycle. With no cycle running, nothing arrives to end it. This is the case that should worry you. |
| Pass-through authentication | "In the cloud, after a secure password verification exchange with the on-premises authentication agent" | New sign-ins are denied. Microsoft: pass-through authentication "enforces the on-premises account policy at the time of sign-in", and "access is denied when an on-premises user's account state is disabled". |
| Federation, for example AD FS | "On-premises" | New sign-ins are denied. Microsoft lists the same account states as supported, including disabled accounts, locked out, expired, and sign-in hours. |
Two qualifications apply to all three rows. A session that is already established is not the same as a new sign-in: access tokens and refresh tokens keep working until they expire or are revoked, which is what session revocation and Continuous Access Evaluation exist to shorten. And the licence, the group memberships and the mailbox remain in place in every case, because removing those is a directory change and directory changes are what stopped.
If you do not know which of the three your tenant uses, that is the single most useful thing to establish this month, and it takes about as long as reading the version number.
Say exactly how much of this is Microsoft's
Most of it. Microsoft documents that all synchronization fails after the deadline, that accountEnabled is one of the attributes synchronization carries, and, in its own words above, that password hash synchronization does not immediately enforce on-premises account state changes, naming disabling accounts as the example. The step we are adding is the short one: with synchronization stopped, the cycle that normally closes that gap within 30 minutes is not running.
What Microsoft has not done is connect the two in one place. It has published no guidance framing this deadline as an offboarding risk, and that connection is ours.
The failure is quiet from the offboarding side rather than silent everywhere. The sync engine logs its own failures on the server, and Connect Health raises alerts when its agents are current. What produces no signal is the offboarding workflow itself: the help desk sees a completed task, and the record shows the account disabled, because on-premises it genuinely is. Nobody doing the deprovisioning is told that half of it did not land.
Which is why the useful question is not whether you would eventually detect a sync outage. It is whether the person who ticked the box on Friday would ever hear about it.
member: access changes made by group stop landing
Group membership travels through the member attribute, and most institutions grant Microsoft 365 access by group precisely because it is the cleaner control. It is also the control that stops: moving somebody out of the group behind a shared mailbox, a SharePoint site or a licensed application changes nothing in the cloud until sync resumes.
The direction of that failure is worth stating plainly. Access you remove stays granted. Access you grant never arrives. The second generates a support ticket within the hour. The first generates nothing.
pwdLastSet: what invalidates a token that is already issued
Microsoft describes pwdLastSet as a mechanical property "used to know when to invalidate already issued tokens", used by password hash synchronization, pass-through authentication and federation alike. So the timestamp that tells Microsoft Entra ID a password changed is itself something synchronization carries. That matters during an incident, when forcing an on-premises password reset is a standard first move against a suspected compromise.
What does not break
Authentication itself is not synchronization. Users already present in Microsoft Entra ID go on working: mail keeps flowing, Teams keeps working, and files stay where they are. Conditional Access policies keep evaluating, and multifactor authentication keeps challenging. Nothing that already exists in the tenant disappears.
Sign-in is the one to qualify rather than assume. Whether a given person can still authenticate depends on the method in the table above and on whether their session is already established, so treat "everyone keeps signing in" as true of the tenant as a whole and not of any account whose on-premises state changed during the outage.
What stops is change. The tenant freezes in the state it was in when sync last ran, and it stays frozen. That is why this can run for weeks without anyone raising it, and it is the reason to fix it in September rather than to plan for how you would detect it in October.
We will read the tenant with you and tell you where you stand
A free security assessment covers this deadline alongside the rest of your identity posture, starting with the two answers that decide how much it costs you: which version each Connect server runs, and which sign-in method your tenant uses.
Get a free security assessmentThe alert that would tell you is on the same impact list
Microsoft Entra Connect Health is the component that watches the sync server and raises alerts when it stops working. It runs as a set of agents, and on the same page that carries the Connect Sync deadline, Microsoft asks customers to move those agents to 4.5.2466.0 or higher by the same date, 30 September 2026, across the Connect Sync agent, the AD DS agent and the AD FS agent.
These are the alerts Microsoft lists for a Connect Sync agent below that minimum:
| Component | Minimum version | What is affected below it |
|---|---|---|
| Connect Health, Connect Sync agent | 4.5.2466.0 | A named subset of alerts, including "Password Hash Synchronization has stopped working", "Password Hash Synchronization heartbeat was skipped in the last 120 minutes", "Connection to Microsoft Entra ID failed due to authentication failure", "Export to Microsoft Entra ID was Stopped. Accidental delete threshold was reached", and two service-start failures. |
| Connect Health, AD DS agent | 4.5.2466.0 | All alerts. |
| Connect Health, AD FS agent | 4.5.2466.0 | All alerts. |
Read the first row again. "Password Hash Synchronization has stopped working" is close to a description of the outage this page is about, and on a stale Health agent it is one of the alerts that does not fire.
An honest reading of that
Microsoft has not said the two failures are designed to coincide, and the alert impact is a property of the agent version rather than an effect of the synchronization stop. What makes it worth a section is the correlation in the field: the organizations that let the Connect server drift are, in practice, the same ones that let the Health agents drift, and Microsoft has put both on the same deadline on the same page.
Which means the sensible order is to check both in the same sitting, and to treat a quiet monitoring dashboard as an unanswered question rather than a clean bill of health.
The minimum version is not the version to install
Almost everything written about this deadline resolves to a single instruction: get to 2.5.79.0. That instruction is correct about the deadline and wrong about the work, for two reasons that both come from Microsoft's own release notes.
It retires 23 days after the deadline it satisfies
Microsoft retires Connect Sync 2.x versions 12 months after a newer version is released, a policy in effect since 15 March 2023. The version release history puts 2.5.79.0's retirement at 23 October 2026. Reaching the minimum on 29 September and stopping there means running an out-of-support build from late October, and doing the change-control paperwork twice.
It carries a documented defect
The release notes for 2.5.79.0 open with a warning not to use the Synchronization Service Manager UI on that build, because doing so may cause the Connect wizard and automatic certificate renewal to fail. Microsoft says the issue is fixed in 2.6.1.0, which means it is not unique to the minimum build and applies to the range up to that fix. The Synchronization Service Manager is where an administrator goes to look at run history and troubleshoot a failed sync, which makes it an awkward thing to have to avoid on a server you just touched. Read the notes for whichever build you are landing on rather than assuming this one carries it alone.
And do not simply take the highest number you find
Version 2.6.79.0 was pulled. Microsoft's note: an issue was identified after release, the installer was recalled, and anyone who installed it should uninstall and install 2.6.84.0. This is the specific case where reading the release history beats searching for a download link, and it is why the installer now lives in one place.
Where the installer actually is
Microsoft states that the Connect Sync .msi is exclusively available in the Microsoft Entra admin center, under Microsoft Entra Connect on the Get started page. It is not on the Download Center any more. Two prerequisites are named on the same pages and are worth confirming before you schedule the window: .NET Framework 4.7.2 and TLS 1.2.
Three ways to upgrade, and when each one is right
| Method | When it fits | What it costs you |
|---|---|---|
| Automatic upgrade | Express installations that are already on 2.3.20.0 or higher and eligible. If this has been working, you are probably already past the minimum and this page is a confirmation exercise. | No manual intervention. Microsoft notes the auto-upgrade build is not always the newest one, because it ships critical fixes rather than every release. |
| In-place upgrade | Microsoft's stated preference for a single server with fewer than roughly 100,000 objects, where the configuration has not drifted far from the defaults. | No rollback if it goes wrong. A full import and full synchronization may run afterwards, which can take hours, and the normal delta scheduler is suspended while it does. Microsoft suggests considering a weekend. Password synchronization continues throughout. |
| Swing migration | Microsoft's recommendation when you are making substantial configuration changes, upgrading the server operating system, or coming from an old build. Its explicit guidance: anyone who has not upgraded in 12 to 18 months should consider this instead. | Needs a second server. In exchange, production sync is not interrupted, the new configuration can be verified before it goes live, and the old server stays available if the new one misbehaves. |
Two things to get right around the change, not during it
Custom sync rules. Microsoft warns that if you have modified the out-of-box synchronization rules, an upgrade sets them back to default. Institutions with attribute filtering, custom joins, or anything built for a core banking or loan origination integration should export the custom rules first and confirm them afterwards. This is the most common way an upgrade succeeds technically and breaks something anyway.
The old server. Finish decommissioning it. Microsoft's warning about rogue sync servers is unusually blunt: one left on the network or powered back on later can overwrite Microsoft Entra data with stale information and revert attribute values on every cycle. Uninstall the product and its components, or delete the virtual machine.
One scheduling note, unrelated to Microsoft. The deadline lands on Wednesday 30 September 2026, which for many institutions is a month-end and a quarter-end. If the plan is a weekend in-place upgrade, the two Saturdays before it are 19 and 26 September, and the second is closer to close than most change boards will accept. The realistic window is narrower than the date suggests.
Should this be the moment you move to Cloud Sync instead?
Microsoft raises this on every page connected to the deadline, in the same words each time: if you are eligible, it recommends migrating from Microsoft Entra Connect Sync to Microsoft Entra Cloud Sync. Cloud Sync is a lightweight agent with its configuration held in the cloud, so the sync rules stop living on a Windows server you have to patch, upgrade and eventually decommission. Microsoft's stated reasoning is that new sync capability is going into Cloud Sync, and choosing it now avoids a later migration.
Two honest qualifications, both Microsoft's own.
- Eligibility is conditional and it is not universal. Microsoft gates the recommendation on "if you're eligible" every time it makes it, and publishes a supported sync scenarios comparison to answer the question. Some configurations are not supported on Cloud Sync today. Read that comparison against your own environment rather than assuming.
- It is a project, not a patch. Whatever the long-term merits, it is not the thing to start on 25 September. If the assessment says Cloud Sync is right for you, the sequence is to get current on Connect Sync first so the deadline is off the table, then plan the move properly.
Which is the practical version of the advice: let the deadline force the upgrade, and let the upgrade prompt the question. They are two different decisions on two different timelines, and merging them is how a hard date turns into a stalled project.
We read the environment and hand back the answer in writing
For most institutions this ends quickly and in your favour, and that is a good outcome to have on paper rather than in somebody's memory. A free security assessment covers this deadline as part of a wider read of the tenant.
- Every Connect server, not the one you know about. Which servers exist, which is active, which is staging, and the installed version of each.
- Whether auto-upgrade is on, eligible, and actually succeeding. The three are different questions and only the third one matters.
- The Connect Health agents. Version state against the 4.5.2466.0 minimum, so the monitoring is trustworthy before you rely on it.
- Custom sync rules and attribute filtering. What has been changed from the defaults, so an upgrade does not quietly revert an integration.
- Your sign-in method. Password hash synchronization, pass-through authentication or federation, which is what decides whether a stopped sync leaves disabled accounts able to sign in.
- A named set of identity checks alongside it. Conditional Access policy coverage, privileged role assignments, registered authentication methods, and stale or unused accounts.
That list is the scope: a point-in-time technical review of the items named above, as they stand on the day we read them.
What it cannot do from the tenant alone: tell you which change window your board will approve, or which of your integrations depends on a custom rule somebody wrote in 2019. Those need your records, and we tell you exactly which ones to pull. The output is written, and you keep it whether or not you engage us for the work.
ABT manages Microsoft 365 tenants and hosts Azure environments for more than 750 financial institutions, so hybrid identity in a regulated setting is the environment we work in daily rather than an occasional project. ABT also operates M365 Guardian, its managed security service for credit unions, banks, and mortgage companies.
Where the facts on this page come from
Every claim here rests on those pages alone, including the offboarding framing, which describes your own control breaking rather than any regulator's expectation. Microsoft's dates also move, as the SMTP AUTH timeline did in January 2026 when a schedule was replaced before it arrived, so check these pages against this one before you act on a date.
The identity controls this deadline touches
Microsoft 365 Employee Offboarding for Financial Institutions
The full runbook, including the steps that do not depend on directory sync and therefore keep working when it is down. Read it alongside this page.
Read the article ›
Hybrid Cloud for Financial Institutions
Why on-premises Active Directory persists alongside Microsoft 365 in this industry, and what that decision commits you to maintaining afterwards.
Read the article ›
Microsoft 365 Audit Log Retention for Financial Institutions
If a sync outage does run for weeks, the audit record is how you reconstruct what changed and when. Worth configuring before you need it.
Read the article ›Answered from Microsoft's own documentation
All synchronization services stop working on any server running a version below 2.5.79.0. Microsoft states this in an identical box on three of its own Learn pages, the security hardening article, the version release history and the upgrade guidance, and states the same requirement in different words on a fourth. The wording is that services will stop working rather than degrade. The cause is a back-end service change that hardens how Connect Sync authenticates to Microsoft Entra ID; the client half of that change shipped in version 2.5.79.0 in May 2025.
No. Microsoft says you can restore the impacted functionality by upgrading to the latest version, but that all synchronization services will fail during the period between September 30, 2026 and when you upgrade. So the outage is recoverable and its length is set entirely by how long it takes somebody to notice and act. That is the reason to treat it as a September task rather than a detection problem for October.
Open Microsoft Entra Connect on the sync server and read the version in the wizard, or find it under Programs and Features on the same machine. The ADSync PowerShell module that ships with the product reports the installed build without opening the wizard, which is the faster route across several servers. Confirm in the Microsoft Entra admin center which server is actually the active one, because organizations that have done a swing migration often have a staging server that is a version behind.
For many organizations, yes. Microsoft has been auto-upgrading Connect Sync and Connect Health customers since September 2023 and says customers who were auto-upgraded are not impacted by the service change. It names the exceptions: customers who opted out, and customers whose auto-upgrade failed. Two further limits apply. Not all Connect configurations are eligible for auto-upgrade, and auto-upgrade itself requires version 2.3.20.0 or higher to work, so the oldest servers are the ones it cannot rescue. Verify the installed version rather than assuming the mechanism ran.
It satisfies the deadline and we would not stop there, for two reasons from Microsoft's own release history. First, 2.5.79.0 reaches its own retirement on October 23, 2026, twenty-three days later, under the policy that 2.x versions retire twelve months after a newer release. Second, Microsoft's notes for that build warn against using the Synchronization Service Manager UI on it, because doing so may cause the Connect wizard and automatic certificate renewal to fail; the notes say this is fixed in version 2.6.1.0, so it is not unique to the minimum build and applies across the range up to that fix. Several supported builds sit between the minimum and the current release and they carry different retirement dates, so check the release history for the build you are actually landing on at the time you do the work.
Microsoft states that the Connect Sync .msi is exclusively available in the Microsoft Entra admin center, under Microsoft Entra Connect on the Get started page. It is no longer obtained from the Download Center. Confirm two prerequisites before scheduling the change: .NET Framework 4.7.2 and TLS 1.2. One caution on picking a build: version 2.6.79.0 was recalled after an issue was identified post-release, and Microsoft says anyone who installed it should uninstall and install 2.6.84.0 instead.
Nothing that already exists disappears. Mail keeps flowing, files stay where they are, Conditional Access keeps evaluating and multifactor authentication keeps challenging. What stops is change: the tenant freezes in the state it was in when synchronization last ran, so new accounts are not created in the cloud, group membership changes do not take effect, and attribute updates do not arrive. Sign-in is the one thing to qualify rather than assume, because for any account whose on-premises state changed during the outage the answer depends on whether the tenant uses password hash synchronization, pass-through authentication or federation. The failure is quiet because the visible services keep working, which is why it can run for weeks without a support ticket.
It depends on how your tenant authenticates, and Microsoft documents this directly. Its hybrid authentication guidance states that password hash synchronization "doesn't immediately enforce changes in on-premises account states" and that "a user has access to cloud apps until the user account state is synchronized to Microsoft Entra ID", giving disabling accounts as its example. Its comparison table supports disabled accounts under password hash synchronization with an up to 30-minute delay, and that delay is the synchronization cycle. So on password hash synchronization, with synchronization stopped, sign-in continues and nothing arrives to end it. On pass-through authentication and on federation such as AD FS the answer differs: Microsoft states that pass-through authentication enforces the on-premises account policy at the time of sign-in and that access is denied when an on-premises account is disabled, and it lists the same account states for federation. In all three cases an established session keeps working until its tokens expire or are revoked, and the licence, group memberships and mailbox stay in place because removing those is itself a directory change. What Microsoft has not published is guidance connecting this deadline to offboarding; that connection is ours.
Yes. On the same page that carries the Connect Sync deadline, Microsoft asks customers to move the Connect Sync agent, the AD DS agent and the AD FS agent to 4.5.2466.0 or higher by the same date of September 30, 2026. Its impact table says the AD DS and AD FS agents lose all alerts below that version, and lists a specific subset for the Connect Sync agent that includes "Password Hash Synchronization has stopped working" and "Password Hash Synchronization heartbeat was skipped in the last 120 minutes". Be precise about what that is: the alert impact is a property of the agent version rather than an effect of the synchronization stop, and Microsoft does not describe the two as causally linked. They are two requirements of one hardening programme published together under one deadline. The practical point is that servers left to drift usually have agents left to drift as well, so check both together and do not read a quiet dashboard as confirmation that nothing is wrong.
Microsoft recommends migrating to Cloud Sync if you are eligible, and repeats that recommendation on every page connected to this deadline, on the reasoning that new sync capability is going into Cloud Sync and choosing it now avoids a later migration. Two qualifications matter. Eligibility is conditional, and Microsoft publishes a supported sync scenarios comparison to settle it rather than leaving it to assumption. And a Cloud Sync migration is a project rather than a patch, so with a September date in front of you the sensible order is to get current on Connect Sync first and then decide about Cloud Sync on its own timeline.
Microsoft documents three. Automatic upgrade suits express installations already on 2.3.20.0 or higher. An in-place upgrade is its stated preference for a single server with fewer than roughly 100,000 objects, with the caveat that there is no rollback and that a full import and full synchronization may run afterwards while the delta scheduler is suspended, though password synchronization continues. A swing migration uses a second server and is Microsoft's recommendation for substantial configuration changes, an operating system upgrade, or any server that has not been upgraded in twelve to eighteen months. Whichever you choose, export any custom synchronization rules first, because Microsoft warns that an upgrade resets modified out-of-box rules to default.
Finish the job. Microsoft warns that an old Connect server left on the network, or powered up again later by mistake, tends to overwrite Microsoft Entra data with its old information and can cause attribute values to revert on every sync cycle, which by default runs every thirty minutes. Its instruction is to completely uninstall the product and its components, or to permanently delete the server if it is a virtual machine. A powered-off virtual machine that somebody restores during an unrelated incident is exactly the scenario the warning describes.
Find out where your directory synchronization actually stands.
Tell us roughly how many users you have and whether this is already on a project list. Our engineers read the environment and come back in writing on the scope set out above: the servers, the versions, the auto-upgrade state, the Health agents, your sign-in method and your customized sync rules. Deciding the change window and confirming which integrations depend on a custom rule needs your records too, and we name exactly which ones to pull.
ABT manages Microsoft 365 tenants and hosts Azure environments for more than 750 financial institutions. The assessment is a technical review and is not legal or compliance advice.
Get a free security assessment
A read of your environment, and a written answer on where you stand before 30 September.
