How-To: Windows Server 2025 Active Directory Installation with Best Practices

Introduction

Hi everyone, and welcome to Techaptic.

Adding the Active Directory Domain Services role to Windows Server is relatively easy and takes only a few minutes. However, transforming that server into a secure, scalable, and reliable Domain Controller architecture that can operate with minimal issues for many years requires a very different level of planning.

In this video, instead of rushing through the standard installation wizard and accepting every default setting, we will build the environment according to enterprise-oriented Active Directory best practices from the beginning.

We will cover server naming, static IP addressing, Domain Controller DNS client configuration, DNS cross-mapping, disk separation for the NTDS database and transaction logs, Active Directory domain naming, forest and domain functional levels, Directory Services Restore Mode, reverse DNS, secure dynamic updates, Active Directory Recycle Bin, time synchronization, the new 32 KB Active Directory database page architecture in Windows Server 2025, DNS health checks, FSMO role verification, backup recommendations, and Domain Controller redundancy.

If you are ready, let’s get started.

𝗥𝗘𝗩𝗜𝗘𝗪𝗜𝗡𝗚 𝗧𝗛𝗘 𝗗𝗢𝗠𝗔𝗜𝗡 𝗖𝗢𝗡𝗧𝗥𝗢𝗟𝗟𝗘𝗥 𝗛𝗔𝗥𝗗𝗪𝗔𝗥𝗘

Before beginning the configuration, let’s quickly review the hardware allocated to this Windows Server 2025 virtual machine.

We assigned four processor cores.

We created three disks. One disk will contain the Windows operating system, while the other two disks will be used for the Active Directory database and transaction log files.

We assigned 4 GB of memory for this lab environment.

The network adapter operates at 1 Gbps, which is sufficient for this demonstration.

These values are appropriate for a small lab, but they should not be considered universal sizing recommendations for a production Domain Controller.

The required CPU, memory, storage, and network resources depend on the number of users, computers, groups, sites, trusts, authentication requests, Group Policy objects, DNS activity, replication traffic, security software, monitoring agents, backup processes, and additional roles installed on the server.

In a production environment, use current Microsoft sizing guidance and monitor the actual workload after deployment.

𝗔𝗦𝗦𝗜𝗚𝗡𝗜𝗡𝗚 𝗔 𝗣𝗥𝗢𝗣𝗘𝗥 𝗦𝗘𝗥𝗩𝗘𝗥 𝗡𝗔𝗠𝗘

The first configuration is the Windows Server computer name.

A Domain Controller should have a meaningful and stable name before Active Directory Domain Services is installed.

Renaming a server after it has been promoted to a Domain Controller is possible in supported scenarios, but it introduces unnecessary complexity. It is much better to choose the correct name before promotion.

Right-click the Start menu and open System.

Select the option to rename this PC.

Enter an appropriate server name. For example, you might use a naming convention such as DC01, HQ-DC01, IST-DC01, or another format that matches your organization’s server standards.

Avoid using a name that is too long, difficult to understand, temporary, or tied to a person.

After entering the new computer name, click Next.

Windows requires a restart before the new name becomes active.

Restart the server and sign in again after it boots.

𝗔𝗦𝗦𝗜𝗚𝗡𝗜𝗡𝗚 𝗔 𝗦𝗧𝗔𝗧𝗜𝗖 𝗜𝗣 𝗔𝗗𝗗𝗥𝗘𝗦𝗦

The second configuration is the network address.

A Domain Controller and DNS server should use a static IP address.

Allowing the address to change unexpectedly can cause DNS registration, client communication, replication, authentication, monitoring, firewall, and management problems.

Open the Start menu and search for Control Panel.

Open Control Panel and go to Network and Sharing Center.

Select Change adapter settings.

Double-click the active network adapter and select Properties.

Open Internet Protocol Version 4, or TCP/IPv4.

Select Use the following IP address.

Enter the static IP address, subnet mask, and default gateway assigned to this Domain Controller.

In this example, the Domain Controller uses an address such as 172.16.10.10.

Use values that are valid for your own network design.

Make sure that the selected IP address is excluded from the DHCP scope or otherwise protected from being assigned to another device.

𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗗𝗡𝗦 𝗢𝗡 𝗧𝗛𝗘 𝗙𝗜𝗥𝗦𝗧 𝗗𝗢𝗠𝗔𝗜𝗡 𝗖𝗢𝗡𝗧𝗥𝗢𝗟𝗟𝗘𝗥

DNS configuration is one of the most important parts of an Active Directory deployment.

Active Directory depends heavily on DNS to locate Domain Controllers, Kerberos services, Global Catalog servers, LDAP services, and other domain resources.

For the first Domain Controller in a brand-new forest, no other internal Active Directory DNS server exists yet.

During the initial setup, the preferred DNS server can point to the server’s own static IP address.

The alternate DNS server can use the loopback address, 127.0.0.1, or another supported self-reference according to the design.

This temporary configuration is suitable while the first Domain Controller is the only Active Directory DNS server.

