Promote your first Domain Controller

Goal

By the end of this session you'll understand what the AD DS role is versus what a domain controller actually is — two things people conflate — and you'll take the clean Windows Server VM from Session 1 and promote it into the very first DC of a new forest, lab.local. You'll see that installing the role and promoting the server are two separate steps, and that spinning up the first DC quietly stands up DNS alongside it. Still early Tier 1: this is you building a working directory, not mastering it.

Concepts

The AD DS role — installing it is not promoting it

Active Directory Domain Services (AD DS) is a role you add to Windows Server, the same way you'd add IIS or DHCP. Adding the role lays down the AD DS binaries, the management tools, and the Install-ADDSForest/Install-ADDSDomainController machinery — but it does nothing to your directory yet. At this point you have a server that can become a domain controller and simply hasn't.

The step people skip past mentally is the second one: promotion. Promotion (historically dcpromo, now the "Promote this server to a domain controller" wizard, or the Install-ADDSForest cmdlet) is what actually creates the directory database (ntds.dit), the SYSVOL share, and the domain itself, and flips this box into a live DC. Two distinct actions:

1. Install the role — put the AD DS bits on the machine. Reversible, low-stakes, changes nothing about identity.
2. Promote the server — create or join a domain and turn the machine into an actual domain controller.

Miss this distinction and the wizard's two-phase flow is confusing; hold it and everything downstream makes sense.

What a domain controller actually is

A domain controller (DC) is a server running AD DS that hosts a writable copy of the directory store for its domain and answers authentication for that domain. Concretely, a DC:

• holds the ntds.dit database — the objects (users, computers, groups, OUs) and their attributes you met in Session 1;
• serves LDAP so tools and applications can search and modify those objects;
• runs the Kerberos Key Distribution Center, issuing tickets to prove who principals are;
• and (almost always, for the first DC) hosts the DNS that clients use to find it.

That's three of your four pillars living on one box: directory store, LDAP, and authentication, with DNS bolted on. Everything the domain does, a DC does.

Promoting the first DC creates a new forest

There's nothing to join on a brand-new network, so promoting your first DC means choosing "Add a new forest." That single action creates three nested things at once:

• a forest — the outermost boundary (the deep dive is Session 9; for now just know it's the top-level container and security boundary);
• a tree — a namespace under that forest;
• a domain — lab.local, the administrative and replication boundary you'll actually work inside.

The name maps straight onto the LDAP naming you learned in Session 1: the DNS domain lab.local becomes the directory root DC=lab,DC=local. Every object you create later hangs off that root. You're not just switching on a service — you're minting the namespace the rest of the course lives in.

The DNS dependency — the pillar that breaks everything else

Back to the fourth pillar from Session 1. AD DS cannot function without DNS. Clients don't find a DC by IP address or by broadcast — they query DNS for SRV records that advertise "here is a domain controller for lab.local, here is the Kerberos service, here is the LDAP service." No DNS, no discovery; no discovery, no logon.

Because of that hard dependency, promoting the first DC will, by default, install the DNS Server role and create an AD-integrated DNS zone for your domain right on the DC — the wizard offers this and you should accept it. The DC then registers its own SRV records into that zone. This is also why a DC points its preferred DNS at itself: it has to resolve names using the very zone it hosts.

The two-phase wizard, click by click

You'll drive both phases from Server Manager — this is the route to learn first. The two-step nature from earlier shows up literally as two passes through the tool:

1. Install the role. Server Manager → Manage → Add Roles and Features → Role-based or feature-based installation → pick your server → on the Server Roles page tick Active Directory Domain Services (accept the prompt to add the required management tools) → Next through to Install. When it finishes, the server has the AD DS bits but is not yet a DC.
2. Promote the server. Server Manager raises a yellow notification flag (the ⚑ near the top) with "Promote this server to a domain controller" — click it. In the promotion wizard: choose Add a new forest, type the root domain name lab.local, leave DNS server checked on the next page, set the DSRM password, then Next through the checks to Install. The server reboots itself when it's done.

The DSRM (Directory Services Restore Mode) password is a recovery password separate from the domain Administrator account — set it to an obvious placeholder in the lab (e.g. P@ssw0rd-lab) and record it; it's a placeholder, never a real credential.

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName "lab.local" -DomainNetbiosName "LAB" -InstallDns

Lab

Goal: take the clean Windows Server VM from Session 1 and turn it into DC01, the first domain controller of a new forest lab.local, then log in and explore the directory it created. Do the prep steps (static IP, DNS-to-self, rename) before promoting — order matters here.

Set the static IP and preferred DNS (GUI). Open Control Panel → Network and Internet → Network Connections (or run ncpa.cpl), right-click your adapter → Properties → select Internet Protocol Version 4 (TCP/IPv4) → Properties. Choose Use the following IP address and enter a fixed address, subnet mask, and gateway for your VM network (e.g. 192.168.56.10 / 255.255.255.0 / 192.168.56.1). Under DNS, choose Use the following DNS server addresses and set the preferred DNS to the server itself — its own static IP or the 127.0.0.1 loopback.

Rename the server (GUI). In Server Manager → Local Server, click the current (random) computer name to open System Properties → Change, set the name to DC01, and reboot when prompted.

Then run the wizard from Server Manager exactly as described in Concepts — Add Roles and Features → Active Directory Domain Services, then the ⚑ Promote this server to a domain controller → Add a new forest lab.local → leave DNS checked → set the DSRM password → install and let it reboot.

How you know it worked: after the final reboot you log in as LAB\Administrator (the domain now prefixes the account); Active Directory Users and Computers opens with lab.local at the root and shows the default containers — Users, Computers, Builtin, and a Domain Controllers OU with DC01 sitting inside it. Get-ADDomain returns your domain with DN DC=lab,DC=local. That's a live directory — you built the namespace the rest of the course runs in.