Deploying Windows Server 2012 and Windows Server 2012 R2 Domain Controllers

  • 4/24/2014
Contents

Lesson 1: Preparing for deploying domain controllers

Careful planning is critical when you roll out or make changes to an AD DS environment by adding, replacing, or upgrading domain controllers. A number of different scenarios are possible, and you should identify best practices for each scenario you need to implement for your organization. This lesson describes some common AD DS deployment scenarios and the different ways that you can deploy domain controllers for these scenarios.

After this lesson, you will be able to:

  • Describe some common AD DS deployment scenarios.
  • Describe different ways Windows Server 2012 and Windows Server 2012 R2 domain controllers can be deployed in a new forest.
  • Describe different ways Windows Server 2012 and Windows Server 2012 R2 domain controllers can be deployed in an existing forest running earlier versions of Windows Server.

Estimated lesson time: 30 minutes

AD DS deployment scenarios

There are two basic scenarios for AD DS deployment:

  • Deploying a new forest based on AD DS in Windows Server 2012 or Windows Server 2012 R2
  • Deploying domain controllers in an existing forest based on AD DS in an earlier version of Windows Server

The sections that follow describe the high-level differences between these scenarios.

New forest deployments

If your organization has not yet deployed AD DS, you’re in luck: this is your opportunity to get it right. Although deploying a new forest based on Windows Server 2012 or Windows Server 2012 R2 AD DS is as simple as deploying your first domain controller (the forest root domain controller), there are numerous planning considerations you need to be aware of before you perform this task.

At a basic level, the technical requirements for deploying your forest root domain controller are straightforward:

  • You must have local Administrator credentials on the server.
  • You must have one or more local fixed NTFS volumes to store the directory database, log files, and SYSVOL share.
  • You need to appropriately configure TCP/IP settings, including Domain Name Server (DNS) server addresses.
  • You either need to use an existing DNS server infrastructure or deploy the DNS Server role with the Active Directory Domain Services role when you make your server a domain controller.

The preceding technical requirements, however, are only a small part of the overall AD DS planning process. The key at this stage is to plan the entire directory structure of your organization so that you won’t need to make drastic changes later, like renaming domains or modifying your hierarchy of OUs. The details of such planning are well beyond the scope of this book, but for readers who are interested, the “More Info” topic in this section highlights some resources that can help you design an effective AD DS infrastructure and plan for its implementation.

After you create your forest by deploying the forest root domain controller, you can deploy additional controllers for the following purposes:

  • Deploy additional domain controllers in your forest root domain for redundancy and load-balancing purposes.
  • Deploy domain controllers that create additional domains within your forest based on your organization’s administrative or geographical structure.
  • Deploy read-only domain controllers (RODCs) at less secure, branch office sites within your organization.
  • Deploy virtualized domain controllers to provide greater support for private and public cloud-computing environments.

More Info: Resources for AD DS planning and design

The following resources can be helpful if you are planning an implementation of AD DS for the first time:

  • Designing and Deploying Directory and Security Services This section of the Windows Server 2003 Deployment Guide on Microsoft TechNet—found at http://technet.microsoft.com/en-us/library/cc787010(v=WS.10).aspx—is a bit dated, but it’s still a good starting point to learn how to design and plan an AD DS environment. Be sure to supplement this resource, however, with the more recent resources that follow.
  • AD DS Design Guide This section of the TechNet Library—found at http://technet.microsoft.com/en-us/library/cc754678(v=ws.10)—provides updated guidance on how to design an AD DS environment based on Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012. Apart from implementing new Windows Server 2012 R2 features like Workplace Join, the guidance in this document also applies to designing AD DS environments based on Windows Server 2012 R2.
  • Windows Server 2008 Active Directory Resource Kit from Microsoft Press This book provides an excellent introduction to basic AD DS concepts, design, and administration. The book is available from O’Reilly Media at http://shop.oreilly.com/product/9780735625150.do in various formats, including APK, DAISY, ePub, Mobi, PDF, and print-on-demand.

Finally, a good place to find answers to your AD DS questions is the Directory Services forum on TechNet at http://social.technet.microsoft.com/Forums/windowsserver/en-us/home?forum=winserverDS.

Best practices for new forest deployments

