Promote the first domain controller

This is the lesson where your lab becomes a real Windows network. You’ll promote domain controller number one: DC01 becomes the first DC of a brand-new forest, saatlab.internal, with its own DNS server.

Promotion takes one command and a restart. The important part is what you check afterwards: the FSMO roles, the DNS zones and SRV records, the SYSVOL and NETLOGON shares, and a clean dcdiag. Those same checks are what you’ll run on any DC at work.

TimeYou needBy the end you can
About 45 minutesDC01 with the AD DS role installed (Lesson 10) and your DSRM passwordPromote the first domain controller of a new forest with PowerShell, then verify FSMO roles, DNS zones, SRV records, SYSVOL and NETLOGON, the DNS forwarder and dcdiag

What it is, in one line

To promote a domain controller means turning a member or standalone server into a DC: it gets a copy of the Active Directory database, the SYSVOL share and usually DNS, and starts answering sign-ins.

In Simple Words

Opening the town’s first records office

A new town needs a records office before anyone can register a birth, a house or a business. On opening day, the office gets an empty register, a stamp, a directory listing on every signpost, and a filing cabinet for the town’s rules.

Promoting DC01 is opening that office. Windows creates the empty register (the AD database), the stamp (the domain’s security keys), the signposts (DNS records pointing to DC01), and the filing cabinet (SYSVOL, where Group Policy and logon scripts live).

After opening day, you check every piece is really there. A records office with no signposts is one nobody can find.

Engineer's View

What Install-ADDSForest actually does

Creates the forest and domain. It builds the database at C:\Windows\NTDS\ntds.dit with the schema, configuration and domain partitions, and the built-in accounts and groups (Administrator, Domain Admins, Enterprise Admins and others). The server’s local accounts disappear: a DC has no local user database, only the domain.

Creates SYSVOL at C:\Windows\SYSVOL and shares it as SYSVOL and NETLOGON. Group Policy files live here, and they’re replicated between DCs by DFS Replication.

Installs and configures DNS (with -InstallDns).

It creates two AD-integrated zones: saatlab.internal and _msdcs.saatlab.internal, stored inside AD and replicated with it. The DNS servers the machine used before become forwarders, so internet names still resolve. DC01’s own DNS client is changed to point at itself.

Registers SRV records. The Netlogon service writes records such as _ldap._tcp.dc._msdcs.saatlab.internal so clients can find DCs. If these are missing, nothing can join or sign in.

Holds every FSMO role and the global catalog. The first DC in a forest always does. You’ll move some roles when DC02 arrives.

Sets the DSRM password for Directory Services Restore Mode, a special local administrator used only when AD is offline for repair.

Restarts. After the restart you sign in as SAATLAB\Administrator, using the password the local Administrator had before promotion.

How it works, step by step

Here’s the sequence, from command to a healthy DC. The checks after the restart matter as much as the promotion itself:

Promote domain controller DC01: snapshot, Install-ADDSForest, restart, FSMO, DNS, SYSVOL and dcdiag checks
  1. Snapshot DC01 so you can retry a failed promotion cleanly.
  2. Run Install-ADDSForest with the domain name, NetBIOS name and -InstallDns, and give the DSRM password.
  3. Restart (automatic) and sign in as SAATLAB\Administrator.
  4. Check the domain and roles: Get-ADDomain, Get-ADForest, netdom query fsmo.
  5. Check DNS: the zones exist, the SRV records resolve, the forwarder points to the internet.
  6. Check SYSVOL and NETLOGON are shared.
  7. Run dcdiag and read every failure line.

And this is how DNS looks on DC01 after promotion. Clients will ask DC01, DC01 answers for saatlab.internal itself and forwards everything else:

Promote domain controller DNS after promotion: clients ask DC01, DC01 forwards public names to 1.1.1.1

From now on, every machine in the domain must use DC01 (and later DC02) as its only DNS servers. A public DNS server as “backup” is the most common cause of random AD failures, as you’ll see in the Break It lab and the work story.

