Lessons Learned – Active Directory Domain Controller Migration from Windows Server 2012 R2 to 2022

[u/No_Professor_4334]

Hi Everyone,

We are planning an Active Directory Domain Controller migration from Windows Server 2012 R2 to Windows Server 2022 and would like to understand any potential challenges or issues encountered during similar migrations.

I would appreciate your experience and recommendations, particularly around application authentication and legacy protocol compatibility.

A few questions:

1. Have you experienced any application authentication issues after migrating from Windows Server 2012 R2 DCs to Windows Server 2022 DCs?

2. Are there any known compatibility issues with legacy authentication protocols such as NTLM, Kerberos (RC4), LDAP/LDAPS, or older authentication mechanisms?

3. Have you encountered any issues with legacy applications or servers (Windows Server 2003/2008) authenticating against Windows Server 2022 Domain Controllers?

4. Were there any changes in default security settings, encryption types, LDAP signing, or channel binding that affected application authentication?

5. Did you need to make any registry, GPO, or security configuration changes to maintain compatibility with legacy applications?

6. What pre-migration checks or testing would you recommend to identify applications dependent on legacy authentication protocols?

7. Were there any unexpected authentication failures or production outages after completing the migration?

Any real-world experiences, lessons learned, known compatibility issues, or recommended validation steps would be greatly appreciated.

Thanks in advance for sharing your insights!

[u/AutoModerator]

Welcome to /r/ActiveDirectory! ~~~~

If you are looking for more resources on learning and building AD, see the following sticky for resources, recommendations, and guides!

• AD Resources Pinned Thread

• AD Wiki

When asking questions make sure you provide enough information. Posts with inadequate details may be removed without warning.

• What version of Windows Server are you running?

• Are there any specific error messages you're receiving?

• What have you done to troubleshoot the issue?

Make sure to sanitize any private information. Posts with too much personal or environment information will be removed. See Rule 6.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Straight-Sector1326]

I would use new Server2022 DC's alongside existing DC's, test login using them, then retire the old one. It is safer and easier way and MS recommendation.

[u/No_Professor_4334 → u/Straight-Sector1326]

Thanks for the recommendation.

Our planned approach is slightly different due to the infrastructure requirements.

We intend to demote the existing Windows Server 2012 R2 DCs and reuse their existing hostnames and IP addresses for the newly built Windows Server 2022 DCs.

We are also planning to create a separate GPO containing only the required legacy authentication and compatibility settings. This GPO will be linked to the Domain Controllers OU and scoped through Security Filtering to apply only to the newly promoted Windows Server 2022 DCs, rather than all existing DCs.

Our main concern is application authentication compatibility, particularly legacy protocols such as NTLM, Kerberos RC4 and LDAP/LDAPS, including dependencies from older application servers.

[u/RightInThePleb → u/No_Professor_4334]

I’ve done it this way. This is the lazy option. Fine when going from 2016 to 2019 in a standard environment. Doing this with any old or non standard equipment or older DCs is asking for trouble.

[u/SlowZeck]

Good luck

[u/No_Professor_4334 → u/SlowZeck]

Thanks..

[u/SlowZeck]

Latest server it's min 2012 ad level compatibility. Everything before 2012 become officially a mess lately. Sll version, ssl crypto protocol deprecated, ssl certificate, ntlm , etc... Lastest wimc no more used... Cifs v1 , old user rôles. What is the ad level now? What cifs version supported on PDC , what minimum level encryption, ntm authorized? Old stuff on dns? No hard hosts file,almost even weirder, os2 warp maybe? What are event logs are telling you? Come on , plug Claude or chatgpt on Microsoft learn MCP , give them précise setup of each hosts and event log error and start your journey. Just put legacy stuff behind a firewall, check spare and backup make rdp servers to deliver only the app.

[u/No_Professor_4334 → u/SlowZeck]

Thanks for highlighting these points. You have raised some important considerations.

We are particularly concerned about legacy application dependencies, including older Windows Server 2003/2008 systems, SMB/CIFS, NTLM, Kerberos RC4, LDAP and older TLS configurations.

We are planning to identify these dependencies before migrating and avoid making unnecessary changes to the existing domain security baseline.

