Active Directory: install & first domain — from server to domain controller, without the guesswork

image placeholder

Image 01 — Active Directory Domain Architecture

Insert an architecture diagram or labeled screenshot: a domain controller hosting the directory database and DNS, with clients resolving the domain and authenticating against it.

Active Directory Domain Services (AD DS) is Windows' centralized directory and authentication service. Without it, every machine keeps its own local user accounts: a password set on one PC means nothing on another, and managing ten machines means ten sets of accounts. With it, user accounts, computer accounts, groups, and policies live in one replicated database, and a user signs in once — the domain verifies the identity, and any domain member can trust that verification. A domain controller (DC) is simply a Windows Server machine that runs that database for a domain; a standalone server has none of this and only knows its own local users.

The vocabulary matters from the first click, because the promotion wizard asks about these things by name. A domain is the unit of authentication: one directory partition, one set of accounts, one DNS namespace (our example: example-lab.com). A forest is the top-level security boundary; the first domain you create is the forest root domain, and a simple lab stays at one forest, one domain. Organizational units (OUs) are folders inside the domain where you organize objects and later apply group policy. Directory objects are users, groups, computers, and OUs themselves. And DNS is not an optional accessory — clients locate domain controllers by querying DNS service (SRV) records, so a domain without working internal DNS is a domain no one can find.

The table below is the whole mental model you need for the rest of the article. Everything that follows — the role installation, the promotion, the verification — is just building the rows of this table, in order.

One distinction pays off in Section 9, so it's here on purpose: installing the AD DS role and promoting the server to a domain controller are two different operations. The role drops the service binaries and tools onto the machine; the promotion creates the forest and domain, installs the DNS zone, and reboots the server into its new identity. A server with the role installed but not promoted is exactly as useful for directory services as a car with the engine on the floor — so the tutorial never treats "role installed" as "domain working."

image placeholder

Image 02 — Windows Server Installation Options

Insert the edition selection screen from the Windows Server 2022 installer, showing the Desktop Experience option highlighted, or a VM settings screen.

Start from a virtual machine, not real hardware — a domain controller you can snapshot, reset, and destroy is the only safe way to learn promotion. For the edition, any Windows Server 2022 edition works for a lab: Standard and Datacenter differ in virtualization rights and scale licensing, not in AD DS features, so choose whichever your license situation gives you. Choose the Desktop Experience image rather than Server Core for this tutorial: the GUI walkthroughs in Sections 9 and 11 assume a full desktop, and seeing Server Manager is half of learning the tool. (Server Core is the right production choice for many DCs later; the PowerShell paths shown here work identically on Core.)

Resources for a first domain lab are modest. The DC needs 2 vCPUs and 4 GB RAM minimum (give it 8 GB if the hypervisor has headroom), a 60 GB virtual disk, and one virtual network card on a network that is isolated from your real network — in VirtualBox that's an Internal Network, in VMware a custom NAT or host-only network with no internet route. The isolation matters for two reasons: a DC on your home LAN changes its DNS behavior and can break other machines' name resolution if misconfigured, and you will want to destroy this domain at least once without consequence. If you later add a test client VM (Section 17), another 2 vCPUs / 4 GB on the same isolated network is enough.

One source of confusion to kill now: the host and the guest are separate machines with separate settings. A static IP configured in your laptop's network adapter does nothing for the VM; an adapter renamed on the host is invisible to Windows Server. From this point on, "the server" always means the Windows Server VM, and everything you type is typed inside it. The lab plan the rest of the article uses:

image placeholder

Image 03 — Initial Windows Server Configuration

Insert the first sign-in screen of a fresh Windows Server 2022 VM, with the Server Manager task pane visible.

Attach the Windows Server 2022 ISO to the VM and boot from it. The installer steps that matter for this tutorial: accept the license terms; choose Custom: Install Windows only (advanced) (there is no upgrade path in a lab); select the virtual disk and let the installer create the partitions — for a fresh 60 GB disk, the default single partition is fine. There is no product key step on the 180-day evaluation image; a licensed image will ask for the key at the edition step. Choose your edition there (Standard or Datacenter, both with Desktop Experience).

