Active Directory Administrator's Pocket Consultant: Deploying Writable Domain Controllers
- 1/14/2009
- Preparing to Deploy or Decommission Domain Controllers
- Adding Writable Domain Controllers
- Decommissioning Domain Controllers
- Forcing the Removal of Domain Controllers
Preparing to Deploy or Decommission Domain Controllers
Adding Writable Domain Controllers
Decommissioning Domain Controllers
Forcing the Removal of Domain Controllers
In this chapter, I provide tips and techniques for adding and removing writable domain controllers. After setting up the initial domain controller in a domain, you deploy additional domain controllers to increase fault tolerance and improve operational efficiency. Just as you establish a server as a domain controller by installing Active Directory Domain Services (AD DS), you decommission a domain controller by removing AD DS. The decommissioned domain controller can then be taken out of service, or it can act as a server.
Preparing to Deploy or Decommission Domain Controllers
Before deploying or decommissioning domain controllers, you should create a plan that lists any prerequisites, necessary postmodification changes, and overall impact on your network. Create your plan by reviewing “Preparing for Active Directory Installation” in Chapter 2.
Domain controllers host the Active Directory database and handle related operations. Active Directory uses a multimaster replication model that creates a distributed environment where no single domain controller is authoritative with regard to logon and authentication requests. This model allows any domain controller to be used for logon and authentication. It also allows you to make changes to standard directory information without regard to which domain controller you use.
Domain controllers also can have special roles as operations masters and global catalog servers. As discussed in Chapter 5, operations masters perform tasks that can be performed only by a single authoritative domain controller. Global catalog servers store partial replicas of data from all domains in a forest to facilitate directory searches for resources in other domains and to determine membership in universal groups.
When you establish the first domain controller in a forest, the domain controller hosts the forestwide and domainwide operations master roles and also acts as the global catalog server for the domain. When you establish the first domain controller in a domain, the domain controller hosts the domainwide operations master roles and also acts as the global catalog server for the domain.
Every domain in the enterprise should have at least two domain controllers. If a domain has only one domain controller, you could lose the entire domain and all related accounts if disaster strikes. Although you may be able to recover the domain from a backup, you will have significant problems until the restore is completed. For example, users may not be able to log on to the domain or obtain authenticated access to domain resources.
Every site should have at least one domain controller. If a domain controller is not available in a site, computers in the site will perform logon and authentication activities with domain controllers in another site, which could significantly affect response times.
Every site should have a global catalog server. If a global catalog server is not available in a site, computers in the site will query a global catalog server in another site when searching for resources in other domains in the forest. Global catalog servers are also used during logon and authentication because they store universal group membership information for all domains in the forest. If a global catalog server isn’t available in the site and the universal group membership has not been previously cached, the domain controller responding to a user’s logon or authentication request will need to obtain the required information from a global catalog server in another site.