Do not configure a Domain Controller to use a public DNS resolver, such as an ISP DNS server or a public internet DNS service, as its preferred DNS client server.

External name resolution should be handled through DNS forwarders or root hints on the internal DNS service, not by bypassing Active Directory DNS.

𝗪𝗛𝗬 𝗢𝗡𝗘 𝗗𝗢𝗠𝗔𝗜𝗡 𝗖𝗢𝗡𝗧𝗥𝗢𝗟𝗟𝗘𝗥 𝗜𝗦 𝗡𝗢𝗧 𝗘𝗡𝗢𝗨𝗚𝗛

A production Active Directory environment should not depend on a single Domain Controller.

A single Domain Controller creates a major availability and recovery risk.

If the server fails, becomes corrupted, is isolated by the network, or requires maintenance, users may be unable to authenticate and computers may be unable to locate domain services.

For an enterprise environment, deploy at least one additional Domain Controller as soon as possible.

Both Domain Controllers should also host the DNS Server role unless the architecture has a documented reason to use a different design.

Additional Domain Controllers provide authentication redundancy, DNS availability, replication partners, maintenance flexibility, and faster recovery from a server failure.

In environments with multiple sites, additional Domain Controllers may also be deployed according to site connectivity, user count, security requirements, and business continuity needs.

𝗨𝗡𝗗𝗘𝗥𝗦𝗧𝗔𝗡𝗗𝗜𝗡𝗚 𝗗𝗡𝗦 𝗖𝗥𝗢𝗦𝗦-𝗠𝗔𝗣𝗣𝗜𝗡𝗚

After the second Domain Controller has been installed and DNS replication is working, the DNS client settings should be reviewed.

Let’s use a simple example.

The first Domain Controller is named DC1 and uses the IP address 172.16.10.10.

The additional Domain Controller is named DC2 and uses the IP address 172.16.10.20.

Instead of configuring each Domain Controller to use only itself as the preferred DNS server, we can cross-map their DNS client settings.

DC1 can use 172.16.10.20, which is DC2, as its preferred DNS server.

DC1 can then use its own address or the loopback address as the alternate DNS server.

DC2 can use 172.16.10.10, which is DC1, as its preferred DNS server.

DC2 can then use its own address or the loopback address as the alternate DNS server.

With this configuration, each Domain Controller first queries its replication partner for DNS and retains itself as an alternate.

This is commonly referred to as DNS cross-mapping.

𝗣𝗥𝗘𝗩𝗘𝗡𝗧𝗜𝗡𝗚 𝗔 𝗗𝗡𝗦 𝗜𝗦𝗟𝗔𝗡𝗗 𝗦𝗖𝗘𝗡𝗔𝗥𝗜𝗢

Why do we use cross-mapping?

During startup, Active Directory Domain Services and DNS may depend on records that are stored in Active Directory-integrated DNS zones.

If a Domain Controller can query only itself and its local DNS or Active Directory services are not fully available yet, service startup and name resolution may be delayed.

Historically, certain configurations could contribute to a DNS island condition, where a Domain Controller could not locate other Domain Controllers or required DNS records correctly.

Using another healthy Domain Controller as the preferred DNS server reduces that dependency during startup.

For DC1, configure DC2 as the preferred DNS server and keep DC1 itself as the alternate.

For DC2, configure DC1 as the preferred DNS server and keep DC2 itself as the alternate.

The exact order may vary according to Microsoft guidance, site design, Domain Controller roles, and operational requirements, but every Domain Controller should use only internal Active Directory-aware DNS servers.

Clients should also receive internal DNS server addresses through DHCP or static configuration.

𝗖𝗢𝗥𝗥𝗘𝗖𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗗𝗘𝗙𝗔𝗨𝗟𝗧 𝗚𝗔𝗧𝗘𝗪𝗔𝗬

Return to the IPv4 configuration and review all values before saving.

In this demonstration, the default gateway was entered incorrectly at first.

Correct the gateway so that it points to the router or Layer 3 interface responsible for the Domain Controller’s subnet.

A wrong default gateway may prevent the server from reaching other networks, update services, time sources, monitoring systems, backup infrastructure, or external DNS forwarders.

Click OK to save the network configuration.

You can verify the final settings by using the Windows network interface or the ipconfig /all command.

𝗣𝗟𝗔𝗡𝗡𝗜𝗡𝗚 𝗔𝗖𝗧𝗜𝗩𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗗𝗜𝗦𝗞 𝗦𝗘𝗣𝗔𝗥𝗔𝗧𝗜𝗢𝗡

The next configuration is disk separation.

We created two additional disks for Active Directory.

One disk will contain the NTDS database.

The other disk will contain the Active Directory transaction logs.

The Active Directory database file is named ntds.dit.

The database contains directory objects, attributes, security information, and other Active Directory data.

The transaction logs record database changes and are used to maintain consistency and support recovery operations.

The database and log files have different I/O characteristics.

The database can perform random reads and writes.

The transaction logs are more sequential and write-oriented.

Separating them can improve organization, monitoring, capacity planning, and potentially storage performance when the underlying storage is genuinely separated.

