PART III in Software

Printer QR in Software PART III

TIP For more information on the construction of an enterprise architecture and the identification of

business requirements, see wwwreso-netcom/articlesasp m=8 and look for the Architecture section Your ADDS design must be flexible and adaptive It must be ready to respond to organizational situations that you haven t even anticipated yet Remember, ADDS creates a virtual space where you will perform and manage networked operations Being virtual, it is always adaptable at a later date, but if adaptability is what you re looking for, you need to take it into account at the very beginning of the design Once you have the information you need, you can proceed to the actual design This will focus on three phases: partitioning, service positioning, and the implementation plan This forms a blueprint for ADDS design (see Figure 5-5)

Partitioning is the art of determining the number of Active Directory Domain Services databases you want to manage and segregating objects within each one This means you will need to determine the number of forests your organization will create remembering that each one is a separate database that will require maintenance and management resources Within each forest, you will need to identify the number of trees, the number of domains within each tree and the organizational unit structure within each domain Overall, you ll need to identify if your Active Directory database will need to share its information with other, non-ADDS network operating system (NOS) databases This will be done either through integration of the two database structures (if the other database is compatible to the

Part III:

FIGURE 5-5

Active Directory Domain Services format) or information sharing In this case, you will need to identify the information sharing strategy to use To control data replication and minimize the impact on your bandwidth, you will identify and structure sites, design replication rules and identify replication methodologies This is site topology design Since you intend to fully exploit the ADDS database (after all why go through all this trouble if you re not going to fully use it ), you ll have to put in place a

5:

schema modification strategy Since every schema modification is replicated to every domain controller in the forest, you ll want to ensure you maintain a tight control over them

Site topology design is closely related to service positioning Each Active Directory domain controller performs important operations that support the proper functioning of the overall database In fact, the objective of site topology design is to determine how each of these database containers will be linked to the others Since ADDS is a distributed database, domain controllers can and should be positioned as close as possible to the user These points of service should be convenient without becoming overabundant and increasing your administrative workload Flexible Single Master of Operations (FSMO) servers are special domain controllers that manage global forest or global domain operations Global Catalog (GC) servers are domain controllers that maintain copies of forest-wide information, acting as the information locator for the forest But since WS08 domain controllers can cache frequently requested global information, GC servers do not need to be as widely spread as domain controllers Read-only domain controllers (RODCs) are DCs that include a read-only copy of the domain database, helping provide services while maintaining security Finally, DNS servers are a must, since they provide namespace management functionality to the directory Because of this integration with the directory service, DNS servers should be seen as subsidiary functions for directory support

If you choose to rely on Microsoft s Hyper-V to run your resource pools, then you will need two different Active Directory Domain Services structures: one for the resource pool that manages all hardware resources and one for the virtual service offerings your end users will interact with This will serve to segregate the security contexts of the two environments Resource pools should not use the same directory service as the virtual service offerings Using the same directory service at both levels can put your entire infrastructure at risk should any portion of your directory be compromised Segregating these two infrastructures keeps them completely separate and can serve to protect the resource pool in the event of a compromise of the VSO directory VSO directories are at a higher risk by default because end users and therefore, potentially malicious users, interact directly with them Resource pools, on the other hand, are less at risk because only administrators interact with them Creating separate directories for each enhances the protection of the resource pool because there is no interaction between the two security contexts Of course, if you decide to use a different, non-Windows, hypervisor you will be segregating the security contexts of the resource pool and the VSOs automatically because non-Windows infrastructures do not participate in ADDS by default Therefore, you should endeavor to keep your resource pool ADDS structure as simple as possible since no end users can participate in it The guidelines included in this implementation plan cover many aspects of the directory implementation you need to prepare for each environment, yet most of these aspects focus on VSO directories since this service will interact with users Keep this in mind as you run through the details of this implementation plan

Part III: