Seizing Operations Master Roles

Although Active Directory is a reliable entity, there may come times when, for one reason or another, one or more of the Operations Masters fails. For example, let's say that DC03, our current schema master, goes down, with absolutely no chance of recovery ( Note: this scenario should never happen, as any good administrator should have a backup and recovery plan. We talk more on this in the next chapter ). If this is the case, Active Directory gives an administrator the ability to literally seize an Operations Master role from a dead domain controller and assign it to a different domain controller. This is accomplished using the ntdsutil command line utility. Keep in mind that seizing an Operations Master role is a last resort tactic, and should be performed only if the dead Operations Master will never be brought back into the domain . In other words, if you can transfer the Operations Master roles using the traditional means outlined in the previous tutorials, then do so. If not, then use a seizure strategy.

Caution

We are not going to actually seize any Operations Master roles in the following tutorial, as this would require you to take one of your test domain controllers out of commission (remember that after a role is seized, the dead domain controller cannot be brought back into the domain). We include the process here for completeness. The following tutorial is for informational purposes only .

Tutorial: Seizing an Operations Master Role

Let's say that DC03, the current forest schema master, has failed, and is completely beyond repair. Let's also say that we have verified this using the previously described repadmin and dcdiag tools . We want to seize the role from the dead DC03 domain controller and reassign it to DC01.

From DC01, open a command prompt and type ntdsutil and hit Enter .
At the ntdsutil prompt, type roles and hit Enter .
At the fsmo maintenance prompt, type connections and hit Enter .
At the server connections prompt, enter a line conforming to the following syntax:

connect to server < name of new operations master>

This line tells ntdsutil which domain controller to connect to so that the schema Operations Master role may be transferred. Since we decided to transfer the role to DC01 we would enter the following, followed by hitting Enter :

connect to server dc01.guinea.pig
At the server connections prompt, type quit and hit Enter .

We're now at the point in which we would officially seize the schema master role. Warning: proceeding with step 6 will render DC03 completely unusable . We are listing this procedure for completeness only, and highly recommend that you do not perform step 6!
To seize the schema master from DC03 and give it to DC01, we would type the following, followed by Enter :

seize schema master

That's all there is to it. If we wanted to seize any of the other Operations Master roles, steps 1 through 5 are pretty much the same for the four remaining Operations Master roles. The only difference is step 6, where we would type one of the following:
- seize PDC
- seize RID master
- seize infrastructure master
- seize domain naming master

Accessing Resources Across Forests

Up to this point, we have learned how domains trust one another, and the process of granting access from one group of users in one domain to resources in another domain. But what happens if we create an entirely new forest (a group of domains with its own schema, Global Catalog, and site/replication settings)? Several factors must come into play if two forests are to communicate:

Two forests must exist
A trust must be configured between the two forests
A trust may only be established between the root domains in each forest
The domain and forest functional level of each domain and forest should be set to Windows Server 2003 Native
A common DNS thread should be configured so that each forest is able to resolve domain names with each other

The first three items are rather self-explanatory. The last two require a bit more discussion. First of all, what is the domain functional level ? Simply put, the domain functional level is a mode which governs what domains can and cannot do. For example, the domains in our forest are running in the default Windows 2000 mixed mode . This mode is a kind of compromise, giving us a good balance of compatibility and features. It offers the broadest level of compatibility with Microsoft's server operating systems, old to new: Windows NT, Windows 2000, and Windows Server 2003. But to attain this compatibility, we lose some functionality. For example, recall that when we shared resources across domains, we were able to nest a global group inside a domain local group. As we shall see later in the chapter, this type of group nesting is not enough for proper sharing of resources across forests. We must be able to add global groups to universal groups, and then add those universal groups to domain local groups. This kind of functionality is simply not possible in the Windows 2000 Mixed domain functional level (as a matter of fact, universal groups are not even an option in the current mixed mode).

The forest functional level is a similar concept to domain functional level. The default forest functional level is Windows 2000. However, with the Windows 2000 forest functional level, we do not have any type of mechanism in which to set up reliable trusts between forests. The Windows Server 2003 mode allows us to do this. The 2003 mode also adds improved domain controller replication as well as improvements to Global Catalog replication.

The last point, a common DNS thread, is very important. For example, all the domain controllers that we have configured in guinea.pig are replicating DNS data to and from one another. In turn , all clients that join the domain must use one of these DNS servers in order to even resolve the name "guinea.pig." When we add a second forest to the mix, with its own set of DNS values and settings, how are clients in one forest going to resolve names in another forest when the two forests are using different DNS servers? One way to solve this problem is to set up DNS forwarding between the two forests. Figure 5-5 helps explain this further:

Figure 5-5: A . A client located in forest 1 sends a query to its DNS server regarding an address in forest 2.
B . The DNS server in forest 1 has no information regarding the address in forest 2.
C . The DNS server in forest 1 is set to forward any DNS requests that it cannot resolve to the DNS server in forest 2.
D . The DNS server in forest 2 is able to resolve the address that the client in forest 1 is requesting. That information is passed back to the client.