Set a strong password for the built-in Administrator account at the end of setup. This is the local administrator of the standalone server — after promotion it becomes the domain's initial Administrator account, so treat this password as a domain credential from day one: complex, not reused from any other account, and noted in your lab password store rather than on a sticky note. Sign in, and Server Manager opens — its red banner will tell you the server has no remote management configured, which is normal and unneeded for a single-machine lab; you can safely dismiss that notification.

Verify you're actually running what you think you're running, because "a Windows that looks server-y" is not a verification. In PowerShell:

image placeholder

Image 04 — Server Hostname Verification

Insert the System properties dialog (rename field) or PowerShell showing the computer name before and after the rename.

A freshly installed server gets a random name like WIN-P3K9D2. You can promote it under that name — Active Directory won't stop you — but a domain is built to be referred to by name for years, and its first machine deserves one: DC01 in this lab. A predictable pattern (DC01, DC02, FILE01) is worth more than a clever name because it survives the day you add machines and start googling your own errors: "DC01" in an event log is instantly locatable, "WIN-P3K9D2" is not. Keep it short — computer names have a 15-character NetBIOS limit that still bites in real environments.

Two ways to do it. GUI: right-click Start → System → Advanced system settings → Computer Name tab → Change…, enter DC01, leave the workgroup as-is (it's irrelevant once the machine joins a domain), and accept the restart prompt. PowerShell (administrative):

image placeholder

Image 05 — Static IPv4 Configuration

Insert the IPv4 properties dialog (or Get-NetIPAddress output) showing DC01's static address, prefix, and gateway.

A domain controller must have a static (or DHCP-reserved) IPv4 address, and the reason is structural, not preference: every client that ever talks to this domain will store this server's IP in its DNS settings, and DNS zone data for the domain is tied to the DC's identity. If the DC's address changed behind the clients' backs, every machine in the domain would quietly lose name resolution at the same moment — a total outage with a boring, avoidable cause. DHCP is fine in the lab for the client VM; for the DC, set the address by hand.

The example network used throughout this article, stated once so every later command is readable: a /24 on 10.10.20.0, gateway 10.10.20.1 (your virtual network's router/NAT device, if it has one — on a purely isolated network with no exit, a gateway is not strictly required, but leave the field consistent with whatever your virtual network provides). Before typing anything: 10.10.20.x is a sample. If your lab uses a different range, use it; and if you do use this range, confirm 10.10.20.10 is unclaimed (a quick ping before configuring) so you don't create an address conflict — duplicate IPs in a lab produce some of the most confusing "nothing works" symptoms there are.

Configure it. GUI path: Settings → Network & internet → Ethernet → (your adapter) → Edit (IP assignment) → Manual, switch on IPv4, and enter the table's values. PowerShell, which is less scrolling and easier to verify:

image placeholder

Image 06 — Domain Controller DNS Settings

Insert the IPv4 DNS section of DC01's adapter properties showing 127.0.0.1 as the preferred DNS server, with automatic disabled.

The relationship that makes or breaks every first domain: a domain controller is expected to be its own primary DNS server, and its clients point at it. When a Windows client needs to find a domain controller, it doesn't call the DC by address — it asks its configured DNS server for SRV records under the domain (service locators like _ldap._tcp.dc._msdcs.example-lab.com). Those records exist only in the domain's own DNS zone, which the DC hosts. A client pointing at a public resolver like 1.1.1.1 or 8.8.8.8 will happily resolve ordinary websites and fail, every single time, to find the domain — which is why "internet works but the domain doesn't" is the single most common first-domain failure, and it's a DNS-settings problem, not an Active Directory problem.

Now the two-stage nuance that trips people up: the correct DNS setting for this server depends on which side of promotion it's on. Before promotion (right now), the server isn't a DC yet, so pointing it at itself would be wrong — leave it on the lab's current resolver, typically the gateway at 10.10.20.1; it needs working DNS to fetch updates and to reach anything during preparation. After promotion, it must use itself: preferred 127.0.0.1 (the DC's own DNS service) with no public resolver listed as preferred. The promotion wizard actually applies this change for you (Section 13), and if it ever doesn't take, this is the setting to check first. The rule to keep for every machine that will join the domain: its preferred DNS server is the domain controller, full stop.

One boundary to state clearly because labs blur it: "don't use public DNS on domain systems" refers to the domain's names — resolving dc01.example-lab.com against 8.8.8.8 will fail or worse. A DC may still need outbound resolution for things like Windows Update; in a richer network that's arranged with conditional forwarders from the domain's DNS to external resolvers. In this isolated lab there's no internet at all, so the question doesn't arise — but the forwarder concept is where this topic goes next in a real environment.

image placeholder

Image 07 — Network and DNS Diagnostic Output

Insert a PowerShell window showing ipconfig, ping, w32tm /query /status, and Get-ComputerInfo hostname output for DC01.

Three minutes of verification now prevents an hour of promotion debugging later, because the promotion wizard will fail on exactly the conditions this section checks — and its error messages are less legible than the tests below. Run these in an administrative PowerShell and read the expected results as you go:

Keep the failure taxonomy straight, because Section 18 leans on it: a connectivity failure is "packets don't get there" (ping fails, wrong subnet, adapter down) — fix the network. A resolution failure is "packets get there fine but names don't work" (ping to an IP works, ping to a hostname doesn't, wrong DNS server configured) — fix DNS settings. The two have opposite fixes, and misdiagnosing one as the other is how people restart services that were never the problem. If every line above matches its expectation, the server is ready for the role: correct name, correct address, live network, sane clock.

image placeholder

Image 08 — AD DS Prerequisite Checklist

Insert the hypervisor snapshot dialog for the DC01 VM alongside the completed preparation checklist from this section.

Preparation has two parts: a state check, and an escape hatch. The state check is short because Sections 4–7 already did the work — confirm, in one place, that the server is on the local Administrators group (you're using the built-in Administrator, so yes), fully updated (Windows Update, then reboot if prompted), named DC01, statically addressed, and DNS-configured per the pre-promotion state. The one condition that must be absent: the server must not already be a domain member or controller (a fresh install isn't — systeminfo shows "Domain: WORKGROUP"-style output; if it shows a domain, you're on the wrong machine or a stale VM).

Finally, run the platform's own prerequisite check, which validates that the OS can host AD DS before you commit to anything:

image placeholder

Image 09 — Add Roles and Features Wizard

Insert the Server Manager Add Roles and Features wizard with Active Directory Domain Services checked, including its confirmation dialog for the additional tools.

This section installs the role — the binaries, services, and management tools for AD DS — and only that. When it finishes, the server is still a standalone machine; nothing about domains has happened yet. The distinction is worth internalizing because it's the conceptual heart of the whole tutorial: role installation is like adding the engine, promotion (Section 11) is like building the car around it. The two are never the same step, and "I installed AD DS" is never by itself "I have a domain controller."

GUI path: in Server Manager, click the red flag notification ("A new deployment option is available") or go to Manage → Add Roles and Features. Click through Installation Type (Role-based) and Server Selection (the local server is preselected) to the Roles page, check Active Directory Domain Services, and accept the dialog that offers to add the Features (the .NET components the role needs) and the Management Tools And Features (the ADUC/DNS consoles you'll use constantly — always take these). Confirm and wait; the role installs in about a minute. PowerShell path:

Verify the role actually landed, and notice the new artifact:

image placeholder

Image 10 — Forest and Domain Naming Diagram

Insert a naming diagram: forest root, first domain example-lab.com, its DNS zones (the domain zone plus the _msdcs subdomain) and the DC's FQDN.

Promotion has exactly two modes, and picking the wrong one is the most expensive mistake in this tutorial. New forest (Section 11's path): create the first domain of a brand-new forest — correct when the server belongs to no domain at all, which is our fresh VM. Add a domain controller to an existing domain/forest: join a domain that already exists elsewhere — correct only when another DC is already running, and it requires that domain's credentials, working DNS to that domain, and network reachability to the existing DC. If you've been told to "build a domain" and no one has handed you credentials for an existing one, you're creating a new forest; if credentials and a domain name have been handed to you, stop and re-read the task, because promoting into someone else's forest with the wrong settings is a production incident, not a lab exercise.

The domain name is the other decision that's annoying to reverse later — not impossible (domain renaming is a documented but involved migration, not a rename dialog), so get the shape right now. The rules that matter: use a name under a domain you actually control. A lab domain like corp.example — where example is a reserved documentation domain — is safe; a lab domain of acme.com or yourcompany.co.uk that belongs to a real organization is not, because it collides with their real DNS and security boundaries the moment your lab touches the internet, and it trains a bad habit. That's why this article's example is example-lab.com: a subdomain-style name you'd own or that's clearly reserved, used consistently everywhere below. And avoid a bare single-label name (corp with no dot): single-label namespaces collide with Top-Level-Domain behavior in modern resolvers and are a known source of resolution breakage. The name you choose here becomes the domain's DNS zone, the suffix of every computer's FQDN (dc01.example-lab.com), and the container of every user's UPN (user@example-lab.com) — one decision, three permanent surfaces.

Two more fields the wizard will ask about, so they're not surprises in Section 11: the NetBIOS domain name — a short, no-dots legacy identifier (we use EXAMPLELAB) that older tools and some error messages still display, and the DNS root, which for the first domain is simply the domain name itself. Write your three values down now — FQDN, NetBIOS, and the DSRM password you'll choose in Section 12 — because the wizard won't let you go back to change them.

image placeholder

Image 11 — Promote This Server to a Domain Controller

Insert the "Promote This Server" wizard on the "Add a new forest" page, showing the root domain name field with example-lab.com.

This is the operation that creates the domain. Concretely, promotion builds the directory partition for your domain, creates the built-in accounts and groups (including the domain Administrator and Domain Admins), installs the DNS zone for the domain on this server, configures the server's network identity as a domain member, writes the initial directory data, and reboots the machine into its new role. Understanding that list explains everything about why it takes minutes rather than seconds, why it ends in a restart, and why Section 13 verifies rather than assumes. The point at which the server becomes a domain controller is the final stage of this process — the reboot — not the role installation you already did.

GUI path (recommended for a first promotion): in Server Manager, click the flag notification → Promote this server. On the first wizard page, choose Add a new forest and enter the root domain name: example-lab.com (yours, per Section 10). Set the Forest and Domain functional levels (Section 12 has the reasoning; for a fresh lab, the top value), and set the Directory Services Restore Mode (DSRM) password — a separate, strong, lab-noted password used only for offline directory repair; the wizard enforces the password policy on it. On the DNS Server options page, for the first domain controller in a new forest there is effectively one correct choice: let it install DNS (it must — the domain needs its zone now), accept the default location for the zones, and decline the delegation (there is no parent zone to delegate from in a new forest; the option is for child domains in existing forests). The subsequent pages are NetBIOS name (EXAMPLELAB), the accounts the DC creates (defaults), and a summary — then Install.

PowerShell path, for scripted or repeatable labs — it encodes the same decisions the wizard made explicit:

image placeholder

Image 12 — Domain Controller Promotion Settings

Insert the promotion wizard's DNS Server options page (install DNS checked, default zone location) next to the DSRM password field.

Section 11 walked the pages; this section explains the two settings that actually carry weight, so that "accept the defaults" becomes an informed choice rather than a reflex. The functional levels (forest and domain) declare the oldest Windows Server version whose AD features this forest/domain will use. In a brand-new lab where every machine will run current software, choosing the top level (Windows Server 2022) is correct and free — it unlocks the current feature set and the choice is one-way (levels can be raised later, never lowered), which is a non-issue when there's nothing older to protect. In an existing environment, this is the setting to stop and ask an administrator about: a legacy server somewhere may be pinning the forest at an old level, and the promotion options you're allowed will reflect that reality rather than your preference.

The DSRM password deserves its own paragraph because it's the setting people set badly and regret in exactly the scenario where regret is most expensive. Directory Services Restore Mode is the offline boot mode used to repair the directory database when normal tools can't run (a corrupted AD database, a DC that won't start its services). That repair requires this password — and it's the only credential that works there; the domain Administrator cannot substitute. So the standard is the same as for any recovery key: complex, unique to this DC, recorded where the rest of the lab's secrets live, and changed if the DC is ever exposed. The wizard's policy check on it isn't nagging; it's the minimum bar for your future offline-recovery option.

Everything else on the promotion pages — the accounts list, the summary — is informational for a first DC: the wizard creates the standard built-in set (Domain Admins, Schema Admins, the DnsAdmins group, the machine account for DC01$, and so on), and there's nothing to customize in a one-domain lab. The one line in the summary to read carefully before clicking Install is the confirmation that you're adding a domain controller to the forest you just named; a surprise existing domain appearing there means this VM is a stale snapshot or the wrong machine, and Install should not happen.

image placeholder

Image 13 — Promotion Completion and Restart

Insert the promotion progress/completion screen showing the reboot notice, and the post-restart sign-in screen with the DC's new domain identity.

Clicking Install (or the cmdlet running) starts the real work: prechecks, directory creation, DNS zone installation, and the configuration writes, each shown as a stage with its own progress. On the GUI path the final screen tells you the server will restart automatically to complete the configuration — accept it. Total elapsed time in a lab VM is typically a few minutes; the reboot itself is part of the operation, not an interruption. After it comes back, sign in with the account you used before (it's now the domain Administrator; more on the identity change in Section 14) and expect the desktop to look normal — promotion doesn't add visible desktop elements, and "it looks the same" is the correct post-restart observation, not a warning sign.

Confirm success by identity, not by appearance:

image placeholder

Image 14 — Domain Administrator Sign-In

Insert the Windows sign-in screen after promotion, showing the sign-in as example-lab\administrator (or administrator@example-lab.com).

Something subtle but real happened to the accounts: the local DC01\Administrator you've been using is still there, but it's no longer the account that matters. Promotion created the domain's example-lab\administrator (the built-in domain Administrator, whose password is the one you set at install time), and that's the identity that carries authority across the domain. The two sign-in forms are equivalent and worth both being able to read: example-lab\administrator (NetBIOS\user — what most tooling and error messages print) and administrator@example-lab.com (user@DNS-domain — the UPN form, what modern sign-in screens prefer). Verify which domain you're actually authenticated to — not just that you're "logged in" — with:

And the handling rules that make the difference between a safe lab and a bad habit: the domain Administrator is a privileged credential, and in this domain it's effectively the keys to everything — every computer, every account, every policy. That's fine for the twenty minutes of this tutorial, and wrong as a daily driver. The pattern to carry forward (and the one Section 16 builds) is: privileged accounts exist to perform administration, then step down; routine work happens under a standard user account that can't damage the domain. Never reuse the domain Administrator's password on any user account, never enter it into anything outside your own lab, and if this were a real domain rather than an isolated VM, the lab-noted password would live in a password manager with access control instead. "It's only a lab" is the exact thought that produces real-world incidents, because the habits are identical.

image placeholder

Image 15 — Active Directory and DNS Verification

Insert a split view: Active Directory Users and Computers showing the domain tree, and DNS Manager showing the example-lab.com zone with its records.

"Role installed" and "directory service functioning" are different claims, and this section exists to make the second one. The verification has three layers — the directory is reachable and reporting sane data, the DNS zone is populated, and name resolution actually works — because a failure at any layer produces symptoms the other layers won't show. Start with the PowerShell queries, which are the fastest complete picture:

The third layer is resolution, and it's the one clients actually depend on:

image placeholder

Image 16 — Test Organizational Unit and User

Insert ADUC showing the new Lab OU containing the ad.test user, with the user's General properties visible.

Verification so far has read the directory; this writes to it. OUs exist to organize objects and — later — to be the scope for group policy, so create one deliberately named container rather than dropping users loose in the default Users container (which is a system container, not a home for your objects): Tools → ADUC → example-lab.com → right-click → New → Organizational Unit, name it Lab. Then inside it, right-click Lab → New → User: first name Ad, last Test, user logon name ad.test (which becomes ad.test@example-lab.com as the UPN), and a new password generated specifically for this account — not the Administrator's, not any password in the lab notes, with the "user must change password at next logon" box ticked. That last habit is the point of the section as much as the user is: test accounts are how you'll sign in as a normal person in Section 17, and a test account sharing the admin password would make every subsequent "did the permission work?" question unanswerable.

The PowerShell equivalent, which doubles as the template for creating accounts in any real environment:

image placeholder

Image 17 — Join a Windows Client to the Domain

Insert the client's "Rename PC" / domain-membership dialog with example-lab.com entered, and the credentials prompt for the domain account.

Bring up Client01 (Section 2's second VM) on the same isolated network. Its one non-negotiable preparation, and the step that fails most joins: its DNS must point at the DC — set the adapter's DNS server to 10.10.20.10 (the DC) as preferred, replacing whatever the virtual network gave it. The join process discovers the domain by DNS, so a client on a public resolver cannot see the domain at all, and the resulting error ("The following error occurred: The specified domain either does not exist or could not be contacted") is a DNS setting problem wearing a domain costume. Verify before joining: ping dc01 from the client should resolve to 10.10.20.10 — if the name fails but the IP pings, you're looking at the exact Section 6 failure, on the client side.

Join it. GUI: Settings → System → About → Domain name (or the classic path: System properties → Change) → Domain → enter example-lab.com → when prompted, credentials of a domain account that may join computers — the domain Administrator (any Domain Admin works; a standard user cannot, and that's the permission boundary doing its job) → accept the invite, reboot when asked. PowerShell (administrative, on the client):

image placeholder

Image 18 — Active Directory Troubleshooting Workflow

Insert a flow diagram of the triage order: client DNS → connectivity → DC services → directory data, with the matching diagnostic commands at each step.

The failures below are the ones that actually happen on first domains, in roughly the order they're encountered, and each row pairs the symptom with the check that discriminates it — because the productive move is identifying which failure, not applying fixes. Use the filter to jump to a symptom class; the diagnostic column is ordered from cheapest to most involved. The general discipline, stated once and used throughout: never restart services or rebuild objects as a first attempt — a service that's "unhealthy" is usually downstream of a DNS or identity problem that restarting would only mask.

No rows match this filter — choose another symptom class or show all rows.

image placeholder

Image 19 — Domain Controller Security and Backup

Insert Windows Server Backup completing a System State backup of DC01, or the backup selection screen with System State checked.

The baseline security posture for a DC has few rules and they're all about exposure. Never expose a domain controller to the public internet — no direct WAN IP, no port forwarding to 389/445/88/53, no "quick" remote access through the DC itself; in production it sits behind the network edge and administration reaches it through a controlled path. This lab's isolation network already enforces the right shape; keep it that way, because the moment a DC is internet-reachable with a weak DSRM or admin password, the failure mode is no longer a broken lab. Restrict who can touch it: keep Domain Admins small (in this lab: effectively one person), do routine work as the standard user from Section 16, and don't create "admin2" convenience accounts — every additional privileged account is a permanent standing credential to protect. Keep it updated: Windows Update applies to DCs like any server, but in a real domain you patch DCs deliberately (understood, staged, reversible) rather than on a silent auto-reboot schedule — in this disposable lab, update whenever and reboot without ceremony.

Backup is where the lab/production line matters most, so it's drawn explicitly. The DC's state that must be recoverable is its System State — the directory database, the registry, and the boot files together — because you can't restore "the user ad.test" from a file backup; you restore the DC. On this lab VM, Windows Server Backup → Backup once → System State (or the hypervisor snapshot) is the right level, and the point to internalize is what snapshots are not: a VM snapshot is a rollback convenience, not a tested recovery — in production, the standard is scheduled System State backups, an off-DC copy, and at least one documented restore test, because an untested backup is a hope, not a plan. The DSRM password from Section 12 is the key to the offline end of that recovery chain, which is why it was never allowed to be weak or shared.

One maintenance habit that compounds: keep the lab's known-good state honest. After this tutorial, take a final snapshot named something like Working-Domain-v1. Every later experiment — a second DC, a broken join, a policy gone wrong — then has a clean "the domain that worked" to return to, and the difference between a productive lab and a dead one is usually just that one habit.

image placeholder

Image 20 — First Domain Validation Checklist

Insert a screenshot of the completed checklist below, or a final "all green" verification: whoami on the DC, Get-ADDomain output, and the client signed in as ad.test.

Run the checklist below as the acceptance test for the whole tutorial — every box corresponds to a section's verification, so an unchecked box is a pointer, not a mystery. Your ticks are saved in this browser; copy the list to carry it into your own notes:

What comes next, in a sensible order: join more clients and practice the standard-user daily flow until the local-vs-domain distinction is invisible; add a second domain controller to meet replication and the "one DC is a single point of failure" reality head-on; then group policy, because that's the payoff the whole directory exists to deliver. Those are their own substantial topics and this article deliberately stops at a verified first domain rather than expanding into them. If you'd rather widen the base first — the hardware the DC runs on, or the power and cooling behavior that quietly takes servers down — the guides below cover it.