In a production environment, separate drive letters on the same physical disk do not provide true performance or failure isolation.

The physical disks, virtual storage, RAID, SAN, hypervisor datastore, redundancy, latency, backup design, and failure domains are equally important.

𝗜𝗡𝗜𝗧𝗜𝗔𝗟𝗜𝗭𝗜𝗡𝗚 𝗧𝗛𝗘 𝗔𝗖𝗧𝗜𝗩𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗗𝗜𝗦𝗞𝗦

Open the Start menu and launch Computer Management.

Select Disk Management.

Windows detects the new disks and asks us to initialize them.

Initialize the disks using the partition style appropriate for the server and disk size. GPT is generally suitable for modern Windows Server deployments.

For the first 30 GB disk, create a New Simple Volume.

Continue through the wizard.

Assign the drive letter N.

Use a meaningful volume label such as NTDS.

Select NTFS as the file system and enable Perform a quick format.

Click Next and then Finish.

For the second disk, create another simple volume.

Assign the drive letter L.

Use a meaningful volume label such as LOGS or NTDS-LOGS.

Format the volume as NTFS and complete the wizard.

The N drive will hold the Active Directory database.

The L drive will hold the Active Directory transaction log files.

𝗜𝗡𝗦𝗧𝗔𝗟𝗟𝗜𝗡𝗚 𝗔𝗖𝗧𝗜𝗩𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗗𝗢𝗠𝗔𝗜𝗡 𝗦𝗘𝗥𝗩𝗜𝗖𝗘𝗦

We are now ready to install the Active Directory Domain Services role.

Open Server Manager.

In the upper-right corner, select Manage and then Add Roles and Features.

Click Next on the introduction page.

Select Role-based or feature-based installation.

Click Next.

Select the local Windows Server from the server pool.

Because this is the server that will become the first Domain Controller, continue with the selected server.

On the Server Roles page, select Active Directory Domain Services.

The wizard asks to add the management tools and supporting features required by Active Directory Domain Services.

Click Add Features.

Also select DNS Server because this first Domain Controller will provide the internal DNS service required by Active Directory.

Accept the supporting DNS features.

Click Next.

No additional Windows features are required for this demonstration, so continue through the Features page.

Review the Active Directory Domain Services and DNS Server information pages.

Click Install.

The wizard installs the required role binaries and management tools.

𝗣𝗥𝗢𝗠𝗢𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗘𝗥𝗩𝗘𝗥 𝗧𝗢 𝗔 𝗗𝗢𝗠𝗔𝗜𝗡 𝗖𝗢𝗡𝗧𝗥𝗢𝗟𝗟𝗘𝗥

Installing the role does not yet make the server a Domain Controller.

After the role installation completes, click the notification flag in Server Manager.

Select Promote this server to a Domain Controller.

The Active Directory Domain Services Configuration Wizard opens.

The wizard provides three deployment choices.

We can add a Domain Controller to an existing domain.

We can add a new domain to an existing forest.

Or we can create a new forest.

Because this is the first Domain Controller and no Active Directory forest exists yet, select Add a new forest.

𝗖𝗛𝗢𝗢𝗦𝗜𝗡𝗚 𝗔 𝗣𝗥𝗢𝗣𝗘𝗥 𝗔𝗖𝗧𝗜𝗩𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗗𝗢𝗠𝗔𝗜𝗡 𝗡𝗔𝗠𝗘

Enter the root domain name.

In this demonstration, we will use ad.techaptic.com.

Domain naming is one of the most important and difficult-to-change decisions in an Active Directory implementation.

Avoid choosing a name without considering public DNS ownership, certificates, cloud integration, user sign-in names, application compatibility, and future organizational requirements.

Older Active Directory deployments frequently used non-public suffixes such as .local or other invented internal names.

Those suffixes are not publicly registrable and cannot normally be validated by a public certificate authority.

They can also complicate certificate deployment, cloud integration, hybrid identity, and name resolution.

A better approach is to use a subdomain of a public DNS domain that the organization owns.

Because Techaptic owns or controls the techaptic.com namespace, ad.techaptic.com can be used as the internal Active Directory DNS name.

The prefix does not have to be ad. Other examples include corp.example.com, internal.example.com, or directory.example.com.

The important point is that the parent DNS domain should be controlled by the organization and the namespace should be planned before deployment.

𝗔𝗩𝗢𝗜𝗗𝗜𝗡𝗚 𝗔 𝗙𝗟𝗔𝗧 𝗦𝗣𝗟𝗜𝗧-𝗕𝗥𝗔𝗜𝗡 𝗗𝗡𝗦 𝗗𝗘𝗦𝗜𝗚𝗡

Why are we using ad.techaptic.com instead of techaptic.com?

If the internal Active Directory domain is created with the same name as the organization’s public website domain, internal DNS becomes authoritative for the entire namespace.

This creates a split-brain DNS design.

Split-brain DNS can be implemented successfully when it is intentionally designed and maintained. However, it requires internal copies of the public records that internal users must access.