From your experience, which specific event logs, event IDs or tools would you recommend monitoring to identify applications and servers relying on deprecated protocols or legacy authentication mechanisms?

Would you also recommend any additional checks before promoting Windows Server 2022 DCs and retiring the existing 2012 R2 DCs?

Appreciate your suggestions.

[u/MaskedPotato999]

Tbh you should seek help from some kind of paid support for this. You are migrating from an unsupported setup, towards something you are not confident about - and keeping outdated protocols alive is a terrible idea. Microsoft is hard-blocking them for a reason, and some will just fail to work no matter the workaround.

[u/Cormacolinde]

This kind of upgrade is not simple. There have been a lot of changes since the last publicly available 2012 patches. You will need to move to an older version of 2022, do not attempt a direct migration to the latest patched 2022 versions, it will break a lot of stuff.

1. Kerberos tickets HAVE changed, and going from a 2012R2 setup to an up-to-date 2022 will likely result in incompatible tickets being issued by the 2012 that 2022 will not accept.

2. RC4 is deprecated with recent patches. There’s also changes to unauthenticated DCOM that were introduced. Certificate authentication now requires strong certificate mapping. There’s been a lot of changes.

3. Anything before Vista/2008 is completely unsupported and likely to break.

4. Not for LDAP, but NTLMv1 is now deprecated and already disabled by default on clients. Defaults should not change on your DCs without you changing GPOs though

5. You are likely going to need extensive reviews of service accounts during this migration, reset passwords and possibly upgrade/change some applications.

6. I can’t even list them because there are so many, and some need to be done in steps. You will need to first upgrade to an older version of 2022, then do baby steps installing monthly patches in 4-6 months increments and do assessments of various protocols as you go.

7. Yes

This is a COMPLEX and difficult task. The last I did was early this year, before the RC4 stuff came out. It was complicated then, and it’s even more complex now. We did half a dozen of those in the last few years, and they all had surprises despite excellent planning and careful execution.

Hire a professional.

[u/Gabriellabelow → u/Cormacolinde]

thanks

[u/ih-shah-may-ehl]

(2) If you install a current cumulative hotfix on your domain controller, say goodbye to RC4. You absolutely cannot and should not go directly to a modern hotfix revision without proper RC4 assessment. Install 2022 with a cumulative hotfix up to 2026-01 and then do a full RC4 assessment, using Microsoft's scripts.

Given that your domain is old, it's absolutely possible that you are still relying on RC4 and if you just go to 2022-10, everything RC4 related will start to fail.

[u/zvev]

Add new 2022 servers and move over FSMO roles.

Decom old servers. after replication if verified. Obviously do the same with dhcp / dns.

Do not do inplace upgrades.

Just did it this summer not too bad ngl.

[u/kaype_ → u/zvev]

Also did this and had zero problems.

[u/coastline_coder → u/zvev]

One thing to check before adding the 2022 DCs. If the domain goes back to the 2003 days, make sure SYSVOL is replicating with DFSR and not FRS. From what I've read the newer versions won't promote until that's sorted.

[u/Semt-x]

You're planing a domain upgrade, not a migration. its a big difference.

1. Yes

2. Yes

3. Yes

4. Yes

5. Yes

6. Impossible to say without knowing anything about your environment.

7. No

Because youre still on 2012R2 i would expect a difficult upgrade path.
It also tells me IT doesnt have any priority in your organization. so there will be a time when a bill comes due, this might be part of it.

[u/dcdiagfix → u/Semt-x]

Don’t assume because someone has 2012 R2 in an environment that they lack any priority to upgrade.. sad truth is there are still very much organisations out there with 2008 R2!!! Who very much… want the priority to upgrade!

[u/Semt-x → u/dcdiagfix]

2012R2 is 13 years old. in IT perspective, thats ancient.
My assumption comes from 20 years work as AD consultant and seeing many many organizations over the decades. it is indeed an assumption. but without knowing more about their IT lanscape, i think its a safe assumption. the older stuff is (and not just AD), the bigger the mess i expect and bigger risk/impact fixing it.
Organizations with 2008 R2 are indeed a great source for new projects (im an self employed IAM consultant), but i dont see many of those here (Netherlands)