The actual number of domain controllers and the types needed for your environment depend on a number of factors, but here are some key best practices to keep in mind:

  • Each domain should have at least two functioning writeable domain controllers to provide fault tolerance. If a domain has only one domain controller and this domain controller fails, users will not be able to log on to the domain or access any resources in the domain. And if you have only one writable domain controller in your domain and this domain controller fails, you won’t be able to perform any AD DS management tasks.
  • Each domain in each location should also have a sufficient number of domain controllers to service the needs of users for logging on and accessing network resources. The TechNet sections described in the earlier “More Info” topic include some recommendations on how to determine the number of domain controllers you need based on their hardware configuration and the number of users at the location.
  • Domain controllers should be dedicated servers that are used only for hosting the AD DS and DNS Server roles. Their full attention should be directed to performing their main job, which is authenticating users and computers for client logons and for accessing network resources.
  • The simplest forest design has one domain. The more domains you have, the more administrative overhead you will experience managing multiple service administrator groups, maintaining consistency among Group Policy settings that are common to different domains, maintaining consistency among access control and auditing settings that are common to different domains, and so on.
  • If your organization has multiple sites, such as a head office and one or more remote branch offices, you should generally deploy at least one domain controller at each remote office to provide users with faster logon times and more efficient access to network resources. For best security, domain controllers at remote offices should be RODCs.

Existing forest deployments

Most readers of this book will likely deploy new Windows Server 2012 or Windows Server 2012 R2 domain controllers in an existing Active Directory infrastructure based on Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003. There are several ways you can introduce such changes:

  • Deploying new Windows Server 2012 or Windows Server 2012 R2 domain controllers in an existing forest whose domain controllers are running an earlier version of Windows Server
  • Upgrading domain controllers running earlier versions of Windows Server to Windows Server 2012 or Windows Server 2012 R2

These scenarios will be discussed later in this lesson.

Important: End of support date for Windows Server 2003

Windows Server 2003 exited mainstream support in July 2010 and will exit extended support in July 2015, so if you are planning to upgrade your AD DS environment to Windows Server 2012 or Windows Server 2012 R2, you should do it before mainstream support ends unless you have an extended support agreement with Microsoft.

New forest domain controller deployment

Depending on the administrative and geographical structure of your organization and the number of users to be supported, deploying a new forest based on Windows Server 2012 or Windows Server 2012 R2 AD DS might involve several of the following domain controller deployment scenarios:

  • Deploying the first domain controller in a new forest (required)
  • Deploying the first domain controller for a new domain (required if additional domains need to be created in the forest)
  • Deploying additional domain controllers in each domain to provide fault tolerance and support the number of users at each location (recommended)
  • Deploying read-only domain controllers (RODCs) at remote branch office locations (recommended)
  • Deploying virtualized domain controllers (not recommended for most production environments)

The sections that follow provide some additional information on each of these deployment scenarios.

First domain controller in a new forest

Installing the first domain controller in a new forest requires that you be logged on as the local Administrator of the server. You can do this using either Server Manager or Windows PowerShell, as demonstrated in Lessons 2 and 3 of this chapter.

Regardless of which method you use for deploying the first domain controller in your forest root domain, you need to provide the following information:

  • Domain name Enter the fully qualified domain name (FQDN) for the root domain of your new forest—for example, corp.contoso.com.
  • Domain NetBIOS name Enter the NetBIOS name for your new forest (required if the FQDN prefix name is longer than 15 characters).

  • Forest functional level Select one of the following:

    • Windows Server 2003
    • Windows Server 2008
    • Windows Server 2008 R2
    • Windows Server 2012 (the default for Windows Server 2012)
    • Windows Server 2012 R2 (the default for Windows Server 2012 R2 and not available for Windows Server 2012)

  • Domain functional level Select one of the following:

    • Windows Server 2003
    • Windows Server 2008
    • Windows Server 2008 R2
    • Windows Server 2012 (set to the selected forest functional level in Windows Server 2012)
    • Windows Server 2012 R2 (set to the selected forest functional level in Windows Server 2012 R2 and not available for Windows Server 2012)
  • Directory Services Restore Mode (DSRM) password You must specify this at the time the server is promoted to a domain controller.
  • DNS Server Indicate whether the new domain controller should also be a DNS server (recommended).
  • Database folder Specify where the AD DS database is stored. (The default location is %windir%\NTDS.)
  • Log files folder Specify where the AD DS log files are stored. (The default location is %windir%\NTDS.)
  • SYSVOL folder Specify where the AD DS SYSVOL share is located. (The default is %windir%\SYSVOL.)

A new feature of deploying Windows Server 2012 and Windows Server 2012 R2 domain controllers is a validation phase that is performed just prior to the promotion process. As Figure 4-1 illustrates, this validation phase invokes a series of tests that check whether all necessary prerequisites have been met to ensure that the domain controller deployment operation will succeed. You can bypass this prerequisite check when deploying domain controllers using Windows PowerShell, but doing this is not recommended.