For example, if the internal zone is techaptic.com, the internal DNS server will consider itself authoritative for www.techaptic.com.

If the corresponding www record is not created internally, users may be unable to open the public website.

Using ad.techaptic.com keeps the Active Directory namespace separate from the public root zone and reduces the number of duplicate public records that must be maintained internally.

It also provides a cleaner foundation for future hybrid identity and cloud integrations.

For this environment, enter ad.techaptic.com and click Next.

𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗧𝗛𝗘 𝗙𝗢𝗥𝗘𝗦𝗧 𝗔𝗡𝗗 𝗗𝗢𝗠𝗔𝗜𝗡 𝗙𝗨𝗡𝗖𝗧𝗜𝗢𝗡𝗔𝗟 𝗟𝗘𝗩𝗘𝗟𝗦

The Domain Controller Options page allows us to select the forest and domain functional levels.

For a new environment, choose the newest functional level that is supported by all Domain Controllers and required applications in the forest.

Because this is a new Windows Server 2025 forest and we want to use Windows Server 2025 Active Directory capabilities, select the Windows Server 2025 forest and domain functional levels where available.

Do not raise functional levels without confirming that every Domain Controller, application, identity product, backup solution, and management tool supports them.

The first Domain Controller should also be configured as a DNS server and a Global Catalog server.

The Read Only Domain Controller option should remain disabled because this server is the first writable Domain Controller in the forest.

𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗧𝗛𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗦𝗘𝗥𝗩𝗜𝗖𝗘𝗦 𝗥𝗘𝗦𝗧𝗢𝗥𝗘 𝗠𝗢𝗗𝗘 𝗣𝗔𝗦𝗦𝗪𝗢𝗥𝗗

Enter a strong Directory Services Restore Mode, or DSRM, password.

DSRM is a special recovery mode used for offline Active Directory maintenance, authoritative or non-authoritative restore operations, database repair, and certain troubleshooting procedures.

It can be considered the Active Directory equivalent of a specialized recovery environment.

The DSRM password is separate from normal domain user passwords.

Store it securely in an approved password vault.

Do not use a weak, predictable, shared, or undocumented password.

The password may be required during a critical recovery situation when normal domain authentication is unavailable.

Confirm the DSRM password and click Next.

𝗥𝗘𝗩𝗜𝗘𝗪𝗜𝗡𝗚 𝗧𝗛𝗘 𝗗𝗡𝗦 𝗗𝗘𝗟𝗘𝗚𝗔𝗧𝗜𝗢𝗡 𝗪𝗔𝗥𝗡𝗜𝗡𝗚

The wizard may display a warning explaining that a DNS delegation cannot be created.

This is expected when the parent DNS zone is not hosted on an accessible Windows DNS server or no delegation has been prepared.

Because this is a new forest and the internal DNS zone will be created during promotion, the warning does not necessarily block the installation.

In a larger or delegated DNS design, the parent zone administrator may need to create the appropriate delegation.

Review the warning according to your environment and click Next.

𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗧𝗛𝗘 𝗡𝗘𝗧𝗕𝗜𝗢𝗦 𝗗𝗢𝗠𝗔𝗜𝗡 𝗡𝗔𝗠𝗘

The wizard automatically suggests a NetBIOS domain name.

The NetBIOS name provides compatibility with legacy domain naming and sign-in formats.

For ad.techaptic.com, the wizard may suggest AD or another available short name.

The proposed name is acceptable for this demonstration.

Make sure that the selected NetBIOS name does not conflict with another trusted domain or existing environment.

Click Next.

𝗦𝗘𝗣𝗔𝗥𝗔𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗡𝗧𝗗𝗦 𝗗𝗔𝗧𝗔𝗕𝗔𝗦𝗘 𝗔𝗡𝗗 𝗟𝗢𝗚 𝗙𝗜𝗟𝗘𝗦

The Paths page allows us to define the locations of the Active Directory database, log files, and SYSVOL folder.

By default, all of these components are placed on the system drive.

The default configuration can work, especially in small environments, but we prepared separate disks to create a more organized structure.

Open the N drive and create a folder such as N:\NTDS\Data.

Open the L drive and create a folder such as L:\NTDS\Logs.

Return to the wizard.

Set the database folder to N:\NTDS\Data.

Set the log files folder to L:\NTDS\Logs.

The NTDS database performs random read and write operations.

The transaction logs are primarily sequential and write-oriented.

Separating them can reduce contention when the underlying storage is also separated.

It can also simplify capacity monitoring and recovery procedures.

𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗬𝗦𝗩𝗢𝗟 𝗟𝗢𝗖𝗔𝗧𝗜𝗢𝗡

The SYSVOL folder contains Group Policy templates, scripts, and other files that must replicate between Domain Controllers.

SYSVOL does not normally generate the same heavy I/O pattern as the NTDS database and transaction logs.

For this environment, we will leave SYSVOL on the default system drive.

In a production environment, the final path decision should consider storage resilience, monitoring, backup, antivirus exclusions, recovery procedures, and Microsoft support guidance.

Click Next.

