Renaming your AD domain

  • Thread starter Thread starter PR.
  • Start date Start date

PR.

PR.

PR.

Associate
Joined
29 Mar 2005
Posts
620
Location
Bedford, England
Currently working at a place that want to rename their domain sometime next year. I've had a read and it certainly seems possible, but wondered if anyone here had done it themselves, and what the experience was like?

We have most of the MS tech, Hyper-V Cluster, Exchange, SCCM, SCOM, SQL, ~40 Win2k3/8/12 servers, ~700 Windows 7 clients.

I'm expecting to spend months afterwards ironing out all the undocumented configurations that used the old domain name!

Thanks
 
Good luck. Is there any particular reason why they want to change it or is it a aesthetic thing? If so then look at UPN suffixes.

If I had to rename a domain I'd probably bring up a new domain and then create a trust between them and move the objects over. Make sure you hit all the MS recommendations for the domain though, you don't want to make headaches for yourself later - no more domain.local!
 
Caged said:
If I had to rename a domain I'd probably bring up a new domain and then create a trust between them and move the objects over. Make sure you hit all the MS recommendations for the domain though, you don't want to make headaches for yourself later - no more domain.local!
Click to expand...
This is what Microsoft's best practice is. There are too many internal services which are probably reliant on the existing (old) Domain's accounts to consider just renaming everything. Orphaned permissions everywhere... The horror...
 
You'll be wanting a new domain for that, I'd certainly never entertain the idea of renaming an established domain.

No offence and i hate to say it but if your asking and with your current size you may want to look into help from MS themselves or a contractor who does this for a living.

Eitherway its a lot of work if they just want to change the aesthetic! :)
 
It's confusing as all hell, MS themselves have changed their minds so many times on this issue, and SBS always used to pick a .local address.

I think the main issue is if you make up a domain that ICANN might then release it in future which will cause all sorts of problems. .local is specifically bad now because Bonjour /mDNS uses it which can cause issues with anything that talks Bonjour (Mac, iPad etc).

Domains are dirt cheap, either have a internal.companyname.com scenario or just register a companyint.com and use that. You don't have to worry about DNS since you're running your own.
 
Thanks for the replies, renaming definitely seems quite risky, I've seen some MS documentation on the process and I couldn't help thinking it wouldn't take much for it to fall apart.

A couple of years ago two schools merged to form a new one, unfortunately they moved to one of schools existing sites and inherited their AD domain which was called the old schools name. Obviously doesn't look very good to parents, students, and staff so there's a desire to get it changed.

I have been told they created a new domain last year and tried to join them but ended up causing a load of issues for people logging in, MS were called but they didn't know what the problem was so the new domain was removed.

There's currently three trains of thought:

1) Rename the domain, deal with the issues that crop up
2) Create a new domain, trust it with the old one and move things over
3) Create a new domain, don't connect it to the old one and rebuild everything.

TBH none of them sound great, and will definitely occupy most of the 6 weeks summer holidays next year to sort out!
 
Option 2 would be the best way

It really depends on the number of objects in the domain and how many service accounts etc. If it's relatively small then Option 3 could be a nice clean solution. While the current domain is up you can use Powershell scripts to pull out users/groups etc and to populate the new domain
 
Option 2 :) the AD migration tool kits are quite mature and work reasonably well these days.
I'm in the process of doing similar as well and I'm not looking forward to it!
 
Without a doubt, option 2. You could then keep the old domain alive, ironing out the bugs down the line. It always happens that something doesn't get moved and is vitally important 5 months down the road.
 
Before you make an entirely new forest for your new domain and trust the existing one, just make sure you run all the AD best practise tests - dcdiag, check DC replication status, repadmin, netdiag etc. Clean up any problems with your current domain before you do anything else, it should ensure the migration goes as smoothly as it can.

And good luck.
 
You must log in or register to reply here.
Back
Top Bottom