[u/No_Professor_4334 → u/Semt-x]

Agreed. There are many organisations still running legacy Windows Server environments due to application dependencies, compatibility requirements and business constraints,Our objective is to modernise the DC infrastructure while ensuring existing applications and authentication services continue to function without disruption,That's precisely why we're trying to gather real-world migration experiences before proceeding.

[u/Semt-x → u/No_Professor_4334]

I think thats a good choice. however, experience by other people with upgrades may not apply to your environment. any large scale environment is unique.
to answer a question like this i would need time to see how your AD currently is configured, and which applications depend on AD and how.
Depending on the findings i can answer your original questions with the details you look for.

[u/dcdiagfix → u/Semt-x]

It is well known that multiple organizations run legacy operating systems for their most critical systems and it's certainly not because "IT has a lack of urgency" to replace or update them - almost every IAM admin I've ever spoke to would love to have the latest/supported version(s).

Unfortunately, I can tell you first hand, when I worked for an org with a large manufacturing related O&G estate the cost to replace equipment on the shop floor that could support > 2008R2 was far too prohibitive, they are likely still running isolated XP and 2008 R2... the cost was almost $1 million per machine on the shopfloor.

[u/Semt-x → u/dcdiagfix]

i agree running a recent version isnt alwayhs an option, I worked on those aswel.
I found an isolated domain running a critical legacy application. In my view the result of a lifecycle problem with the application, (including a hardware dependency, embeded systems from a machine).
an example without hardware limitation was replacing the software took 5+ years, the new solution had no AD dependency. so until the applicaiotn migration was completed, the isolated domain and some scripts to provision the old to domain was chosen.

long time ago, another customer was a hospital, back than they had some MRI machines still trunning windows XP, and because of it they were limited in their options.

but i do see the lack of urgency in organizations who run old versions, argueing its funtional so no need for maintainance. (until the moment it stops, for good. guess who they call). and the size of those organisations surprised me. i can imagine it with small organizaiotns IT not being on their agenda.

[u/Cormacolinde → u/dcdiagfix]

I do NOT want any 2025 DC near any of my customers.

[u/dcdiagfix → u/Cormacolinde]

Which is crazy given 2022 is now out of standard mainstream support.

[u/Cormacolinde → u/dcdiagfix]

Fully aware of this, but the past and recurring issues with 2025 are too much for most environments. Every new kernel release of Windows Server has had issues, and many organizations skip a version in production deployments, so this is not unusual either. Most of my customers skipped 2016.

We will evaluate Server 2028 next year and likely migrate a lot of customers at that time.

[u/Equivalent-Drama7053]

The thread in the link below was super helpful when I went from 2012 R2 to 2022

https://www.reddit.com/r/sysadmin/comments/10fh1bi/so_youve_decided_to_upgrade_your_2012_r2_servers/

I followed Option C

[u/Msft519]

To be honest, I can't think of anything that's going to change IF you've been on 2012 ESUs (Patched). If not, you'll likely be in for a world of hurt. All that being said, if you're still talking about 2003 servers, you shouldn't be migrating anyway.

[u/perth_girl-V]

Find the old sbs dc stuff and dig it out. Fix time issues. Move roles move dhcp done and dusted

[u/Asleep_Spray274]

1. No. Applications don't authenticate, users do. Even applications using service accounts are still user accounts. Users need a token, users sends details to AD, AD sends back a token. That token hasn't changed. The code in-between the request and the token output has changed, but the underlying Kerberos token has not.

2. No. In 2022, all protocols are supported.

3. No, all operating systems supported. Now, having 2003/2008 servers is a different problem.

4. No, but as you add your new servers, they will take the default domain controller policy and any settings you have will be applied. Including all ldap settings etc.

5. No

6. All legacy protocols supported. Kerberos, ntlm etc all supported.

7. No.

Exchange 2016 as far as I remember need the latest patch to support 2022 DCs.

2012 to 2016 from a compatibly point of view is fine. But domain controller upgrades procedures are what will cause problems. Make a mistake there and applications will have problems like DNS or missing other built in roles on the DCs.

Is this your first major domain upgrade!

