Windows Server 2008 : Designing a Forest Structure

1. Forest Functional Levels

As you've already learned from your study of Active Directory in Windows Server 2008, Windows Server 2008 currently has three functional levels at both the domain and forest levels:

• Windows 2000 Native

• Windows Server 2003

• Windows Server 2008

In previous exams, this feature wasn't quite as important as it is now. This is because each of these three functional levels has important and unique abilities, each of which is detailed in Table 1.1.

The most important thing to know about these functional levels is that big changes will occur when you upgrade your infrastructure to the Windows Server 2003 level. Table 1.1 illustrates the drastic changes that were implemented with the release of Windows Server 2003. Beyond these major changes, the overall functional level of the forest is relatively simple.

In general, the best practice for an overall forest design is to use the most robust (and therefore highest) functional level possible. However, more often than not, because of the presence of certain older domain controllers or technological limitations, you will be forced to settle for less advanced deployments. Keep in mind, however, that if any domains within your forest are functioning at low levels, such as Windows 2000 Native, raising the overall functional level of the forest will raise any domains that are not already at that level to at least that level.

2. Forest Design Elements

When you first decide to design a forest in Active Directory, you have three important elements to consider:

• Organizational requirements

• Operational requirements

• Legal requirements

As much as you may like, you're not allowed to create a forest at whim. If you did that, almost every environment would be a single forest (unless you felt curious), and it's likely that none of these requirements would be met. To understand what you need to do to accommodate these elements, let's define them a little further:

Organizational requirements is a fancy term that means "doing what your organization says needs to be done." On a practical level, what it means to administrators like you and me is that some users in the environment may require their own individual playground (an area where they can make changes and not affect anyone else), or they may require access to more folders and shared documents (items that need to be accessed by them as well as users in the rest of the structure). When you choose your design, you have to keep in mind that situations may occur where you have to assume that there may be a lot of political reasons for separation or collaboration, and you should plan accordingly.

Operational requirements (or perhaps restrictions is a more apt term) usually stem from the fact that different groups within a company run different services at different times. For example, a branch of your organization may run Exchange Server 2007, while another may run a custom application that conflicts with Exchange Server's requirements by directly accessing the Active Directory structure and modifying it. Thus, these branches will have to be separated at the beginning of your design.

Legal requirements are laws and regulations that impact data access throughout the network infrastructure. Believe it or not, some businesses may be legally required to keep certain functions in a separate environment. From an IT person's standpoint, this may seem kind of odd, but it's true. Imagine what would happen, for instance, if you were working for an insurance company where the claims adjusters had direct access to the accounting applications. In practical terms, this could be a bad thing. The adjusters could make payments to claimants, get direct access to underwriting data, or figure out other ways to make a mess. But in addition to these practical business reasons, legal and regulatory rules mandate separation between the accounting, underwriting, and adjusting functions.

3. Autonomy vs. Isolation

When you first hear the words autonomy and isolation, they might strike you as nearly synonymous. In the non-IT world, autonomous describes something that is independent and functions of its own accord, and isolation describes something that has been set apart from the rest of any given group. However, when working with Windows Networking components and building an infrastructure, these terms have very distinct and important meanings.

3.1. Autonomy

In the world of Windows administrators, autonomy means that a particular resource is administered, but not completely controlled by, one group. It basically means putting things together in a spot that's independently operating. This means that if you have an autonomous group of administrators, they have the rights and authority to operate on their own group of servers, or even their own domain. However, you will most likely have another group of administrators that will have authority over this group and the ability to delegate their authority (or even supercede it). In general, administrators strive for two types of autonomy when they create an administrative design: service autonomy and data autonomy. Data autonomy is the result of creating an environment where particularly important pieces of data are placed in a location that can be overseen by administrators. Service autonomy, however, is the result of making sure part of service management is directly overseen by a particular group of administrators.

Just keep in mind that in both data autonomy and service autonomy, a single group of administrators will almost always not be the only ones in charge.

3.2. Isolation

There's something about the word isolation that seems to appeal to most administrators. That's a huge stereotype, but at least in terms of the enterprise, isolation can be a very good thing. The concept behind it is that sometimes pieces of data or services running within a forest require domains that are separated completely from others. This means that, no matter what, particular administrators are the only individuals who can administer a particular area in your environment. As with autonomy, you would likely consider isolation for two resources: services and data. With service isolation, you are preventing other administrators from controlling a particular resource. With data isolation, you are blocking other administrators from accessing important files and information.

4. Forest Models