𝗥𝗘𝗩𝗜𝗘𝗪𝗜𝗡𝗚 𝗧𝗛𝗘 𝗔𝗖𝗧𝗜𝗩𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗔𝗧𝗜𝗢𝗡

The wizard displays a summary of the selected configuration.

Review the root domain name, forest and domain functional levels, DNS Server option, Global Catalog setting, DSRM configuration, NetBIOS name, and folder paths.

You can also export the configuration as a PowerShell script for documentation or automated deployments.

Click Next.

The wizard runs prerequisite checks.

Wait for every check to complete.

In this environment, the prerequisite checks pass successfully.

The DNS delegation warning can be accepted for this new forest because the DNS zone will be created during promotion.

Click Install.

The server installs Active Directory Domain Services, creates the forest and domain, configures DNS, creates the NTDS database, initializes SYSVOL, and promotes itself to a Domain Controller.

After the operation finishes, Windows restarts automatically.

𝗦𝗜𝗚𝗡𝗜𝗡𝗚 𝗜𝗡 𝗔𝗙𝗧𝗘𝗥 𝗗𝗢𝗠𝗔𝗜𝗡 𝗖𝗢𝗡𝗧𝗥𝗢𝗟𝗟𝗘𝗥 𝗣𝗥𝗢𝗠𝗢𝗧𝗜𝗢𝗡

After the restart, sign in using the new domain administrator context.

The sign-in screen should now display the domain name or allow the domain account format.

Server Manager may take a short time to load because Active Directory, DNS, Netlogon, Kerberos, and other services are starting.

Confirm that the Active Directory Domain Services and DNS Server roles appear in Server Manager.

The server is now the first Domain Controller in the new forest.

However, several post-installation configurations should still be completed.

𝗖𝗥𝗘𝗔𝗧𝗜𝗡𝗚 𝗔 𝗥𝗘𝗩𝗘𝗥𝗦𝗘 𝗗𝗡𝗦 𝗟𝗢𝗢𝗞𝗨𝗣 𝗭𝗢𝗡𝗘

The next configuration is the reverse DNS lookup zone.

Forward DNS lookup zones resolve hostnames to IP addresses.

Reverse DNS lookup zones resolve IP addresses back to hostnames through PTR records.

A reverse lookup zone is strongly recommended in many enterprise environments.

It improves log readability and can be useful for monitoring systems, security tools, network troubleshooting, certain application checks, and mail server validation.

Open the Start menu and search for DNS.

Launch DNS Manager.

Expand the DNS server and right-click Reverse Lookup Zones.

Select New Zone.

Click Next.

Select Primary zone.

Because this Domain Controller uses Active Directory-integrated DNS, keep the option to store the zone in Active Directory where available.

Click Next.

Select the replication scope appropriate for the environment. For a simple single-domain forest, replicating to all DNS servers in the domain is a common choice.

Select IPv4 Reverse Lookup Zone.

Click Next.

𝗗𝗘𝗙𝗜𝗡𝗜𝗡𝗚 𝗧𝗛𝗘 𝗥𝗘𝗩𝗘𝗥𝗦𝗘 𝗗𝗡𝗦 𝗡𝗘𝗧𝗪𝗢𝗥𝗞 𝗜𝗗

Enter the network ID.

For the example subnet 172.16.10.0/24, enter the first three octets: 172.16.10.

The wizard creates the reverse zone in the format 10.16.172.in-addr.arpa.

This reverse order is normal for IPv4 reverse DNS.

Click Next.

Select Allow only secure dynamic updates.

Secure dynamic updates allow authenticated domain members and approved processes to update records while preventing unauthenticated systems from modifying the Active Directory-integrated zone.

Click Next and then Finish.

The reverse lookup zone is now available.

When creating or updating an A record, select Create associated pointer, or PTR, record when appropriate.

This allows DNS Manager to create the matching reverse record automatically.

𝗣𝗥𝗘𝗣𝗔𝗥𝗜𝗡𝗚 𝗧𝗛𝗘 𝗔𝗖𝗧𝗜𝗩𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗢𝗣𝗧𝗜𝗠𝗜𝗭𝗔𝗧𝗜𝗢𝗡 𝗦𝗖𝗥𝗜𝗣𝗧

The next step is to apply several post-installation configurations through PowerShell.

We prepared a PowerShell script that can be reviewed and downloaded from the Techaptic website.

The script performs three main tasks for this lab.

First, it enables the Active Directory Recycle Bin.

Second, it applies the intended DNS client configuration for this first Domain Controller.

Third, it configures the authoritative external time source for the forest root PDC Emulator.

The script should be reviewed and adapted before use in another environment.

Do not run infrastructure scripts without understanding every command and confirming that the values match your own domain, server name, IP address, DNS design, and NTP policy.

𝗘𝗡𝗔𝗕𝗟𝗜𝗡𝗚 𝗧𝗛𝗘 𝗔𝗖𝗧𝗜𝗩𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗥𝗘𝗖𝗬𝗖𝗟𝗘 𝗕𝗜𝗡

The first configuration enabled by the script is Active Directory Recycle Bin.