Hands-on Lab: promote domain controller DC01 and check it

DC01 is powered off after Lesson 10. Steps 1 and 2 happen on your laptop and DC01; after the restart everything is on DC01 in PowerShell as administrator.

1Take a snapshot before promotion

On your laptop:

VBoxManage snapshot DC01 take "Before promotion"
VBoxManage startvm DC01

✅ Checkpoint: DC01 has a “Before promotion” snapshot and is starting.

2Promote DC01

On DC01, run this. Enter the DSRM password twice, then answer Y:

Install-ADDSForest -DomainName saatlab.internal -DomainNetbiosName SAATLAB -InstallDns

You should see something like this before DC01 restarts by itself:

SafeModeAdministratorPassword: ****************
Confirm SafeModeAdministratorPassword: ****************

The target server will be configured as a domain controller and restarted when this operation is complete.
Do you want to continue with this operation?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): Y
WARNING: This computer has at least one physical network adapter that does not have static IP address(es) ...
WARNING: A delegation for this DNS server cannot be created because the authoritative parent zone cannot be found ...

You’ll see a progress bar for a few minutes, then DC01 signs you out and restarts. The first start after promotion takes longer than usual (“Applying computer settings”).

✅ Checkpoint: DC01 restarted on its own after the promotion finished.

3Sign in and check the domain and forest

Press Right Ctrl + Delete. The sign-in screen now says SAATLAB\Administrator; use the same password as before. Open PowerShell as administrator.

Run these one at a time:

Get-ADDomain | Select-Object DNSRoot, NetBIOSName, DomainMode
Get-ADForest | Select-Object Name, ForestMode, GlobalCatalogs
netdom query fsmo

You should see something like this:

DNSRoot          NetBIOSName DomainMode
-------          ----------- ----------
saatlab.internal SAATLAB     Windows2025Domain

Name             ForestMode        GlobalCatalogs
----             ----------        --------------
saatlab.internal Windows2025Forest {DC01.saatlab.internal}

Schema master               DC01.saatlab.internal
Domain naming master        DC01.saatlab.internal
PDC                         DC01.saatlab.internal
RID pool manager            DC01.saatlab.internal
Infrastructure master       DC01.saatlab.internal
The command completed successfully.
Promote domain controller checks: netdom query fsmo, SRV record and SYSVOL shares
Example output.

The forest and domain run at the 2025 functional level, DC01 is the only global catalog, and it holds all five FSMO roles. netdom query fsmo is the fastest way to answer “where are the roles?” on any domain.

✅ Checkpoint: Get-ADDomain shows saatlab.internal and SAATLAB, and netdom lists DC01 for all five roles.

4Check DNS: zones, SRV records and the forwarder

Run these one at a time:

Get-DnsServerZone | Select-Object ZoneName, ZoneType, IsDsIntegrated
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.saatlab.internal | Select-Object Name, NameTarget, Port
Get-DnsServerForwarder | Select-Object IPAddress
Get-DnsClientServerAddress -InterfaceAlias Ethernet -AddressFamily IPv4 | Select-Object ServerAddresses

You should see something like this:

ZoneName                ZoneType IsDsIntegrated
--------                -------- --------------
_msdcs.saatlab.internal Primary            True
0.in-addr.arpa          Primary           False
127.in-addr.arpa        Primary           False
255.in-addr.arpa        Primary           False
saatlab.internal        Primary            True
TrustAnchors            Primary            True

Name                                   NameTarget            Port
----                                   ----------            ----
_ldap._tcp.dc._msdcs.saatlab.internal  DC01.saatlab.internal  389

IPAddress
---------
{1.1.1.1}

ServerAddresses
---------------
{::1, 127.0.0.1}

Both AD zones are AD-integrated, the SRV record points at DC01 on port 389 (LDAP), and 1.1.1.1 became a forwarder so internet names still resolve. Promotion pointed DC01’s own DNS at itself (127.0.0.1 and ::1).

