There are several factors that impact AD design, and I can see a few doozies in your path. The following factors play a role in how your forest is ultimately designed:
- Politics "Six very different business units". That right there is probably going to be the thing you spend the most time on. Each business unit has their own way of doing things, and this AD structure needs to be compatible with those ways. Even if those ways are diametrically opposed to how things are done in another BU.
- IT decision making processes Perhaps a subset of Politics, but this one will greatly impact your final design. If business managers can veto IT decisions of this level, that impacts things. The same goes with how inter-business-unit wrangling impacts the process.
- WAN links How tightly knit your individual sites are will drive several key decisions. If they're highly available you can make some economies. If they're unreliable or slow, it may force you into other decisions.
- Organizational sizes The number of employees in each location will guide certain decisions as well. Larger organizations will have their own self-sufficient IT departments. Each BU already has such (so you said) but the same may be true of larger sub-units within those BUs.
- IT administrative structure The people who manage specific groups of users will suggest a form of hierarchy for an eventual structure.
- Business administrative structure How the org-chart looks will suggest another form of hierarchy for an eventual structure.
From here it looks like you with have a multi-Site (the AD term) infrastructure, no matter how the actual domains are laid out. The location and quality of the WAN links will determine where the Sites have to be declared. Each Site will need its own Domain Controller and Global Catalog, also regardless of how the actual domains are laid out. You already have 6 sites pre-built (those pre-existing NT4 domains), but you may end up with more. If you end up with more than one domain, some Sites may require more than one DC; operational needs will determine this one.
One very interesting feature that Windows 2008 provides for is the Read Only DC. This is a DC that contains a full copy of the domain database, minus the security principles. Groups of users who are allowed to authenticate against it can be declared, and the RODC will cache those credentials. This is very useful for smaller sites across unstable WAN links, as it allows those users to still be able to authenticate and use domain resources when their WAN link is down, and if the DC machine itself gets stolen the exposure to the company is minimized. These are relatively new, so dealing with them hasn't made it into all of the AD Design documentation out there on the Internet.
That's the network infrastructure, and that's the easy part. Now comes the hard part. Figuring out:
- If more than one domain is required
- Organizational Unit layout within domains, or policies governing such
- Policies for governing Group Policy administration
- Handling appropriate rights delegation to IT entities
A single domain keeps some things simple, and is to be desired. However, with six very different business units this may not be politically allowed. The major sticking point will be who is in Domain Admins, and whether or not those people are universally trusted. Some groups may insist most loudly that they need the ability to have full Domain Admin rights, and yet not allow other groups to have those rights in their area. These are the fights that lead to multiple domain trees.
If a multi-domain forest is agreed upon, the next fight will be who gets to be in Enterprise Administrators. Someone has to, and they'll probably be Central Office types. Uncertainties over this, crossed with Business Managers concerned with protecting their area of influence getting involved in this technical process may force you into a multiple forest environment with carefully selected cross-domain trusts. This is the model most like the old NT-style domains. You don't want this if at all possible.
Educating yourself and anyone who will listen about exactly what 'Domain Admin' allows that can't be delegated in some way will pay you dividends. There is real fear out there about 'foreign admins looking at our stuff'. You can do quite a lot of AD administration without being in Domain Admins given sufficient delegation, which is the kind of thing that can sooth nervous managers.
Having multiple domains may require that you have DCs for multiple domains in specific Sites. The Home Office (if there is such) is a good spot for that, but try to prevent its need in other offices.
Once you have a Domain structure hammered out, the next step is figuring out the Organizational Unit structures within the domains. This is important since GPOs rely on this structure, and a well selected structure eases IT support costs. Politics can rear its ugly head again during this process as well.
If you ended up with multiple domains, then a grand unifying policy regarding OU structure may not be possible; the decision may end up in the hands of the Domain Admins for each domain.
If you ended up with one or a few large Domains, a grand unified OU policy is more likely, though it'll probably cover the top two levels at most.
As for a good OU policy, there are several schools of thought on this.
- Base it on the IT management structure
- Base it on the Organizational structure
- Hybrids of the previous two (Org then IT, IT then Org)
- Don't bother and use GPO Filtering to do the heavy lifting
Basing it on the IT management structure greatly simplifies where rights need to be assigned to support normal IT functions. Rights are granted at certain key levels and they filter down appropriately. The down side to this is that it can lead to some non-obvious configurations, which can confuse people new to the environment.
Basing it on the Organizational structure makes the overall structure easy to understand, and can assist any Identity Management integrations as all similar users would be located similarly. The down side is that IT rights management can get very fragmented.
Using a hybrid model involves picking one standard for the top level, and a different one for the sub-levels. This doesn't work for everyone, but it has been known to be a perfectly valid compromise. Especially if the major business units don't change often.
Chucking the structure and just filtering everything is the kind of thing that Identity Management solutions tend to like, since it really REALLY simplifies object-placement rules. It makes it harder on the IT staff as figuring out what GPOs apply to which locations can't be done just by looking at the OU structure, they'll have to actually look at each GPO and see how it is filtered. But if User, Group, and Computer management is only ever done through external tools like IDM integration or non-MS management portals, it may not matter.
Group Policy Administration
There are some policies that are enterprise wide and can affect everyone, therefore GPO management needs to be addressed at the highest level before things go live. Some of this is definitely going to get delegated to area IT, but the extent to which this is done will depend on how the Domain and OU decisions were made.
Some sort of enterprise-wide management framework will need to be hammered out. It may end up that the top level admins don't care about GPOs for pushing printers to specific office floors, but there are still policies that affect very large areas.
If a multiple domain environment is in place with local-control of OUs, then there isn't much to decide here. Each area will do its own thing, thank you. OU structure and Domain structure will dictate how rights need to be delegated, and IT and Business management will dictate to whom they are delegated and why. It is best to get these processes settled earlier rather than later.