Infrastructure Planning and Design (IPD) is a series of planning and design guides created to clarify and streamline the planning and design process for Microsoft infrastructure technologies. Each guide in the series addresses a unique infrastructure technology or scenario. These guides include the following topics: Defining the technical decision flow (flow chart) through the planning process Describing the decisions to be made and the commonly available options to consider in making the decisions Relating the decisions and options for the business in terms of cost, complexity, and other characteristics Framing the decision in terms of additional questions for the business to ensure a comprehensive understanding of the appropriate business landscape The guides in this series are intended to complement and augment Microsoft product documentation.
This guide was created to enable infrastructure planners to design virtualization infrastructure solutions. This guide includes specific design information, including activities that encourage sound planning. Each activity includes: Prerequisites and background on the activity Tasks that will be performed to complete the activity Reference information regarding the activity's impact on characteristics such as cost, complexity, and capacity of the solution Questions to ensure business needs are captured and reflected in the solution This guide is written for information technology (IT) infrastructure specialists who are responsible for planning and designing a virtualized server infrastructure.
The purpose of this guide is to assist designers in the decision-making process by providing a clear and concise path for designing the Active Directory infrastructure considering the relative context. This guide relies on best practices and real-world experience to offer design considerations and alternatives at each point in the design.
According to the Core Infrastructure Optimization Model, having administrator-controlled automated physical or virtual application distribution will help move an organization to the Rationalized level. Active Directory provides the administrator with the mechanism for user and machine authentication within the organization. Active Directory begins to move the organization to the Standardized level, while providing the infrastructure for additional services required in the Rationalized and Dynamic levels.
The critical path of the design process is the path that orders decisions in series, as one task must be completed before another task starts. There are some process flows that, while they must be completed, can be performed in parallel, or sequentially in any order. For example, both A and B must be completed; however, they can be performed at the same time, or A can be performed before B, or vice versa. For the purposes of this document, we have chosen to perform the steps in a sequential path moving from the top to the bottom of the diagram.
Complexity The complexity of this option relative to other options. Cost The initial setup and sustained cost of this option. Fault Tolerance How the decision supports the resiliency of the infrastructure. This will ultimately affect the availability of the system. Performance How the option will affect the performance of the infrastructure. Scalability The impact the option will have on the scalability of the infrastructure. Security This value reflects whether the option will have a positive or negative impact on overall infrastructure security.
All of these design criteria are related to the “big picture” of the AD design. At this point, the forest, tree, and domain structure are determined, as well as the naming scheme that will be used. The naming scheme is key, as it will tie into not only AD, but DNS.
When considering the overall design of Active Directory, a single forest implementation is always desired. Administration of a single forest is easier and more efficient than multiple forests. Multiple Schemas. Everything in the forest shares a common schema. If there are any conflicts with applications or administration of the schema, this can introduce the need for an additional forest. Resource forests. Some organizations may require multiple forests for isolation reasons, but need to share a common resource, for example Microsoft Exchange Server 2000 and later. A separate forest can be created to host the shared resources, and forest-level trusts can be used to provide the authentication and authorization paths. A test environment could be created as a resource forest. Forest Administrator Distrust. There are instances where a company or entity that is considering Active Directory has an internal structure where there is more than one IT staff. If each IT staff wants to control the forest, while denying the other IT staff from controlling the forest, multiple forests are the only way to provide the solution. This is a common scenario when companies merge, government agencies, and Universities. Legal Regulations for Application or Data Access. Due to the fact that all domains in a single forest have automatic, two-way, Kerberos trusts, data and applications can be accessible very easily. When working with some foreign countries, the legal requirements can dictate that data and applications need to be separated. Multiple forests provide this separation.
Single domains A single domain is the least expensive option. As more domains are added, cost for hardware, software, and administration increases. Manageability: A single domain is easier to manage. Management costs rise with the second domain because of additional management overhead. Multiple domains If Active Directory has a large number of frequently changing attributes, it may be useful to break the environment into multiple domains to control the replication within the domains. Testing should be done in a lab to determine whether multiple domains reduce the replication traffic in a significant way. For a very dynamic environment that is changing objects often, the replication traffic could be excessive at a threshold of 100,000 objects in a domain. To reduce the traffic associated with any one domain, multiple domains can be created. Although the compression algorithm used to replicate directory service changes across slow links is highly efficient, there could still be times when a separate domain is beneficial and necessary when slow links are causing issues for replication. This scenario is usually more sensitive when there are numerous changes occurring to directory service objects on a regular basis. If there is an existing Microsoft directory in place, running on a different OS level, and if there is a requirement to preserve that directory on the older OS, this may be best achieved by separating that environment into its own domain.
Name resolution conflicts can be avoided by using a NetBIOS name that is more likely to be unique across corporations, such as CONTOSOCORP in the case of a corporation named Contoso. Use a name that will be unique and independent of existing regional or organizational names within the corporation. The DNS names of Active Directory domains include two parts: a host name and a network name that, when concatenated, create a non-ambiguous name for a resource. In this case the host is the Active Directory domain. To ensure uniqueness with other companies, don’t duplicate existing corporations’ registered Internet DNS domain names. Also, it is a best practice to register all top level domain names that are being used, both internal and external, with Internic to ensure uniqueness of the name. Top level domain names might include fabrikam.com or contoso.com, but the child domains in the forest, child1.fabrikam.com or child2.contoso.com, would not need to be registered. DNS names should not represent the business unit or division as the domain name. DNS names could become stale or out of synch as the business unit or division name changes.
Option 1: When the domain design for a forest indicates a single domain, then this single domain is the forest root domain. This one domain will host all users, groups, computers, and the forest root groups. This is an ideal solution for management and cost. If multiple domains exist in the design, one of the domains can be selected to be the forest root domain in addition to managing the users and resources of the domain. The selected domain will define the forest namespace and will need to be the first domain deployed in the environment. Although it will also manage users and resources, it will always maintain its unique status as the domain containing the Enterprise Admins and Schema Admins groups. Option 2: In many cases where a company decides to have multiple domains, the forest root domain will be designed as an empty root domain. This is when there are not additional users, computers, groups, or resources placed in the domain. The domain is used only for the Enterprise Admins and Schema Admins functionality. Since the forest root domain name can’t be changed, it is also used as a namespace holder for companies that have many changes to domains or mergers and acquisitions. The time can either be set to synch with an internal source or an external source. If it is set to an internal source, it is still suggested that this internal source be synched with a time server that is on the Internet. If an internal time source is used, authentication can be used by the time source and domain controller to ensure a reliable time. If an external time source is used, there is no authentication provided. It is not suggested that the time be set manually and updated manually. The Active Directory environment relies too heavily on the time and serious problems can occur if the time is not set properly.
Objects in the directory can be organized by using organizational units (OUs). The design for the OUs will have two primary factors. First, the OUs will need to be created for a function. The primary function for OU design is to deploy Group Policy Object (GPO) settings. The second factor is to delegate administration over objects within the directory. The OU design should not reflect the hierarchy of the organization or company.
OUs can be used to delegate administration of objects within the OU, such as users or computers, to a designated individual or group. Delegation by an OU involves creating the OU, placing the individual or group that is being granted delegated rights into an administrative group, assigning the rights that are delegated to the group, and placing the objects to be controlled within the OU. It is a best security practice to delegate to groups, not individuals. OUs can be created for the purpose of applying Group Policy to a specific subset of computers or users. By default, all objects contained in an OU will receive the settings contained in a GPO. Identify groups of users or machines that require Group Policy to be applied to them. Examine the current OU design for the domain. If possible, reuse existing OUs if they meet the requirements. For example, if management of departmental computers has been delegated, and a Group Policy is to apply to the same computers, the OU used for delegating the permissions for the departmental computers can be used. However, if the planned OU structure and the Group Policy requirements don’t align, then the OU design will need to be investigated and potentially expanded to accommodate both needs since an object that is being managed can only exist in a single OU.
Determining the placement and role of the domain controller is essential to the performance of the domain controller and the overall AD network. A poorly designed and placed DC can result in slow authentication, replication that occurs poorly or not at all, and logons that might seem inconsistent. The GC and FSMO roles are essential to much of the authentication and management of AD and must be placed on the network correctly.
Task 1: Hub locations provide computing and networking services to many users within the organization. Hub locations may provide these resources to users in the hub, as well as to one or more satellite locations. Task 2: Satellite locations are connected to the overall network through hubs. In most cases, a satellite location has fewer users and computers than a hub. The clients in a satellite location can use resources locally, can use resources in the hub, or can use the hub to access network resources located in other parts of the network. Several considerations can indicate the need to place a domain controller in a satellite site. Domain controllers need to be managed. Place a domain controller in a particular location only if it can be managed locally or managed remotely by use of a secure connection.
As a best practice, every domain should have a minimum of two domain controllers in each site, to ensure domain resiliency in the event of a server failure. This does increase the cost for hardware, software, and administration. If there is only one domain controller per site, consideration should be made for the need to span the WAN to authenticate, access resources, and so on in order to communicate with a domain controller. All domain controllers within a domain must be fully aware of all information related to the domain. This is handled by replication of the Active Directory database between domain controllers. This replication occurs within Active Directory sites and across site boundaries. If the number of replication partners reaches 15 or more in a given site, add an additional domain controller to the site. Then, add an additional domain controller for every additional 15 replication partners. For each domain controller identified, determine whether that domain controller will be a writeable or a read-only domain controller (RODC). The full domain controller should only be placed in locations where the physical security of the domain controller can be ensured.
***ANIMATED SLIDE***CLICK TO ADVANCE TO FLOWCHART*** If a forest consists of only one domain, then all domain controllers should be configured as global catalog servers. The subset of data that would be replicated to all global catalogs is already being replicated through the normal domain replication process. There are no additional requirements for disk space usage, CPU usage, or replication traffic. In a multi-domain forest environment, a subset of the domain controllers in the environment will be configured to run as global catalog servers. Because all global catalogs replicate a subset of all objects in each domain, placement of the global catalog needs to be carefully considered due to increased bandwidth overhead introduced by the additional traffic.
Near applications: Certain applications, such as Microsoft Exchange, Message Queuing, and applications using Distributed COM, rely heavily on global catalog servers. They tend to perform better when they have a local global catalog available to improve query performance time. Number of Users at the Location Greater Than 100: Global catalog servers should be placed at all locations that have more than 100 users in order to reduce WAN traffic as well as to prevent productivity loss in case of WAN link failures. WAN Link Availability: Consider placing a global catalog in a location where the WAN link is not reliable enough to ensure user authentication or configure Universal Group Caching. Roaming Users at Location: Roaming users need to contact a global catalog server whenever they log on for the first time at any location. A global catalog should be placed at the location if there are a large number of roaming users. In many scenarios, too many logons over the WAN link can cause significant WAN traffic and cause performance degradation and production loss. Use of Universal Group Caching: For locations that include less than 100 users and do not include a large number of roaming users or applications that require a global catalog server, universal group membership caching can be enabled on domain controllers in the location running Windows Server 2003 or Windows Server 2008. How Many Global Catalog Servers? In most cases, one or two global catalog servers will suffice in a location. Application requirements, such as Microsoft Exchange, may increase the number of global catalogs required per location.
Primary domain controller (PDC) emulator operations master. This role processes all replication requests from Microsoft Windows NT ® 4.0 backup domain controllers (BDCs) and processes all password updates for clients that are not running Active Directory client software. This is also the default domain controller used for updating Group Policy. Relative ID (RID) operations master. This role allocates RIDs to all domain controllers to ensure that all security principals have a unique security identifier (SID). Infrastructure operations master. This role maintains a list of the security principals from other domains that have membership in groups within its domain. There are also two operations master roles for each forest: Schema operations master. This role allows changes to the schema. Domain naming operations master. This role is responsible for additions and removal of domains, sites, and domain-based DFS configurations to and from the forest.
In a single domain forest, leave the five roles on the initial server. There is no benefit to separating them. The only consideration is the placement of the domain controller; it should be in the site where most users reside. In the forest root domain, leave all of the operations master roles on the first domain controller, provided that all domain controllers in the forest root domain are also global catalog servers. If some of the forest root domain controllers are not configured as global catalog servers, then ensure the infrastructure master role is moved to a domain controller that is not a global catalog server and ensure that it is never configured as one. The infrastructure master role should never reside on a global catalog server unless all domain controllers in the domain are also global catalog servers. In all other domains, the three domain-specific operations master roles can reside on the first domain controller for that domain. Ensure the infrastructure master role is not placed on a domain controller that is also running as a global catalog server.
The site design consists of matching the logical AD sites with physical networks. Placement of the DCs in the sites is critical, as the clients will need to communicate with the closest DC for optimum performance of authentication and resource access. The site links and site link bridge design must be considered for larger organizations. If the network is basic, both of these process steps might be skipped.
A site should be defined for any physical location where replication between domain controllers should be managed and resources/services exist that can benefit from a site. Certain services, such as Distributed File System (DFS), use site topology to locate the closest resources for clients. For any remaining physical locations that have not been associated with a site within Active Directory, associate the subnets in that location to an existing site. The site selected should include a location that has the greatest WAN speed and available bandwidth to the location being configured. This will help direct client traffic generated within the location to the site having the greatest capacity to handle the additional traffic.
The default-first-site-link is created automatically by Active Directory. When all sites in the design are connected with the same connectivity and availability to each other, then a single site link can be used to represent the links between the sites. This full mesh design assumes that all sites are well connected and there is no need for designing specific links between sites. This simplifies the design by eliminating the need to design site links, as well as configuring the site link structure. If sites are connected with physical network links that have different costs of usage, availability, speed, or available bandwidth, then there may be a need for different replication schedules. A new site link would need to be created to account for these differences.
If the network is fully routed and there is no need to control the Active Directory replication flow, then leave the transitivity enabled for all site links by leaving the Bridge All Site Links option enabled, which is the default state. If a network is not fully routed, disable the Bridge All Site Links option for the IP transport and configure site link bridges to map to the physical network connections. Additionally, if the IP network is fully routed but there are too many routes that the KCC should not consider, creating a custom site link bridge topology and disabling the automatic transitivity of site links will eliminate the KCC can consider all possible connections and bridges for replication. Site link bridges can be used to control replication flow of Active Directory. The two most common reasons are to control replication for failover of a hub and spoke network design and to control replication through a firewall. If Active Directory replication flow is to be controlled through the design of site link bridges, then disable the Bridge All Site Links option for the IP transport.
The final stage is to determine the details of the DCs. This will include placement of the files for AD, HD size, network requirements, and memory requirements.
Task 1: For each domain controller, plan to allocate at a minimum the following amount of space: 500 MB for Active Directory transaction logs 500 MB for the drive containing the SYSVOL share 1.5 GB to 2 GB for the Windows Server 2008 operating system files 0.4 GB of storage for every 1,000 users in the directory for the NTDS.dit drive For a given global catalog server, the additional space requirement is 50 percent of the recommended disk space for each additional domain outside of the global catalog’s own domain. In the earlier example, Domain A required 4 GB of disk space and Domain B required 2 GB of disk space. For a global catalog server in Domain A, an additional 1 GB will be needed (Domain B’s 2 GB / 2) for a total of 5 GB of storage. For a global catalog server in Domain B, an additional 2 GB will be needed (Domain A’s 4 GB / 2) for a total of 4 GB of disk space. Finally, if any applications are using the directory to store data in an application partition, the storage requirements for each application partition will need to be added to the domain controller disk requirements. Task 2: Users per Domain in a Site Minimum Memory Requirements per Domain Controller 1–499 512 MB 500–999 1 GB >1,000 2 GB Task 3: The general recommendation is that for sites with fewer than 500 users, start with a single CPU; for sites with fewer than 10,000 users, start with dual CPUs and then scale from there. This assumes that the primary work of the directory is user authentication. Task 4: Typically, a single network adapter is sufficient to handle all of the network traffic to/from the server. If extremely high network traffic is expected, then it may be necessary to conduct testing to see if multiple network adapters are required. Some companies choose to use redundant network adapters to provide network adapter failover capabilities.
DNS provides name resolution and SRV record support. LDAP provides the ability to query the AD database, as well as update it. WINS is for NetBIOS name resolution, which is still required in most environments.
![What is IPD? ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Page |](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)