Best practice is to use the DC’s real address instead of loopback, so set it now:

Run this:

Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses 10.0.0.10

✅ Checkpoint: Both zones show IsDsIntegrated True, the SRV record points to DC01, and the forwarder is 1.1.1.1.

5Check SYSVOL and NETLOGON

Run this:

Get-SmbShare | Where-Object Name -in 'SYSVOL','NETLOGON' | Select-Object Name, Path

You should see this:

Name     Path
----     ----
NETLOGON C:\Windows\SYSVOL\sysvol\saatlab.internal\SCRIPTS
SYSVOL   C:\Windows\SYSVOL\sysvol

These two shares appear only when the DC has finished initialising. If they’re missing after promotion, Group Policy won’t work and the DC isn’t really ready, even if everything else looks fine.

✅ Checkpoint: Both SYSVOL and NETLOGON are shared.

6Run dcdiag

Run this:

dcdiag /q

/q prints only errors.

On a healthy new DC you’ll see nothing at all, or a couple of lines about the System event log containing warnings from the first start. Read any failure and check it against the troubleshooting table below. Lesson 45 covers dcdiag in depth.

✅ Checkpoint: dcdiag /q shows no failed tests (or only event log warnings from the first boot).

7Confirm the network profile and take a snapshot

Run this:

Get-NetConnectionProfile | Select-Object Name, NetworkCategory

You should see this:

Name             NetworkCategory
----             ---------------
saatlab.internal DomainAuthenticated

The connection moved from Public to DomainAuthenticated, so the Domain firewall profile now applies. Shut down DC01 and take a snapshot called “DC promoted” from your laptop.

✅ Checkpoint: NetworkCategory is DomainAuthenticated and DC01 has a “DC promoted” snapshot.

Break It, Then Fix It

Two DNS faults cause most “AD is broken” calls. Start DC01 from the “DC promoted” snapshot and break both.

1Break it: point the DC at public DNS

On DC01, run these:

Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses 1.1.1.1
Clear-DnsClientCache
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.saatlab.internal

You’ll get an error like this:

Resolve-DnsName : _ldap._tcp.dc._msdcs.saatlab.internal : DNS name does not exist
At line:1 char:1
+ Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.saatlab.internal
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (_ldap._tcp.dc._msdcs.saatlab.internal:String) [Resolve-DnsName], Win32Exception
    + FullyQualifiedErrorId : DNS_ERROR_RCODE_NAME_ERROR,Microsoft.DnsClient.Commands.ResolveDnsName
Promote domain controller lab: SRV lookup fails when the DC points at public DNS
Example output.

The record still exists on DC01’s DNS server, but DC01’s own DNS client now asks the internet, which has never heard of saatlab.internal. Any member pointed at a public resolver has exactly this problem, and so would DC01’s own services.

Fix it: point the DNS client back at the DC and test again:

Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses 10.0.0.10
Clear-DnsClientCache
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.saatlab.internal | Select-Object Name, NameTarget, Port

You should see this:

Name                                   NameTarget            Port
----                                   ----------            ----
_ldap._tcp.dc._msdcs.saatlab.internal  DC01.saatlab.internal  389

✅ Checkpoint: The SRV lookup fails with 1.1.1.1 and works with 10.0.0.10.

2Break it: lose the DC’s SRV records

Delete DC01’s main SRV record from the _msdcs zone, as if someone had cleaned up “old” records:

Get-DnsServerResourceRecord -ZoneName _msdcs.saatlab.internal -Name _ldap._tcp.dc -RRType Srv |
    Remove-DnsServerResourceRecord -ZoneName _msdcs.saatlab.internal -Force
Clear-DnsClientCache
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.saatlab.internal

You get “DNS name does not exist” again, and this time it’s true. New computers can’t find a DC to join (you’ll see that error in Lesson 13) and existing ones start failing over to other DCs, or fail outright if there are none.

