How to Set Up Active Directory (AD DS) on Windows Server

Before you begin: prerequisites

A domain controller becomes the backbone of your network, so get the basics right first:

• A supported Windows Server installation (Standard or Datacenter). A trial or evaluation build is fine for a lab.
• A static IP address. Domain controllers should never use a DHCP-assigned address. Set a fixed IPv4 address, subnet mask and gateway before promotion.
• A sensible computer name set before you promote — renaming a domain controller afterwards is disruptive.
• Latest updates installed and a reboot done, so you start from a clean, patched state.
• A domain name you have thought about. Use a name you control, such as a subdomain of a domain you own (for example ad.example.com or corp.example.com). Avoid a bare single-label name like CONTOSO, and avoid reusing your public website's exact domain.

Step 1 — Install the AD DS role

You can do this with the graphical Server Manager or with one line of PowerShell.

Using Server Manager

1. Open Server Manager and choose Manage → Add Roles and Features.
2. Click through Before You Begin, keep Role-based or feature-based installation, and select your local server.
3. On the Server Roles page, tick Active Directory Domain Services. When the pop-up offers to add the required management tools, click Add Features.
4. Click Next through the remaining pages and then Install. You do not need to reboot yet.

Using PowerShell

Open an elevated PowerShell window and run:

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

This installs the role and the AD DS administration tools without touching the promotion step, which comes next. It is the same command Microsoft gives in Install Active Directory Domain Services on Windows Server, which also notes that no reboot is required until the AD DS installation is complete.

Step 2 — Promote the server to a domain controller

Installing the role does not create a domain by itself. The promotion step is what actually builds the directory.

1. In Server Manager, look for the yellow notification flag near the top right after the role install finishes. Click it and choose Promote this server to a domain controller.
2. The Active Directory Domain Services Configuration Wizard opens. On the Deployment Configuration page, because this is a brand-new environment, select Add a new forest.
3. Enter your Root domain name as a fully qualified name, for example corp.example.com. This becomes the name of your first domain and your forest.
4. On Domain Controller Options, choose your forest functional level and domain functional level (see the note below), keep DNS server selected, and set a Directory Services Restore Mode (DSRM) password. Store that password somewhere safe — you need it for directory recovery.
5. You may see a warning about DNS delegation on the DNS Options page. For a first, standalone forest this is expected and safe to continue past.
6. Confirm or accept the NetBIOS domain name the wizard suggests (a short version of your domain).
7. Accept or change the default database, log and SYSVOL paths, review the summary, and let the prerequisite check run. Warnings are common and usually fine; hard errors must be fixed first.
8. Click Install. The server configures the directory and reboots automatically. After it comes back up, you sign in with the new domain administrator account.

Prefer to script it? The equivalent command creates a new forest and installs DNS in one go:

Install-ADDSForest -DomainName "corp.example.com" -InstallDns

You will be prompted for the DSRM (SafeMode) password, and the server reboots when it finishes — Microsoft's Install-ADDSForest cmdlet reference confirms all three: -InstallDns defaults to $true for a forest installation, an omitted -SafeModeAdministratorPassword makes the cmdlet prompt for a masked password, and leaving out -NoRebootOnCompletion means the computer reboots when the command finishes.

A word on functional levels

The functional level sets which Active Directory features are available and, in effect, the oldest version of Windows Server you are allowed to run as a domain controller. It has nothing to do with your client PCs. For a new forest, pick the highest level that every domain controller you plan to run can support:

• If all your domain controllers will run a current Windows Server release, choose the matching level to unlock the newest capabilities.
• If you must keep an older domain controller around, you are capped at the level it supports, and you can raise the level later once that server is retired.

You can raise a functional level after the fact, but lowering it is generally not supported, so choose deliberately. Newer Windows Server versions also set a minimum functional level: a Windows Server 2025 domain controller requires at least the Windows Server 2016 forest and domain functional level, so very old levels will block a modern domain controller. Microsoft's AD DS functional levels interoperability matrix shows exactly that — a Windows Server 2025 DC is supported at the 2025 and 2016 levels but not at Windows Server 2012 R2 — and confirms functional levels do not affect the operating systems on workstations and member servers.

