Moving from a single domain to a forest

[ericargyle]

Hey guys. I'm working with a school that I previously set up with a Server 08 R2 DC that hosts AD, runs DHCP, DNS, and the show. It works brilliantly, users are able to login, shares push properly, scripts are delivered, I've had no issues. However, seeing how well this implementation has gone, the secondary campus is looking to join the show and wants their own file server in house. The two campus's are physically connected, Cisco routers on each end. I simply haven't dealt with multiple trees and forests in a bit, so some basic answers to some questions would help me out.

For simplicity's sake, lets say that the current DC running AD at the initial Campus is called "CAMPUS". I want to rename this to CAMPUSNORTH, and I want the additional AD tree to be called CAMPUSSOUTH, however, I want them both under the guise of the district domain, eg: DIST999.

Can I create a forest called DIST999, and have CAMPUSNORTH and CAMPUSSOUTH under them. AD on CAMPUSSOUTH will be dcpromo'd as secondary to the new campus, and theoretically, all users will simply login to DIST999, but for speeds sake, the files per campus will be pushed appropriately (I can do this with scripts, no help needed) from the campus they're native to.

Is there a "right" way to do this, and steps I should bear in mind while making the additional AD at the second campus? I can hack it together, but I'd like to do it with best practices in mind. Thoughts would be greatly appreciated.

Edited November 10, 2010 by ericargyle

[cluberti]

Why create a forest when a second DC and a second site should be all that's needed? You only need a new branch in a forest when you want administrative or security separation - if they're going to be on the same domain, if it's just a physical thing (DFS, local file / DC servers, etc), then just create a new site and subnet in AD, make sure to use the Default IP Site Link, and you should be good to go. I'm assuming you already have routes between the two sites so that the one site can already talk to the other - if not, you'll have to make sure that works as well (you'd have to do this one in a multi-domain forest scenario as well).

If you *need* to create new forests, what you will need to do (for ease of migration) is rename the "CAMPUS" domain to "DIST999" (if it's the only domain, then it should be the forest root domain already), create two new child domains (CAMPUSNORTH and CAMPUSSOUTH), and then migrate the user objects from DIST999 to the new CAMPUS* domain(s) that you need to move these to. Note you will need at least one DC for each domain (so if you have one now, you will need at least three to do this - if going with redundancy, you should currently have at least two, and you would need at least 6). Also note that with a multi-domain forest, you have DNS delegation or conditional forwarding consideration designs to address as well. To reiterate, doing this is *not* as easy as the wizard might portend when you're considering it, and you *must* plan this out properly if you don't want to be troubleshooting a nightmare afterwards. If you do decide to go the multi-domain forest route, consider strongly making a Disk2VHD (or other) VM copy of the current DC/domain, and build up a copy in your lab on an isolated VM network; this way you can try out anything you'd like and blow it away if you screw it up, etc. I would not be doing any changes to a production single-domain forest without doing a VM test of all proposed design changes, and I strongly suggest you follow this advice as well. Measure twice, cut once, so to speak.

You probably want to read these, at least, if you do decide to go the multi-domain forest route:

FSMO placement and optimization on Active Directory domain controllers

Active Directory Best practices

DNS design options in a multi-domain forest

You will also want to make sure your current domain is "healthy" before you do ANY changes, even adding a second site, using BPA.

[ericargyle]

Thanks so much, always a great help! I guess you're right. The routes between campuses are already set up, and since it's basically 2 distinct campuses with some traveling staff and students, I should simply create 2 DCs, and then have them change login domain on startup if they're not at their native school. There's really no need to do it at the district level. At this point, if they're choosing campus at login, is there even a need to replicate AD, or should I keep that seperate as well?

[cluberti]

Well, I cannot really answer that question - If you think you'll ever need a user from one campus domain to be able to access resources from another, then it makes sense. I'm still in favor of adding just a new site and subnet to the original domain (you could still rename that if necessary), but you could also simply create a new single-domain forest for the new campus, sure.