-
14 Building Webster’s Lab V2 – Create Active Directory
[Updated 22-Sep-2021]
With the two Server 2019 VMs built for domain controllers, the next step is to create Active Directory (AD). To make sure you understand what I cover in this article, you should understand a few terms.
Definitions
A directory is a hierarchical structure that stores information about objects on the network. A directory service, such as AD, provides the methods for storing directory data and making this data available to network users and administrators. For example, AD stores information about user accounts, such as names, passwords, phone numbers, and so on, and enables other authorized users on the same network to access this information.
AD stores information about objects on the network and makes this information easy for administrators and users to find and use. Active Directory uses a structured data store to form a logical, hierarchical organization of directory information.
This data store, also known as the directory, contains information about AD objects. These objects typically include shared resources such as servers, volumes, printers, and the network user and computer accounts.
What is Domain Name System (DNS)?
DNS is one of the industry-standard suites of protocols that comprise TCP/IP. The DNS Client and DNS Server provide computer name-to-IP address mapping name resolution services to computers and users.
AD uses DNS as its domain controller location mechanism. When any principal AD operations are performed, such as authentication, updating, or searching, computers use DNS to locate Active Directory domain controllers. In addition, domain controllers use DNS to locate each other.
What is the Global Catalog (GC)?
A Domain run by AD can consist of many partitions or naming contexts. The distinguished name (DN) includes enough information to locate a replica of the partition that holds the object. However, the user or application may not know the DN of the target object or which partition might contain the object. The GC allows users and applications to find objects in an AD domain tree, given one or more attributes of the target object.
The global catalog contains a partial replica of every naming context in the directory. It contains the schema and configuration naming contexts as well. This means the GC holds a replica of every object in the directory but with only a small number of their attributes. The attributes in the GC are those most frequently used in search operations (such as a user’s first and last names or login names) and those required to locate a full replica of the object. The GC allows users to quickly find objects of interest without knowing what domain holds them and without requiring a contiguous extended namespace in the enterprise.
What is Flexible Single Master Operations (FSMO)?
AD is the central repository in which all objects in an enterprise and their respective attributes are stored. It’s a hierarchical, multi-master-enabled database that can store millions of objects. Changes to the database can be processed at any given domain controller (DC) in the enterprise, regardless of whether the DC is connected or disconnected from the network.
A multi-master-enabled database, such as AD, provides the flexibility of allowing changes to occur at any DC in the enterprise. But it also introduces the possibility of conflicts that can potentially lead to problems once the data is replicated to the rest of the enterprise. One way Windows deals with conflicting updates is by having a conflict resolution algorithm handle discrepancies in values. It’s done by resolving to the DC to which changes were written last, which is the last writer wins. The changes in all other DCs are discarded. Although this method may be acceptable in some cases, there are times when conflicts are too difficult to resolve using the last writer wins approach. In such cases, it’s best to prevent the conflict from occurring rather than trying to resolve it after the fact.
To prevent conflicting updates in Windows, AD performs updates to certain objects in a single-master fashion. In a single-master model, only one DC in the entire directory is allowed to process updates. It’s similar to the role given to a primary domain controller (PDC) in earlier versions of Windows, such as Microsoft Windows NT 3.51 and 4.0. In earlier versions of Windows, the PDC is responsible for processing all updates in a given domain.
AD extends the single-master model found in earlier versions of Windows to include multiple roles and transfer roles to any DC in the enterprise. Because an AD role isn’t bound to a single DC, it’s referred to as an FSMO role. Currently, in Windows, there are five FSMO roles:
- Schema master
- Domain naming master
- RID master
- PDC emulator
- Infrastructure master
What is Dynamic Host Configuration Protocol (DHCP)?
DHCP is a client/server protocol that automatically provides an Internet Protocol (IP) host with its IP address and other related configuration information. These include the subnet mask and default gateway.
AD sites manage organizations that have branches spread across different geographical locations but fall under the same domain. It is a robust solution to geographically manage an AD network without changing any aspect of the logical structure of the environment. AD sites are physical groupings of well-connected IP subnets used to efficiently replicate information among domain controllers (DC). Image AD sites as a map describing the best routes for replicating in AD, thus efficiently using the available network bandwidth. AD sites help to achieve cost-efficiency and speed. It also lets one exercise better control over the replication traffic and the authentication process. AD sites can locate the closest DC to perform these actions when more than one DC is in the associated site capable of handling client logon, services, and directory searches. Sites also play a role in the deployment and targeting of group policies.
In AD, the information about the topology is stored as site link objects. By default, the Default-First-Site-Name site container is created for the forest. Until another site is created, all DCs are automatically assigned to this site.
Within sites, subnets are entities that help in grouping neighboring computer systems based on their IP addresses. A range of associated IP addresses identifies every subnet, and a site is the aggregate of all well-connected subnets. Subnets could be based on either TCP/IPv4 or TCP/IPv6 protocol addresses.
What is Directory Services Restore Mode (DSRM)?
DSRM is a special boot mode for repairing or recovering Active Directory. Use DSRM to log on to the computer when AD has failed or needs restoring.
What are AD Forest and Domain Functional Levels?
Functional levels determine the available AD domain or forest capabilities. They also determine which Windows Server operating systems you can run on domain controllers in the domain or forest. However, functional levels do not affect which operating systems you can run on workstations and member servers joined to the domain or forest.
When deploying AD, set the domain and forest functional levels to the highest value that your environment can support. This way, you can use as many AD DS features as possible. When you deploy a new forest, you are prompted to set the forest functional level and domain functional level. You can set the domain functional level to a value that is higher than the forest functional level. You cannot set the domain functional level to a lower value than the forest functional level.
The accidental deletion of Active Directory objects is common for AD. Before Windows Server 2008 R2, you could recover accidentally deleted objects in AD, but the solutions had drawbacks.
In Windows Server 2008, you could use the Windows Server Backup feature and ntdsutil authoritative restore command to mark objects as authoritative to ensure that the restored data replicates throughout the domain. The drawback to the authoritative restore solution was that you had to perform it in DSRM. During DSRM, the domain controller used for the restoration had to remain offline. Therefore, it could not service client requests.
In Windows Server 2003 Active Directory and Windows Server 2008 AD DS, you could recover deleted AD objects through tombstone reanimation. However, reanimated objects’ link-valued attributes (for example, group memberships of user accounts) that were physically removed and non-link-valued attributes cleared were not recovered. Therefore, administrators could not rely on tombstone reanimation as the ultimate solution to the accidental deletion of objects. For more information about tombstone reanimation, see Reanimating Active Directory Tombstone Objects.
Starting in Windows Server 2008 R2, AD Recycle Bin builds on the existing tombstone reanimation infrastructure and enhances your ability to preserve and recover accidentally deleted Active Directory objects.
When the AD Recycle Bin is enabled, all link-valued and non-link-valued attributes of the deleted AD objects are preserved. The objects are restored in their entirety to the same consistent logical state they were in immediately before deletion. For example, restored user accounts automatically regain all group memberships and corresponding access rights that they had immediately before deletion, within and across domains.
In Windows Server 2012 and newer, the AD Recycle Bin feature is enhanced with a new graphical user interface to manage and restore deleted objects. Users can now visually locate a list of deleted objects and restore them to their original or desired locations.
Create Forest
The first DC we build is a GC, DNS, and DHCP server. We use PowerShell to install and configure all AD Roles and Features.
Use mstsc to remote into the VM that is our first DC. Exit Server Manager and start an elevated PowerShell session, as shown in Figure 1.
Figure 1 We start by installing the necessary Roles and Features.
- Active Directory Domain Services
- Remote Server Administration Tools
- Role Administration Tools
- Active Directory module for Windows PowerShell
- AD DS and AD LDS Tools
- Active Directory Administrative Center
- AD DS Snap-Ins and Command-Line Tools
- Role Administration Tools
- Telnet Client
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 2.
#setup new AD Forest/Domain Install-WindowsFeature AD-Domain-Services, RSAT-AD-PowerShell, RSAT-ADDS, RSAT-AD-AdminCenter, RSAT-ADDS-Tools, Telnet-Client
Figure 2 We now create the new AD Forest, which automatically creates the first domain. The first domain is also known as the forest root domain. You can never rename this domain without destroying the domain or migrating to a new forest or domain.
Remember to use your domain name.
The first thing we need is the password used for DSRM. This password should be the same for every DC.
The highest forest and domain functional level support is Windows Server 2016. The help text for the Install-ADDSForest cmdlet shows the following allowed values:
-DomainMode (and also for -ForestMode)
The acceptable values for this parameter are:
- Windows Server 2003: 2 or Win2003
- Windows Server 2008: 3 or Win2008
- Windows Server 2008 R2: 4 or Win2008R2
- Windows Server 2012: 5 or Win2012
- Windows Server 2012 R2: 6 or Win2012R2
- Windows Server 2016: 7 or WinThreshold
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 3.
$DomainName = "LabADDomain.com" $NetbiosName = "LabADDomain" $SafeModePwd = Read-Host -AsSecureString -Prompt "Enter DSRM password"
Figure 3 Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 4.
Install-ADDSForest ` -Confirm:$False ` -CreateDnsDelegation:$False ` -DomainMode "WinThreshold" ` -DomainName $DomainName ` -DomainNetbiosName $NetbiosName ` -ForestMode "WinThreshold" ` -SafeModeAdministratorPassword $SafeModePwd #new DC restarts at this point
Figure 4 The local account named Administrator is now the domain account named Administrator, and the password used for the local account is the password used for the domain account.
After the VM restarts, log in using the domain’s Administrator account and password.
Now we can start the debate. The DC promotion process changed the network card’s Preferred DNS Server to 127.0.0.1, the Local Loopback address. My AD mentors taught me over the years that on the first DC, the Preferred DNS Server should be the DC’s IP address, and, at this time, the Loopback address should be Secondary. I recommend changing the DNS servers, as shown in Figure 5.
Figure 5 Next up is enabling the AD Recycle Bin.
AD Recycle Bin
Open the AD Administrative Center.
Server Manager, Tools, and click on Active Directory Administrative Center, as shown in Figure 6.
Figure 6 In the left pane, click on your domain, and in the right pane, you see Enable Recycle Bin…, as shown in Figure 7. We do not use the GUI to enable the recycle bin. We use PowerShell to enable the recycle bin.
Figure 7 Start an elevated PowerShell session.
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 8.
#enable the AD Recycle Bin $DomainName = "LabADDomain.com" Enable-ADOptionalFeature 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target $DomainName -Confirm:$False
Figure 8 Refresh the AD Administrative Center and see that Enable Recycle Bin… greyed out, as shown in Figure 9.
Figure 9 Exit the AD Administrative Center.
Now we set the domain’s password and lockout policy.
Set the Domain’s Password and Lockout Policy
Open the Group Policy Management console.
Server Manager, Tools, and click on Group Policy Management, as shown in Figure 10.
Figure 10 You may want to widen the console and expand the width of the two panes.
In the left pane, expand the Forest node.
Expand Domains.
Expand your domain.
Click on Default Domain Policy, click on the Settings tab in the right pane, and scroll down to the Security Settings section, as shown in Figure 11.
Figure 11 Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 12.
Remember to set the values you need.
#set the domain's password and lockout policy $DomainName = "LabADDomain.com" Set-ADDefaultDomainPasswordPolicy -Identity $DomainName ` -PasswordHistoryCount 6 ` -MaxPasswordAge 90.00:00:00 ` -MinPasswordAge 7.00:00:00 ` -MinPasswordLength 8 ` -ComplexityEnabled $False ` -ReversibleEncryptionEnabled $False ` -LockoutDuration 00:00:00 ` -LockoutObservationWindow 00:00:00 ` -LockoutThreshold 5
Figure 12 Refresh the Group Policy Management console and view the Security Settings in the Default Domain Policy, as shown in Figure 13.
See how the settings in the policy match what we set using PowerShell.
Figure 13 Exit the Group Policy Management console.
Next up is AD Sites and Services.
AD Sites and Services
Open the Active Directory Sites and Services console.
Server Manager, Tools, and click on Active Directory Sites and Services, as shown in Figure 14.
Figure 14 We perform the following steps using PowerShell.
- Create a new site named after the city where I live
- Move the new DC from the default Default-First-Site-Name site to the site created in Step 1
- Remove the default Default-First-Site-Name site
- Create a subnet and link it to the site created in Step 1
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 15.
Remember to set the values you need.
#setup Sites $DomainName = "LabADDomain.com" $ADSites2 = @() #create a new site $ADSites = @{ "Tullahoma" = "Webster's Lab in Tullahoma, TN" } ForEach($ADSite in $ADSites.Keys) { $ADSites2 += $ADSite New-ADReplicationSite -Name $ADSite -Description $ADSites[$ADSite] -ProtectedFromAccidentalDeletion $True -Server $DomainName } #move the new domain controller from the Default-First-Site-Name site to the new site Move-ADDirectoryServer -Identity "LabDC1" -Site "Tullahoma" #remove the Default-First-Site-Name site Remove-ADReplicationSite -Identity "Default-First-Site-Name" -Confirm:$False #create subnets and associate them to a site $Subnets = @{ "Tullahoma" = "192.168.1.0/24" } ForEach($Subnet in $Subnets.Keys) { New-ADReplicationSubnet -Name $Subnets[$Subnet] -Site $Subnet }
Figure 15 Refresh the Active Directory Sites and Services console. Expand the various nodes to verify the changes, as shown in Figure 16.
Figure 16 Note: If you have multiple AD Sites in your lab, please read Report and Edit AD Site Links From PowerShell (Turbo Your AD Replication) for Microsoft’s recommendations on DC replication between AD Sites.
Exit the Sites and Services console.
Now on to the topics that need much discussion: DNS, Aging & Scavenging, and DHCP. This discussion is only necessary if you run Microsoft DHCP and Microsoft DNS on a Microsoft AD domain controller.
Even though we create and configure the DHCP server later, let’s discuss the various settings now.
DNS and DHCP
DNS Aging and Scavenging
The DNS Server service supports Aging and Scavenging features. These features are provided as a mechanism for performing cleanup and removing stale resource records that accumulate in zone data over time.
With dynamic updates, resource records are automatically added to zones when computers start on the network. However, sometimes, they are not automatically removed when computers leave the network. For example, if a computer registers its host (A) resource record at startup and is later improperly disconnected from the network, its host (A) resource record might not be deleted. If your network has mobile users and computers, this situation can occur frequently.
If left unmanaged, the presence of stale resource records in zone data may cause problems:
- If many stale resource records remain in zones, they can eventually take up server disk space and cause unnecessarily long zone transfers.
- DNS servers that load zones that contain stale resource records might use outdated information to answer client queries, potentially causing the clients to experience name resolution problems on the network.
- The accumulation of stale resource records at the DNS server can degrade its performance and responsiveness.
- Sometimes, the presence of a stale resource record in a zone can prevent a DNS domain name from being used by another computer or host device.
The DNS Server service has these features to solve these problems:
- Timestamping, based on the current date and time set at the server computer, for any resource records added dynamically to primary-type zones. Also, timestamps are recorded in standard primary zones where aging and scavenging are enabled.
- A timestamp value of zero is used for manually added resource records, indicating that these records are not affected by the aging process. They can remain without limitation in zone data unless you otherwise change their time stamp or delete them.
- Aging of resource records in local data, based on a specified refresh time period for any eligible zones.
- Only primary-type zones loaded by the DNS Server service are eligible to participate in this process.
- Scavenging for any resource records that persist beyond the specified refresh period.
- When a DNS server performs a scavenging operation, it can determine that resource records have aged to the point of becoming stale and remove them from zone data. You can configure servers to perform recurring scavenging operations automatically, or you can initiate an immediate scavenging operation at the server.
- A highly recommended option is to set an advanced zone parameter that enables you to specify a restricted list of IP addresses for DNS servers enabled to perform scavenging of the zone.
By default, if this parameter is not specified, all DNS servers that load an Active Directory-integrated zone (also enabled for scavenging) attempt to perform scavenging of the zone. Sometimes, this parameter can be helpful if it is preferable that scavenging is performed at some servers loading the directory-integrated zone.
To set this parameter, you must specify the list of IP addresses for the servers enabled to scavenge the zone in the ZoneResetScavengeServers parameter for the zone. You do this using the dnscmd command, a command line-based tool for administering Windows DNS servers.
Microsoft recommends configuring at least one and no more than two DNS servers for scavenging for a zone.
You must enable Aging and Scavenging in five places:
- DNS Server
- DNS Server Properties
- Forward Lookup Zones
- Reverse Lookup Zones
- Then via dnscmd.exe, set a scavenging server
The default Aging and Scavenging interval is 7 days. Seven days is tied to the DHCP Lease Duration, which, by default, is 8 days. A DHCP client requests a lease renewal at 50% of the Lease Duration, or 4 days (by default). If the lease is not renewed, the DHCP Client attempts another lease renewal at 87.5% of the Lease Duration, or 7 days (by default). If the lease is not renewed, the DHCP Client stops requesting a renewal of its IP address and requests a new IP address. If DHCP and DNS are correctly configured (DHCP DNS Dynamic Update Credentials and Secure Dynamic updates), the original DHCP server releases the non-renewed IP address. DNS is updated to show the DNS resource record flagged as eligible to be aged and then scavenged.
By default, the DNS Server does not accept any refreshes of a non-static resource record for7 days.
By default, the DNS Server waits 7 days for the resource record to have its timestamp refreshed.
By default, after these two 7-day intervals (14 days), the resource record is removed from the DNS management console and flagged as tombstoned. The resource record still resides in the AD database.
By default, the resource record is tombstoned for 7 days.
By default, after the 7-day tombstone period has passed, the resource record is marked to be scavenged.
By default, the resource record stays in the “to be scavenged” state for 7 days.
At this time, by default, 28 days have passed since the resource record was not renewed by DHCP and flagged as eligible to be aged and scavenged.
The resource record is purged from the AD database at 2 AM (non-configurable) on day 29 (by default).
At any time in the 28 days (by default), the record is flagged as deleted/tombstoned/scavenged, if the original DHCP Client is granted the original IP address from the original DHCP server, the resource record is reanimated from the scavenge/tombstone state and returned to DNS with an updated timestamp.
If you change the DHCP Lease Duration from the default 7 days, you should carefully consider aging and scavenging effects.
In AD, all domain controllers are equal. Still, the domain controller that holds the Primary Domain Controller Emulator (PDCe) Flexible Single Master Operations (FSMO) role holder is the most equal of all domain controllers. That specific domain controller provides several critical functions in an AD Domain and must be the most stable, reliable, and highly available domain controller in the domain.
All PDC Emulator Functions http://rickardnobel.se/all-pdc-emulator-functions/
Because of the importance of the PDCe FSMO role holder, I recommend making that DC the primary DNS Server.
Select a DNS Server for each domain to serve as a scavenging server for every AD-Integrated Forward and Reverse Lookup Zone.
DNS Forwarders
DNS servers are designed to resolve names for a specific set of computers. DNS calls this “specific set” a zone, but this typically maps to a domain or a forest in a Windows environment. If a DNS server hosts a zone, it is considered authoritative for that zone, and all those computers are considered to be internal to the zone. All other zones are external.
To resolve names for an external zone requires using a forwarder –a DNS server that “knows more” than the local DNS server. By default, external resolution is enabled in Windows DNS servers; however, it can be disabled if desired. Specific servers can be configured to be used as forwarders, or DNS can default to using Root Hints.
A forwarding query only occurs if a DNS server cannot resolve a query using its data or cache. This often occurs when a query for an external name occurs (for example, a DNS server hosting “contoso.local” receives a query for “www.microsoft.com”). Figure 17 depicts the sequence for DNS name resolution.
Figure 17 (Image taken from https://www.mustbegeek.com/understanding-dns-forwarders-and-root-hints-in-windows-dns-server/) You can see where DNS Forwarders and Root Hints take part in name resolution on the above flowchart. DNS Forwarders itself is a list of DNS servers used to help resolve a query. A DNS Forwarder can be a master DNS appliance residing on the internal network or an external DNS server, such as Google or an ISP. The only thing to consider is the network accessibility between the servers (quicker access à better DNS).
DHCP: DNS Dynamic Update Credentials
If Microsoft DHCP runs on a domain controller and a DNS zone is configured for secure dynamic updates, and you do not configure DNS dynamic update credentials DHCP, DNS registrations fail.
DNS dynamic update credentials require no special rights, privileges, or permissions. You should use a regular domain user account following your naming standards.
Create a regular domain user account dedicated for use by DNS dynamic update credentials. You should set the account so the user cannot change the password, and the password should never expire.
I recommend using the account name DNSDynamicUpdateCred. In the Description property for this account, enter the text ” DO NOT CHANGE THE PASSWORD OR DELETE/DISABLE ACCOUNT”.
Once you configure DHCP with the DNS dynamic update credentials, configure all AD-related DNS Forward and Reverse lookup zones to secure dynamic updates only.
You should add this account to the IPv4 protocol on every DHCP server. The DHCP servers do not replicate the account between DHCP servers. If the password for this account is changed, you must enter the updated password on every DHCP server configured to use the account.
DHCP Name Protection
DHCP name protection is a feature of the DHCP service that, when used with Dynamic DNS registration, prevents a DHCP client with a name already in the DNS domain zone from registering or overwriting an existing name that it does not own (known as name squatting). This functionality prevents client and server spoofing and name corruption for statically configured systems already registered in DNS. You enable name protection at either the IPv4 or IPv6 node level or the scope level. When configured at the scope level, the settings take precedence over the IPv4 or IPv6 node settings.
Name squatting could also occur when a non-Windows-based computer registers in Domain Name System (DNS) with a name previously registered to a Windows-based computer. The use of name protection in Windows Server prevents name squatting by non-Windows-based computers. Name squatting does not present a problem on a homogeneous Windows network where Active Directory Domain Services (AD DS) can be used to reserve a name for a single user or computer.
Name protection is based on the Dynamic Host Configuration Identifier (DHCID) in the Dynamic Host Configuration Protocol (DHCP) server and supports the new DHCID RR (resource record) in DNS. DHCID RR is described by the Internet Engineering Task Force (IETF) in RFCs 4701 and 4703.
DHCID is a resource record (RR) stored in DNS that maps names to prevent duplicate registration. DHCP uses this RR to store an identifier for a computer and other information for the name, such as the computer’s A/AAAA records. The unique position of DHCP in the name registration process allows it to request this match and then refuse the registration of a computer with a different address attempting to register a name with an existing DHCID record.
DHCID prevents the following name squatting situations:
- Server name squatting by a client
- Server name squatting by another server
- Client name squatting by another client
- Client name squatting by a server
Using Name Protection requires the following:
- Use DNS Secure Dynamic Updates
- Secure the DnsUpdateProxy security group
- Add the DHCP server to the DnsUpdateProxy security group
Note: Creating the forest and domain created the forward lookup zone named after the domain. No reverse lookup zone exists.
Configure DNS
We perform the following steps using PowerShell.
- Get the IP address for the DC to use as the scavenging server address
- Enable aging and scavenging on all zones using the default values
- Set the replication scope to all DNS servers in the forest
- Set dynamic updates to secure
- Set the zone’s aging to the default values and set the DC as the scavenging server
- Configure DNS Forwarders
- Create a reverse lookup zone named after the subnet created in AD Sites and Services
- Set the replication scope to all DCs in the forest
- Set dynamic updates to secure
- Verify that all forward and reverse lookup zones that are not system created have the scavenging server and aging intervals set
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 18.
Remember to set the values you need.
#configure DNS $DomainName = "LabADDomain.com" $ScavengeServer = @(Get-ADDomainController).IPv4Address Set-DnsServerScavenging ` -ApplyOnAllZones ` -ScavengingState $True ` -ScavengingInterval 7.00:00:00 ` -RefreshInterval 7.00:00:00 ` -NoRefreshInterval 7.00:00:00 Set-DnsServerPrimaryZone -Name $DomainName -ReplicationScope "Forest" Set-DnsServerPrimaryZone -Name $DomainName -DynamicUpdate "Secure" Set-DnsServerZoneAging -Name $DomainName -Aging $True -ScavengeServers $ScavengeServer -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00 Set-DnsServerForwarder -Confirm:$False -IPAddress 1.1.1.1,8.8.8.8,8.8.4.4 -UseRootHint $True ForEach($Subnet in $Subnets.Keys) { Add-DnsServerPrimaryZone -NetworkID $Subnets[$Subnet] -ReplicationScope "Forest" -DynamicUpdate "Secure" } Get-DnsServerZone | Where-Object {$_.IsAutoCreated -eq $False} | Set-DnsServerZoneAging -Aging $True -ScavengeServers $ScavengeServer -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00
Figure 18 Open the DNS console.
Server Manager, Tools, and click on DNS, as shown in Figure 19.
Figure 19 Expand the server node.
The first thing we need to check is verifying that the Trusts Points node exists, as shown in Figure 20.
Side note:
I have seen in my lab and at many customer sites where the Trust Points node did not exist. If the node does not exist, the DC is not seen as a valid DNS server and is not used for name resolution. There is nothing to worry about as the fix is simple.
Run the following commands on the domain controller that holds the PDCe FSMO role from an elevated command prompt.
dnscmd <dcname> /Config /enablednssec 1 net stop dns && net start dns
Refresh the DNS console, and the missing Trust Points node is there.
Figure 20 Right-click the server, click Properties, and click the Forwarders tab, as shown in Figure 21.
The three forwarders are there.
Figure 21 Click the Advanced tab, as shown in Figure 22.
See that scavenging is enabled and set to 7 days.
Figure 22 Click Cancel.
Expand the Forward Lookup Zones node.
Right-click the msdcs.domainname.tld node and click Properties, as shown in Figure 23.
Figure 23 Click the General tab, as shown in Figure 24.
See that Replication is set to All DNS servers in this forest, and Dynamic updates are set to Secure only.
Click Aging.
Figure 24 As shown in Figure 25, Scavenging is enabled for the zone, and both refresh intervals are set to 7 days.
Figure 25 Click Cancel twice.
Verify that the same settings exist for the other forward lookup zone.
Expand Reverse Lookup Zones, right-click on the reverse zone, and click Properties, as shown in Figure 26.
Figure 26 Verify that the same settings exist for this zone, as shown in Figures 27 and 28.
Figure 27 
Figure 28 Click Cancel twice and exit the DNS console.
Open a command prompt and run the following command. You may need to expand the window to see all the results.
dnscmd /zoneinfo <dns domain name>
For me, that is dnscmd /zoneinfo labaddomain.com, as shown in Figure 29.
There are two things I look for.
- The words Scavenge Servers
- The IP address
If those exist and the IP address belongs to the DC that holds the PDCe FSMO role, I know that scavenging is configured correctly.
Figure 29 Exit the command prompt.
We need to create the OU structure for the domain to create groups and users, place users into groups, and install and configure DHCP.
Create the OU Structure
The OU structure used in my lab is:
Lab
Accounts
Admin
Service
Users
Citrix
CVAD2103
Groups
Admin
Users
Horizon
PhysicalPC
RDS
VDI
Infrastructure
Citrix
Microsoft
Parallels
VMware
Parallels
RDS
VDI
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 30. You may want to resize the PowerShell window vertically to see more of the output.
Remember to set the values you need.
#create the OU structure $ADDomain = "LabADDomain" $TLD = "com" $Protect = $True #Create OUs #Top level OU - Lab New-ADOrganizationalUnit -Name "Lab" ` -Path "dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose #Second level OUs under Lab New-ADOrganizationalUnit -Name "Accounts" ` -Path "ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "Citrix" ` -Path "ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "Groups" ` -Path "ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "Horizon" ` -Path "ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "Infrastructure" ` -Path "ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "Parallels" ` -Path "ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose #Third level OUs under Lab/Accounts New-ADOrganizationalUnit -Name "Admin" ` -Path "ou=Accounts,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "Service" ` -Path "ou=Accounts,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "Users" ` -Path "ou=Accounts,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose #Third level OUs under Lab/Citrix New-ADOrganizationalUnit -Name "CVAD2103" ` -Path "ou=Citrix,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose #Third level OUs under Lab/Groups New-ADOrganizationalUnit -Name "Admin" ` -Path "ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "Users" ` -Path "ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose #Third level OUs under Lab/Horizon New-ADOrganizationalUnit -Name "PhysicalPC" ` -Path "ou=Horizon,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "RDS" ` -Path "ou=Horizon,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "VDI" ` -Path "ou=Horizon,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose #Third level OUs under Lab/Infrastructure New-ADOrganizationalUnit -Name "Citrix" ` -Path "ou=Infrastructure,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "Microsoft" ` -Path "ou=Infrastructure,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "Parallels" ` -Path "ou=Infrastructure,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "VMware" ` -Path "ou=Infrastructure,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose #Third level OUs under Lab/Parallels New-ADOrganizationalUnit -Name "RDS" ` -Path "ou=Parallels,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "RemotePC" ` -Path "ou=Parallels,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose New-ADOrganizationalUnit -Name "VDI" ` -Path "ou=Parallels,ou=Lab,dc=$ADDomain,dc=$TLD" ` -ProtectedFromAccidentalDeletion $Protect -verbose
Figure 30 Open the Active Directory Users and Computers console.
Server Manager, Tools, and click on Active Directory Users and Computers (ADUC), as shown in Figure 31.
Figure 31 Expand the domain and expand the Lab node, as shown in Figure 32.
Verify that all the OUs exist.
Figure 32 Now, on to AD Security Groups.
Create AD Security Groups
I place my security groups here in the OU structure.
Lab
Groups
Admin
CtxAdmins
CtxHelpdesk
DEMAdmins
RASAdmins
RASHelpdesk
VMwAdmins
VMwHelpdesk
Users
DEMUsers
H8Users
RASUsers
XAUsers
XDUsers
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 33. You may want to resize the PowerShell window vertically to see more of the output.
Remember to set the values you need.
#admin security groups $ADDomain = "LabADDomain" $TLD = "com" $Protect = $False New-ADGroup -DisplayName "CtxAdmins" ` -GroupCategory "Security" ` -GroupScope "Global" ` -Name "CtxAdmins" ` -Path "ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -SamAccountName "CtxAdmins$" New-ADGroup -DisplayName "CtxHelpdesk" ` -GroupCategory "Security" ` -GroupScope "Global" ` -Name "CtxHelpdesk" ` -Path "ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -SamAccountName "CtxHelpdesk$" New-ADGroup -DisplayName "DEMAdmins" ` -GroupCategory "Security" ` -GroupScope "Global" ` -Name "DEMAdmins" ` -Path "ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -SamAccountName "DEMAdmins$" New-ADGroup -DisplayName "RASAdmins" ` -GroupCategory "Security" ` -GroupScope "Global" ` -Name "RASAdmins" ` -Path "ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -SamAccountName "RASAdmins$" New-ADGroup -DisplayName "RASHelpdesk" ` -GroupCategory "Security" ` -GroupScope "Global" ` -Name "RASHelpdesk" ` -Path "ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -SamAccountName "RASHelpdesk$" New-ADGroup -DisplayName "VMwAdmins" ` -GroupCategory "Security" ` -GroupScope "Global" ` -Name "VMwAdmins" ` -Path "ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -SamAccountName "VMwAdmins$" New-ADGroup -DisplayName "VMwHelpdesk" ` -GroupCategory "Security" ` -GroupScope "Global" ` -Name "VMwHelpdesk" ` -Path "ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -SamAccountName "VMwHelpdesk$" #user security groups New-ADGroup -DisplayName "DEMUsers" ` -GroupCategory "Security" ` -GroupScope "Global" ` -Name "DEMUsers" ` -Path "ou=Users,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -SamAccountName "DEMUsers$" New-ADGroup -DisplayName "H8Users" ` -GroupCategory "Security" ` -GroupScope "Global" ` -Name "H8Users" ` -Path "ou=Users,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -SamAccountName "H8Users$" New-ADGroup -DisplayName "RASUsers" ` -GroupCategory "Security" ` -GroupScope "Global" ` -Name "RASUsers" ` -Path "ou=Users,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -SamAccountName "RASUsers$" New-ADGroup -DisplayName "XAUsers" ` -GroupCategory "Security" ` -GroupScope "Global" ` -Name "XAUsers" ` -Path "ou=Users,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -SamAccountName "XAUsers$" New-ADGroup -DisplayName "XDUsers" ` -GroupCategory "Security" ` -GroupScope "Global" ` -Name "XDUsers" ` -Path "ou=Users,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -SamAccountName "XDUsers$"
Figure 33 Refresh the ADUC console.
Click on Lab/Groups/Admin, and in the right pane, verify the admin security groups exist, as shown in Figure 34.
Figure 34 Click on Lab/Groups/Users, and in the right pane, verify the user security groups exist, as shown in Figure 35.
Figure 35 Now, on to AD User Accounts.
Create AD User Accounts
I place user accounts here in the OU structure.
Lab
Accounts
Admin
CtxAdmin
RASAdmin
UMSAdmin
VMwAdmin
Service
DNSDynamicUpdate
Users
CtxUser1
CtxUser2
CtxUser3
RASUser1
RASUser2
RASUser3
VMwUser1
VMwUser2
VMwUser3
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 36. You may want to resize the PowerShell window vertically to see more of the output.
Remember to set the values you need.
#Create admin user accounts $UserPwd = Read-Host -AsSecureString -Prompt "Enter password" New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "CtxAdmin" ` -Enabled $True ` -Name "CtxAdmin" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Admin,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "CtxAdmin" ` -UserPrincipalName "CtxAdmin@LabADDomain.com" New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "RASAdmin" ` -Enabled $True ` -Name "RASAdmin" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Admin,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "RASAdmin" ` -UserPrincipalName "RASAdmin@LabADDomain.com" New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "UMSAdmin" ` -Enabled $True ` -Name "UMSAdmin" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Admin,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "UMSAdmin" ` -UserPrincipalName "UMSAdmin@LabADDomain.com" New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "VMwAdmin" ` -Enabled $True ` -Name "VMwAdmin" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Admin,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "VMwAdmin" ` -UserPrincipalName VMwAdmin@LabADDomain.com
Figure 36 Refresh the ADUC console.
Click on Lab/Accounts/Admin, and in the right pane, verify the admin user accounts exist, as shown in Figure 37.
Figure 37 Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 38.
Remember to set the values you need.
#create service accounts #Create the service account DNSDynamicUpdate DNS Dynamic Update Credentials account for DHCP New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -Description "DO NOT CHANGE THE PASSWORD OR DELETE/DISABLE ACCOUNT" ` -DisplayName "DNSDynamicUpdate" ` -Enabled $True ` -GivenName "DNSDynamicUpdate" ` -Name "DNSDynamicUpdate" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Service,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "DNSDynamicUpdate" ` -UserPrincipalName "DNSDynamicUpdate@LabADDomain.com" #Create the service account svc_CtxVMware for CVAD hosting connection New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -Description "DO NOT CHANGE THE PASSWORD OR DELETE/DISABLE ACCOUNT" ` -DisplayName "svc_CtxVMware" ` -Enabled $True ` -GivenName "svc_CtxVMware" ` -Name "svc_CtxVMware" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Service,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "svc_CtxVMware" ` -UserPrincipalName "svc_CtxVMware@LabADDomain.com" #Create the service account svc_VMwareHorizon for Horizon vCenter permissions New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -Description "DO NOT CHANGE THE PASSWORD OR DELETE/DISABLE ACCOUNT" ` -DisplayName "svc_VMwareHorizon" ` -Enabled $True ` -GivenName "svc_VMwareHorizon" ` -Name "svc_VMwareHorizon" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Service,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "svc_VMwareHorizon" ` -UserPrincipalName "svc_VMwareHorizon@LabADDomain.com" #Create a service account ldap_query for LDAP Queries New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -Description "DO NOT CHANGE THE PASSWORD OR DELETE/DISABLE ACCOUNT" ` -DisplayName "ldap_query" ` -Enabled $True ` -GivenName "ldap_query" ` -Name "ldap_query" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Service,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "ldap_query" ` -UserPrincipalName "ldap_query@LabADDomain.com"
Figure 38 Refresh the ADUC console.
Click on Lab/Accounts/Service, and in the right pane, verify the service user account exists, as shown in Figure 39.
Figure 39 In the right pane, double-click an account, click on the Account tab, and verify the properties, as shown in Figure 40.
Figure 40 Click Cancel.
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 41. You may want to resize the PowerShell window vertically to see more of the output.
Remember to set the values you need.
#Create lab user accounts New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "CtxUser1" ` -Enabled $True ` -Name "CtxUser1" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "CtxUser1" ` -UserPrincipalName "CtxUser1@LabADDomain.com" New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "CtxUser2" ` -Enabled $True ` -Name "CtxUser2" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "CtxUser2" ` -UserPrincipalName "CtxUser2@LabADDomain.com" New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "CtxUser3" ` -Enabled $True ` -Name "CtxUser3" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "CtxUser3" ` -UserPrincipalName "CtxUser3@LabADDomain.com" New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "RASUser1" ` -Enabled $True ` -Name "RASUser1" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "RASUser1" ` -UserPrincipalName "RASUser1@LabADDomain.com" New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "RASUser2" ` -Enabled $True ` -Name "RASUser2" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "RASUser2" ` -UserPrincipalName "RASUser2@LabADDomain.com" New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "RASUser3" ` -Enabled $True ` -Name "RASUser3" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "RASUser3" ` -UserPrincipalName "RASUser3@LabADDomain.com" New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "VMwUser1" ` -Enabled $True ` -Name "VMwUser1" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "VMwUser1" ` -UserPrincipalName "VMwUser1@LabADDomain.com" New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "VMwUser2" ` -Enabled $True ` -Name "VMwUser2" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "VMwUser2" ` -UserPrincipalName "VMwUser2@LabADDomain.com" New-ADUser -AccountPassword $UserPwd ` -CannotChangePassword $True ` -ChangePasswordAtLogon $False ` -DisplayName "VMwUser3" ` -Enabled $True ` -Name "VMwUser3" ` -PasswordNeverExpires $True ` -PasswordNotRequired $False ` -Path "OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" ` -SamAccountName "VMwUser3" ` -UserPrincipalName "VMwUser@LabADDomain.com"
Figure 41 Refresh the ADUC console.
Click on Lab/Accounts/Users, and in the right pane, verify the user accounts exist, as shown in Figure 42.
Figure 42 Now on to adding admin users to admin security groups.
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 43. You may want to resize the PowerShell window vertically to see more of the output.
Remember to set the values you need.
#add admin users to admin groups Add-ADGroupMember -Identity "CN=CtxAdmins,ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -Members "CN=CtxAdmin,OU=Admin,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" Add-ADGroupMember -Identity "CN=CtxHelpdesk,ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -Members "CN=CtxUser1,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" Add-ADGroupMember -Identity "CN=DEMAdmins,ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -Members "CN=VMwUser1,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" Add-ADGroupMember -Identity "CN=RASAdmins,ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -Members "CN=RASAdmin,OU=Admin,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" Add-ADGroupMember -Identity "CN=RASHelpdesk,ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -Members "CN=RASUser1,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" Add-ADGroupMember -Identity "CN=VMwAdmins,ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -Members "CN=VMwAdmin,OU=Admin,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" Add-ADGroupMember -Identity "CN=VMwHelpdesk,ou=Admin,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -Members "CN=VMwUser1,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD"
Figure 43 Refresh the ADUC console.
Click on Lab/Groups/Admins, and in the right pane, double-click one of the admin security groups and click on the Members tab, as shown in Figures 44 and 45.
Verify that the appropriate admin account exists as a member of the admin security group.
Figure 44 
Figure 45 Now on to adding users to user security groups.
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 46. You may want to resize the PowerShell window vertically to see more of the output.
Remember to set the values you need.
#add lab users to lab user groups Add-ADGroupMember -Identity "CN=DEMUsers,ou=Users,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -Members "CN=VMwUser1,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD","CN=VMwUser2,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD","CN=VMwUser3,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" Add-ADGroupMember -Identity "CN=H8Users,ou=Users,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -Members "CN=VMwUser1,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD","CN=VMwUser2,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD","CN=VMwUser3,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" Add-ADGroupMember -Identity "CN=RASUsers,ou=Users,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -Members "CN=RASUser1,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD","CN=RASUser2,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD","CN=RASUser3,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" Add-ADGroupMember -Identity "CN=XAUsers,ou=Users,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -Members "CN=CtxUser1,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD" Add-ADGroupMember -Identity "CN=XDUsers,ou=Users,ou=Groups,ou=Lab,dc=$ADDomain,dc=$TLD" ` -Members "CN=CtxUser1,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD","CN=CtxUser2,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD","CN=CtxUser3,OU=Users,OU=Accounts,OU=Lab,DC=$ADDomain,DC=$TLD"
Figure 46 Refresh the ADUC console.
Click on Lab/Groups/Users, and in the right pane, double-click one of the user security groups and click on the Members tab, as shown in Figures 47 and 48.
Verify that the appropriate user account exists as a member of the user security group.
Figure 47 
Figure 48 Exit the ADUC console.
Now on to installing and configuring DHCP.
Installing and Configuring DHCP
We perform the following steps using PowerShell.
- Install the DHCP Server role and the DHCP Server Tools
- Authorize the new DHCP server in AD
- Add the new DHCP server to the DnsUpdateProxy security group
- Add DHCP security groups
- Set DHCP server DNS settings
- Set DHCP Server Network Access Protection policy settings
- Set the DNS Dynamic Update Credentials
- Set Filters
- Set DHCP server options
- Set DHCP scope
- Set scope options
- Set scope DNS settings
- Set scope reservations
- Set reservation DNS settings
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 49. You may want to resize the PowerShell window vertically to see more of the output.
Remember to set the values you need.
#install DHCP Install-WindowsFeature DHCP, RSAT-DHCP #authorize the new DHCP server in AD $DHCPServer = "$($env:ComputerName).$($env:USERDNSDOMAIN)" Add-DhcpServerInDC -DnsName $DHCPServer #add new DHCP server to the DnsUpdateProxy security group $computer = "$($env:ComputerName)$" Add-ADGroupMember "DnsUpdateProxy" -members $computer #add DHCP security groups #This command adds the security groups DHCP Users and DHCP Administrators to the DHCP server Add-DhcpServerSecurityGroup -ComputerName $DHCPServer #Set DHCP server DNS settings Set-DhcpServerv4DnsSetting -ComputerName $DHCPServer ` -DynamicUpdates Always ` -NameProtection $True #Set DHCP Server Network Access Protection policy settings Set-DhcpServerSetting -ComputerName $DHCPServer ` -NapEnabled $False ` -ConflictDetectionAttempts 0 ` -ActivatePolicies $False ` -NpsUnreachableAction Full #set the DNS Dynamic Update Credentials $DHCPCredentials = Get-Credential -UserName "DNSDynamicUpdate" -Message "Enter password for DNSDynamicUpdate" Set-DhcpServerDnsCredential -Credential $DHCPCredentials -ComputerName $DHCPServer #set Filters Set-DhcpServerv4FilterList -ComputerName $DHCPServer -Allow $False -Deny $False #set DHCP server options Set-DhcpServerv4OptionValue -ComputerName $DHCPServer ` -DnsServer 192.168.1.201,192.168.1.202 ` -Router 192.168.1.1 ` -Force ` -DnsDomain "LabADDomain.com" #set DHCP scope Add-DhcpServerv4Scope -Name "Webster's Lab" ` -StartRange 192.168.1.100 ` -EndRange 192.168.1.199 ` -SubnetMask 255.255.255.0 ` -ComputerName $DHCPServer ` -LeaseDuration 8.00:00:00 ` -State Active ` -Type DHCP ` -Description "" #set scope options Set-DhcpServerv4OptionValue -ComputerName $DHCPServer ` -ScopeId 192.168.1.0 ` -DnsServer 192.168.1.201,192.168.1.202 ` -Force ` -DnsDomain "LabADDomain.com" ` -Router 192.168.1.1 #Set scope DNS settings Set-DhcpServerv4DnsSetting -ComputerName $DHCPServer ` -ScopeId 192.168.1.0 ` -DynamicUpdates Always ` -NameProtection $True #set scope reservations Add-DhcpServerv4Reservation -Name "APC SmartUPS 2200" ` -ScopeId 192.168.1.0 ` -IPAddress 192.168.1.249 ` -ClientId "28-29-86-1b-f9-b1" ` -Type Both ` -Description "APC SmartUPS 2200" #Set reservation DNS settings Set-DhcpServerv4DnsSetting -ComputerName $DHCPServer ` -IPAddress 192.168.1.249 ` -DynamicUpdates Always Add-DhcpServerv4Reservation -Name "Netgear 1G Switch" ` -ScopeId 192.168.1.0 ` -IPAddress 192.168.1.250 ` -ClientId "28-80-88-6d-51-60" ` -Type Both ` -Description "Netgear 1G Switch" #Set reservation DNS settings Set-DhcpServerv4DnsSetting -ComputerName $DHCPServer ` -IPAddress 192.168.1.250 ` -DynamicUpdates Always Add-DhcpServerv4Reservation -Name "Netgear 10G Switch" ` -ScopeId 192.168.1.0 ` -IPAddress 192.168.1.251 ` -ClientId "3c-37-86-2a-0e-0c" ` -Type Both ` -Description "Netgear 10G Switch" #Set reservation DNS settings Set-DhcpServerv4DnsSetting -ComputerName $DHCPServer ` -IPAddress 192.168.1.251 ` -DynamicUpdates Always #Added 22-Sep-2021 at the request of Jurjen van Leeuwen @Leodesk_IT on Twitter #https://docs.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-deploy-wps#notify-server-manager-that-post-install-dhcp-configuration-is-complete-optional Set-ItemProperty –Path registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager\Roles –Name ConfigurationState –Value 2
Figure 49 Open the DHCP console.
Server Manager, Tools, and click on DHCP, as shown in Figure 50.
Figure 50 Expand the width of the console and the left and middle panes.
Expand the DHCP server.
Expand IPv4.
Right-click IPv4 and click Properties, as shown in Figure 51.
Figure 51 Click the DNS tab and verify that Name Protection is enabled, as shown in Figure 52.
Figure 52 Click the Filters tab and verify the both MAC Filters options are not selected, as shown in Figure 53.
Figure 53 Click the Advanced tab and Credentials, as shown in Figure 54.
Figure 54 Verify that the DNS dynamic update credentials are configured, as shown in Figure 55.
Figure 55 Exit the IPv4 Properties.
Right-click on the scope and click Properties, as shown in Figure 56.
Figure 56 Click the General tab and verify that the Scope configuration is correct, as shown in Figure 57.
Figure 57 Click the DNS tab and verify that Name Protection is enabled, as shown in Figure 58.
Figure 58 Exit the Scope Properties.
Click the Reservations node to verify the creation of the reservations, as shown in Figure 59.
Figure 59 Click the Address Leases node and look in the middle pane to see if the DHCP server is handing out DHCP leases, as shown in Figure 60.
Figure 60 Click the Scope Options node and verify that the scope options are correct, as shown in Figure 61.
Figure 61 Click the Server Options node and verify that the server options are correct, as shown in Figure 62.
Figure 62 Exit the DHCP console.
Even in a lab setup, having only one DC is a recipe for disaster. You should always have at least two DCs.
Create Second DC
Go to the second VM built to use as the second DC.
In Server Manager, click on Local Server.
Click on the IP Address link, as shown in Figure 63.
Figure 63 Right-click the network adapter and click Properties.
Click Internet Protocol Version 4 (TCP/IPv4) and click Properties, as shown in Figure 64.
Figure 64 Change the Preferred DNS server to the IP address of the first DC, the Alternate DNS server to the IP address of this server, and click Advanced…, as shown in Figure 65.
Figure 65 Click the DNS tab and click Add…, as shown in Figure 66.
Figure 66 Enter 127.0.0.1 and click Add, as shown in Figure 67.
Figure 67 Verify that the IP addresses listed are in the order of the first DC, this server, and 127.0.0.1, and click OK, as shown in Figure 68. If they are not in the correct order, use the Up and Down arrows to reorder the list.
Figure 68 Click OK.
Click Close.
We are ready to add a DC to the existing forest/domain. We start by installing the necessary Roles and Features.
- Active Directory Administrative Center
- Active Directory Domain Services
- Active Directory module for Windows PowerShell
- Active Directory Snap-Ins and Command-Line Tools
- Active Directory Tools
- Remote Server Administration Tools
- Role Administration Tools
- Telnet Client
Start an elevated PowerShell session. Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 69.
#add a domain controller Install-WindowsFeature AD-Domain-Services, RSAT-AD-PowerShell, RSAT-ADDS, RSAT-AD-AdminCenter, RSAT-ADDS-Tools, Telnet-Client
Figure 69 Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 70.
$DomainName = "LabADDomain" $SafeModePwd = Read-Host -AsSecureString -Prompt "Enter DSRM password" Install-ADDSDomainController ` -Confirm:$False ` -Credential (Get-Credential "$DomainName\Administrator") ` -DomainName $DomainName ` -InstallDns ` -SafeModeAdministratorPassword $SafeModePwd #new dc reboots
Figure 70 After the VM restarts, log in using the domain’s Administrator account and password.
We are now configuring this DC’s DNS server properties. We configured the zones and zone properties earlier, and this new DC picks up all the configured AD and DNS configurations via AD replication.
Start an elevated PowerShell session. Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 71.
#configure DNS $computer = "$($env:ComputerName)" Set-DnsServerScavenging ` -ComputerName $computer ` -ApplyOnAllZones ` -ScavengingState $True ` -ScavengingInterval 7.00:00:00 ` -RefreshInterval 7.00:00:00 ` -NoRefreshInterval 7.00:00:00 Set-DnsServerForwarder -ComputerName $computer -Confirm:$False -IPAddress 1.1.1.1,8.8.8.8,8.8.4.4 -UseRootHint $True
Figure 71 Open the ADUC console, expand the domain and click on the Domain Controllers OU, as shown in Figure 72. Verify that both DCs exist in the OU.
Figure 72 Close the ADUC console.
Open the Active Directory Sites and Services console, expand Sites, expand the site created earlier, and click on the site, as shown in Figure 73. Verify that the new DC exists in the site.
Figure 73 Close the Active Directory Sites and Services console.
Despite what we might think, the new server is not technically a DC until the NETLOGON and SYSVOL shares are created, populated, and shared.
Open a command prompt on the new DC, type in net share, and press Enter, as shown in Figure 74.
If BOTH the NETLOGON and SYSVOL shares show in the list, the new server is officially a DC. In a large environment, especially if hundreds or thousands of Group Policies exist, it can take hours before SYSVOL appears in the share list.
Figure 74 Now that the second DC is officially a DC, we need to add its IP address to the DNS configuration on the first DC.
Go to the first DC.
In Server Manager, click Local Server, and click the IP Address link for the Etherther interface, as shown in Figure 75.
Figure 75 Right-click the network adapter and click Properties, as shown in Figure 76.
Figure 76 Click Internet Protocol Version 4 (TCP/IPv4) and click Properties, as shown in Figure 77.
Figure 77 Click Advanced…, as shown in Figure 78.
Figure 78 Click the DNS tab and click Add…, as shown in Figure 79.
Figure 79 Enter the IP address of the second DC and click Add, as shown in Figure 80.
Figure 80 Use the arrow buttons to arrange the DNS servers, so the top is the first DC, the middle is the second DC, and the third is the local loopback address, as shown in Figures 81 and 82.
Figure 81 
Figure 82 Click OK, OK, and Close to exit the network adapters properties.
DC NIC Adapter DNS Settings
Why do I care so much about the adapter’s DNS configuration on DCs? Because I rarely see any consistency in the configuration. In most places I go, it looks like every admin built and configured each DC with their own opinion on the configuration. If there are 12 DCs, there are 12 different configurations. There is no one way to set the DNS configuration on DCs. The goal is to set a standard and use it.
As mentioned earlier, DNS is critical to a properly functioning AD. To ensure that DNS contains the proper resource records and registrations in DNS, every domain controller should have a consistent configuration for its DNS servers. You should only include DNS servers that know how to register, process and handle AD-related resource records in the DNS configuration on DCs. You should never use public DNS servers and DNS servers from Internet Service Providers.
There are different recommendations for the following scenarios:
- One Domain, one Site
- One Domain, multiple Sites, single domain controller per Site
- One Domain, multiple Sites, multiple domain controllers per Site
- Multiple Domains, one Site
- Multiple Domains, multiple Sites, single domain controller per Site
- Multiple Domains, multiple Sites, multiple domain controllers per Site
The number one recommendation is to be consistent in how domain controllers have their DNS servers configured.
- The PDCe FSMO Role holder becomes the Primary DNS Server for the domain (PriDNS)
- If a remote Site has multiple domain controllers, select a domain controller to be the Primary DNS for the Site (SitePri)
Domain DNS Configuration:
- All domain controllers in the domain’s main Site point to PriDNS for Primary DNS
- The PriDNS server points to Loopback for Secondary DNS
- The PriDNS server points to a second DNS server in the domain’s main Site for tertiary DNS
- All other domain controllers in the domain’s main Site point to themselves for Secondary DNS
- All other domain controllers in the domain’s main Site point to Loopback for Tertiary DNS
Remote Site DNS Configuration:
- SitePri points to PriDNS for Primary DNS
- SitePri points to itself for Secondary DNS
- SitePri points to Loopback for Tertiary DNS
- All other domain controllers in the remote Site point to SitePri for Primary DNS
- All other domain controllers in the remote Site point to themselves for Secondary DNS
- All other domain controllers in the remote Site point to Loopback for Tertiary DNS
Figure 83 shows the recommended configuration for a single domain with a single site (like the lab we are building).
Figure 83 How many DNS servers should you configure on the network adapter? Not as many as you think. I recommend on DCs, a total of three where the third is always 127.0.0.1. For all other computers, also no more than three. I have seen places with 15 DCs, and every computer had all 15 DCs in the list of DNS servers. If you understand Windows DNS client resolution timeouts, limit the number of DNS entries.
Create Additional DNS A Records
After completing this article and creating the other articles, I realized I completely forgot about all the static DNS A records I mentioned in the introduction article. I am too lazy to rewrite this article and redo screenshots, so I am adding this information at the end of this article.
We create static A records with PowerShell, with the options shown when manually creating an A record, as shown in Figure 84.
Figure 84 Go back to the first DC we created and open an elevated PowerShell session.
Copy and paste the following into the elevated PowerShell session and press Enter, as shown in Figure 85. You may want to resize the PowerShell window vertically to see more of the output.
Remember to set the values you need.
#Do this on the first DC #add the DNS static records I forgot $ZoneName = "LabADDomain.com" Add-DnsServerResourceRecordA -AllowUpdateAny ` -CreatePtr ` -IPv4Address "192.168.1.91" ` -Name "AppLayering" ` -TimeToLive 01:00:00 ` -ZoneName $ZoneName Add-DnsServerResourceRecordA -AllowUpdateAny ` -CreatePtr ` -IPv4Address "192.168.1.253" ` -Name "DiskStation1" ` -TimeToLive 01:00:00 ` -ZoneName $ZoneName Add-DnsServerResourceRecordA -AllowUpdateAny ` -CreatePtr ` -IPv4Address "192.168.1.254" ` -Name "DiskStation2" ` -TimeToLive 01:00:00 ` -ZoneName $ZoneName Add-DnsServerResourceRecordA -AllowUpdateAny ` -CreatePtr ` -IPv4Address "192.168.1.53" ` -Name "ESXiHost1" ` -TimeToLive 01:00:00 ` -ZoneName $ZoneName Add-DnsServerResourceRecordA -AllowUpdateAny ` -CreatePtr ` -IPv4Address "192.168.1.57" ` -Name "EsxiHost2" ` -TimeToLive 01:00:00 ` -ZoneName $ZoneName Add-DnsServerResourceRecordA -AllowUpdateAny ` -CreatePtr ` -IPv4Address "192.168.1.61" ` -Name "EsxiHost3" ` -TimeToLive 01:00:00 ` -ZoneName $ZoneName Add-DnsServerResourceRecordA -AllowUpdateAny ` -CreatePtr ` -IPv4Address "192.168.1.65" ` -Name "EsxiHost4" ` -TimeToLive 01:00:00 ` -ZoneName $ZoneName Add-DnsServerResourceRecordA -AllowUpdateAny ` -CreatePtr ` -IPv4Address "192.168.1.69" ` -Name "EsxiHost5" ` -TimeToLive 01:00:00 ` -ZoneName $ZoneName Add-DnsServerResourceRecordA -AllowUpdateAny ` -CreatePtr ` -IPv4Address "192.168.1.73" ` -Name "EsxiHost6" ` -TimeToLive 01:00:00 ` -ZoneName $ZoneName Add-DnsServerResourceRecordA ` -AllowUpdateAny ` -CreatePtr ` -IPv4Address "192.168.1.90" ` -Name "vCenter" ` -TimeToLive 01:00:00 ` -ZoneName $ZoneName
Figure 85 Open the DNS console, expand the domain name’s Forward Lookup Zone, and verify that the static A records exist, as shown in Figure 86.
Figure 86 Expand Reverse Lookup Zones, click on the reverse zone created earlier, and verify that the static PTR records exist, as shown in Figure 87.
Figure 87
About Carl Webster
Carl Webster is an independent consultant specializing in Citrix, Active Directory, and technical documentation. Carl (aka “Webster”) serves the broader Citrix community by writing articles (see CarlWebster.com) and by being the most active person in the Citrix Zone on Experts Exchange. Webster has a long history in the IT industry beginning with mainframes in 1977, PCs and application development in 1986, and network engineering in 2001. He has worked with Citrix products since 1990 with the premiere of their first product – the MULTIUSER OS/2.
View all posts by Carl WebsterSubscribe
Subscribe to our e-mail newsletter to receive updates.
June 10, 2021
Active Directory, DHCP, DNS, PowerShell