Fix it: make Netlogon register its records again:

nltest /dsregdns
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.saatlab.internal | Select-Object Name, NameTarget, Port

You should see something like this:

The command completed successfully

Name                                   NameTarget            Port
----                                   ----------            ----
_ldap._tcp.dc._msdcs.saatlab.internal  DC01.saatlab.internal  389

nltest /dsregdns tells Netlogon to re-register every DC record right now. Restarting the Netlogon service does the same, and Netlogon re-registers them by itself periodically anyway. The full list of records it registers is in C:\Windows\System32\config\netlogon.dns.

✅ Checkpoint: The SRV record is back after nltest /dsregdns.

This happened at work

The domain controller with Google as a backup

A company built a new domain controller for its branch office. To be “safe”, the engineer set its DNS servers to itself first and 8.8.8.8 second, “in case our DNS goes down”. Branch laptops got the same two servers from DHCP.

For months, people complained about random problems: a slow sign-in one morning, a mapped drive missing, a Group Policy that applied on Tuesday but not Wednesday. Each ticket was closed with “restarted, works now”.

The pattern only showed up when someone ran nslookup against the second DNS server: whenever Windows briefly switched to 8.8.8.8 (after a slow answer from the first server, for example), it got “name does not exist” for every AD record, and cached that answer for a while.

The fix: every domain member and DC uses only internal DNS servers, with two DCs for redundancy. Internet names are resolved through forwarders on the DNS servers, never through public resolvers on clients. A Group Policy and DHCP option now set this, and monitoring alerts on any client with a public DNS server.

The lesson: in Active Directory, a public DNS server isn’t a backup. It’s a second source of wrong answers.

Common mistakes and troubleshooting

Mistake or symptomWhat happensWhat to do instead
Members or DCs using public DNS as primary or secondaryRandom failures to find DCs, slow sign-ins, missed Group PolicyOnly internal DNS servers on members; forwarders for the internet
Promoting without a snapshot or backupA failed promotion is hard to clean upSnapshot first in a lab; system state backup in production
Signing in as “.\Administrator” after promotionConfusion: a DC has no local accountsSign in as SAATLAB\Administrator
SYSVOL and NETLOGON shares missingGroup Policy and logon scripts don’t workCheck DFS Replication and event logs; the DC isn’t fully ready
SRV records missing from _msdcsComputers can’t join or find a DCnltest /dsregdns or restart Netlogon; check DNS client settings on the DC
DC01’s DNS client left on 127.0.0.1 onlyWorks, but hides DNS problems and complicates multi-DC setupsUse the DC’s own IP and a partner DC
Forgetting the DSRM passwordCan’t enter Directory Services Restore Mode for repairsReset it with ntdsutil “set dsrm password” and store it safely
dcdiag failures ignored right after promotionSmall problems grow into replication failuresFix or understand every failure before adding more DCs
Install-ADDSForest run on the wrong serverA server you didn’t plan becomes the forest rootDouble-check the server name before running it

Interview questions

Click a question to open it. Under each one you’ll find what the interviewer is really looking for, and one good way to answer.

Fresher level

1. How do you promote a server to a domain controller?

What they’re really checking: Have you done it?

How you could answer: Install the AD DS role, then use Server Manager’s promotion wizard or PowerShell: Install-ADDSForest for a new forest, Install-ADDSDomainController to add a DC to an existing domain. Provide the DSRM password and restart.

2. What is the SYSVOL share?

What they’re really checking: Do you know what lives there?

How you could answer: A shared folder on every DC containing Group Policy templates and logon scripts. NETLOGON is a share inside it. It’s replicated between DCs by DFS Replication.

3. What is the DSRM password used for?

What they’re really checking: Do you know recovery basics?

How you could answer: Signing in to Directory Services Restore Mode, where AD is stopped, to repair or restore the AD database.

2–5 years experience