FIGURE 4-1

FIGURE 4-1 This is the new validation phase that occurs during domain controller promotion using Server Manager.

Real World: Domain controllers and DNS servers

Unless your organization uses a third-party DNS server such as BIND on your internal network, you should always have all your domain controllers also function as DNS servers to ensure high availability in distributed environments. By default, when you install the AD DS role on a server and then promote the server to a domain controller, the DNS Server role is automatically installed and configured.

First domain controller in a new domain

After the first domain of the forest (that is, the forest root domain) has been created, new child domains or tree domains can be created if your AD DS design warrants doing so. Installing the first domain controller for a new child domain or tree domain requires supplying the credentials of a member of the Enterprise Admins security group, which is one of two new security groups (the other is the Schema Admins group) that AD DS creates when the forest root domain controller is deployed.

Deployment of domain controllers for new child domains or tree domains can be performed remotely using Server Manager or Windows PowerShell. The required information is similar to that listed in the previous section, with the addition of the following:

  • Domain type Specify whether to create a new child domain or a new tree domain.
  • Parent domain name Enter the name of the parent domain of which the new child or tree domain will be a subdomain.
  • DNS delegation Specify whether to create a DNS delegation that references the new DNS server you are installing with the domain controller. (The default is determined automatically based on your environment.)

Additional domain controllers in a domain

After you create a domain by deploying its first domain controller, you can deploy additional domain controllers to provide fault tolerance and support the number of users at the location. Installing additional domain controllers in a domain requires supplying the credentials of a member of the Domain Admins security group for that domain.

You can perform deployment of additional domain controllers for a domain by using Server Manager or Windows PowerShell. The information you will be required to provide is similar to that listed in the previous section, with the addition of the following:

  • Site name Specify the name of the AD DS site to which the domain controller should be added.
  • Global catalog Specify whether the new domain controller should host the global catalog.
  • Replication source Specify an existing domain controller to be used as the initial replication partner for replicating a copy of the directory database to the new domain controller. (The default is any available domain controller.)
  • Application partitions to replicate Specify application partitions on existing domain controllers that should be replicated to the new domain controller.
  • Install from media path You can choose to install the new domain controller using backed-up media by means of the Install From Media (IFM) deployment option.

Real World: Domain controllers and the global catalog

The global catalog contains a searchable, partial representation of every object in every domain in the forest. You can use the global catalog to quickly locate objects from any domain in the forest without having to know the name of the domain. All your domain controllers should also function as global catalog servers to ensure high availability in distributed environments. By default, when you promote a server to a domain controller, the new domain controller is automatically configured as a global catalog server.

Read-only domain controllers

key.jpg

Read-only domain controllers (RODCs) are additional domain controllers for a domain and are intended mainly for deployment in branch office environments that have relatively few users, few or no IT staff, and slow wide area network (WAN) connectivity with the head office, and in environments that lack the level of physical security controls available at a typical head office.

RODCs host read-only partitions of the AD DS database. Clients can authenticate against an RODC but cannot write directory changes to it. RODCs include additional safeguards that help ensure any information on the RODC remains confidential if it is stolen or if its security is compromised.

You can remotely perform deployment of an RODC by using Server Manager or Windows PowerShell. Deploying an RODC requires the following:

  • Availability of credentials of a member of the Domain Admins for the domain
  • A forest functional level of Windows Server 2003 or later
  • At least one writable domain controller running Windows Server 2008 or later installed in the domain

More Info: Deploying RODCs

More information on how to plan the deployment of RODCs can be found in the TechNet Library at http://technet.microsoft.com/en-us/library/cc771744(v=ws.10).

Real World: RODC on Server Core installations

Beginning with Windows Server 2008 R2, RODCs can be deployed on Windows Server Core installations. Doing this helps further reduce the attack surface of your RODCs and lower their maintenance requirements. Refer to Chapter 2, “Deploying servers,” for information on how to convert a Server With A GUI installation of Windows Server 2012 or Windows Server 2012 R2 to a Server Core installation.

Virtualized domain controllers

key.jpg

Virtualized domain controllers are domain controllers running in virtual machines on Hyper-V hosts. Beginning with Windows Server 2012, new capabilities were introduced that help make domain controller virtualization much safer and less prone to problems than with previous Windows Server versions. For more information, see the following “Real World” topic.

Real World: Virtualizing domain controllers

