1

Hello Everyone,

Taking over a project that was to migrate old DC 2019 to new DC 2025. From the information I received, this was all a live migration. We have a total of 3 DCs in our environment. One DC (“3rd DC”) is not being worked on as of now but is in place from old remote building that is no longer in place. Im taking over the project after AD and DNS were moved over.

What appears has been done:

  • AD roles have been moved over to new DC. (Verified via netdom query fsmo)
  • DNS has been moved over to new DC. DNS is still enabled on old DC and initially machines were listing old DC and 3rd DC as DNS server. Had to finish pointing DHCP to new DNS server.
  • DHCP role is installed on new DC. DHCP migration seemed pretty straight forward. After copying everything over, disabling DHCP on old DC, and authorizing new DHCP server, machines were unable to contact new DHCP server. Disabled firewall and ensured there were no DHCP relays or IP Helpers. Machines were still unable to contact new DHCP server.

Problems we are having:

  • Currently our main problem is we are having machines unable to authenticate. They need a reboot in the mornings and will authenticate the rest of the day, but will have the same issue in the morning. This issue started with a few machines and has been spreading.

Errors I am seeing:

-On the machines being affected with the authentication issue, reviewing logs I see that they are attempting to authenticate with the old DC and will get the error
“This computer was not able to setup a secure session with a domain controller due to the following: And internal error occurred.”
I believe this is related to Kerberos.

  • On the new DC i keep receiving the error, “The directory blocked access to one or more confidential attributes on one or more LDAP search requests because one or more clients were using an unencrypted LDAP connection”
  • I also get replication errors, such as " This directory server has not recently received replication information from a number of directory servers" and " The remote server which is the owner of a FSMO role is not responding. This server has not replicated with the FSMO role owner recently"
  • To add on to this mess, when I run dcdiag on the new server, I will see the machines affected with the authentication issues pop up on the dcdiag results with the error, “The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server . The target name used was cifs/.. This indicated that the target server failed to decrypt the ticket provided by the client…” Noted that the only test that fails on DCDIAG is the KccEvent test.

What I have done:

  • Have ran repadmin and the DCDIAG tests for replication and all test pass. I was hoping to get more information with these tests but they all pass.
  • Ran klist to show what KDC were being used and found that the machines with authentication issues were using the KDC on the old server. Tried purging tickets on those machines and that did not help.
  • Tried all the microsoft solutions in their KB’s and all their suggestions for solutions seem to be in place already.

Kind of stuck here. Most of the solutions I see on here and other threads seem to suggest just starting over. Trying to fix this if I can but dont really know what to focus on as errors are pointing me different directions.

4 Spice ups
2

There’s at least three (more likely closer to five) threads here alone that say all the reasons having Server 2025 acting as a DC is a bad idea…stand up a new Server 22 instance, seize the roles, verify replication, then repeat so that you have two functional DC’s.

2 Spice ups
3

Welcome to the family

1 Spice up
4

Hi Jay,

I appreciate the response. Thats what I was thinking as I have seen that as the response in similar threads. My questions here are do i transfer or seize the role from the new DC? Also, what would your suggestion be on going about this. Sorry Im very green at server migrations and unfortunately dont have anybody on the team that has done them before.

1 Spice up
5

Thanks Nerf!

2 Spice ups
6

If you can stand up a new Server 2022 instance and the roles transfer peacefully, then great! If not, seize the roles. Try the gentle approach before you start swinging hammers.

7

Okay, sounds good! So no reverting back to working DC and starting from there needed? That was another concern as i was seeing threads with failed migrations being reverted back to working DC and working from there.

1 Spice up
8

You could revert, but if you’re able to move forward instead by standing up Server 2022 and (hopefully) taking roles gracefully, I’d start there, rather than dropping back to 2019 on the old DC. Once you’ve got 2022 stable and everything synching, evaluate your environment before you do anything else. Take it slow, so you don’t make things worse than they are already!

9

Definitely not trying to make things worse. Thats the reason there is so much hesitancy on actually doing this. When you say evaluate your environment, what do you mean?

1 Spice up
10

AD works best with two DC’s, minimum. Once you’ve got the system stable on 2022, you need to decide on when to spin up a redundant DC. Only you’ll know when it’s “safe” to do that, as you’re the on-site expert. You might be good watching the system for a day and spinning it up the next morning or you might feel the need to watch it for a week. That’s your call, but I’d suggest having the second one up and running sooner rather than later.

11

That makes sense. Would I demote the 2025 DC once AD and DNS have been moved over or should i worry about making sure 2022 server is all good first? Wondering if keeping it up and running will continue to cause issues.

1 Spice up
12

Make sure 2022 is good, then demote. So long as the AD sync is good and roles migrate without problems, you can demote Server 2025.

13

fix the issues before adding more DCs.
if you have only 1 subnet with no firewalls blocking anything - then the only issue you have is likely to be DNS.
the person who added the new DCs may not have updated the dns server settings correctly.
Does each DC that exists now use another DC plus itself (as second) for DNS?
that is critical.

1 Spice up
14

Yes all DCs have a second DNS plus itself.

1 Spice up