4. After promotion, what do you check?

What they’re really checking: Do you verify instead of assuming?

How you could answer: Get-ADDomain and netdom query fsmo for roles, DNS zones and SRV records, the forwarders, SYSVOL and NETLOGON shares, event logs, and dcdiag /q. The network profile should be DomainAuthenticated.

5. Clients can’t find a domain controller. How do you troubleshoot?

What they’re really checking: Do you start with DNS?

How you could answer: Check the client’s DNS servers point only at DCs, then Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.<domain>. If the record is missing, run nltest /dsregdns on the DC and check its DNS client settings.

6. What are DNS forwarders and why use them?

What they’re really checking: Do you know how DCs resolve internet names?

How you could answer: DNS servers send queries they can’t answer to another server, such as the ISP’s or a public resolver. Clients only talk to internal DNS, and the DCs reach the internet through forwarders.

Senior level

7. What would you do differently promoting the first DC in production?

What they’re really checking: Do you think about hardening and resilience?

How you could answer: Plan the name and IP, harden the build, place it in a secure network segment, take a system state backup right after promotion, add a second DC immediately, configure time sync on the PDC Emulator from a reliable source, and document the DSRM password in a vault.

8. Why should a DC not use only 127.0.0.1 for DNS?

What they’re really checking: Do you know the multi-DC best practice?

How you could answer: With several DCs, each should point first to another DC and then itself (or itself by real IP), so it can find replication partners even if its own DNS has problems. Loopback-only can hide DNS faults.

9. How do you check a new forest is healthy before adding more servers?

What they’re really checking: Do you have a checklist?

How you could answer: dcdiag clean, repadmin /replsummary (once there are two DCs), SRV records resolving, SYSVOL shared, time correct on the PDC Emulator, event logs reviewed, and a successful system state backup.

Quick quiz

Q1. Which command promotes the first DC of a new forest?

  1. Install-ADDSDomainController
  2. Install-ADDSForest
  3. Add-Computer
Show answer

B — Install-ADDSForest creates a new forest and its first domain.

Q2. How do you sign in to DC01 after promotion?

  1. DC01\Administrator
  2. SAATLAB\Administrator
  3. .\Guest
Show answer

B — A DC has no local accounts; use the domain account.

Q3. What happened to 1.1.1.1 during promotion?

  1. It was deleted
  2. It became a DNS forwarder
  3. It became the domain name
Show answer

B — The old DNS servers become forwarders for internet names.

Q4. Which command re-registers a DC’s SRV records?

  1. ipconfig /flushdns
  2. nltest /dsregdns
  3. gpupdate /force
Show answer

B — nltest /dsregdns makes Netlogon register the records again.

Q5. In the work story, why were the failures random?

  1. Faulty network cards
  2. Clients sometimes used 8.8.8.8, which knows nothing about AD
  3. Expired licences
Show answer

B — Public DNS as a “backup” gives wrong answers for AD names.

Quick recap

  • To promote a domain controller for a new forest: Install-ADDSForest -DomainName ... -InstallDns.
  • The first DC holds every FSMO role and the global catalog; check with netdom query fsmo.
  • DNS gets two AD-integrated zones; old DNS servers become forwarders.
  • Clients find DCs through SRV records like _ldap._tcp.dc._msdcs.saatlab.internal; nltest /dsregdns re-registers them.
  • Check SYSVOL and NETLOGON shares and run dcdiag /q.
  • Domain members use only internal DNS, never public resolvers.

Next lesson

Lesson 12: Users, groups and OUs → You’ll design an OU structure for the lab, create users and groups by hand and from a CSV file, learn group scopes and the AGDLP model, and turn on the AD Recycle Bin.

Further reading: promote domain controller

Want to go deeper into how to promote a domain controller? Microsoft’s guide to installing Active Directory Domain Services covers the wizard and the PowerShell commands used here. You can also see the full plan for this course on the Windows Server Administration course page.

Scroll to Top