When designing a forest, there are traditionally three models for breaking the forest up into understandable parts: organizational, resource based, and restricted access. Each of these structures is defined in the following sections, along with the pros and cons of the concept.

4.1. Organizational Forest Model

In the organizational forest model, administrators design the forest from the ground up to accommodate the needs of an organization according to its departments, locations, or other criteria that define the physical layout of the campus and the functional structure of the business model. These criteria take precedence over any customized scheme provided by the network designer. As an example, the domain model shown in Figure 1 was designed to represent the company in a single-forest organizational model. This model is designed logically to divide the company up: first by department, and then by location.

Figure 1. Single-forest organizational model

Figure 2 shows this same company but utilizes a trust with another forest. Each of these forests still maintains the concept of an organizational layout.

Figure 2. Organizational forest trust

4.2. Resource-Based Forest Model

Fairly often companies will face situations where an environment contains valuable or highly demanding resources that have to be accessed by multiple personnel, and both users and business interests could be exposed to unnecessary liability if the resources are not separated from the rest of the organization at the forest level.

Sometimes, in an environment with a particularly useful or powerful application, shared folder, or other system resource, administrators will create a forest specifically designed for users who need to access that resource. Usually this type of forest—called a resource-based forest—is a new or additional forest in an organization, and trusts are established to access this forest.

Another advantage of a resource-based forest is that it is independent of any other forest; therefore, should there be a problem in a forest unrelated to the forest dedicated to the resource, the resource-based forest will be unaffected. This is particularly useful for backup strategies, which will be discussed later.

4.3. Restricted-Access Forest Model

A restricted-access forest, as shown in Figure 3, is a forest that is completely separated from another forest but (usually) is linked with a trust. This forest is administered wholly separately from the other forest and does not in any way share the administration needs with the other forest. Ordinarily, the administrators of this forest know nothing about other administration policies throughout the rest of the organization.

Figure 3. Restricted-access forest

5. Forest Schema

Within all versions of Windows Server, the Active Directory schema acts as a guiding rule for what exists in Active Directory, what is allowed in Active Directory, and how everything within Active Directory is formally defined. At the server level, you might see the need to modify the schema in order to incorporate different versions of Windows or new objects in Active Directory. This process can be a little annoying at times, but it's all part of upgrading your environment, "Naming Conventions, Networking, and Access Principles." For now, I'll cover the Active Directory schema from a higher design level and show what you need to consider before you make changes to the schema or plan for future changes.

5.1. Single-Forest vs. Multiple-Forest Design

One of the biggest advantages of working with a schema is its all-encompassing quality. Most administrators dream of the day where they can operate in a campus that uses only one forest and where they can control all the domains within. Remember, all domains with parent/child relationships that are within a forest are linked by two-way transitive trusts by default, and they're all part of the same schema. This architecture is called a single-forest design.

On the other hand, most organizations have a good reason to keep multiple forests, with their own independent resources, in addition to their current forest. This architecture is (surprise!) called a multiple-forest design.

Autonomous model

An autonomous model is an administration concept that forces each independent forest or domain within your network to remain independent in its own administration and gives only a certain group of administrators the privilege to alter its contents. In terms of setup, this is by far the easiest model to implement. However, it can cause administrative headaches in the future because only a certain group has the authority to change permissions, and those permissions may need to be altered when the group is unavailable. Also, remember that this will affect the Active Directory application mode containers!

Collaborative Model

In a collaborative model, administrators assist each other across multiple forests. This eases the load of administration throughout the organization. Of the two forest administration models, this is by far the more difficult one because it requires the creation of forest trusts and the delegation of privileges.

5.2. Schema Modification

Thankfully, with all the features that have been enabled in Active Directory through the years, the process of modifying your schema has become a less common process. However, sometimes this process still does occur. In particular, it is exceptionally common when an administrator decides to install a software package that creates its own individual object classes, which may require an update to be spread throughout the rest of your Active Directory environment.

As an example, Exchange Server 2007 creates numerous individual definitions before installation that must be replicated throughout the entire environment. This creates a problem because if new object classes are being created, the schema is being modified. If you're in a large organization with a lot of users, the process of replication can take quite a while because every machine needs to become aware of what's happening throughout the rest of the environment.

Therefore, it's best to adhere to the following steps before you alter your schema:

Plan

Determine what changes are required.

Plan again

Make sure you've considered all the changes that are necessary.

Test your plan

Simulate your changes in a test environment.

Roll out your plan

Begin the changes on a small scale when traffic is low.

By following this protocol, you can make sure the process goes as smoothly as possible.