Without Active Directory Recycle Bin, recovering an accidentally deleted object may require an authoritative restore, backup restoration, or more complex recovery process.

After Active Directory Recycle Bin is enabled, deleted objects retain many of their important attributes for the configured deleted-object lifetime.

This makes it easier to restore users, groups, computers, and organizational units without performing a full database restore.

In this environment, deleted objects can be retained for a period such as 180 days, depending on the forest configuration.

Active Directory Recycle Bin should be enabled early in the life of the forest.

Enabling it is a forest-wide and irreversible operation. After it is enabled, it cannot be disabled.

Before enabling it, confirm that the forest functional level and all Domain Controllers support the feature.

𝗥𝗘𝗩𝗜𝗘𝗪𝗜𝗡𝗚 𝗧𝗛𝗘 𝗗𝗡𝗦 𝗖𝗟𝗜𝗘𝗡𝗧 𝗦𝗘𝗧𝗧𝗜𝗡𝗚𝗦 𝗔𝗙𝗧𝗘𝗥 𝗣𝗥𝗢𝗠𝗢𝗧𝗜𝗢𝗡

The second script task applies the intended DNS client configuration.

Let’s review what happened to the network adapter after Domain Controller promotion.

Open Control Panel, Network and Sharing Center, and Change adapter settings.

Open the network adapter properties and then open Internet Protocol Version 4.

Before promotion, we configured the server’s own static IP address as the preferred DNS server and the loopback address as the alternate.

The promotion process or later configuration may modify the DNS client settings.

For a single-Domain-Controller lab, the script restores the expected self-referencing DNS values.

This specific DNS configuration is intended only for the current single-DC lab.

After an additional Domain Controller is deployed, return to the cross-mapped design described earlier.

The preferred DNS server on each Domain Controller should normally point to another healthy Active Directory DNS server, with the local server used as an alternate.

Do not apply a single-DC DNS configuration blindly to a multi-DC production environment.

𝗨𝗡𝗗𝗘𝗥𝗦𝗧𝗔𝗡𝗗𝗜𝗡𝗚 𝗔𝗖𝗧𝗜𝗩𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗧𝗜𝗠𝗘 𝗦𝗬𝗡𝗖𝗛𝗥𝗢𝗡𝗜𝗭𝗔𝗧𝗜𝗢𝗡

The third configuration is Windows Time Service and NTP.

Accurate time is critical for Active Directory.

Kerberos authentication relies heavily on synchronized clocks.

If the time difference between a domain computer and the authenticating Domain Controller exceeds the permitted Kerberos skew, authentication may fail.

Users may be unable to sign in, services may reject tickets, replication may be affected, and logs may become difficult to correlate.

In a default Active Directory hierarchy, domain members synchronize from Domain Controllers.

Domain Controllers synchronize through the domain hierarchy.

The PDC Emulator in the forest root domain is the authoritative time source for the forest and should synchronize with a reliable external NTP source.

Only the appropriate PDC Emulator should be configured to use external NTP servers.

Other domain members should normally follow the Active Directory time hierarchy.

𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗧𝗛𝗘 𝗘𝗫𝗧𝗘𝗥𝗡𝗔𝗟 𝗡𝗧𝗣 𝗦𝗢𝗨𝗥𝗖𝗘

In this lab, the script configures the forest root PDC Emulator to use external NTP servers, such as the pool.ntp.org service.

For production, use NTP sources approved by your organization.

These may be internal network time appliances, GPS-based time sources, firewall or router NTP services, a national time service, or trusted external NTP providers.

Do not rely only on an inaccurate hypervisor or hardware clock without understanding the virtualization time design.

When a Domain Controller is virtualized, review whether host time synchronization should be enabled or disabled according to the hypervisor platform and Microsoft guidance.

The Active Directory time hierarchy must remain consistent.

𝗖𝗥𝗘𝗔𝗧𝗜𝗡𝗚 𝗔𝗡𝗗 𝗥𝗨𝗡𝗡𝗜𝗡𝗚 𝗧𝗛𝗘 𝗣𝗢𝗪𝗘𝗥𝗦𝗛𝗘𝗟𝗟 𝗦𝗖𝗥𝗜𝗣𝗧

Create a folder such as C:\Temp.

Create a new text document.

Name the script something meaningful, such as AD-Optimization.ps1.

Make sure that Windows displays file extensions so that the file does not remain AD-Optimization.ps1.txt.

Open the file and paste the reviewed PowerShell commands.

Save the script.

Open Windows PowerShell as an administrator.

Change the working directory to the folder containing the script.

Run the script.

In this environment, the script finishes successfully.

The output confirms that the Active Directory Recycle Bin, DNS client settings, and time configuration have been applied.

𝗩𝗘𝗥𝗜𝗙𝗬𝗜𝗡𝗚 𝗧𝗛𝗘 𝗗𝗡𝗦 𝗖𝗟𝗜𝗘𝗡𝗧 𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗔𝗧𝗜𝗢𝗡

The script reports that the Domain Controller DNS client is configured to use 172.16.10.10.