Windows Server 2012 and Windows Server 2012 R2 help enable cloud computing by making virtualized domain controllers both easier to deploy and less prone to problems. For example, you can deploy replica virtual domain controllers by cloning existing virtual domain controllers and then deploying them using Server Manager or Windows PowerShell. Virtualizing domain controllers is also much safer than it was with previous versions of Windows Server. That’s because each virtual domain controller has a unique identifier called a GenerationID that is exposed to the hypervisor on the host machine. This helps protect the AD DS directory hosted by a virtual domain controller from unexpected rollback events caused by the accidental application of snapshots or other occurrences that caused duplicate directory objects and other issues in previous Windows Server versions.

For more information about these different improvements, see the section “Virtualization that just works” in the topic “What’s New in Active Directory Domain Services (AD DS)” in the TechNet Library at http://technet.microsoft.com/en-us/library/hh831477#BKMK_VirtualizationJustWorks.

tick.jpg Quick check

  • What are the minimum credentials you need to deploy an additional domain controller in an existing domain of a forest?

    Quick check answer

  • The minimum credentials you need are those for a member of the Domain Admins security group in the target domain. You could also use the credentials of a member of the Enterprise Admins or Schema Admins group, but these credentials should generally be used only for managing the forest root domain and schema.

Windows Azure Active Directory

Deploying your Active Directory infrastructure on-premises isn’t the only option available for today’s businesses. Windows Azure Active Directory (Windows Azure AD) is a cloud-based version of Active Directory that provides a subset of the functionality of the familiar Active Directory Domain Services (AD DS) that so many businesses around the world use as their identity and access control solution.

Windows Azure AD provides a cloud-based identity provider that can integrate into your on-premises AD DS deployments. Windows Azure AD is also the identity solution used by Microsoft Online Services such as Windows Azure, Microsoft Office 365, Dynamics CRM Online, and Windows Intune. Because of these things and because of its ability to integrate with web identity providers like Microsoft Account and popular third-party providers like Google, Yahoo!, and Facebook, Windows Azure AD can provide single sign-on for users across Microsoft Online Services, third-party cloud services, and applications built on Windows Azure.

Using Windows Azure AD

When you log on to the Windows Azure Management Portal for the first time and select the Active Directory tab on the left, an item called the Default Directory appears as Active for your subscription, as shown here:

163fig01.jpg

Click to view larger image

If you click Default Directory, a page similar to this opens:

163fig02.jpg

Click to view larger image

As you can see from the above screenshot, you can use this page of the Management Portal to create and manage new user accounts, add applications and manage access to them, and perform other identity management tasks.

For more detailed information on what Windows Azure Active Directory is and how to get started using it, see http://www.windowsazure.com/en-us/documentation/services/active-directory/.

Deploying Active Directory using Windows Azure Virtual Machines

Windows Azure also supports other ways of deploying Active Directory in the cloud. For example, you can deploy an entire Active Directory forest in a self-contained manner using Windows Azure Virtual Machines. Another identity and access control scenario that Windows Azure supports is a hybrid deployment in which you deploy an organization’s domain controllers partly on-premises and partly on Windows Azure Virtual Machines.

For more information on these types of deployment scenarios, see “Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines,” which can be found at http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx.

Existing forest domain controller deployment

There are two basic ways of deploying Windows Server 2012 or Windows Server 2012 R2 domain controllers in a forest whose domain controllers are running Windows Server 2008 R2 or earlier:

  • Installing additional domain controllers running Windows Server 2012 or Windows Server 2012 R2
  • Upgrading existing domain controllers running earlier versions of Windows Server

The sections that follow provide more details about these approaches.

Installing additional domain controllers

Installing additional domain controllers running Windows Server 2012 or Windows Server 2012 R2 in a forest whose domain controllers are running an earlier version of Windows Server involves the following steps:

  1. Install Windows Server 2012 or Windows Server 2012 R2 on the servers that will become the new domain controllers.
  2. Join the new servers to the domain.
  3. Use Server Manager or Windows PowerShell to install the AD DS role on the new servers and then promote them to domain controllers.

Once deployed, the new Windows Server 2012 or Windows Server 2012 R2 domain controllers can coexist with the domain controllers running earlier versions of Windows Server if you want them to. Alternatively, you can move the Flexible Single Master Operations (FSMO) roles from the earlier domain controllers that are running earlier versions of Windows Server to the new domain controllers that are running Windows Server 2012 or Windows Server 2012 R2. Then you can finally demote and retire the earlier domain controllers.

NOTE: Preparing the schema

Introducing Windows Server 2012 or Windows Server 2012 R2 domain controllers into a forest whose domain controllers are running earlier versions of Windows Server automatically causes the AD DS schema to be extended to the latest version. See Lesson 2 for more information on extending the schema.

