Posted on by sqlozano

Your own domain, where your word is law

Having a domain is one of the most complex requirements to learn and practice advanced SQL architecture setups. Sure, you can build a domain-independent cluster and even build an Availability Group on top of it. You can also use local accounts to run your SQL services, and SQL authentication, but you’ll miss the opportunity to experience many configurations that are usual in a production environment. So, despite not being part of a DBA’s regular responsibilities, this post will cover the installation and configuration of a domain controller as well as a DNS server.

But first, a disclaimer: this does not reflect how a production environment looks, nor it does it intend to. A production environment has high availability and redundancy requirements to ensure there will not be a potential single point of failure, and can consist of several machines acting as domain controllers, and another set of machines acting as DNS servers.

This is the most basic setup I can think of so you can build it in your own home using Windows Server 2019, and the one I have configured for myself every time I’ve built a home lab for learning and testing purposes.

Installing the role

The role (whose full name is “Active Directory Domain Services” or AD DS) requires a DNS to be installed on the network. Since this post is meant to show how to configure it for local tests, the same box will be given both roles to reduce complexity in the setup.

  • This is the landing page for the wizard, not much to do here
  • We are applying roles to a server
  • Select the server on which to apply the role. Only one is listed, since this is a brand new lab consisting in that lone machine
  • Select the two roles “Active Directory Domain Server” and “DNS Server”. This will trigger a pop-up regarding additional components required for each of them
  • Additional components required by the AD DS role
  • Additional components required by the DNS role
  • No features are being explicitly added for this installation
  • As part of the DNS role’s installation we get the first reminder than an AD DS requires a DNS to be installed on the network
  • As part of the AD DS installation, we are reminded again than a DNS server is required on the network the AD DS is being installed
  • Notice the explicit roles selected (red), along with the required components listed in previous pop-ups (green)
  • Installation in progress
  • The installation is complete, but we can see the first reminder that we are not done with the configuration of AD DS yet

With both roles installed, it is time to configure them.

Building the foundations: setting up your DNS

It wouldn’t make sense to have a DNS server that needs a DNS itself to be found on this scenario, so first let’s set a static IP address to it.

  • The Settings menu is a cleaner version of the usual Control Panel, which can also be used
  • Select the ethernet (unless you are building a VM with an emulated Wifi card)
  • This option will take you out of the Settings menu and back to the old familiar interface
  • Select the ethernet card to where you want to set the static IP on
  • For this scenario, only using IPv4
  • (Red) Ensure the selected IP won’t collide with any of your other VMs nor with the host itself (consult your HyperVisor for this, most common being Hyper-V or VMware), and leave the default gateway empty if you don’t want this VM to have access to the outside world
  • (Blue) Since this will machine will act as a DNS server on this brand new lab there are no existing DNS servers to use, so leave these values blank.

With a static IP set, open the DNS manager console to configure the DNS server. This console can be found in the start menu, or in the Server Manager Dashboard, under Tools.

Now it is time to get the DNS configured.

Since this DNS server will serve a small network (just a handful of machines), the simpler configuration will be enough for that purpose.

And only one DNS server will be set, so this server will maintain the DNS forward zone by itself.

Time to name our DNS: I’ve used sqlozanot.com to differentiate it from the one I have already set on a different machine named sqlozano.com.

And this being a brand new DNS for a brand new zone, there is no DNS zone file to load, just select the name for the new one to be created.

I have selected not to allow dynamic updates of the DNS entries: this will let me control the mapping of DNS and IPs. I consider it a good practice to learn the basics on how to configure it yourself, so when you work in a place where you don’t have access to it, you will know how to properly express your request to whoever will be handling these changes for you.

Having a single DNS means we have nowhere else to forward the requests this one can’t handle (for example, trying to reach servers not registered in this one, like those on the sqlozano.com domain).

The wizard will now look for root hints (think of them as the entries you configure in your Windows hosts file to hard code addresses), but this being a brand new machine and DNS, it won’t find any.

Now the DNS is ready to be saved and be used.

Just ignore this last message: as seen above, there are no root hints to be configured.

This message startled me the first 4 times I configured my own DNS server. And I bet there will be a fifth.

The DNS is almost ready. Before moving on to the Active Directory setup, a reverse zone will be configured as well.

Time to put the “Active” in “Active Directory”

The Server Manager dashboard will remind you the Active Directory Domain Services haven’t been configured yet, and will even give you a shortcut to promote the machine as a domain controller, which is exactly the purpose of this post.