Open the network adapter’s IPv4 properties again.

Confirm that the preferred and alternate DNS values match the intended single-DC lab configuration.

As you can see, the configuration is correct.

When a second Domain Controller is deployed, update these values so that each Domain Controller points to the other server as its preferred DNS resolver.

The PowerShell script can be adapted to perform these post-installation tasks consistently in another lab or deployment, but every value must be reviewed before execution.

𝗨𝗡𝗗𝗘𝗥𝗦𝗧𝗔𝗡𝗗𝗜𝗡𝗚 𝗧𝗛𝗘 𝗪𝗜𝗡𝗗𝗢𝗪𝗦 𝗦𝗘𝗥𝗩𝗘𝗥 𝟮𝟬𝟮𝟱 𝟯𝟮 𝗞𝗕 𝗗𝗔𝗧𝗔𝗕𝗔𝗦𝗘 𝗣𝗔𝗚𝗘 𝗙𝗘𝗔𝗧𝗨𝗥𝗘

The next configuration is the optional 32 KB Active Directory database page architecture introduced with Windows Server 2025.

For many years, the Active Directory database used an 8 KB page size.

Windows Server 2025 introduces support for 32 KB database pages when the required forest conditions and optional feature are enabled.

The larger page architecture can improve scalability and allow Active Directory to support larger database records and expanded object capabilities.

This feature is especially relevant to large or future-facing environments that need the new Windows Server 2025 Active Directory database architecture.

However, it should not be enabled simply because it is new.

Before activating it, review Microsoft’s requirements, forest functional level, Domain Controller versions, replication design, backup software, recovery procedures, application compatibility, identity products, and rollback limitations.

𝗥𝗘𝗩𝗜𝗘𝗪𝗜𝗡𝗚 𝗧𝗛𝗘 𝟯𝟮 𝗞𝗕 𝗔𝗥𝗖𝗛𝗜𝗧𝗘𝗖𝗧𝗨𝗥𝗘 𝗥𝗜𝗦𝗞𝗦

The transition to the 32 KB database page feature is an important forest-level change.

Treat it as an irreversible or one-way operation unless current Microsoft documentation explicitly provides a supported reversal path.

After the new database architecture is enabled and the environment is using it, older 8 KB database backups may not be suitable for restoring the upgraded state in the same way.

Backup and recovery software must support the Windows Server 2025 Active Directory database format.

Before enabling the feature, create and verify supported system-state backups.

Document the current forest health.

Confirm replication.

Test restoration procedures in an isolated environment.

Make sure that all responsible infrastructure, identity, security, and backup teams approve the change.

In this demonstration, we will run the prepared command to enable the 32 KB database page feature.

The exact command should be copied from current Microsoft documentation or the reviewed Techaptic script rather than typed from memory.

Run the command only after confirming that the environment meets every prerequisite.

𝗧𝗘𝗦𝗧𝗜𝗡𝗚 𝗔𝗖𝗧𝗜𝗩𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗗𝗡𝗦 𝗛𝗘𝗔𝗟𝗧𝗛

After completing the configuration, we need to confirm that Active Directory and DNS are healthy.

Open PowerShell or Command Prompt as an administrator.

Run the DNS-specific Domain Controller diagnostic test by using dcdiag /test:dns.

The tool checks DNS registration, name resolution, delegation, dynamic updates, service records, and other DNS-related conditions.

In this environment, the test reports that ad.techaptic.com passes the primary DNS tests.

Some warnings or failures may appear for external root hints, delegation, or unreachable root servers in an isolated lab.

Do not ignore failures automatically.

Review each result and determine whether it is expected for the current network design or represents a genuine DNS problem.

In a production environment, the final diagnostic result should be documented and unresolved errors should be corrected before the Domain Controller is considered ready.

𝗩𝗘𝗥𝗜𝗙𝗬𝗜𝗡𝗚 𝗧𝗛𝗘 𝗙𝗦𝗠𝗢 𝗥𝗢𝗟𝗘𝗦

The second validation is the Flexible Single Master Operations, or FSMO, role check.

Run netdom query fsmo.

Active Directory contains five FSMO roles.

The Schema Master controls schema updates.

The Domain Naming Master controls changes to the forest namespace.

The PDC Emulator provides several critical functions, including time hierarchy leadership, urgent password update behavior, and legacy compatibility.

The RID Master allocates relative ID pools to Domain Controllers.

The Infrastructure Master maintains certain cross-domain object references.

In a new forest with one Domain Controller, all five roles are installed on the first Domain Controller.

The command output should list the current owner of every role.

As you can see, all five roles are present and assigned to this Domain Controller.

When additional Domain Controllers are deployed, the roles can be transferred according to availability, maintenance, site, and operational requirements.

Do not seize FSMO roles unless the previous role holder is permanently unavailable and the recovery procedure requires it.

𝗩𝗘𝗥𝗜𝗙𝗬𝗜𝗡𝗚 𝗢𝗩𝗘𝗥𝗔𝗟𝗟 𝗔𝗖𝗧𝗜𝗩𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗛𝗘𝗔𝗟𝗧𝗛