Step 3 — Create Organizational Units and users

With the domain up, open Active Directory Users and Computers (ADUC) — search for it in the Start menu, or run dsa.msc. This is where day-to-day directory administration happens.

Create an Organizational Unit (OU)

Organizational Units are folders that let you group users and computers so you can delegate control and target Group Policy. A flat directory with everything in the default Users container is a habit worth breaking early.

1. In ADUC, right-click your domain (or a parent OU) and choose New → Organizational Unit.
2. Give it a clear name such as Staff, Workstations or Service Accounts.
3. Leave Protect container from accidental deletion ticked unless you have a specific reason not to. Click OK.

Create a user account

1. Open the OU where the account should live, right-click in it and choose New → User.
2. Fill in the name fields and the User logon name (this is what they will sign in with, for example jsmith@corp.example.com). Click Next.
3. Set an initial password. For a real account, leave User must change password at next logon ticked so the person sets their own. Click Next, then Finish.

You can do the same from PowerShell once the tools are installed — for example New-ADOrganizationalUnit to make an OU and New-ADUser to create accounts — which is far quicker when you are onboarding many people at once.

Step 4 — Join a client to the domain

Now connect a workstation so its users can log in with domain accounts. The client must run a business edition of Windows — Windows 11 Pro, Enterprise or Education (Home cannot join a domain) — and must be able to reach the domain controller over the network.

1. On the client, set its preferred DNS server to the domain controller's IP address. Without this, the PC cannot find the domain. This is the step people forget.
2. Open Settings → System → About (or run sysdm.cpl) and open the System Properties dialog. On the Computer Name tab click Change.
3. Under Member of, select Domain, type your domain name (for example corp.example.com) and click OK.
4. When prompted, enter the credentials of a domain account that is allowed to join computers to the domain (a domain administrator works for testing).
5. You should see a "Welcome to the domain" message. Restart the client, then at the sign-in screen choose Other user and log in as corp\username or username@corp.example.com.

The scripted equivalent, run in an elevated PowerShell on the client, is:

Add-Computer -DomainName "corp.example.com" -Credential (Get-Credential) -Restart

Where to go next

Once the basics work, the natural next steps are: promote a second domain controller for redundancy (add the AD DS role on another server and choose Add a domain controller to an existing domain instead of a new forest), start shaping Group Policy to enforce settings across your OUs, and set up regular system state backups of your domain controllers. Treat the DC and its DSRM password as critical infrastructure from day one.

Frequently asked

Do I need a separate DNS server to run Active Directory?

No. Active Directory depends heavily on DNS, but the promotion wizard can install and configure a DNS server on the domain controller for you when you create a new forest. That is the normal setup for a first domain controller. In larger environments you may point to existing DNS servers instead, but every domain-joined machine must be able to resolve the domain's DNS records, so its preferred DNS server should be a domain controller, not your router or a public resolver.

What forest and domain functional levels should I choose?

For a brand-new forest, pick the highest functional level that every domain controller you plan to run can support. The functional level is tied to the oldest Windows Server version you allow as a domain controller, not to your client PCs. If all your domain controllers will run a current Windows Server release, choose the matching level to unlock the newest features. If you must keep an older domain controller, you are limited to the level it supports and can raise it later once the old server is gone. You can raise a functional level, but you cannot easily lower it.

Can I join a Windows 11 Home PC to the domain?

No. Windows 11 Home cannot join an Active Directory domain. You need Windows 11 Pro, Enterprise or Education. The client must also use a domain controller as its preferred DNS server and be able to reach the domain over the network, and you sign in with an account that has permission to join computers to the domain.

How many domain controllers do I need?

Technically one domain controller is enough to have a working domain, but a single DC is a single point of failure. For anything beyond a lab, run at least two domain controllers so authentication and DNS keep working if one server goes offline or is rebooted for updates. Additional domain controllers are added by promoting more servers into the existing domain rather than by creating a new forest.