For this basic setup, a brand new forest will be created, named sqlozanot.com after the DNS zone sqlozanot.com created in the previous steps. The new domain may be named differently, but that would require the configuration of a DNS zone with the same name, and this setup is aiming to be as simple as possible.

Set a password so the Active Directory can be repaired in case of a failure to continue its configuration.

This warning is related to the DNS settings we are configuring. Since this is going to be part of a home lab and won’t be external connections to it, there is no need to worry about it at the moment.

Just confirm the NETBIOS name and move to the next.

I only had to worry about NETBIOS a couple of times in my life due to Microsoft Distributed Transaction Coordinator issues with SQL Servers, so I’d recommend not changing this unless you know what you are doing.

When selecting the folders to store all of AD’s related files, it would be a good idea to ensure antivirus won’t mess with these folders, and even locate them on a separate drive with additional backups for safety. But again, the simplest setup possible is being used so using the default values here.

Review the settings before applying those changes: those can be saved as a PowerShell script so the setup can be reproduced elsewhere if the machine must be rebuilt.

This is the complete summary of the options selected

Configure this server as the first Active Directory domain controller in a new forest.

The new domain name is "sqlozanot.com". This is also the name of the new forest.

The NetBIOS name of the domain: SQLOZANOT

Forest Functional Level: Windows Server 2016

Domain Functional Level: Windows Server 2016

Additional Options:

  Global catalog: Yes

  DNS Server: Yes

  Create DNS Delegation: No

Database folder: C:\Windows\NTDS

Log file folder: C:\Windows\NTDS

SYSVOL folder: C:\Windows\SYSVOL

The DNS Server service will be configured on this computer.

This computer will be configured to use this DNS server as its preferred DNS server.

The password of the new domain Administrator will be the same as the password of the local Administrator of this computer.

And the PowerShell script to create it (as generated by the Wizard):

Import-Module ADDSDeployment
Install-ADDSForest `
-CreateDnsDelegation:$false `
-DatabasePath "C:\Windows\NTDS" `
-DomainMode "WinThreshold" `
-DomainName "sqlozanot.com" `
-DomainNetbiosName "SQLOZANOT" `
-ForestMode "WinThreshold" `
-InstallDns:$true `
-LogPath "C:\Windows\NTDS" `
-NoRebootOnCompletion:$false `
-SysvolPath "C:\Windows\SYSVOL" `
-Force:$true

If all the prerequisites for the installation of Active Directory Domain Services are met, you are ready to complete the installation.

I got some warnings but this is not going to be a production environment, so I’ll just go with them

Once the installation is complete, you’ll be logged out and the machine will reboot.

On your next login on the machine, you’ll see the Administrator account belongs to the new domain.

And that’s it, you are the sole ruler of your own domain.

Welcome to outsider.sqlozanot.com, capital of sqlozanot.com. Population: 1

But now that you have both DNS and Active Directory, let’s finish up with the configuration of a Reverse Lookup Zone

What is a Reverse Lookup Zone?

Think of a DNS Forward Lookup Zone as your phone agenda. You usually search for the name of your contact since it is easier to remember than a bunch of numbers. However, sometimes you may want to figure out who a certain IP address belongs to. If only the Forward Lookup Zone were available, the only way to find that out would be to query every single DNS entry and compare their IP address to the one you are looking for. A Reverse Lookup Zone maps the information the other way around.

Creating a Reverse Lookup Zone for your DNS

Using the DNS console, a wizard will guide you through the whole process

Since this is the only DNS on this home lab, the new zone will be the primary. And having the Active Directory in the same machine allows this zone to be stored in it.

All servers in this forest (the only one we have) will replicate this zone’s data.

For simplicity I have used IPv4 on my boxes, so the zone will be configured for IPv4 addresses.

All the machines built will have their IPs in the 192.168.1.1 – 192.168.1.255 range, so that’s the Network ID used to identify this zone.

This being a zone integrated with the Active Directory created previously, allows for secure dynamic updates no (this was not an option during the initial installation of the DNS).

Now the Reverse Lookup Zone is ready to be created.

How is our DNS looking now?

Since there is no other machine than the DNS server itself, there is not much to see at the moment, so below are some screen captures of the same DNS with some additional machines added.

  • The Forward Lookup Zone maps the DNS name (column Name) with the IP address (column Data)
  • The Reverse Lookup Zone maps the IP address (column Name) with the DNS name (column Data)
Notes on this post

The machine used for this post runs Windows Server 2019. In the past I set similar testing environments using Windows 2012 and Windows 2016 and the steps are very similar, so you shouldn’t have any trouble following these instructions with those operating systems.