DNS and FSMO checks are important, but production validation should include additional checks.

Run a full dcdiag review.

Confirm that the SYSVOL and NETLOGON shares exist.

Verify that the DNS SRV records are registered.

Review Event Viewer, especially the Directory Service, DNS Server, DFS Replication, System, and Security logs.

Confirm that the Windows Time service is synchronized with the intended source.

After an additional Domain Controller is deployed, use replication tools such as repadmin to verify inbound and outbound replication.

Resolve serious warnings or errors before adding business-critical workloads to the domain.

𝗗𝗘𝗣𝗟𝗢𝗬𝗜𝗡𝗚 𝗔𝗡 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗗𝗢𝗠𝗔𝗜𝗡 𝗖𝗢𝗡𝗧𝗥𝗢𝗟𝗟𝗘𝗥

Although the first Domain Controller is operating successfully, a single Domain Controller is not a complete production architecture.

Deploy an additional Domain Controller as soon as possible.

The second server should use a different physical host, hypervisor failure domain, power source, storage failure domain, or site where possible.

Install Active Directory Domain Services and DNS on the additional server.

Promote it as an additional Domain Controller in the existing domain.

Confirm Active Directory, SYSVOL, and DNS replication.

After replication is healthy, update the Domain Controller DNS client settings to use cross-mapping.

Also configure domain clients to receive both internal DNS server addresses.

Redundancy must be tested rather than assumed. Perform controlled maintenance and verify that authentication and DNS continue to work when one Domain Controller is unavailable.

𝗕𝗔𝗖𝗞𝗜𝗡𝗚 𝗨𝗣 𝗔𝗖𝗧𝗜𝗩𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗖𝗢𝗥𝗥𝗘𝗖𝗧𝗟𝗬

Active Directory must be protected with a supported backup strategy.

Use an Active Directory-aware backup product and create regular system-state backups of more than one Domain Controller where appropriate.

Store backup copies outside the Domain Controller and outside the same storage failure domain.

Encrypt and protect the backups because they contain highly sensitive directory data.

Monitor backup jobs and perform restoration tests.

A backup that has never been restored successfully should not be considered fully validated.

Document the DSRM password, backup locations, retention, recovery order, authoritative restore procedure, and forest recovery plan.

𝗔𝗩𝗢𝗜𝗗𝗜𝗡𝗚 𝗨𝗡𝗦𝗨𝗣𝗣𝗢𝗥𝗧𝗘𝗗 𝗩𝗜𝗥𝗧𝗨𝗔𝗟 𝗠𝗔𝗖𝗛𝗜𝗡𝗘 𝗥𝗢𝗟𝗟𝗕𝗔𝗖𝗞𝗦

One of the most important rules for virtualized Domain Controllers is to avoid treating ordinary hypervisor snapshots as the primary backup and recovery method.

Do not roll back a Domain Controller casually by restoring an old snapshot.

An improper rollback can reintroduce outdated directory data, disrupt replication, create lingering objects, cause USN-related problems, or leave the forest in an inconsistent state.

Modern virtualization platforms and Windows Server include safeguards for supported Domain Controller cloning and virtualization scenarios, but those protections do not make every snapshot workflow safe.

Use supported Active Directory-aware backup and restore procedures.

Before restoring a Domain Controller snapshot or checkpoint, confirm that the operation is supported by Microsoft, the hypervisor vendor, and the backup product.

For routine recovery, prefer tested system-state or full-server backups created by a supported backup tool.

𝗖𝗢𝗡𝗖𝗟𝗨𝗦𝗜𝗢𝗡

We have now completed the Windows Server 2025 Active Directory Domain Services installation and initial best-practice configuration.

We assigned a meaningful server name and a static IP address.

We configured the initial DNS client settings and explained how to cross-map DNS after an additional Domain Controller is deployed.

We prepared separate disks for the NTDS database and transaction logs.

We installed Active Directory Domain Services and DNS Server.

We created a new forest using ad.techaptic.com instead of a non-public suffix or an unplanned flat public namespace.

We selected the appropriate functional levels, configured a strong Directory Services Restore Mode password, reviewed the NetBIOS name, and separated the NTDS database and log directories.

We created an IPv4 reverse lookup zone with secure dynamic updates.

We enabled the Active Directory Recycle Bin.

We reviewed the Domain Controller DNS configuration and configured the forest root PDC Emulator to synchronize with an approved external NTP source.

We reviewed the optional Windows Server 2025 32 KB Active Directory database page architecture and its compatibility and recovery considerations.

We validated DNS health with dcdiag /test:dns and verified the FSMO role holders with netdom query fsmo.

Finally, we explained why a second Domain Controller, supported system-state backups, tested recovery procedures, and careful virtualization practices are essential for a production Active Directory environment.

The server is now operating as the first Domain Controller in the new forest, but the environment should not be considered fully resilient until an additional Domain Controller, monitoring, backup, security hardening, and recovery testing have been completed.

I hope you found this video useful.

Thank you for watching.

I will see you in the next video.

Goodbye.