Copying Users to a new Domain Controller

Edward6534 · 2024-08-13T13:18:40.787Z

We have 4 domain controllers, each serving a physical location. Replication between the servers has failed and there are multiple Kerberos errors. Our server provider has dug deeper and found multiple issues, and have recommended new DCs.

We would like to remain on the same domain name to save having to de-domain/re-domain client PCs, and to preserve local settings in their profile (ost files, browser saved passwords etc).

Our supplier has advised against replicating one of our existing DCs to a new DC as it could bring across existing issues, so they plan to create a new DC on the same domain.

Is there any way to bring over the users and groups from the old DC preserving the SIDs? We have folder redirection to a file server, and if they are just created on the new DC the SIDs will not match the permissions.

Or is there a way to selectively replicate a DC, choosing which items to replicate (Ideally GPOs, and users and groups). Other server roles such as DNS and DHCP can be easily recreated.

Thanks

kwelch007 · 2024-08-13T13:41:26.450Z

As long as you/they are promoting the new DCs in the existing Domain, all user information will transfer automatically. No “transfer process.”

Unless there’s something missing from your description, your MSP is making a good recommendation. DC’s should be considered mostly disposable, so when there’s a problem with one, it’s generally best to just spin up a new one from scratch to replace it.

Edward6534 · 2024-08-13T14:04:17.028Z

I’ve probably not described it well.

They do not want to add the new DC to the existing domain and promote it as they think it may bring over issues from an existing DCs. So their recommendation is to create a new DC on the same domain, then build the GPOs and Users/groups before putting it into use - but I think the new SIDs for users would then be an issue.

I’m going to suggest again trying to add the new DC and promote it, but they’ve already said they don’t want to.

PatrickFarrell · 2024-08-13T14:51:43.342Z

They are going to try and create another DC with the same domain name as the existing domain but not join it to the same domain?

My gut reaction? Fire the supplier. What have they found that warrants rebuilding the entire domain? If you have to do that you use a new domain name. Existing workstations will not function in the new domain even if the name is the same. All machines will have to be unjoined from the existing domain.com, then rejoined to the new domain.com (even though it has the same name), and then all local user profiles will need to be migrated, which will likely cause problems with the domain names being the same. If they have not explained this to you, fire the supplier.

Then check DNS on your domain controllers and make sure it’s configured correctly.

Active Directory DNS Refresher Windows

It’s DNS. It’s always DNS. No, DNS is fine, it’s not DNS, trust me. It was DNS. I’m posting because in the last few weeks we’ve had a few posts that turned out to be misconfigurations with DNS in a domain environment. Things like Domain controllers pointing at themself first for DNS, or having a public DNS server on the NIC of the Domain Controller or the clients. Hopefully this will help some people get out in front of potential issues. The general rules for DNS in an AD E…

While you’re looking for a new supplier, post your problems with replication in a new thread and see if the community can help you fix them.

GDaddy · 2024-08-13T14:57:57.790Z

agree with Patrick, very bad advice from the Supplier. Fix your Replication, and most like your Kerberos errors will go away.

Edward6534 · 2024-08-13T15:36:16.343Z

The suggestion of using the same domain came from me, not them.

I’m checking out the DNS article you’ve posted, as it seems to describe my issues:

Server replication
Kerberos errors in the event log
unable to browse by domain url (getting access denied errors

Thanks again

AdmiralKirk · 2024-08-13T16:07:04.004Z

Pick which DC is in the best shape, AKA the one that has the most accurate and current data. Demote/remove all the other DCs, then promote new ones one at a time. As you bring each new DC online, verify correct replication before you bring the next one up. You will have the opportunity to learn a lot about the ins and outs of DC replication, and hopefully you will never have to leverage that knowledge again.

As has already been covered, creating a new domain with the same name is just about the worst possible way to try to solve this problem.

kwelch007 · 2024-08-13T16:18:41.852Z

Yeah, I clearly misunderstood. There is no reason to create a new Domain, MSP is giving bad advice here.

adrian_ych · 2024-08-14T06:16:23.724Z

I would think to check the proficiency of your “supplier”.

There is literally no way to add a set of Domain Controllers to existing Domain without replicating all the Domain Data (Users, User Passwords, Computers, GPOs etc).

Solving Kerberos issues in DCs

The more common issue is time differences between DCs
Other issues can arise from mis configured DNS server IPs of the DCs
Else there was long periods where DCs did not replicate thus there are some "authentication conflicts.

Steps to resolve

Ensure there are at least 2 DCs per network (so you might need 8 DCs, or at least 2 DCs in HQ)
There should be DNS IP address round-robin for the DCs such that
i. DCs in HQ should have other DC IP address as Primary DNS IP and secondary to use 127.0.0.1
ii. Remote site DCs to have the IPs of 2 DCs in HQ as primary & Secondary DNS IP, 3rd DNS server to use other remote site DC IP address and 4th to use 127.0.0.1.
iii. The sites & HQ are properly created in Domain sites & services and the DCs are properly placed in the respective sites
iv. All DCs to be recorded in the DNS (else run IPCONFIG /REGISTER on all the DCs)
v. If any of the above changes are made, allow 24-72hrs for propagation & replication to take place

Edward6534 · 2024-08-14T07:47:17.910Z

Just to clarify, the suggestion about trying to fudge things onto the same domain was MY suggestion, not our supplier’s. I was asking about on options on here in case it was possible, their solution has always been a clean start on a new domain. A classic case of a little knowledge being a dangerous thing on my part.

I’ve checked all the DNS settings as suggested and they were already configured as you’d set out in your article.

So I’ll discuss with our supplier, looks like a fresh domain is the safest option if we can’t get a new DC set up and replicated cleanly.

Thanks to everyone for your advice.

PatrickFarrell · 2024-08-14T14:41:58.688Z

A fresh domain should be a last resort. You would have to have a pretty catastrophic failure of all domain controllers, and all backups to go that route.

Worst case scenario, you bring it back down to one domain controller that you know has the data and then add new ones and let them replicate.

Changing domains is a big deal. Do not go that route if you can avoid it.

randomparts · 2024-08-14T14:49:53.539Z

GDaddy:

Fix your Replication, and most like your Kerberos errors will go away.

I would recommend this first before spinning up a new domain. As others have said, that will create a lot more problems, I’m assuming issues the supplier can bill you for.

general-tsao · 2024-08-15T13:23:23.211Z

Please trust all those here that are telling you to fix what you have rather than try to do anything else. You will suffer much less stress and aggravation by fixing what you have.

Dashrender · 2024-08-15T13:38:12.640Z

PatrickFarrell:

es will need to be migrated, which will likely cause problems with the domain names being the same. If they have not explained this to you, fire

This is likely where I would start. The only thing that might trump it is setting up a brand new DC and see if it replicates cleanly - though it sounds like it might not if for some reason it can’t actually talk to all of the other DCs.

In any case - if the above posted troubleshooting steps don’t solve the replication issues, I’d demote all DCs but the one believed to be the most stable/clean. Then stand up a brand new DC and with luck, the replication issues won’t reappear.

Dashrender · 2024-08-15T13:39:31.435Z

Specifically why does your vendor believe they can’t recover the existing domain? If you do create a new thread - please link it here.

Dashrender · 2024-08-15T13:41:55.571Z

As to the recommendation of making a whole new domain - There sadly are times when this is warranted. I know of a very large company who’s Cisco Call Manager install went so horrible - the company had to start over with a new AD because of the damage to the schema.

How many end points/users are involved in this situation?
Software does exist that makes moving profiles between domains possible, sadly I haven’t dealt with it in a long time - so I have no recommendations.

Edward6534 · 2024-08-15T13:56:43.544Z

Hi Dashrender

I have queried their recommendation to start afresh on a new Domain. They had already considered the approach everyone is recommending, of starting from one DC and adding/replicating new DCs to preserve the domain. When they carried out the pre-requisite checks to demote a DC that was not replicating, they encountered multiple errors preventing this.

Thanks

Dashrender · 2024-08-15T14:05:51.310Z

I recently went through a similar issue - I had a tombstoned DC. It was a PITA, but I did manage to resurrect the DC after about 3 hours. Compared to the cost of a software solution to migrate profiles, and the hundreds if not thousands of house needed to move 120+ PCs to a new domain - those 3 hours was worth it.

Dashrender · 2024-08-15T14:08:17.720Z

FYI - MS does have a process to remove DCs that have failed and can’t be gracefully removed from AD. I’d still seriously consider this solution before looking at a whole new domain - again, unless there is something like my aforementioned schema issue at play here, where there is known damage that can’t be repaired.

Dashrender · 2024-08-15T14:11:19.504Z

While considering all the options - I’d also update all endpoints to ensure they are only using a single DC company wide. This way all endpoints are ensured to be using the same data, and not fragmented data between unsynced DCs.
I’m wondering if you in fact already have this issue - DCs that don’t know about PC password updates/DCs that don’t have the latest password for a user, etc.

also - are there local file shares in each location? that’s going to make things messy as well, less so if those file servers are NOT DCs.