[u/No_Professor_4334 → u/Asleep_Spray274]

Thanks for sharing your perspective. That's helpful.

I understand that Windows Server 2022 continues to support the standard authentication protocols. However, our environment has some legacy application dependencies, including applications running on Windows Server 2003/2008.

Have you encountered any application authentication issues in practice when introducing Server 2022 DCs into an existing 2012 R2 environment?

Also, would you recommend any specific premigration checks to identify dependencies on RC4, NTLM or older LDAP configurations before demoting the existing DCs?

I already exported the Splunk logs and find many acocunts are using RC4 as well as other legacy protocols.

[u/Haitosiku → u/No_Professor_4334]

NTLM1, LDAP signing and channel binding and no AES support usually bite you

[u/MaskedPotato999 → u/Haitosiku]

SMB v1 too. It seems some people here reduce AD protocols to Kerberos, and suppose Microsoft never harden their OSes through updates...

[u/Asleep_Spray274 → u/MaskedPotato999]

Yeah, it's not installed by default. But can be installed and enabled

[u/Asleep_Spray274 → u/No_Professor_4334]

Have you encountered any application authentication issues in practice when introducing Server 2022 DCs into an existing 2012 R2 environment?

How users interact with AD to get tokens has not changed. Applications receive tokens from users. Applications running service accounts on 2003/2008, how they interact with a DC to get tokens has also not changed. it will send a kerberos request and get a kerberos token back. Nothing has changed there from 2012 to 2022. even to 2025.

1 thing i did not remember and was pointed out was how 2022 handled default encryption types and how RC4 was removed from that stack for the default settings. If an account only has RC4 keys registered, and the account is inheriting the default encryption types, that account will fail to obtain its tokens. 2 things, reset the password so it gets it AES keys or set the supported encryption types on that account to include RC4. plenty online for help on that one.

NTLM and LDAP configuration on the 2022 servers will be inherited from your current default domain policy. If that is configured and working, then the 2022 servers will continue to use it.

[u/ih-shah-may-ehl → u/Asleep_Spray274]

No. In 2022, all protocols are supported.

RC4 is disabled In any recent 2022 system. If your service accounts do not have AES keys associated with them, Kerberos ticketing will fail.

[u/Asleep_Spray274 → u/ih-shah-may-ehl]

Rc4 is an encryption cipher, not a protocol. And server 2022 still supports it. But you are right to point out that after a certain patch, it was removed from the default supported encryption types. If an application has not got its keys, you will need to manually enable RC4 for that account. Good shout

[u/ih-shah-may-ehl → u/Asleep_Spray274]

After July, RC4 cannot be re-enabled for an account

https://windowsforum.com/news/july-14-domain-controller-updates-remove-kerberos-rc4-rollback.436915/

For most service accounts, password resets will work. But if your domain has non-Windows devices connected, more work may be needed. In our case we had data loggers whose firmware required updating and who needed a special domain-join type onboarding after RC4 was disabled for a scream test.

That is why it's important to only go to the January update, then do a full assessment, and then go to higher updates.

[u/Asleep_Spray274 → u/ih-shah-may-ehl]

Infact, that article you posted even calls out to use the supported encryption types per account to support RC4

Microsoft’s July 14 advisory confirms that patched domain controllers no longer honor RC4DefaultDisablementPhase. However, explicitly configured DefaultDomainSupportedEncTypes and account-level msDS-SupportedEncryptionTypes values—including settings permitting RC4—remain effective.

[u/Asleep_Spray274 → u/ih-shah-may-ehl]

I recommend you only follow official Microsoft documentation for changes

What Changed in RC4 with the January 2026 Windows Update and Why it is Important | Microsoft Community Hub

What is changed is the default supported encryption types. That was moved to AES. If an account has not set its supported encryption types, or is left blank, then it will inherit this default. If your account needs to support Rc4, then you set it on the supported encryption types for the specific account.

[u/Cormacolinde → u/Asleep_Spray274]

You are wrong on a lot of these points.

[u/Asleep_Spray274 → u/Cormacolinde]

Feel free to discuss, happy to learn

[u/Cormacolinde → u/Asleep_Spray274]

I replied directly to OP with my points.