• 14 Building Webster’s Lab V2 – Create Active Directory

    June 10, 2021

    Active Directory, DHCP, DNS, PowerShell

    [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

    What is Active Directory?

    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.

    What are AD Sites?

    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.

    What are Subnets?

    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.

    What is the AD Recycle Bin?

    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
    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
    • 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
    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
    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
    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
    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
    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
    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
    Figure 8

    Refresh the AD Administrative Center and see that Enable Recycle Bin… greyed out, as shown in Figure 9.

    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
    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
    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
    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
    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
    Figure 14

    We perform the following steps using PowerShell.

    1. Create a new site named after the city where I live
    2. Move the new DC from the default Default-First-Site-Name site to the site created in Step 1
    3. Remove the default Default-First-Site-Name site
    4. 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
    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
    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:

    1. DNS Server
    2. DNS Server Properties
    3. Forward Lookup Zones
    4. Reverse Lookup Zones
    5. 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/)
    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.

    1. Get the IP address for the DC to use as the scavenging server address
    2. Enable aging and scavenging on all zones using the default values
    3. Set the replication scope to all DNS servers in the forest
    4. Set dynamic updates to secure
    5. Set the zone’s aging to the default values and set the DC as the scavenging server
    6. Configure DNS Forwarders
    7. Create a reverse lookup zone named after the subnet created in AD Sites and Services
    8. Set the replication scope to all DCs in the forest
    9. Set dynamic updates to secure
    10. 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
    Figure 18

    Open the DNS console.

    Server Manager, Tools, and click on DNS, as shown in Figure 19.

    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
    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
    Figure 21

    Click the Advanced tab, as shown in Figure 22.

    See that scavenging is enabled and set to 7 days.

    Figure 22
    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
    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
    Figure 24

    As shown in Figure 25, Scavenging is enabled for the zone, and both refresh intervals are set to 7 days.

    Figure 25
    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
    Figure 26

    Verify that the same settings exist for this zone, as shown in Figures 27 and 28.

    Figure 27
    Figure 27
    Figure 28
    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.

    1. The words Scavenge Servers
    2. 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
    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
    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
    Figure 31

    Expand the domain and expand the Lab node, as shown in Figure 32.

    Verify that all the OUs exist.

    Figure 32
    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
    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
    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
    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
    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
    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
    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
    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
    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
    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
    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
    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 44
    Figure 45
    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
    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 47
    Figure 48
    Figure 48

    Exit the ADUC console.

    Now on to installing and configuring DHCP.

    Installing and Configuring DHCP

    We perform the following steps using PowerShell.

    1. Install the DHCP Server role and the DHCP Server Tools
    2. Authorize the new DHCP server in AD
    3. Add the new DHCP server to the DnsUpdateProxy security group
    4. Add DHCP security groups
    5. Set DHCP server DNS settings
    6. Set DHCP Server Network Access Protection policy settings
    7. Set the DNS Dynamic Update Credentials
    8. Set Filters
    9. Set DHCP server options
    10. Set DHCP scope
    11. Set scope options
    12. Set scope DNS settings
    13. Set scope reservations
    14. 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\12 –Name ConfigurationState –Value 2
    
    Figure 49
    Figure 49

    Open the DHCP console.

    Server Manager, Tools, and click on DHCP, as shown in Figure 50.

    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
    Figure 51

    Click the DNS tab and verify that Name Protection is enabled, as shown in Figure 52.

    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
    Figure 53

    Click the Advanced tab and Credentials, as shown in Figure 54.

    Figure 54
    Figure 54

    Verify that the DNS dynamic update credentials are configured, as shown in Figure 55.

    Figure 55
    Figure 55

    Exit the IPv4 Properties.

    Right-click on the scope and click Properties, as shown in Figure 56.

    Figure 56
    Figure 56

    Click the General tab and verify that the Scope configuration is correct, as shown in Figure 57.

    Figure 57
    Figure 57

    Click the DNS tab and verify that Name Protection is enabled, as shown in Figure 58.

    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
    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
    Figure 60

    Click the Scope Options node and verify that the scope options are correct, as shown in Figure 61.

    Figure 61
    Figure 61

    Click the Server Options node and verify that the server options are correct, as shown in Figure 62.

    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
    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
    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
    Figure 65

    Click the DNS tab and click Add…, as shown in Figure 66.

    Figure 66
    Figure 66

    Enter 127.0.0.1 and click Add, as shown in Figure 67.

    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
    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
    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
    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
    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
    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
    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
    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
    Figure 75

    Right-click the network adapter and click Properties, as shown in Figure 76.

    Figure 76
    Figure 76

    Click Internet Protocol Version 4 (TCP/IPv4) and click Properties, as shown in Figure 77.

    Figure 77
    Figure 77

    Click Advanced…, as shown in Figure 78.

    Figure 78
    Figure 78

    Click the DNS tab and click Add…, as shown in Figure 79.

    Figure 79
    Figure 79

    Enter the IP address of the second DC and click Add, as shown in Figure 80.

    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 81
    Figure 82
    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.

    1. The PDCe FSMO Role holder becomes the Primary DNS Server for the domain (PriDNS)
    2. If a remote Site has multiple domain controllers, select a domain controller to be the Primary DNS for the Site (SitePri)

    Domain DNS Configuration:

    1. All domain controllers in the domain’s main Site point to PriDNS for Primary DNS
    2. The PriDNS server points to Loopback for Secondary DNS
    3. The PriDNS server points to a second DNS server in the domain’s main Site for tertiary DNS
    4. All other domain controllers in the domain’s main Site point to themselves for Secondary DNS
    5. All other domain controllers in the domain’s main Site point to Loopback for Tertiary DNS

    Remote Site DNS Configuration:

    1. SitePri points to PriDNS for Primary DNS
    2. SitePri points to itself for Secondary DNS
    3. SitePri points to Loopback for Tertiary DNS
    4. All other domain controllers in the remote Site point to SitePri for Primary DNS
    5. All other domain controllers in the remote Site point to themselves for Secondary DNS
    6. 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
    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
    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
    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
    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
    Figure 87

    Up next: Create a Microsoft Certificate Authority

    Landing page for the article series







    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 Webster

    No comments yet.

    Leave a Reply