Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

moving forest root domain controller

Status
Not open for further replies.

blade1000

IS-IT--Management
Mar 1, 2009
133
US
All-
I am moving the forest root domain controller which holds the Schema and Domain wide Roles.. it will be moved from one physical site to another, there are 4 child domains within the forest to consider here, so if I turn off the root dc and transport it, as long as I can bring it up again within a 1 hour period of time, do we need to worry that the child domains and(or) certain domain roles like pdc emulator won't complain too much?
Should I force replication once the forest root server is up and running in its new location or let it ride?
It is also a global catalog server btw....

Thank you for any options provided here,btw- all my routes are open to allow ldap, rpc and dns traffic both ways...

Thanks
Blade1000
 
blade1000,

Don't see any issues with doing that. Provided that you can bring the root DC online relatively fast. One thing to remember is that if you have any forest trusts, you may have issues goign from the child domain to the other forest whilst the server is down.

Anyway, from what I can gather, you have anly one root domain DC. If that's the case, I would add another root DC before doing anything with the first one.

Michael
 
If it were me, I'd do the following:

1. Backup the existing DC
2. Add another DC/GC to the root domain.
3. Add it to the correct AD site.
4. Verify that the destination for the original DC is correctly configured in AD Sites & Services (including subnets).
5. Wait for replication to complete.
6. Move the related FSMO roles to it & verify.
7. Backup the new DC.
8. Move the original DC to its new location.
8a. Assign new IP if new site is a different subnet.
9. Verify functionality, including DCDiag and NetDiag.
10. Transfer the FSMO roles back to the original DC & verify.
11. Demote & decommission the "new" DC if desired.

The reasoning for this is that you maintain all functionality while the original DC is moved. You also have a working solution should something happen while moving the original DC (it wouldn't be the first time I've seen a DC fail to boot after being moved, or the first time someone's in an accident while moving a server). You also should have no end user issues while the original DC is moved, since functionality exists during that time.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.
 
58sniper-

I truly appreciate all your detail based on this. I was under the impression that you couldn't just transfer the Schema and Domain role (Forest fsmo roles) to another dc but you can do it with ntdsutil as I've researched.

There is in fact another DC ready and available to take on the Forest wide roles and I will follow your steps as you've always been great support on these forums Pat!

blade
 
Hey Pat-

What exactly is imperative that I must backup on a DC whether it be a FSMo role holder/GC or not.. Just backup the system state stuff, would that do it?

I used to do this kind of stuff all the time years ago but I get to this current project and we got tossed into corporate moves while implementing other projects like migrating "tther" subsidiary businesses of their's into the parent schema etc..

thanks for any info at all Pat and I truly appreciate your responses!

blade
 
thanks Pat,

I agree now that I look at the DC, why take chances...

I appreciate your response!

blade
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top