Upgrading domain controllers running Windows Server 2008 R2 or earlier

Upgrading all of a forest’s existing domain controllers that are running Windows Server 2008 R2 or earlier to Windows Server 2012 or Windows Server 2012 R2 involves the following steps:

  1. Prepare your forest and domains for an upgrade by using either the Windows Server 2012 or Windows Server 2012 R2 version of the Adprep.exe command-line tool (depending on which version of Windows Server you are upgrading to) to extend your Active Directory schema. (See Lesson 2 for more information about Adprep.)
  2. Verify that the operating system of your existing domain controllers has a supported in-place upgrade path to Windows Server 2012 or Windows Server 2012 R2.
  3. Verify all prerequisites for upgrading your existing domain controllers to Windows Server 2012 or Windows Server 2012 R2. For example, the drive that hosts the AD DS database (NTDS.DIT) must have at least 20 percent free disk space before you begin the operating system upgrade.
  4. Perform an in-place upgrade of your existing domain controllers to Windows Server 2012 or Windows Server 2012 R2.

Upgrading Windows Server 2012 domain controllers to Windows Server 2012 R2

Upgrading all of a forest’s existing domain controllers that are running Windows Server 2012 to Windows Server 2012 R2 involves the following steps:

  1. Prepare your forest and domains for an upgrade by using the Windows Server 2012 R2 version of the Adprep.exe command-line tool to extend your Active Directory schema. (See Lesson 2 for more information about Adprep.)
  2. Verify all prerequisites for upgrading your existing domain controllers to Windows Server 2012 R2. For example, the drive that hosts the AD DS database (NTDS.DIT) must have at least 20 percent free disk space before you begin the operating system upgrade.
  3. Perform an in-place upgrade of your existing domain controllers to Windows Server 2012 R2.

More Info: Prerequisites for upgrading domain controllers

For more information about supported upgrade paths and other prerequisites for performing in-place upgrades of domain controllers running earlier versions of Windows Server to Windows Server 2012 and Windows Server 2012 R2, see the topic “Upgrade Domain Controllers to Windows Server 2012” in the TechNet Library at http://technet.microsoft.com/en-us/library/hh994618. See also “Determine Domain Controller Upgrade Order” at http://technet.microsoft.com/en-us/library/cc732085(WS.10).aspx.

Lesson summary

  • The two main AD DS deployment scenarios are deploying new forests using Windows Server 2012 or Windows Server 2012 R2 and deploying domain controllers into existing forests running earlier versions of Windows Server.
  • Be sure to gather the necessary information and credentials before deploying AD DS and complete any other steps needed to prepare your environment before deploying domain controllers.
  • The process of promoting member servers running Windows Server 2012 or Windows Server 2012 R2 as domain controllers includes a prerequisites check to ensure the promotion process can succeed.
  • The process of promoting member servers running Windows Server 2012 or Windows Server 2012 R2 as domain controllers automatically runs Adprep when needed to prepare a forest and domains running earlier versions of Windows Server.
  • You still need to run Adprep manually if you are performing in-place upgrades of domain controllers running earlier versions of Windows Server.

Lesson review

Answer the following questions to test your knowledge of the information in this lesson. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

  1. Which of the following is not a best practice for performing new forest deployments?

    1. Ensure that each domain has at least two domain controllers to provide fault tolerance and ensure availability. Only one of these domain controllers needs to be writeable; the other can be an RODC.
    2. Make sure that each site in your domain has a sufficient number of domain controllers to service the needs of users for logging on and accessing network resources.
    3. Whenever possible, keep the design of your forest simple by having only one domain.
    4. Install only the AD DS and DNS Server roles on your domain controllers; do not install any other server roles.

  2. Which of the following information should you obtain or decide upon during the planning stage of deploying the first Windows Server 2012 or Windows Server 2012 R2 domain controller in a new forest? (Choose all that apply.)

    1. The fully qualified domain name (FQDN) for the root domain of your new forest
    2. The forest and domain functional levels
    3. The location for the AD DS database, log files, and SYSVOL folder
    4. The credentials of a member of the Domain Admins security group

  3. Which of the following is not true? (Choose all that apply.)

    1. Creating a DNS delegation is a required step for all AD DS deployments.
    2. All domain controllers in a domain should have the DNS Server role installed and configured to ensure high availability in distributed environments.
    3. All domain controllers in a domain should be configured as global catalog servers to ensure high availability in distributed environments.
    4. Read-only domain controllers require that there be at least one writeable domain controller running Windows Server 2003 or later installed in the domain.
Save to your account

This chapter is from the book