Training Guide Installing and Configuring Windows Server 2012 R2 (2014)
Chapter 4. Deploying domain controllers
Active Directory Domain Services (AD DS) provides a distributed database and directory service that stores and manages information about the users, computers, groups, shares, printers, and other types of objects that comprise an organization’s IT infrastructure. With AD DS, you can create the following:
A forest that acts as the security boundary for your organization
One or more domains that define the scope of authority of administrators in your organization
A hierarchical collection of organizational units (OUs) to simplify delegation of authority for managing directory objects
Sites that map to the structure of your organization’s network
Domain controllers are servers that host AD DS within your infrastructure, and the process for deploying domain controllers has been enhanced in several ways beginning with Microsoft Windows Server 2012. The Active Directory Domain Services Configuration Wizard (dcpromo.exe) used in previous Windows Server versions has been replaced with a new Active Directory Domain Services Configuration Wizard that simplifies the task of deploying new domain controllers to help reduce the possibility of error. Windows PowerShell now provides a way of scripting all aspects of domain controller deployment, making it possible to automate the mass deployment of domain controllers in data center environments. Safeguards have also been introduced so that you can safely virtualize domain controllers, which simplifies deployment of private and public cloud solutions.
Windows Server 2012 R2 introduced several more enhancements to Active Directory, the most important of which is Workplace Join. Workplace Join enables information workers to join their personal devices to the Active Directory infrastructure of their company to access company resources and services from these devices. Workplace Join is enabled by means of a new Device Registration Service (DRS) included in the Active Directory Federation Role in Windows Server 2012 R2. Administrators can use Workplace Join to identify known devices with device authentication and can then provide these devices with conditional access to resources. The result for users is a more seamless Single Sign-On experience to company resources from trusted devices.
This chapter describes how to prepare for the deployment of Windows Server 2012 and Windows Server 2012 R2 domain controllers, how to deploy domain controllers using both Server Manager and Windows PowerShell, and how to take advantage of domain-controller virtualization.
Lessons in this chapter:
Lesson 1: Preparing for deploying domain controllers
Lesson 2: Deploying domain controllers using Server Manager
Lesson 3: Deploying domain controllers using Windows PowerShell
Before you begin
To complete the practice exercises in this chapter
You need at least two servers that have a clean install of Windows Server 2012 R2 and are configured as stand-alone servers in a workgroup. They can be either physical servers or virtual machines, and their TCP/IP settings should be configured to provide connectivity with the Internet.
You might need additional servers to perform some of the optional exercises in the “Suggested practice exercises” section. You might also need access to installation media for earlier Windows Server versions for some of these exercises.
You should be familiar with basic AD DS concepts such as forests, domains, organizational units (OUs), sites, domain controllers, schema, replication, and so on.
It will be helpful if you also have at least rudimentary knowledge of using Windows PowerShell.
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 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
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
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.
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:
If you click Default Directory, a page similar to this opens:
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. (SeeLesson 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?
A. 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.
B. 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.
C. Whenever possible, keep the design of your forest simple by having only one domain.
D. 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.)
A. The fully qualified domain name (FQDN) for the root domain of your new forest
B. The forest and domain functional levels
C. The location for the AD DS database, log files, and SYSVOL folder
D. The credentials of a member of the Domain Admins security group
3. Which of the following is not true? (Choose all that apply.)
A. Creating a DNS delegation is a required step for all AD DS deployments.
B. All domain controllers in a domain should have the DNS Server role installed and configured to ensure high availability in distributed environments.
C. All domain controllers in a domain should be configured as global catalog servers to ensure high availability in distributed environments.
D. Read-only domain controllers require that there be at least one writeable domain controller running Windows Server 2003 or later installed in the domain.
Lesson 2: Deploying domain controllers using Server Manager
Server Manager provides an easy way to deploy Windows Server 2012 and Windows Server 2012 R2 domain controllers. Server Manager is mainly intended for managing small and midsized environments where the automation of domain controller deployment is not required. This lesson demonstrates how to use Server Manager to deploy domain controllers in both new and existing forests.
After this lesson, you will be able to:
Use Server Manager to prepare your Windows Server 2012 or Windows Server 2012 R2 environment for domain controller deployment.
Install the Active Directory Domain Services role using the Add Roles And Features Wizard of Server Manager.
Promote servers to domain controllers using the Active Directory Domain Services Configuration Wizard of Server Manager.
Verify the promotion of servers to domain controllers.
Demote domain controllers and remove the Active Directory Domain Services role.
Estimated lesson time: 30 minutes
Preparing for domain controller deployment
The steps for preparing to deploy Windows Server 2012 or Windows Server 2012 R2 domain controllers using Server Manager differ depending on whether you are deploying the first domain controller in a new forest, deploying additional domain controllers in the new forest, or deploying domain controllers in an existing forest whose domain controllers are running an earlier version of Windows Server.
Preparing for deploying the first domain controller in a new forest
To deploy the first Windows Server 2012 or Windows Server 2012 R2 domain controller in a new forest using Server Manager, you should either log on locally to the server or connect to it using Remote Desktop. No other preparation is needed for this scenario.
Preparing for deploying additional domain controllers in the new forest
After you create a new forest by deploying your first Windows Server 2012 or Windows Server 2012 R2 domain controller, you can use Server Manager to deploy additional domain controllers in an existing domain, create new child domains, or create new tree domains. You can perform these tasks remotely by using Server Manager on any Windows Server 2012 or Windows Server 2012 R2 domain controller or member server or on a Windows 8 or Windows 8.1 client computer that has the appropriate version of the Remote Server Administration Tools (RSAT) installed.
The recommended steps for preparing to use Server Manager to deploy additional domain controllers are as follows:
1. Make sure you have the appropriate credentials for the task you are going to perform. For example, if you are going to add domain controllers to an existing domain, make sure you have Domain Admin credentials for that domain. If you are going to create a new child domain, make sure you have Enterprise Admin credentials.
2. Add the remote servers you’ll be promoting to domain controllers to the server pool so that you can manage them remotely using Server Manager.
3. Create a new server group for the remote servers you’ll be promoting to domain controllers and add the servers to the server group. Doing this makes it easier to promote multiple remote servers to domain controllers simultaneously.
Preparing for deploying domain controllers in an existing forest
Adding Windows Server 2012 or Windows Server 2012 R2 domain controllers to an existing forest or domain running an earlier version of Windows Server first requires that you extend the existing Active Directory schema. In previous versions of Windows Server, you used Adprep.exe for extending the schema. Adprep is a command-line tool that was available in the \support\adprep folder of Windows Server 2008 R2 installation media or in the \sources\adprep folder of Windows Server 2008 installation media. The Adprep command uses parameters such as /forestprep and/domainprep to prepare an existing forest for the introduction of a domain controller running a later version of Windows Server.
Beginning with Windows Server 2012, however, Adprep is run automatically as needed when you deploy a new Windows Server 2012 or Windows Server 2012 R2 domain controller in an existing forest or domain running an earlier version of Windows Server. This change simplifies the task of adding Windows Server 2012 or Windows Server 2012 R2 domain controllers to an existing forest or domain running an earlier version of Windows Server because you no longer need to manually run Adprep before introducing the new domain controllers into your forest.
Adprep is also available as a stand-alone command-line tool in the \support\adprep folder of Windows Server 2012 and Windows Server 2012 R2 installation media. The stand-alone version of Adprep is required for certain scenarios, such as performing an in-place upgrade of your first Windows Server 2012 or Windows Server 2012 R2 domain controller. In this case, you must run Adprep manually to prepare your forest and its domains before you begin upgrading your existing domain controllers to Windows Server 2012 or Windows Server 2012 R2.
Note: Adprep syntax
To display the syntax and usage examples for Adprep, type <drive>\support\adprep\adprep at a command prompt, where drive is the letter for the drive where your installation media can be found.
You can use the Windows Server 2012 version of Adprep to extend the schema of an existing forest whose domain controllers are running any of the following versions of Windows Server:
Windows Server 2008 R2
Windows Server 2008
Windows Server 2003 R2
Windows Server 2003
However, the following considerations apply when running the Windows Server 2012 version of Adprep:
You must have the credentials of a member of the Enterprise Admins group to run the Adprep /forestprep command.
Adprep can be run only on a server (domain controller, member server, or stand-alone server) that is running a 64-bit version of Windows Server 2008 or later. You cannot run Adprep on a server running Windows Server 2003 or a 32-bit version of Windows Server 2008.
The server on which you run Adprep must have network connectivity to the schema master of the existing forest.
The server on which you run Adprep must have network connectivity to the infrastructure master of the existing domain where you want to add a new Windows Server 2012 domain controller.
You can use the Windows Server 2012 R2 version of Adprep to extend the schema of an existing forest whose domain controllers are running any of the following versions of Windows Server:
Windows Server 2012
Windows Server 2008 R2
Windows Server 2008
Windows Server 2003 R2
Windows Server 2003
Similar considerations apply when running the Windows Server 2012 R2 version of Adprep as when running the Windows Server 2012 version.
Real World: Verifying Adprep
You can use the Dsquery.exe command-line tool to verify whether Adprep has extended your forest’s schema. For example, let’s say your existing forest has domain controllers running Windows Server 2008 R2. To determine the current schema level of your forest, open a command prompt on one of your domain controllers and run the following command:
dsquery * cn=schema,cn=configuration,dc=fabrikam,dc=com -scope base
-attr objectVersion
The output from this command looks like this:
objectVersion
47
Next, take a server running Windows Server 2012, join it to a domain in your forest, and use Server Manager to promote the server to a domain controller. After you finish introducing the new domain controller into your forest, rerun the preceding dsquery command on the domain controller on which you previously ran it. The output from the command looks like this:
objectVersion
56
The version number 56 indicates that the schema of your forest has been extended to include domain controllers running Windows Server 2012.
Finally, take a server running Windows Server 2012 R2, join it to a domain in your forest, and use Server Manager to promote the server to a domain controller. After you finish introducing the new domain controller into your forest, rerun the preceding dsquery command on the domain controller on which you previously ran it. The output from the command looks like this:
objectVersion
69
The version number 69 indicates that the schema of your forest has been extended to include domain controllers running Windows Server 2012 R2.
Quick check
When deploying additional domain controllers in a forest using Server Manager, why should you create a server group using Server Manager for the remote servers you’ll be promoting to domain controllers?
Quick check answer
You should create a server group so that you can more easily promote them remotely as domain controllers and manage them.
Installing the AD DS role
Before you can promote a server to a domain controller, you must first install the AD DS role on the server. To do this using Server Manager, select Add Roles And Features from the Manage menu to launch the Add Roles And Features Wizard. On the Select Server Roles page of the wizard, select the Active Directory Domain Services role and confirm the installation of the tools for managing AD DS, as shown in Figure 4-2.
FIGURE 4-2 Install the AD DS role with the role-management tools.
Running the AD DS Configuration Wizard
When you complete the installation of the role, the final page of the AD DS Configuration Wizard prompts you to promote the server to a domain controller. If you close the wizard at this point, you can still access the link to promote the server from the Notifications menu of Server Manager, as shown in Figure 4-3.
FIGURE 4-3 You can use the Notifications menu to promote the server to a domain controller.
Clicking the link to promote the server to a domain controller launches the AD DS Configuration Wizard. The steps of this wizard depend on which type of domain controller deployment scenario you are performing. The upcoming sections cover the following scenario types:
First domain controller in new forest
Additional domain controller in new domain
First Windows Server 2012 or Windows Server 2012 R2 domain controller in existing forest
First domain controller in new forest
After you have added the AD DS role to the server, using the AD DS Configuration Wizard to promote the server to the first domain controller in a new forest involves the following steps:
1. On the Deployment Configuration page of the wizard, shown in Figure 4-4, select the Add A New Forest option and specify the root domain for your new forest. Then proceed through the wizard and perform the steps that follow.
FIGURE 4-4 Deploy the first domain controller for a new forest using the AD DS Configuration Wizard.
2. On the Domain Controller Options page, specify a functional level for your new forest and root domain. The default forest and functional levels are Windows Server 2012 if your server is running Windows Server 2012 or Windows Server 2012 R2 if your server is running Windows Server 2012 R2. If you have no domain controllers running earlier versions of Windows Server in your environment, you should leave the defaults unchanged.
3. On the same page, specify whether your domain controller should also be a DNS server. Microsoft recommends that all domain controllers also be DNS servers to ensure AD DS availability.
4. On the same page, note that the first domain controller must be a global catalog server and that it cannot be an RODC.
5. On the same page, enter a password for the Directory Services Restore Mode (DSRM) administrator account.
6. On the DNS Options page, specify DNS delegation options if you are integrating AD DS with an existing DNS infrastructure. To do this, you can manually create a delegation for your new DNS server in its authoritative parent zone to ensure reliable name resolution from outside your AD DS environment. For example, if the root domain name of your new forest is corp.contoso.com, as shown in Figure 4-4, you create a delegation for your DNS server in the authoritative parent zone on the DNS server that manages the public contoso.com domain for your organization.
7. On the Additional Options page, the wizard suggests a NetBIOS name for your forest root domain. You can either accept what the wizard suggests or specify a different name of up to 15 Internet-standard characters (A–Z, a–z, 0–9, and “-”) but not entirely numeric.
8. On the Paths page, specify the location of the AD DS database, log files, and SYSVOL or accept the defaults.
9. The Review Options page displays the results of your selections.
10. The Prerequisites Check page verifies that all prerequisites have been met for successfully deploying the domain controller. See Figure 4-1 earlier in this chapter for an example of what this wizard page looks like.
11. Clicking Install promotes the server to a domain controller and automatically reboots the server at the end of the promotion operation.
Real World: Windows PowerShell behind the wizard
The AD DS Configuration Wizard is built entirely on Windows PowerShell. In other words, you can think of the wizard as a UI that simply runs a Windows PowerShell command whose parameters are determined by the selections you make on the different wizard pages. On the Review Options page of the wizard, you can click View Script to display the Windows PowerShell script in Notepad. For example, if you are deploying the first Windows Server 2012 R2 domain controller in a new forest whose forest root domain is corp.contoso.com, the script that performs this action looks like this:
#
# Windows PowerShell script for AD DS Deployment
#
Import-Module ADDSDeployment
Install-ADDSForest `
-CreateDnsDelegation:$false `
-DatabasePath "C:\Windows\NTDS" `
-DomainMode "Win2012R2" `
-DomainName "corp.contoso.com" `
-DomainNetbiosName "CORP" `
-ForestMode "Win2012R2" `
-InstallDns:$true `
-LogPath "C:\Windows\NTDS" `
-NoRebootOnCompletion:$false `
-SysvolPath "C:\Windows\SYSVOL" `
-Force:$true
Being able to view the script behind the wizard provides several benefits. First, it enables you to quickly learn the syntax of Windows PowerShell cmdlets for AD DS deployment. Second, you can copy these scripts, customize them, and use them to automate the deployment of other domain controllers in your environment.
More Info: Naming your new forest
For some recommendations on how to name the forest root domain of a new forest, see the topic “Selecting the Forest Root Domain” in the TechNet Library at http://technet.microsoft.com/en-us/library/cc726016(v=WS.10).aspx.
Additional domain controller in new domain
After you deploy the first domain controller in a new domain or forest, you should deploy at least one additional domain controller in the domain for fault tolerance. After adding the AD DS role to the server that will become the additional domain controller, you can use the AD DS Configuration Wizard to promote the server to be an additional domain controller for the domain by performing the following steps:
1. On the Deployment Configuration page of the wizard, shown in Figure 4-5, select the Add A Domain Controller To An Existing Domain option. Specify the domain to which you want to add the new domain controller, and if your current logon credentials have insufficient privileges to perform the option, click Change and specify suitable credentials.
FIGURE 4-5 Deploy an additional domain controller to an existing domain.
2. On the Domain Controller Options page, specify whether your domain controller should also be a DNS server. (This option is selected by default.)
3. On the same page, specify whether your domain controller should also be a global catalog server. (This option is selected by default.)
4. On the same page, specify whether your domain controller should also be an RODC. You should have at least two writeable domain controllers in every domain in your forest, so do not select this option if this is the second domain controller in your domain.
5. On the same page, specify the name of the existing AD DS site to which the new domain controller should belong. (The default is Default-First-Site-Name.)
6. On the same page, enter a password for the DSRM administrator account.
7. On the DNS Options page, specify DNS delegation options if you are integrating AD DS with an existing DNS infrastructure.
8. On the Additional Options page, select the Install From Media (IFM) option if you used the Ntdsutil.exe tool to create installation media for additional domain controllers that you are deploying in the domain. You can use the Install From Media (IFM) option to minimize the replication of directory data over your network, which helps make deploying additional domain controllers at remote sites more efficient. If you are deploying additional domain controllers at your organization’s hub site (its headquarters or central office), however, you generally will not use the IFM option.
9. On the same page, if you are not using the IFM option for deploying additional domain controllers, you can select which domain controller in your domain the new additional domain controller should use as an initial replication partner for pulling down a copy of the AD DS database. By default, your new domain controller replicates from any available domain controller in the domain, but you have the option of specifying a particular domain controller as its initial replication partner.
10. Complete the remaining steps of the wizard to deploy the additional domain controller in the domain.
More Info: Install From Media
For more information about deploying domain controllers using the Install From Media (IFM) option, see the topic “Installing AD DS from Media” in the TechNet Library at http://technet.microsoft.com/en-us/library/cc770654(v=WS.10).aspx.
First Windows Server 2012 or Windows Server 2012 R2 domain controller in existing forest
You can also use the AD DS Configuration Wizard to deploy Windows Server 2012 or Windows Server 2012 R2 domain controllers in a forest or domain whose existing domain controllers are running Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003. As explained earlier in this lesson, when you use the wizard to deploy the first Windows Server 2012 or Windows Server 2012 R2 domain controller in a domain of a forest whose domain controllers are running earlier Windows Server versions, the Adprep tool automatically runs to prepare the forest and domain by extending the schema to its latest version.
The procedure that follows demonstrates this scenario by deploying a Windows Server 2012 or Windows Server 2012 R2 domain controller named VAN-SRV-3 in a forest root domain named fabrikam.com whose existing domain controllers are all running Windows Server 2008 R2. After you have added the AD DS role to server VAN-SRV-3, using the AD DS Configuration Wizard to add the server as the first Windows Server 2012 or Windows Server 2012 R2 domain controller in the fabrikam.com forest involves the following steps:
1. On the Deployment Configuration page of the wizard, shown in Figure 4-6, select the Add A Domain Controller To An Existing Domain option, specify fabrikam.com as the forest root domain, and specify suitable credentials for performing the operation.
FIGURE 4-6 Promote the server named VAN-SRV-3 to be the first Windows Server 2012 or Windows Server 2012 R2 domain controller in the existing fabrikam.com forest root domain.
2. Proceed through the wizard as described in the previous section until you reach the Preparation Options page shown in Figure 4-7. This page informs you that performing this operation will prepare your forest and domain for Windows Server 2012 or Windows Server 2012 R2 domain controllers by extending the schema. If you do not want to extend the schema, cancel the operation and do not deploy the new domain controller.
FIGURE 4-7 The wizard informs you that the forest schema will be extended if you perform this operation.
3. Complete the remaining steps of the wizard to deploy the domain controller and extend the schema. Note that you did not have to manually run Adprep to prepare your forest or domain for the domain controller running Windows Server 2012 or Windows Server 2012 R2.
Verifying the installation
After deploying a new domain controller running Windows Server 2012 or Windows Server 2012 by using Server Manager, you should verify the installation by performing the following steps:
1. Add the new domain controller to the server pool and to any server group you created for grouping together your Windows Server 2012 domain controllers.
2. Select the new domain controller from any applicable page of Server Manager.
3. Check for any alerts raised concerning the new controller on the Notifications menu.
4. Scroll down the page to the Events tile and review any events raised for the new domain controller. Pay special attention to any critical, error, or warning events raised and perform any additional configuration or remedial action needed to address these events.
5. Scroll down the page to the Services tile and review the condition of the services on the new domain controller. Make sure that all services have their startup values configured appropriately and that automatic services are running.
6. Scroll down the page and start a Best Practices Analyzer (BPA) scan on the new domain controller by selecting Start BPA Scan from the Tasks menu of the Best Practices Analyzer tile. (See Figure 4-8.) BPAs are server management tools built into Windows Server 2012 and Windows Server 2012 R2 that help you adhere to best practices by scanning installed server roles and reporting any violations discovered.
FIGURE 4-8 Start a BPA scan on a domain controller.
As an example, Figure 4-9 shows the results of running a BPA scan on two Windows Server 2012 or Windows Server 2012 R2 domain controllers deployed in a new forest. These domain controllers have been grouped together in Server Manager by creating a custom server group named Domain Controllers. The Error displayed in the Best Practices Analyzer tile indicates that domain controller SEA-DC-1 is the PDC Emulator operations master for the forest and needs to be able to synchronize its clock with a reliable time source on the Internet. After you run a BPA scan on your domain controllers, be sure to carefully review the results displayed in the tile.
FIGURE 4-9 Review the results of a BPA scan performed on newly deployed domain controllers.
Quick check
You used Server Manager to install the AD DS role on a remote server, but you closed the Add Roles And Features Wizard without first promoting the server to a domain controller. How can you finish the job and promote the server?
Quick check answer
Access the link to promote the server from the Notifications menu of Server Manager.
Uninstalling AD DS
If you need to retire a Windows Server 2012 or Windows Server 2012 R2 domain controller from your environment—for example, to repurpose its server hardware for some other role—you can do this using Server Manager by performing the following steps:
1. Launch the Remove Roles And Features Wizard from the Manage menu and select your server from the server pool.
2. On the Remove Server Roles page, deselect the Active Directory Domain Services check box. The Validation Results page appears, indicating that you must demote the domain controller before you can remove the AD DS role. (See Figure 4-10.)
FIGURE 4-10 You must demote a domain controller before you can remove the AD DS role from it.
3. On the Validation Results page, click Demote This Domain Controller to launch the AD DS Configuration Wizard.
4. On the Credentials page, supply the necessary credentials to perform this operation if your current logon credentials have insufficient privileges. If previous attempts to remove AD DS from this domain controller failed, select the Force The Removal Of This Domain Controller check box on this page.
5. If you are demoting the last domain controller in the domain, make sure the Last Domain Controller In The Domain check box is selected to confirm that you want to remove the domain from your forest. Note that this check box is displayed only if the server is the last domain controller in the domain.
6. On the Warnings page, make sure the Proceed With Removal check box is selected to confirm your decision to perform the demotion. Note that this page is not displayed if you chose to force the removal of AD DS in the previous step.
7. On the Removal Options page, you have the option to remove any DNS delegations created in the authoritative parent zone. Note that you need to supply appropriate credentials to perform this action.
8. If you are demoting the last domain controller in the domain, you also have the options of removing the DNS zone and any application partitions from the domain. (See Figure 4-11.) By clicking View Partitions, you can display a list of any application partitions in AD DS.
FIGURE 4-11 You have options for removing the DNS zone and application partitions when demoting the last domain controller in a domain.
9. On the New Administrator Password page, enter a password for the local Administrator account for the server.
10. On the Review Options page, click Demote. The server restarts, and you can log on using the local Administrator account and the new password you specified in the previous step.
11. Launch the Remove Roles And Features Wizard again from the Manage menu and select your server from the server pool.
12. On the Remove Server Roles page, deselect the Active Directory Domain Services and DNS Server check boxes. Finish running the wizard. When the server restarts, both the AD DS and DNS Server roles will have been removed.
Important: Removing application partitions
When you demote the last domain controller in a domain using Server Manager, you have the option of removing any application partitions. At a minimum, when you do this you should see the default DNS application partitions—for example:
DC=DomainDNSZones,DC=corp,DC=contoso,DC=com
DC=ForestDNSZones,DC=corp,DC=contoso,DC=com
If you have other server applications deployed in your environment, you might see additional application partitions. Before removing these partitions, make sure that your deployed server applications will still be able to work properly unless you are also retiring those server applications from your environment.
Real World: Forcing the removal of AD DS
The demotion of domain controllers can fail when the domain controller on which you are performing this action has no connectivity with other domain controllers in the domain. If this happens, try selecting the Force The Removal Of This Domain Controller check box on the Credentials page of the AD DS Configuration Wizard when you are attempting to demote the domain controller.
Lesson summary
You can use Server Manager to deploy Windows Server 2012 and Windows Server 2012 R2 domain controllers. This procedure is mainly intended for small and midsized environments in which automating this process is not needed.
After you use the Add Roles And Feature Wizard to install the AD DS role on a remote server, you can use the AD DS Configuration Wizard to promote the server to a domain controller.
After you deploy a domain controller, you can use Server Manager to verify the installation by reviewing the Event logs, reviewing the state of services, and running a Best Practices Analyzer scan on the new domain controller.
You can use the Remove Roles And Features Wizard to uninstall the AD DS role on a remote server, but you first need to demote the server from being a domain controller.
Adprep is still available as a stand-alone command-line tool in the \support\adprep folder of Windows Server 2012 and Windows Server 2012 R2 installation media when you need to perform an in-place upgrade of your first Windows Server 2012 or Windows Server 2012 R2 domain controller.
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 procedures for deploying the first Windows Server 2012 R2 domain controller in a new forest is correct? (Choose all that apply.)
A. Install Windows Server 2012 R2 on your server and log on using the local Administrator account. Open Server Manager and run the AD DS Configuration Wizard to promote the server as a domain controller.
B. Install Windows Server 2012 R2 on your server and log on using the local Administrator account. Open Server Manager and run the Add Roles And Features Wizard to promote the server as a domain controller.
C. Install Windows Server 2012 R2 on your server and log on using the local Administrator account. Open Server Manager and run the Add Roles And Features Wizard to install the AD DS role on the server. Then run the AD DS Configuration Wizard to promote the server as a domain controller.
D. Install Windows Server 2012 R2 on your server and log on using the local Administrator account. Open Server Manager and run the AD DS Configuration Wizard to install the AD DS role on the server. Then run the Add Roles And Features Wizard to promote the server as a domain controller.
2. Which of the following statements is not correct concerning the deployment of the first Windows Server 2012 R2 domain controller in an existing forest running an earlier version of Windows Server? (Choose all that apply.)
A. You must prepare the forest and domain and extend the schema by manually running Adprep before you use Server Manager to deploy the first Windows Server 2012 R2 domain controller in an existing forest running an earlier version of Windows Server.
B. You must select the Add A Domain Controller To An Existing Domain option on the Deployment Configuration page of the AD DS Configuration Wizard to deploy the first Windows Server 2012 R2 domain controller in an existing forest running an earlier version of Windows Server.
C. You can use the Install From Media (IFM) deployment method to deploy the first Windows Server 2012 R2 domain controller in an existing forest running an earlier version of Windows Server.
D. If your current logon credentials have insufficient privileges to deploy the first Windows Server 2012 R2 domain controller in an existing forest running an earlier version of Windows Server, you can specify different credentials on the Deployment Configuration page of the AD DS Configuration Wizard.
3. Which of the following is the best syntax when using the Dsquery.exe command-line tool to verify that Adprep has successfully extended your forest’s schema?
A. Dsquery * cn=schema,cn=configuration,dc=fabrikam,dc=com –attr objectVersion
B. Dsquery * cn=schema,cn=configuration,dc=fabrikam,dc=com –scope base –attr sAMAccountName
C. Dsquery * cn=schema,cn=configuration,dc=fabrikam,dc=com –scope base –attr *
D. Dsquery * cn=schema,cn=configuration,dc=fabrikam,dc=com –scope base –attr objectVersion
Lesson 3: Deploying domain controllers using Windows PowerShell
Windows PowerShell provides a way to automate the deployment of Windows Server 2012 and Windows Server 2012 R2 domain controllers. This approach to domain controller deployment can be particularly useful in large enterprise environments, data centers, and cloud-computing scenarios. This lesson demonstrates how to use Windows PowerShell to deploy domain controllers in both new and existing forests.
After this lesson, you will be able to:
Prepare your environment for domain controller deployment using Windows PowerShell.
Use Windows PowerShell to verify the prerequisites for installing new forests, domains, and domain controllers.
Use Windows PowerShell to install AD DS on servers and promote them as domain controllers in both new and existing forests.
Use Windows PowerShell to demote domain controllers.
Estimated lesson time: 30 minutes
Preparing for domain controller deployment
Like deploying domain controllers using Server Manager as described in the previous lesson, the steps for preparing to deploy Windows Server 2012 and Windows Server 2012 R2 domain controllers using Windows PowerShell differ depending on the scenario.
Real World: Windows PowerShell and Server Core installations
The Server Core installation option for Windows Server 2012 and Windows Server 2012 R2 is ideal for data center environments because of its smaller servicing footprint, disk space requirements, and attack surface. The Server Core installation option also supports installing the AD DS role, so using Windows PowerShell to deploy Server Core domain controllers is ideal for a data center.
Preparing for deploying the first domain controller in a new forest
To deploy the first Windows Server 2012 or Windows Server 2012 R2 domain controller in a new forest, you can run Windows PowerShell commands directly on the server by either logging on locally to the server or connecting to it using Remote Desktop. Another option is to use Windows PowerShell remoting, which enables you to run Windows PowerShell commands on one or more remote computers simultaneously by using the WS-Management protocol.
As explained previously in Chapter 3, “Server remote management,” the remote management capability is enabled by default on Windows Server 2012 and Windows Server 2012 R2 to make it easy to remotely manage servers using both Server Manager and Windows PowerShell. For more information, see the section “Configuring remote management” in Lesson 4 of Chapter 3.
The difficulty, however, is that Windows PowerShell remoting is primarily intended for remotely managing domain-joined computers, and if you are preparing to deploy the first domain controller in a new forest there is no domain to join! In other words, the remote server that will be promoted to a domain controller is initially in a workgroup, not a domain. In addition, the local computer from which you will be performing the deployment might also be in a workgroup.
The solution is to prepare your environment by enabling the two stand-alone computers to talk to each other using the WS-Management protocol. If the computer from which you are performing the deployment is also running Windows Server 2012 or Windows Server 2012 R2, you just need to add the name of the remote server to the TrustedHosts list in the local computer’s WinRM configuration. Doing this enables the local computer to connect to the remote server using NTLM as the authentication mechanism instead of Kerberos, which is used in domain-based environments.
Important: Adding remote servers to the TrustedHosts list on your computer
When you add a remote server to the TrustedHosts list on your computer, you allow your credentials to be sent to the remote server without verifying the server’s identity. So add remote servers to this list only if you are certain the network path from your computer to the remote server machine is completely secure.
To illustrate how to do this, consider a scenario in which you have two stand-alone servers running Windows Server 2012 or Windows Server 2012 R2: a local server named SEA-HOST-2 and a remote server named SEA-SRV-1. You want to use the Get-WindowsFeature cmdlet on the local server to display a list of installed and available roles and features on the remote server, but when you try to do this on the local server, you get the error indicated in the following code:
PS C:\> Get-WindowsFeature -ComputerName SEA-SRV-1 -Credential SEA-SRV-1\Administrator
Get-WindowsFeature : The WinRM client cannot process the request. If the authentication
scheme is different from Kerberos, or if the client computer is not joined to a domain,
then HTTPS transport must be used or the destination machine must be added to the
TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that
computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config.
At line:1 char:1
+ Get-WindowsFeature -ComputerName SEA-SRV-1 -Credential SEA-SRV-1\Administrator
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : DeviceError: (Microsoft.Manag...rDetailsHandle):CimException)
[Get-WindowsFeature], Exception + FullyQualifiedErrorId : UnSupportedTargetDevice,
Microsoft.Windows.ServerManager.Commands.GetWindowsFeatureCommand
The error occurs because the remote server SEA-SRV-1 is not domain-joined and therefore must be added to the TrustedHosts list on the local server before you can manage the remote server from the local server. You can use the Set-Item cmdlet to do this:
PS C:\> Set-Item wsman:\localhost\Client\TrustedHosts -Value SEA-SRV-1
WinRM Security Configuration.
This command modifies the TrustedHosts list for the WinRM client. The computers
in the TrustedHosts list might not be authenticated. The client might send credential
information to these computers. Are you sure that you want to modify this list?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y
You can then use the Get-Item cmdlet to verify the result:
PS C:\> Get-Item wsman:\\localhost\Client\TrustedHosts
WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Client
Type Name SourceOfValue Value
---- ---- ------------- -----
System.String TrustedHosts SEA-SRV-1
Running the Get-WindowsFeature cmdlet now no longer throws an error:
PS C:\> Get-WindowsFeature -ComputerName SEA-SRV-1 -Credential SEA-SRV-1\Administrator
Display Name Name Install State
------------ ---- -------------
[ ] Active Directory Certificate Services AD-Certificate Available
[ ] Certification Authority ADCS-Cert-Authority Available
[ ] Certificate Enrollment Policy Web Service ADCS-Enroll-Web-Pol Available
...
Note: Tips for running Set-Item wsman:\localhost\Client\TrustedHosts
If you need to add another remote server to the TrustedHosts list on your local computer, include the –Concatenate parameter when you use Set-Item the second time so that you don’t overwrite the current contents of the list. You can also suppress the Yes/No prompt with the Set-Item cmdlet by adding the –Force parameter to it.
Preparing for deploying additional domain controllers in the new forest
Deploying additional domain controllers in a new forest is easier than deploying the first domain controller because you already have a domain environment, which means Windows PowerShell remoting will work without any further configuration. By running your Windows PowerShell commands from an existing Windows Server 2012 or Windows Server 2012 R2 domain controller in your forest or from a Windows 8 or Windows 8.1 client computer on which the appropriate version of RSAT has been installed, you are able to deploy additional domain controllers to existing domains, install new child domains, and install new tree domains as long as you have the appropriate credentials for the task you are going to perform.
Preparing for deploying domain controllers in an existing forest
You can also deploy Windows Server 2012 or Windows Server 2012 R2 domain controllers in a forest whose domain controllers are running an earlier version of Windows Server by using Windows PowerShell as follows:
1. Install Windows Server 2012 or Windows Server 2012 R2 on a server and join the server to an existing domain.
2. Use the Install-WindowsFeature cmdlet to install the AD DS role with its role-management tools as follows:
Install-WindowsFeature -name AD-Domain-Services –IncludeManagementTools
3. Run commands from the ADDSDeployment module on the server to remotely install AD DS on other domain-joined servers running Windows Server 2012 or Windows Server 2012 R2.
Using Windows PowerShell to deploy domain controllers
The Windows PowerShell cmdlets for installing a forest, installing domains, deploying domain controllers, and performing similar deployment tasks are found in the ADDSDeployment module. This Windows PowerShell module is installed by default when you add the AD DS role with its role-management tools on a server, regardless of whether the server has been promoted to a domain controller. To see a list of the available cmdlets in this module, use the Get-Command cmdlet as follows:
PS C:\> Get-Command -Module ADDSDeployment
CommandType Name ModuleName
----------- ---- ----------
Cmdlet Add-ADDSReadOnlyDomainControllerAccount ADDSDeployment
Cmdlet Install-ADDSDomain ADDSDeployment
Cmdlet Install-ADDSDomainController ADDSDeployment
Cmdlet Install-ADDSForest ADDSDeployment
Cmdlet Test-ADDSDomainControllerInstallation ADDSDeployment
Cmdlet Test-ADDSDomainControllerUninstallation ADDSDeployment
Cmdlet Test-ADDSDomainInstallation ADDSDeployment
Cmdlet Test-ADDSForestInstallation ADDSDeployment
Cmdlet Test-ADDSReadOnlyDomainControllerAccountCreation ADDSDeployment
Cmdlet Uninstall-ADDSDomainController ADDSDeployment
Verifying prerequisites
You can use the Test-ADDS* cmdlets to run a prerequisites check before attempting to install a new forest, install a new domain, deploy a writeable domain controller, or deploy an RODC in your environment. The output of this command will help you determine whether your environment is ready for the operation you intend to perform or whether additional configuration might be required. The example here shows some output from running the Test-ADDSForestInstallation cmdlet on a stand-alone server running Windows Server 2012 or Windows Server 2012 R2 to determine whether the server satisfies the prerequisites for becoming the first domain controller of the forest root domain of a new forest:
PS C:\> Test-ADDSForestInstallation -DomainName corp.adatum.com
SafeModeAdministratorPassword: ********
Confirm SafeModeAdministratorPassword: ********
WARNING: Windows Server 2012 Release Candidate domain controllers have a default for the
security setting named "Allow cryptography algorithms compatible with Windows NT 4.0"
that prevents weaker cryptography algorithms when establishing security channel
sessions.
For more information about this setting, see Knowledge Base article 942564
(http://go.microsoft.com/fwlink/?LinkId=104751).
WARNING: This computer has at least one physical network adapter that does not have
static IP address(es) assigned to its IP Properties. If both IPv4 and IPv6 are enabled
for a network adapter, both IPv4 and IPv6 static IP addresses should be assigned to both
IPv4 and IPv6 Properties of the physical network adapter. Such static IP address(es)
assignment should be done to all the physical network adapters for reliable Domain Name
System (DNS) operation.
WARNING: A delegation for this DNS server cannot be created because the authoritative
parent zone cannot be found or it does not run Windows DNS server. If you are integrating with an existing DNS infrastructure, you should manually create a delegation to this DNS server in the parent zone to ensure reliable name resolution from outside
the domain "adatum.com". Otherwise, no action is required.
Message Context RebootRequired Status
------- ------- -------------- ------
Operation completed succes... Test.VerifyDcPromo... False Success
To determine whether a remote server running Windows Server 2012 or Windows Server 2012 R2 satisfies these requirements, use the Invoke-Command cmdlet to execute the Test-ADDSForestInstallation cmdlet on the remote server as follows:
Invoke-Command -ComputerName SEA-SRV-1 {Test-ADDSForestInstallation -DomainName corp
.adatum.com}
First domain controller in new forest
Deploying the first domain controller running Windows Server 2012 or Windows Server 2012 R2 in a new forest is equivalent to installing a new forest and involves two steps:
1. Adding the AD DS role to the server
2. Promoting the server as a domain controller
Using Windows PowerShell, you can combine these actions into a single script you can execute on remote servers. The following scenario uses two stand-alone servers running Windows Server 2012 or Windows Server 2012 R2: a local server named SEA-HOST-2 and a remote server named SEA-SRV-1. The goal is to run a script on SEA-HOST-2 that will install a new forest, with SEA-SRV-1 being the first domain controller in the forest root domain. To accomplish this, you could proceed as follows:
1. Begin by logging on to a local server running Windows Server 2012 or Windows Server 2012 R2 using your administrator credentials and open an elevated Windows PowerShell prompt. (If you are logged on with the built-in Administrator account, any Windows PowerShell prompt you open will be elevated.)
2. Change the script execution policy on the local server to RemoteSigned by running the following command:
Set-Execution Policy RemoteSigned
Note: Default execution policy
Beginning with Windows Server 2012 R2, the default execution policy for Windows PowerShell is RemoteSigned. This means that step 2 only has to be performed if the server is running the earlier version of Windows Server 2012.
3. Changing the execution policy enables you to run Windows PowerShell scripts (.ps1 files) on the local server. By using Windows PowerShell remoting, you are also able to run scripts on the remote server.
4. Open Notepad and type the following two commands:
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName corp.adatum.com -InstallDNS
The first command installs AD DS with the role-management tools on the targeted server. The second command promotes the targeted server as the first domain controller in the forest root domain corp.adatum.com. Note that the name of the targeted server has not been specified in this script. Use Notepad to save the script with the file name script1.ps1 in the folder C:\scripts or some other suitable location on the local server.
5. Run the following command on the local server to execute your script on the remote server SEA-SRV-1:
Invoke-Command -ComputerName SEA-SRV-1 -FilePath C:\scripts\script1.ps1
6. When the AD DS role has finished installing on SEA-SRV-1, you will be prompted to specify a Safe Mode Administrator Password. This password is necessary because it enables you to log on to the new domain controller in Directory Services Recovery Mode when needed. After entering a password and confirming it, press Y and then ENTER to confirm that you want to promote the server as a domain controller. The promotion process begins, as shown in Figure 4-12. Note that you can eliminate the need to press Y and then ENTER by including the –Forceparameter in the second line of your script.
FIGURE 4-12 Remote server SEA-SRV-1 is being promoted to be the first domain controller in a new forest.
7. Command output like the following will be displayed if the promotion process is successful:
PSComputerName : SEA-SRV-1
RunspaceId : dd268942-f430-43c9-9830-7c547d1a4b73
Message : Operation completed successfully
Context : DCPromo.General.3
RebootRequired : False
Status : Success
The server will then be restarted to complete the promotion process. If the remote server is a Server With A GUI installation, logging on to the server and launching Server Manager will confirm that the AD DS and DNS Server roles have been installed and the server is the first domain controller in the corp.adatum.com forest.
Additional domain controller in domain
You can use the Install-ADDSDomainController cmdlet to install an additional domain controller in an existing domain. For example, the following command installs and promotes a new domain controller and DNS server in the corp.adatum.com domain using domain administrator credentials:
Install-ADDSDomainController -InstallDns -Credential `
(Get-Credential CORP\Administrator) -DomainName corp.adatum.com
You will be prompted to provide and confirm the Directory Services Restore Mode (DSRM) password during the installation process.
If you want to use local administrator credentials instead of domain administrator credentials for this process, omit the –Credential parameter as follows:
Install-ADDSDomainController -InstallDns -DomainName corp.adatum.com
If you want to be prompted to supply the credentials needed to install and promote the domain controller, use the following command instead:
Install-ADDSDomainController -InstallDns -Credential `
(Get-Credential) -DomainName corp.adatum.com
You can use the Invoke-Command cmdlet to install several additional domain controllers at once, like this:
Invoke-Command -ComputerName SEA-SRV-2, SEA-SRV-3 -ScriptBlock `
{Install-ADDSDomainController -InstallDns -DomainName corp.adatum.com}
Note: Multiple-line commands
The backtick character is an escape character in Windows PowerShell that is appended to a line to indicate that the command continues on the next line.
First domain controller in child or tree domain
You can use the Install-ADDSDomain cmdlet to install a new child or tree domain in an existing forest by deploying the first domain controller for the new domain. For example, to install and promote a server to be the first domain controller of a child domain hq in the parent domaincorp.adatum.com, use this command:
Install-ADDSDomain -Credential (Get-Credential CORP\Administrator) `
-NewDomainName hq -ParentDomainName corp.adatum.com -DomainType ChildDomain `
-InstallDNS -CreateDNSDelegation
For more information on the syntax for this command, use the Get-Help cmdlet.
Read-only domain controllers
You can use the Add-ADDSReadOnlyDomainControllerAccount cmdlet to create an RODC account that can be used to install an RODC in your forest. After you have created the RODC account, you can use the Install-ADDSDomainController cmdlet with the –ReadOnlyReplica parameter to deploy a new RODC in an existing domain. For more information on these cmdlets, use the Get-Help cmdlet.
More Info: Installing and promoting domain controllers
For additional examples and guidance concerning the deployment of domain controllers in different scenarios, see the following topics in the TechNet Library:
“Install Active Directory Domain Services” at http://technet.microsoft.com/en-us/library/hh472162
“AD DS Deployment Cmdlets” at http://technet.microsoft.com/en-us/library/hh974719
See also Lesson 4 of Chapter 3.
Quick check
What do you need to do before you can use one stand-alone Windows Server 2012 R2 server to remotely execute Windows PowerShell commands on another stand-alone Windows Server 2012 R2 server?
Quick check answer
Add the second server to the TrustedHosts list on the first server.
Verifying domain controller deployment
You can also use Windows PowerShell to verify the results of installing AD DS on remote servers and promoting them as domain controllers. For example, you can use the cmdlets of the BestPractices module to perform BPA scans on remote servers. To illustrate this and continue the preceding scenario, begin by using Invoke-Command on local server SEA-HOST-2 to execute the Invoke-BPAModule cmdlet on remote server SEA-SRV-1:
PS C:\> Invoke-Command -ComputerName SEA-SRV-1 -ScriptBlock `
{Invoke-BpaModel -ModelId Microsoft/Windows/DirectoryServices}
ModelId : Microsoft/Windows/DirectoryServices
SubModelId :
Success : True
ScanTime : 6/20/2012 9:30:05 PM
ScanTimeUtcOffset : -07:00:00
Detail : {SEA-SRV-1, SEA-SRV-1}
You can then execute the Get-BPAResult cmdlet on the remote server to display the results of the scan you performed by using this command:
PS C:\> Invoke-Command -ComputerName SEA-SRV-1 -ScriptBlock `
{Get-BpaResult Microsoft/Windows/DirectoryServices}
The output from this command will be quite extensive, so you might try piping it into the Where-Object cmdlet to display only results whose severity level is Error:
PS C:\Users\Administrator> Invoke-Command -ComputerName SEA-SRV-1 -ScriptBlock `
{Get-BpaResult Microsoft/Windows/DirectoyServices} | Where-Object Severity -eq Error
ResultNumber : 28
ResultId : 513979436
ModelId : Microsoft/Windows/DirectoryServices
SubModelId :
RuleId : 36
ComputerName : SEA-SRV-1
Context :
Source : SEA-SRV-1
Severity : Error
Category : Configuration
Title : The PDC emulator master SEA-SRV-1.corp.adatum.com in this forest should
be configured to correctly synchronize time from a valid time source
Problem : The primary domain controller (PDC) emulator operations master in this
forest is not configured to correctly synchronize time from a valid
time source.
Impact : If the PDC emulator master in this forest is not configured to
correctly synchronize time from a valid time source, it might use its
internal clock for time synchronization. If the PDC emulator master in
this forest fails or otherwise becomes unavailable (and if you have not
configured a reliable time server (GTIMESERV) in the forest root
domain), other member computers and domain controllers in the forest
will not be able to synchronize their time.
Resolution : Set the PDC emulator master in this forest to synchronize time with a
reliable external time source. If you have not configured a reliable
time server (GTIMESERV) in the forest root domain, set the PDC emulator
master in this forest to synchronize time with a hardware clock that is
installed on the network (the recommended approach). You can also set
the PDC emulator master in this forest to synchronize time with an
external time server by running the w32tm /config /computer:SEA-SRV-
1.corp.adatum.com /manualpeerlist:time.windows.com
/syncfromflags:manual /update command. If you have configured a
reliable time server (GTIMESERV) in the forest root domain, set the PDC
emulator master in this forest to synchronize time from the forest root
domain hierarchy by running w32tm /config
/computer:SEA-SRV-1.corp.adatum.com /syncfromflags:domhier /update.
Compliance :
Help : http://go.microsoft.com/fwlink/?LinkId=142195
Excluded : False
PSComputerName : SEA-SRV-1
More Info: Using the BestPractices module
For more information on how to use Windows PowerShell to perform BPA scans, see the topic “Run Best Practices Analyzer Scans and Manage Scan Results” in the TechNet Library at http://technet.microsoft.com/en-us/library/hh831400.
Uninstalling AD DS
Finally, you can use the Uninstall-ADDSDomainController cmdlet to remove the AD DS role and demote a domain controller to a member server in the domain. You will be prompted to set and confirm the local Administrator password before the completion of the removal process. For more information on using this cmdlet, use the Get-Help cmdlet.
Lesson summary
You can use Windows PowerShell to deploy domain controllers running Windows Server 2012 or Windows Server 2012 R2. This procedure is mainly intended for large enterprises, data centers, and cloud-computing environments in which automation of this process is a requirement.
You can use Windows PowerShell to install and promote a remote stand-alone server running Windows Server 2012 or Windows Server 2012 R2 to a domain controller after taking some preparatory steps to enable Windows PowerShell remoting to work properly in a workgroup environment.
To use Windows PowerShell to install the AD DS role on a remote server, use the Invoke-Command cmdlet to remotely execute the Install-WindowsFeature cmdlet.
To use Windows PowerShell to promote a remote server that already has the AD DS role installed, use the Invoke-Command cmdlet to remotely execute the appropriate cmdlet from the ADDSDeployment module.
To use Windows PowerShell to run a prerequisites check before attempting to install a new forest, install a new domain, deploy a writeable domain controller, and use the Test-ADDS* cmdlets from the ADDSDeployment module.
To use Windows PowerShell to run a Best Practices Analyzer (BPA) scan on remote servers after installing AD DS and promoting them to domain controllers, use the Invoke-Command cmdlet to remotely execute the appropriate cmdlet from the BestPractices module.
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 Windows PowerShell commands adds the remote server SRV-A to the TrustedHosts list on the local server?
A. Get-Item wsman:\localhost\Client\TrustedHosts –Value SRV-A
B. Set-Item wsman:\localhost\Client\TrustedHosts –Value SRV-A
C. Get-Item wsman:\localhost\Server\TrustedHosts –Value SRV-A
D. Set-Item wsman:\localhost\Server\TrustedHosts –Value SRV-A
2. Which of the following is not a cmdlet from the ADDSDeployment module?
A. Install-ADDSDomain
B. Install-ADDSDomainController
C. Uninstall-ADDSDomainController
D. Get-ADForest
3. Which Windows PowerShell command should you use to run a prerequisites check before attempting to deploy an additional domain controller in an existing forest?
A. Install-ADDSDomainController –Prerequisites
B. Invoke-BpaModel –ModelId Microsoft/Windows/DirectoryServices
C. Test-ADDSDomainControllerInstallation
D. Install-ADDSDomainController –Whatif
Practice exercises
The goal of this section is to provide you with hands-on practice with the following:
Deploying domain controllers using Server Manager
Deploying domain controllers using Windows PowerShell
To perform the following exercises, you need two clean installations of Windows Server 2012 R2: one installed using the Server With A GUI installation option and the other installed using the Server Core installation option. The servers should be stand-alone servers belonging to a workgroup, have Internet connectivity, and have no additional roles or features installed. For the purposes of these exercises, the name of the first server (the Server With A GUI installation) is assumed to be SERVER1 and the name of the second server (the Server Core installation) is assumed to be SERVER2. You should be logged on interactively to SERVER1 using the built-in local Administrator account.
Note: Switching to Server Core
If your SERVER2 is a Server With A GUI installation, you can switch it to a Server Core installation by running the following Windows PowerShell command on it:
Uninstall-WindowsFeature Server-Gui-Mgmt-Infra –Restart
Exercise 1: Installing a new forest using Server Manager
In this exercise, you install a new forest named corp.contoso.com by using Server Manager to install AD DS on SERVER1 and promote the server as a domain controller.
1. Log on to SERVER1 using the built-in Administrator account and open Server Manager if it doesn’t open automatically.
2. Use the Dashboard to verify that SERVER1 is in a healthy state before proceeding.
3. Use Server Manager to launch the Add Roles And Features Wizard and install the Active Directory Domain Services role on the server, including the administration tools for this role. Close the Add Roles And Features Wizard upon completion of the role installation.
4. Use the Notifications flag on the Server Manager menu to perform the post-deployment configuration task of promoting the server to a domain controller using the Active Directory Domain Services Configuration Wizard.
5. Select the Add A New Forest option on the first page of the AD DS Configuration Wizard and create a new forest root domain named corp.contoso.com. Make appropriate selections for the remaining items in the wizard pages.
6. On the Review Options page, click View Script and examine the Windows PowerShell script that the wizard will be executing. Look up the help page for the command in the TechNet Library to make sure you understand the syntax of the command.
7. After reviewing the results on the Prerequisites Check page, click Install to promote SERVER1 to be the first domain controller in the new forest.
8. After the server reboots, log on using the default domain administrator account and open Server Manager if it doesn’t open automatically.
9. Use the Dashboard to examine any alerts that are raised for your new domain controller.
10. Select the AD DS page of Server Manager and review the Roles And Features tile at the bottom of the page to verify that the AD DS role has been installed on SERVER1.
11. Also on the AD DS page, review any critical, error, or warning events raised in the Events tile.
12. Also on the AD DS page, review the status of the services on SERVER1.
13. Also on the AD DS page, initiate a BPA scan of SERVER1 and review the results of this scan when it finishes.
14. Close Server Manager when you are finished.
Exercise 2: Remotely adding an additional domain controller using Windows PowerShell
In this exercise, you join SERVER2 to the corp.contoso.com domain and then use Windows PowerShell from SERVER1 to remotely deploy SERVER2 as an additional domain controller in your domain.
1. Log on locally to SERVER2 using the built-in local Administrator account. A command prompt window should be visible.
2. Type Sconfig in the command prompt window and press Enter to run the Server Configuration Tool (Sconfig.cmd).
3. Type 8 and press Enter to access the Network Adapter Settings page of the Configuration Tool. You are presented with a list of available network adapters that are attached to the server.
4. Type the index number of the adapter that you want to configure and then press Enter. You are presented with the current configuration for the network adapter that you selected.
5. Type 2 and press Enter to configure DNS Server settings for the selected network adapter.
6. Type the IP address for SERVER1 as the new preferred DNS server and press Enter. Then click OK in the dialog box that appears.
7. Press Enter to indicate that you will not be specifying an alternate DNS server.
8. The Configuration Tool returns you to the Network Adapter Settings page. Review the information on this page and make sure it is correct before proceeding. Then type 4 and press Enter to return to the Main Menu page.
9. Type 1 and press Enter and then type D and press Enter to indicate that you want to join SERVER2 to a domain.
10. Type corp.contoso.com as the name of the domain you want SERVER2 to join and then press Enter.
11. Type CORP\Administrator as the name of an authorized user for performing the domain join operation and then press Enter. (If you specified a different NetBIOS name for your domain in Exercise 1, use that name instead of CORP.)
12. In the new command prompt that opens, type the password associated with the user account you specified in the previous step and press Enter.
13. In the Change Computer Name dialog box that opens, click No.
14. In the Restart dialog box that opens, click Yes.
15. After SERVER2 has restarted, log on again using the local Administrator account and run the Server Configuration Tool again to verify that the server has successfully joined the domain. Then exit the Configuration Tool and switch to using SERVER1 for the remainder of this exercise.
16. Log on to SERVER1 with the default domain administrator account and close Server Manager if it opens automatically.
17. Open a Windows PowerShell prompt on SERVER1.
18. Use the Invoke-Command cmdlet with the Get-WindowsFeature cmdlet to remotely review the installed roles and features on SERVER2. Verify that the AD DS role is not yet installed on SERVER2.
19. Use Invoke-Command with Install-WindowsFeature to remotely install the AD DS role on SERVER2. Once this is done, use Get-WindowsFeature to confirm the installation.
20. Use the following command to remotely run a prerequisites check on SERVER2 to make sure the server is ready to be promoted to a domain controller:
Invoke-Command -ComputerName SERVER2 -ScriptBlock `
{Test-ADDSDomainControllerInstallation -DomainName corp.contoso.com `
-Credential (Get-Credential CORP\Administrator)}
Review the results the prerequisites check returns before proceeding.
21. Use the following command to remotely promote SERVER2 as an additional domain controller in the corp.contoso.com domain:
Invoke-Command -ComputerName SERVER2 `
{Install-ADDSDomainController -InstallDNS `
-Credential (Get-Credential CORP\Administrator) `
-DomainName corp.contoso.com}
22. When the promotion operation finishes, wait for SERVER2 to reboot. Then open Server Manager on SERVER1 and add SERVER2 to the server pool.
23. Use the Tools menu of Server Manager to launch the Active Directory Users And Computers console, select the Domain Controllers container under corp.contoso.com, and verify that SERVER2 is now a domain controller for this domain.
Suggested practice exercises
The following additional practice exercises are designed to give you more opportunities to practice what you’ve learned and to help you successfully master the lessons presented in this chapter.
Exercise 1 Continue with the preceding exercises by first using Windows PowerShell to demote SERVER2 and remove AD DS and then using Server Manager to demote SERVER1 and remove AD DS to retire the forest.
Exercise 2 Perform a clean install of Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003, add the AD DS role, and promote the server as the first domain controller in the new forest root domain adatum.com. Use the Adprep.exe tool on your Windows Server 2012 R2 installation media to update the schema and prepare the forest for deploying Windows Server 2012 R2 domain controllers. Then perform an in-place upgrade of the first domain controller to Windows Server 2012 R2.
Answers
This section contains the answers to the lesson review questions in this chapter.
Lesson 1
1. Correct answer: A
A. Correct: Having only one writeable domain controller in a domain is not a best practice. You should have at least two writeable domain controllers in each domain so that if one of them fails, users will still be able to log on and you will still be able to perform AD DS management tasks.
B. Incorrect: Making 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 is a best practice.
C. Incorrect: Keeping the design of your forest simple by having only one domain is a best practice.
D. Incorrect: Installing only the AD DS and DNS Server roles on your domain controllers is a best practice.
2. Correct answers: A, B, and C
A. Correct: The fully qualified domain name (FQDN) for the root domain of your new forest is required information when planning the deployment of the first domain controller in a new forest.
B. Correct: The forest and domain functional levels are required information when planning the deployment of the first domain controller in a new forest.
C. Correct: The location for the AD DS database, log files, and SYSVOL folder is required information when planning the deployment of the first domain controller in a new forest.
D. Incorrect: There is no Domain Admins security group if you haven’t yet deployed the first domain controller in a new forest. Instead, you need the credentials of a member of the local Administrators security group on the server you are promoting to a domain controller.
3. Correct answers: A and D
A. Correct: Creating a DNS delegation is not a required step for AD DS deployments if no external DNS servers will be used to reference the FQDN of your organization’s internal forest.
B. Incorrect: A best practice is for all domain controllers in a domain to have the DNS Server role installed and configured to ensure high availability in distributed environments.
C. Incorrect: A best practice is for all domain controllers in a domain to be configured as global catalog servers to ensure high availability in distributed environments.
D. Correct: Read-only domain controllers require that there be at least one writeable domain controller running Windows Server 2008 or later installed in the domain. Having only writeable domain controllers running Windows Server 2003 is insufficient.
Lesson 2
1. Correct answer: C
A. Incorrect: You need to run the Add Roles And Features Wizard to install the AD DS role on the server before you can run the AD DS Configuration Wizard to promote the server to a domain controller.
B. Incorrect: The Add Roles And Features Wizard is used to install the AD DS role on a server, not to promote the server to a domain controller.
C. Correct: This is the correct procedure.
D. Incorrect: The Add Roles And Features Wizard is used to install the AD DS role on a server, not to promote the server to a domain controller. The AD DS Configuration Wizard is used to promote a server to a domain controller, not to install the AD DS role on the server.
2. Correct answers: A and C
A. Correct: When you use the AD DS Configuration Wizard to deploy the first Windows Server 2012 R2 domain controllers in a domain of a forest whose domain controllers are running earlier Windows Server versions, the Adprep tool automatically runs to prepare the forest and domain by extending the schema to its latest version.
B. Incorrect: Add A Domain Controller To An Existing Domain is the correct option to select on the Deployment Configuration page of the AD DS Configuration Wizard to deploy the first Windows Server 2012 R2 domain controller in an existing forest running an earlier version of Windows Server.
C. Correct: Install From Media (IFM) is a supported deployment method to deploy the first Windows Server 2012 R2 domain controller in an existing forest running an earlier version of Windows Server.
D. Incorrect: You can specify different credentials on the Deployment Configuration page of the AD DS Configuration Wizard if your current logon credentials have insufficient privileges to deploy the first Windows Server 2012 R2 domain controller in an existing forest running an earlier version of Windows Server.
3. Correct answer: D
A. Incorrect: This command is missing the –scope base parameter and therefore does not return the correct result.
B. Incorrect: This command returns the value of the sAMAccountName attribute, which has nothing to do with the schema level.
C. Incorrect: This command works because it returns the values of all attributes for the specified LDAP path, including the desired attribute objectVersion, but it is not the best syntax because it returns too much unnecessary information.
D. Correct: This is the correct command syntax to verify that Adprep has successfully extended your forest’s schema.
Lesson 3
1. Correct answer: B
A. Incorrect: This command displays the contents of the TrustedHosts list on the local server.
B. Correct: This is the correct command syntax.
C. Incorrect: You need to use Set-Item, not Get-Item, to configure the TrustedHosts list on the local server. In addition, the wsman:\ path is incorrect in this command—it should be wsman:\localhost\Client\TrustedHosts.
D. Incorrect: The wsman:\ path is incorrect in this command—it should be wsman:\localhost\Client\TrustedHosts.
2. Correct answer: D
A. Incorrect: Install-ADDSDomain is a cmdlet from the ADDSDeployment module.
B. Incorrect: Install-ADDSDomainController is a cmdlet from the ADDSDeployment module.
C. Incorrect: Uninstall-ADDSDomainController is a cmdlet from the ADDSDeployment module.
D. Correct: Get-ADForest is not a cmdlet from the ADDSDeployment module; it is a cmdlet from the ActiveDirectory module.
3. Correct answer: C
A. Incorrect: The Install-ADDSDomainController cmdlet doesn’t have a –Prerequisites parameter.
B. Incorrect: This command performs a BPA scan on the server and is intended for use after the server has been promoted as a domain controller, not before.
C. Correct: This is the correct command because it runs only the prerequisites check for deploying a domain controller.
D. Incorrect: This command only summarizes the changes that would occur during the deployment process; it doesn’t actually test whether those changes are possible given the current environment like the Test-ADDSDomainControllerInstallation command does.