Determining Domain Controller Specifications andPlacement
Domain controllers are probably the single most important server type within your organization. Without them, you would not have a nice unified database that holds the objects used for authentication, stores application information, and provides centralized security control.
To have this functionality available to users, you need to determine where you will place domain controllers within your environment. This includes the domain controllers you will use primarily for authentication purposes, those designated as Global Catalog servers, and those that hold the master operations roles. You can start choosing the hardware you will use for a domain controller and then base the number of domain controllers required for each site on the hardware, or you can determine how many domain controllers and Global Catalog servers you would like to locate at each site and determine the hardware you will need to support the design. Finally, you will need to determine how the domain controllers will be created, because you may have domain controllers that will be installed in remote locations. You may not want to have the initial replication occur across a WAN link.
Determining Domain Controller Specifications
Although it is best to test the hardware you would like to use as domain controllers to determine how they perform when they are supporting users, some general guidelines, shown in Table 8.2, can give you an idea of how many domain controllers you will need to support your infrastructure. The values you find on the following pages are according to Microsoft s calculations. We decided to include them for a reference since there are many companies that are continuing to use their existing hardware instead of purchasing new systems. As a rule of thumb, always test your hardware before implementing the system. Newer processors, bus speeds, memory speeds and drive subsystems work more efficiently than the older technologies. As with anything, your mileage may vary.
| Number of Users | Processor(s) | Memory |
|---|---|---|
| 1 “499 | Single 866Mhz or faster | 512 MB |
| 500 “1499 | Dual 899Mhz or faster | 1 GB |
| 1500+ | Quad 899Mhz or faster | 2 GB |
If you use Table 8.2 to determine how many domain controllers are required to support the Newark campus in our example from earlier in the chapter, you will remember that there were 11,200 users within the Newark site. If you assumed that the hardware the company wants to purchase for domain controllers has dual 2000Mhz processors with 1GB of RAM each, then you would need to have at least 8 domain controllers. With the faster processors that you have included within the system, you will probably be able to exceed the recommendations in Table 8.2, but the memory or network subsystems may cause a bottleneck. Again, your best bet is to test the hardware that you plan on using to see what type of performance you can get out of it.
As far as the amount of drive space you will need to support your domain controller goes, there are also guidelines you can follow. For every 1000 users, you will need 0.4GB of disk space. For the 12,625 users of corp.com, you will need approximately 5.05GB of disk space.
As a rule of thumb, if the domain controller is also used as a Global Catalog server, you will need to have enough drive space to support half of the drive space requirements from each of the other domains. In a scenario where a company may have three domains ”DomainA with 10,000 users, DomainB with 18,000 users, and DomainC with 4,000 users ”the space requirements for each of the domains would work out as shown in Table 8.3.
| Domain | Domain Requirements (# Users/1000 * .4) | Total Space Required (Domain + (Total of Other Domains /2)) |
|---|---|---|
| DomainA | 4GB | 8.4GB |
| DomainB | 7.2GB | 10GB |
| DomainC | 1.6GB | 7.2GB |
You will need additional drive space for the transaction logs that are generated as the domain controller performs its functions. All transactions that occur on the domain controller are performed in memory. These transactions are written sequentially to the transaction logs so that the data is safeguarded in case the domain controller fails before the transaction is committed to the database.
Once you have determined what the server specifications for your domain controllers should be, you need to determine where they will be located. In the following section you will find the reasons for locating domain controllers in sites and what happens when a domain controller is not located in a user s site.
In the Calculating the Database Size Design Scenario, we are going to estimate the drive space requirements based upon the objects that will make up the Active Directory database.
 |
Argobot Mechanations is preparing to expand operations. They are in the process of upgrading their network infrastructure, which will implement Windows Server 2003 Active Directory as their directory service. Currently they have three divisions within their organization. The main division is their robotics line, which employs 4,500 people. The second division is the Research and Development department (R&D), which will become its own domain. R&D employs 500 users. Robotic Techs is the third division, and it operates as a subsidiary to Argobot Mechanations. This division employs 6,000 users and will also be a separate domain.
-
Question: When you are planning the drive space requirements for the domain controller, how much drive space will be consumed? Answer: Argobot Mechanations should have 1.8GB, R&D should have .2GB, and Robotic Techs should have 2.4GB.
-
Question: When planning the drive space requirements for the Global Catalog, how much drive space will be consumed? Answer: Argobot Mechanations should have 3.1GB, R&D should have 2.3GB, and Robotic Techs should have 3.4GB.
| |
Choosing Domain Controller Placement
Choosing where domain controllers will be placed can be difficult. You should take several things into consideration before deciding to place a domain controller at a location. Security, replication traffic, and user authentication should all be taken into account. When determining the placement at the design phase, some questions will help you determine which site the domain controller should be placed in:
Will the domain controller by physically secure at the location? If the domain controller will not be locked away, the computer could be physically attacked and the drives containing the database could be compromised. In some small organizations, this may not be as important a consideration as in large companies, but it should be considered nonetheless.
Can the domain controller be administered by local staff? If the staff members from the location do not have the ability to manage the domain controller, will you be able to provide remote access capabilities to the domain controller? Built-in tools allow an administrator to manage the domain controller remotely, and you need to determine if having those tools loaded is worth the trade-off of having the domain controller located at another location where it can be managed by local administrators. Make sure that your network infrastructure will allow you to connect to the remote servers because firewalls and connectivity issues could limit your access to the domain controllers.
Is the WAN link reliable? If the link is not reliable enough, you need to determine if you can get by without a domain controller for the site. We recommend that you do not allow for a site to be left without a domain controller if the WAN link is unreliable. However, if security concerns are greater than the users ability to authenticate for a short period of time, or the user base is small enough that you cannot justify the cost of a domain controller, you may choose to have them authenticate to a domain controller in another site away from the users.
If you are allowing authentication across the WAN link, is the logon performance acceptable? If it is, you should be able to host a site without a dedicated domain controller. However, if users are complaining about logon times, consider moving the domain controller to their site so that they can authenticate more efficiently. You may have to consider a trade-off between local authentication and replication traffic. Replication traffic in large domains or domains that have many Active Directory updates could consume too much of the available bandwidth. If the logon traffic is less than the replication traffic, it may make more sense to not locate the domain controller within the site.
You may encounter cases when domain controllers from the forest root will be placed within a site even though users from the forest root will not be authenticating within that site. If resources are located in another domain, having a domain controller from the forest root in the same site as the users will alleviate some of the WAN traffic caused by the Kerberos ticket passing that is going on. Of course, creating a shortcut trust between the domains that are affected may be a more efficient solution in a small environment, but locating a forest root domain controller within the site will alleviate traffic and the need for multiple shortcut trusts if there are several domains that the users are accessing.
After determining where the domain controllers should be placed, you should determine where Global Catalog servers are needed. The following section details the reasons for having a Global Catalog in a site.
Choosing Global Catalog Placement
Global Catalog servers provide functionality to users as well as applications within the domain. Global Catalog servers are responsible for collecting information about the objects that exist in the domain partition of other domains in the forest. Although this is just a subset of the attributes for the objects, this could still be a considerable amount of information. Once a domain controller is specified as a Global Catalog server, additional replication will occur so that information from the other domains will populate the database. You need to determine if this additional replication is going to affect the performance of the network links.
When determining if you should have a Global Catalog server placed within a site, you should consider how much the Global Catalog server will be used and whether applications within the site need to use a Global Catalog server. The following questions should be asked to determine whether or not a Global Catalog should be placed within a site:
Are there any applications, such as Exchange 2000 Server or Exchange Server 2003, located within the site? If this is the case, you will want to locate a Global Catalog server within the same site as the application since the LDAP queries being posted to the Global Catalog server will probably consume more bandwidth than replication. Test the network requirements to determine which will consume more bandwidth. If the WAN link is not 100 percent reliable, you should always have the Global Catalog server local, otherwise the application will not function properly when the link goes down.
Do you have more than 100 users located within the site? If you have more than 100 users within a site, you will need to determine if stranding them without having the ability to access a Global Catalog server if the WAN link goes down is an acceptable option. You will also need to determine if the query latency is worth the cost savings of keeping the Global Catalog server at another location and not dedicating hardware for the site in question.
Is the WAN link 100 percent available? If you do need application support and the user base is less than 100 users, you could have those users access a Global Catalog server in the remote site if the WAN link is reliable. Although no WAN link will ever be 100 percent available, the higher the reliability of the link, the better your chances of being able to support the user base from a remote site. If the WAN link is not always available and there are not any applications that rely on the Global Catalog server, you could implement universal group membership cacheing to alleviate some of the problems associated with user authentication.
Are there many roaming users who will be visiting the site? If many roaming users will be logging on at the site, you will want to locate a Global Catalog server within the site. Whenever a user logs on, the user s universal group membership is retrieved from the Global Catalog server. However, if the user population at the site is relatively static, you may be able to implement universal group membership cacheing on a domain controller.
One of the new features of Windows Server 2003 is universal group membership caching . This feature is only available when the domain is in the Windows 2000 Native mode or a higher functional level, and only Windows Server 2003 domain controllers provide this functionality. The benefit of using universal group membership cacheing is that a domain controller does not have to be made a Global Catalog server in order to provide the user with their universal group membership, which is required to log on. As users authenticate, the domain controller contacts a Global Catalog server from another site to retrieve the required information. The group membership is then cached on the domain controller ready to be used the next time the user logs on. Because the domain controller does not have to provide Global Catalog services, replication across the WAN link is reduced.
Universal group membership cacheing is not meant for sites with large user populations, nor is it meant to be used where applications need to access a Global Catalog server. A maximum of 500 users is supported using this cacheing method. Also, the cached data is only updated every 8 hours. If you are planning on performing group membership changes on a regular basis, your users may not receive those changes in a timely manner. You can reduce the timeframe for updating the cache, but in doing so you will be creating more replication traffic on your WAN link. Make sure you weigh the trade-offs before you decide where you will place a Global Catalog server.
Another Active Directory technology whose location needs to be determined is the master operations roles. Because only specific servers support the master operations functions, you should know the criteria for their placement.
Choosing Master Operations Placement
Back in Chapter 4, Designing the Active Directory Domain Structure, we discussed the master operations roles and their functions within the forest. Due to the importance of the master operations, you should carefully choose where the domain controllers holding each of these roles are placed. The following sections discuss what guidelines you should take into consideration.
Operations Masters in a Single Domain Forest
Within a single domain forest, the infrastructure master does not play a very important role. As a matter of fact, its services are not used at all. Because you will not have any remote domains for the infrastructure master to compare domain information to, it will not matter if the domain controller is a Global Catalog server or not. In fact, in a single domain environment, all domain controllers could be enabled as Global Catalog servers because there will not be any additional replication costs.
By default, the first domain controller within the domain will hold all of the master operations roles and will also be a Global Catalog server. You should also designate another domain controller as a standby server. You do not have to configure anything special on this domain controller. Just make sure that all administrative personnel are aware of your preference to use a specific server as the standby in case the first fails. Then, if a failure of the first server does occur, you can quickly seize the master operations on the second server. Make sure that the two systems are located close to one another and connected via a high-speed connection. You could even create connection objects between the two systems so that they replicate directly to one another, ensuring that their directories are as identical as possible.
Operations Masters Site Placement in a Multiple Domain Forest
The five master operations roles will have to be placed on domain controllers where they will be the most effective. You should take certain criteria into consideration when you are deciding on which site these domain controllers will be placed.
Schema Master
The schema master role is not one that is used very often. Typically, the only time the schema master needs to be online after the initial installation of Active Directory is when you are making changes to the schema. When you are planning the placement of the schema master, place it in a site where the schema administrators have easy access to it. Also take into consideration the replication that will be incurred when a change is made. For this reason alone you may want to place the schema master within a site that has the most domain controllers within the forest.
Domain Naming Master
As with the schema master, the domain naming master is not used very often. Its role is to guarantee the uniqueness of domain names within the forest. It is also used when removing domains from the forest. For the domain naming master to perform its function, you should locate it on a global catalog server, although with Windows Server 2003 this is not a requirement as it was in Windows 2000.
The domain naming master and the schema master can be located on the same domain controller since neither of the roles will impact the way the domain controllers function. And as with the schema master, it should be located close to where the administrative staff can access.
Relative Identifier (RID) Master
The RID master is responsible for generating and maintaining the RIDs used by the security principles within the domain. Each domain controller will contact the RID master to obtain a group of RIDs to be used as the accounts are created. If your domain is in native mode or higher, you should place the RID master in a site that has domain controllers where administrators are creating a majority of the accounts. This will allow the RID master to efficiently hand out allocations of RIDs to the domain controllers. If your domain is in mixed mode, consider placing the RID master on the same server as the PDC emulator. The PDC emulator is the only domain controller that can create accounts within the domain when the domain is in mixed mode.
Infrastructure Master
The infrastructure master holds a very important role within a multiple domain forest. If users from one domain are added to the membership of groups from a second domain, the infrastructure master is then responsible for maintaining any updates when changes occur within the remote domain.
For instance, if a user from domain A is added to a group in domain B, and the user s name changes because she gets married, the user account name in domain A does not match the entry within the group membership of domain B. The infrastructure master is responsible for reviewing the information from domain A and checking for discrepancies. If it finds that a change has been made, the infrastructure master updates the information in domain B so that the new name information within the group can be replicated to all of the domain controllers.
If the infrastructure master is located on a Global Catalog server, it will check for differences between domain A and domain B, but it will not notice any discrepancies because the Global Catalog server hosts information from domain A. Other servers that are not Global Catalog servers in domain B will not have the correct information for the group, and the infrastructure master will not update the other domain controllers. So, in a multiple domain forest, move the infrastructure master to a domain controller that is not a Global Catalog server. Of course, if you make every domain controller a Global Catalog server, you will not have to worry about the infrastructure master placement because every domain controller will host information from every domain and replicate changes whenever they are made.
When you are choosing the placement of the infrastructure master, place it within a site that also contains domain controllers from the other domains. This ensures that the queries and updates performed are local.
Primary Domain Controller (PDC) Emulator
The other master operations role that you need take into consideration is the Primary Domain Controller (PDC) emulator. Whenever Windows NT 4 Backup Domain Controllers (BDCs) exist within the domain, the PDC Emulator is responsible for keeping the Windows NT 4 BDCs and all other Windows 2000 Server or Windows Server 2003 domain controllers updated. The PDC emulator is also responsible for accepting password change requests from pre “Active Directory clients . If the domain is placed in Windows 2000 Native mode or the Windows Server 2003 functional level, the PDC emulator becomes the clearinghouse for password changes within the domain. Any time another domain controller receives a password change from a client, the PDC emulator is passed the change so that the other domain controllers can be notified of the change. If a user has entered a bad password, the PDC emulator is passed the authentication request to validate that the user s password was not changed on another domain controller prior to the authentication request.
Another important function of the PDC Emulator is time synchronization. All members of the domain, whether they are running Windows 2000, Windows XP or Windows Server 2003 as their operating system will synchronize their clocks according to time on the PDC emulator and use the timestamp to authenticate clients. This timestamp is then used with the Kerberos service to authenticate clients.
When deciding the most appropriate site for the PDC emulator role, choose a site that is close to the majority of users within the domain. Also, make sure that domain controllers placed in other sites have reliable links and available bandwidth to support the traffic that will be used by the PDC emulator.
The section that follows describes the options available when you are building domain controllers to support users and applications within the site topology that we have been designing.
Determining Domain Controller Creation Options
You have two options when creating domain controllers. The first option is to promote the member server to a domain controller and allow replication of the Active Directory objects to occur across the network. This is the default method and is the easiest to perform. The administrator who has the ability to promote the system to a domain controller only needs to provide the information required by the wizard. The promotion can even be automated so that the administrator will only have to provide the path to the answer file that contains the settings necessary to create the domain controller.
Promoting the domain controller and allowing the objects to be replicated works well because the data is up-to-date as soon as the replication is complete. However, this replication could cause a lot of network traffic. If this is the choice that you make, be sure that you have a high-speed connection between the two domain controllers where replication is occurring. If you are trying to build a domain controller within a remote site and the nearest domain controller is across a WAN link, replicating the objects may not be an option. You may need to perform the second option.
| |
Becca is the manager of the information technology division of an art supply retailer. The company has their headquarters in St. Louis, MO, and has five regional distribution centers. Each of the distribution centers services anywhere from 20 to 45 retail outlets. Each of the regional distribution centers hosts an Exchange Server 2003 server and an SQL 2000 Server database server. Some of the larger retail outlets, those with more than 200 employees, also host their own Exchange and SQL servers. Retail outlets that have fewer than 200 employees rely on the servers at the regional distribution center for e-mail and database services but will have a local domain controller to authenticate them.
After identifying the sites and the domain controllers that are going to be placed within each site, Becca devises a plan for the domain controller creation at each site. After installing the domain controllers at the company headquarters, she performs a system state backup of a Global Catalog server and stores the backup on a share on the network. Servers that will be used for domain controllers at the regional distribution centers and retail outlets are all delivered to the regional distribution center that services them.
During the night, the backup data is transferred to servers at the regional distribution centers. The following morning, the administrative staff at each of the regional distribution centers is told how to perform their domain controller promotion. Each server will be promoted using the advanced mode of dcpromo and the backed -up system state data will be chosen . Because each of the regional distribution centers will host Exchange Server 2003, the domain controllers at each will also be Global Catalog servers.
The administrators from the regional distribution center will then be responsible for building the domain controllers for the retail outlets. Because each of the retail outlet domain controllers will be identical, an answer file is created that will automate the domain controller creation. Once the domain controllers are ready, they will be shipped to the retail outlets where they can be connected to the network.
| |
The second option is to perform what is referred to as an advanced install of Active Directory. An advanced install is initiated by using the dcpromo /adv switch when you are promoting a Windows Server 2003 system to a domain controller. When you are using the advanced mode, you use the system state information from an existing domain controller within the domain as the initial data to populate Active Directory. Once the initial population is finished, standard Active Directory replication updates the domain controller bringing it up-to-date. Using the advanced mode will drastically reduce the amount of data that will have to pass across a WAN link to the new domain controller.
If the system state information was taken from a Global Catalog server, you will be prompted to answer whether you would like the new domain controller to become a Global Catalog server. If you select Yes, a new Global Catalog server will be created. If you select No, only the objects for the local domain will be loaded onto the new domain controller. Do note that the system state backup that you are using to create the new domain controller cannot be older than the tombstone lifetime to ensure that old objects are not regenerated into the domain. The tombstone lifetime is the amount of time that a deleted object will remain within Active Directory. By keeping a deleted item within Active Directory, the object can be marked for deletion on all domain controllers before it is purged.
| Tip | The older the backup media that contains the system state, the more replication that will occur when the data is restored. Make sure you back up the data regularly. |
EAN: 2147483647
Pages: 159