Windows Server Administration & Active Directory

Most organizations eventually reach a point where managing user accounts, permissions, and security settings on each machine individually becomes unsustainable. Imagine a small company, Greenfield Engineering, with 50 employees split between an Engineering department and an Operations department. Each employee needs a login, access to shared files, and consistent security settings on their workstation. Without centralized management, an administrator would need to create local accounts on every machine, set permissions one by one, and hope that password policies stay consistent. Windows Server and Active Directory solve this problem by providing a single directory service that stores identities, enforces policies, and controls access across the entire network. This chapter walks through the core concepts, from choosing a Windows Server edition to managing day-two operations, using Greenfield Engineering as a running example.

A Brief History

Microsoft has shipped a server-focused operating system since 1993. The major milestones help explain why Windows Server and Active Directory are so deeply embedded in enterprise IT:

Desktop Release	Server Counterpart	Notable Addition
Windows NT 3.1 (1993)	Windows NT 3.1 Advanced Server	First server OS from Microsoft
Windows XP (2001)	Windows Server 2003	Widespread domain adoption
Windows Vista (2007)	Windows Server 2008	Server Core mode introduced
Windows 8 (2012)	Windows Server 2012	ReFS filesystem, RDMA, more virtualization
Windows 10 (2016)	Windows Server 2016	Windows containers, Nano Server
Windows 11 (2021)	Windows Server 2022	Secured-core, SMB compression

Active Directory premiered with Windows 2000 Server in 1999. Desktop and server releases generally coincide because they share a large amount of underlying code. Windows Server licenses for the Datacenter edition can cost several thousand dollars, which is one reason cloud-hosted directory services and open-source alternatives have become attractive.

Windows Server Editions and Installation Modes

Microsoft ships Windows Server in two main editions: Standard and Datacenter. Both share the same feature set for Active Directory, DNS, file services, and most server roles. The key difference is virtualization licensing. Standard edition includes licenses for up to two virtual machines (VMs) running Windows Server on the same physical host. Datacenter edition allows unlimited VMs per host, making it the right choice for dense virtualization environments. For Greenfield Engineering’s modest infrastructure (a few physical servers), Standard edition is the practical and cost-effective choice.

Beyond edition selection, administrators choose between two installation modes. Desktop Experience (sometimes called the GUI install) provides the familiar Windows graphical interface with Server Manager, the MMC snap-ins, and a taskbar. Server Core strips away the graphical shell entirely, leaving only a command prompt and PowerShell. Server Core uses less disk space, has a smaller attack surface (fewer components means fewer vulnerabilities), and requires fewer patches. The tradeoff is that all configuration happens through the command line or remote management tools.

When to Choose Server Core

For domain controllers and infrastructure servers that rarely need interactive login, Server Core is the recommended choice. You can manage it remotely using tools like Remote Server Administration Tools (RSAT) from a workstation with Desktop Experience, or through Windows Admin Center in a browser. Reserve Desktop Experience for servers where you genuinely need a local GUI, such as a jump box or a training environment.

Windows Server organizes its functionality into roles and features. A role is a primary function the server performs; features are supporting capabilities. You install only what you need, following the principle of least functionality. For Greenfield Engineering’s first domain controller, the essential roles are AD DS and DNS Server. A broader list of available roles illustrates just how much Windows Server can do:

Role / Service	Purpose
Active Directory Domain Services (AD DS)	Centralized identity, authentication, and policy
DNS Server	Name resolution; required for AD to function
DHCP Server	Automatic IP address assignment
File and Storage Services	File shares, DFS, deduplication, storage tiering
Internet Information Services (IIS)	Web server (about 10 % market share, similar to Apache)
Remote Desktop Services	Hosted virtual desktops and remote application delivery
Hyper-V (Virtualization)	Create and manage virtual machines
Windows Server Backup	Backup and recovery for servers and AD
Exchange Server	On-premises email (now largely replaced by Microsoft 365)
RADIUS (NPS)	Authentication, authorization, and accounting for network access
WDS (Windows Deployment Services)	Network-based OS installation for new machines
SMTP Server	Mail relay for applications and services
VPN (RRAS)	Remote access and site-to-site VPN
DNSSEC	DNS Security Extensions for signed zones

Windows Server also runs Windows Defender Antivirus, supports failover clustering for high availability, and since Windows Server 2016 can run Windows Server Containers managed by Docker.

Active Directory Fundamentals

Active Directory Domain Services is a directory service that stores information about objects on the network (users, computers, groups, printers) and makes that information available for authentication and authorization. When an employee at Greenfield Engineering logs in at their workstation, the workstation contacts a domain controller to verify the credentials against the AD database. This centralized model means that one user account works across every domain-joined machine.

Several concepts form the foundation of Active Directory:

A domain is a logical boundary for administration and authentication. All objects within a domain share a common database and a common set of policies. Greenfield Engineering will operate a single domain, greenfield.local, which is sufficient for a 50-person company. Domains use DNS-style names; organizations typically use a .local suffix for internal-only domains to avoid conflicts with publicly registered names, or a subdomain of their real domain (e.g., corp.greenfield.com). Internal domains with .local are not routable on the internet.

A forest is the top-level container in Active Directory. The first domain you create automatically becomes the root of a new forest. Forests matter because they define the outermost trust boundary. In a multi-domain enterprise, domains within the same forest automatically trust each other. Greenfield Engineering’s single domain is also its entire forest.

A trust relationship allows users in one domain to access resources in another. Within a forest, trusts are automatic and transitive. Between forests, trusts must be explicitly configured. For a small company, this concept becomes relevant only if Greenfield Engineering later merges with or acquires another company that has its own domain.

Kerberos authentication is the protocol AD DS uses to verify identities. When a user logs in, the workstation contacts a Key Distribution Center (KDC) on the domain controller and proves the user’s identity (via password hash). The KDC returns a Ticket-Granting Ticket (TGT) that is valid for a set period (typically 10 hours). When the user then needs to access a network resource (a file share, a web app), the workstation presents the TGT to the KDC and receives a service ticket for that specific resource — without re-entering credentials. The resource server validates the service ticket without contacting the KDC again. This mutual-authentication, ticket-based design means credentials are never sent over the network in the clear.

DNS dependency is one of the most important things to understand about Active Directory. AD relies on DNS to locate domain controllers, services, and resources. When a workstation needs to find a domain controller, it queries DNS for SRV records (service locator records) that point to the right server. If DNS is broken, authentication fails, domain joins fail, and Group Policy cannot be applied. For this reason, the domain controller almost always runs the DNS Server role as well, and all domain-joined machines should point to internal DNS servers (not public resolvers) for name resolution.

DNS Is the Foundation

The single most common cause of Active Directory problems is misconfigured DNS. Every domain-joined machine must use the domain’s DNS servers as its primary resolvers. Pointing a workstation at 8.8.8.8 or another public resolver will prevent it from locating domain controllers, and login will fail. When troubleshooting AD issues, always check DNS first.

AD Building Blocks: Users, Groups, and Organizational Units

Within a domain, the three most important object types are users, groups, and organizational units.

A user object represents a person (or a service account) and stores attributes like username, password hash, email address, department, and group memberships. For Greenfield Engineering, each of the 50 employees gets a user object. The user account is what they use to log in, access file shares, and authenticate to internal applications.

A group is a collection of users (or other groups) used to assign permissions efficiently. Instead of granting file share access to 25 individual engineers, you create an “Engineering” group, add the 25 users, and grant access to the group. When a new engineer joins, you add them to the group and they instantly inherit the correct permissions. Active Directory supports several group types, but the most commonly used is the security group with global scope, which works for assigning permissions to resources within the domain.

An organizational unit (OU) is a container within a domain that lets you organize objects and delegate administration. OUs serve two purposes: they provide structure (similar to folders in a file system), and they serve as targets for Group Policy. Greenfield Engineering might create the following OU structure:

greenfield.local
├── Engineering
│   ├── Users
│   └── Computers
├── Operations
│   ├── Users
│   └── Computers
└── Service Accounts

This structure allows the administrator to apply different Group Policies to Engineering and Operations, delegate password-reset authority for Operations users to the Operations manager, and keep service accounts in their own OU with a stricter policy.

OUs vs. Groups

A common source of confusion is when to use OUs versus groups. OUs organize objects for policy application and administrative delegation. Groups collect users for permission assignments. A user can belong to many groups but sits in only one OU. Think of OUs as the organizational chart and groups as project teams: an employee has one position on the chart but may be on several project teams.

Promoting a Domain Controller

A freshly installed Windows Server is just a member server. To make it a domain controller, you promote it by installing the AD DS role and running the Active Directory Domain Services Configuration Wizard. Here is what happens during promotion for a new forest:

1. The administrator installs the AD DS role (through Server Manager or PowerShell).
2. The promotion wizard asks whether to add a DC to an existing domain or create a new forest. For Greenfield Engineering’s first server, you select “Add a new forest” and specify the root domain name (greenfield.local).
3. The wizard configures the DNS Server role, since AD needs DNS to function. It creates the forward lookup zone for greenfield.local and populates it with SRV records that clients use to locate the domain controller.
4. A Directory Services Restore Mode (DSRM) password is set. This password is used for offline recovery of the AD database and should be stored securely (for example, in a sealed envelope in a safe).
5. The server reboots. When it comes back up, it is a domain controller hosting the AD database (stored in C:\Windows\NTDS\) and the SYSVOL share (which holds Group Policy files and logon scripts).

After promotion, the domain controller handles Kerberos authentication, responds to LDAP queries, serves DNS for the domain, and replicates its database to any additional domain controllers. For resilience, production environments should always have at least two domain controllers; if one fails, the other continues to authenticate users.

In PowerShell, the entire promotion can be scripted:

# Install the AD DS role and management tools
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

# Promote to a new forest (prompts for DSRM password)
Install-ADDSForest -DomainName "greenfield.local" `
    -DomainNetbiosName "GREENFIELD" `
    -InstallDns:$true `
    -Force:$true

Group Policy Objects

Group Policy Objects (GPOs) are the primary mechanism for enforcing configuration and security settings across domain-joined machines. A GPO is a collection of settings that can target computers, users, or both. GPOs are created in the Group Policy Management Console (GPMC) and linked to a site, domain, or OU.

When a computer starts up, it applies computer-targeted policies. When a user logs in, it applies user-targeted policies. The order of application follows the acronym LSDOU: Local policy first, then Site, Domain, and finally OU. If multiple GPOs apply conflicting settings, the last one applied wins (the OU-linked GPO overrides the domain-linked one). This layered model lets you set broad defaults at the domain level and apply specific overrides at the OU level.

For Greenfield Engineering, consider these common policies:

Password policy (applied at the domain level): minimum length of 12 characters, complexity enabled, maximum age of 90 days, lockout after 5 failed attempts for 30 minutes. Note that the default domain password policy applies to all users in the domain; fine-grained password policies (available in Windows Server 2008 and later) allow different rules for different groups.

Screen lock policy (applied at the OU level): configure the screen saver timeout to 10 minutes and require a password on resume. You might set a shorter timeout for Operations workstations that sit in a shared workspace, and a longer one for Engineering workstations in private offices.

Software restriction or AppLocker policies: control which applications users can run, preventing the execution of unauthorized software.

Drive mapping and printer deployment: use Group Policy Preferences to map network drives and install printers automatically when users log in.

GPO Testing Strategy

Never link an untested GPO directly to a broad OU. Instead, create a “Test” OU, move one or two test computer or user accounts into it, link the GPO there, and verify the behavior. Once confirmed, move the GPO link to the production OU. You can also use the gpresult /r command on a client machine to see which GPOs are currently applied and whether any were denied or filtered.

User and Group Management with PowerShell

While the GUI tools (Active Directory Users and Computers, Active Directory Administrative Center) work well for one-off tasks, PowerShell is essential for bulk operations and repeatable administration. The ActiveDirectory PowerShell module (installed with RSAT or on a domain controller) provides cmdlets for every common task.

Creating a single user:

New-ADUser -Name "Alice Chen" `
    -SamAccountName "achen" `
    -UserPrincipalName "achen@greenfield.local" `
    -Path "OU=Users,OU=Engineering,DC=greenfield,DC=local" `
    -Department "Engineering" `
    -AccountPassword (ConvertTo-SecureString "TempP@ss2026!" -AsPlainText -Force) `
    -ChangePasswordAtLogon $true `
    -Enabled $true

The -Path parameter places the user in the correct OU. The -ChangePasswordAtLogon flag ensures Alice sets her own password at first login.

Bulk-creating users from a CSV file:

Import-Csv "C:\setup\new-employees.csv" | ForEach-Object {
    New-ADUser -Name "$($_.FirstName) $($_.LastName)" `
        -SamAccountName $_.Username `
        -UserPrincipalName "$($_.Username)@greenfield.local" `
        -Path $_.OUPath `
        -Department $_.Department `
        -AccountPassword (ConvertTo-SecureString $_.TempPassword -AsPlainText -Force) `
        -ChangePasswordAtLogon $true `
        -Enabled $true
}

This approach scales to onboarding dozens of employees at once, with the CSV serving as a reviewable record of what was created.

Querying users:

# Find all users in the Engineering OU
Get-ADUser -Filter * -SearchBase "OU=Users,OU=Engineering,DC=greenfield,DC=local" `
    -Properties Department, LastLogonDate |
    Select-Object Name, SamAccountName, Department, LastLogonDate

# Find disabled accounts that have not logged in for 90 days
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $cutoff -and Enabled -eq $false} `
    -Properties LastLogonDate

Managing groups:

# Create a security group
New-ADGroup -Name "Engineering-FileShare" `
    -GroupScope Global `
    -GroupCategory Security `
    -Path "OU=Engineering,DC=greenfield,DC=local" `
    -Description "Access to the Engineering shared drive"

# Add a user to the group
Add-ADGroupMember -Identity "Engineering-FileShare" -Members "achen"

# List members of a group
Get-ADGroupMember -Identity "Engineering-FileShare" | Select-Object Name

The pattern is consistent: use groups to control access, and use PowerShell to manage group membership at scale.

File Shares and NTFS Permissions

Shared folders are one of the most common resources that Active Directory groups control. Windows uses two layers of permissions for network file access: share permissions and NTFS permissions. Understanding how they interact is critical.

Share permissions apply only when a user accesses the folder over the network (via \\server\sharename). They are coarse-grained, offering only Full Control, Change, and Read. Best practice is to set share permissions to “Authenticated Users: Full Control” (or Change) and use NTFS permissions for fine-grained control. This simplifies troubleshooting because only one permission layer is doing the real work.

NTFS permissions apply whether the user accesses the file locally or over the network. They are granular, supporting Read, Write, Modify, Read & Execute, List Folder Contents, and Full Control, among others. NTFS permissions also support inheritance: permissions set on a parent folder flow down to child folders and files unless explicitly broken.

The effective permission a user has is the most restrictive combination of share and NTFS permissions. If the share grants Change but NTFS grants only Read, the user gets Read. This is why setting the share permission broadly and relying on NTFS keeps things predictable.

For Greenfield Engineering, a file share structure might look like this:

E:\Shares
├── Engineering    (Engineering-FileShare group: Modify; Operations group: no access)
├── Operations     (Operations-FileShare group: Modify; Engineering group: no access)
└── Common         (All Employees group: Read; Department Leads group: Modify)

Creating a share and setting permissions in PowerShell:

# Create the folder
New-Item -Path "E:\Shares\Engineering" -ItemType Directory

# Share it on the network
New-SmbShare -Name "Engineering" `
    -Path "E:\Shares\Engineering" `
    -FullAccess "Authenticated Users"

# Set NTFS permissions (remove inheritance first, then add explicit)
$acl = Get-Acl "E:\Shares\Engineering"
$acl.SetAccessRuleProtection($true, $false)  # disable inheritance, remove inherited rules

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    "GREENFIELD\Engineering-FileShare", "Modify", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$acl.AddAccessRule($rule)

$adminRule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    "BUILTIN\Administrators", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$acl.AddAccessRule($adminRule)

Set-Acl "E:\Shares\Engineering" $acl

Permission Inheritance Pitfalls

Breaking inheritance is sometimes necessary, but it creates a management burden: permissions on those folders no longer update automatically when parent permissions change. Document every folder where inheritance is broken. A common mistake is breaking inheritance, forgetting to add back the necessary explicit permissions, and accidentally locking out administrators.

Day-Two Operations: Backup, Replication, and Monitoring

Installing and configuring a domain is the beginning, not the end. Ongoing operations determine whether the environment stays healthy.

Backup and recovery for Active Directory means backing up the System State of domain controllers, which includes the AD database (ntds.dit), the SYSVOL, the registry, and the boot files. Windows Server Backup can perform this, and the backup should run nightly at minimum. The DSRM password set during promotion is required to perform an authoritative restore, where you mark specific objects or an entire database as the version that should replicate to other DCs. Test your restore procedure periodically; a backup that has never been tested is not really a backup.

Replication keeps the AD database consistent across domain controllers. In a single-site deployment like Greenfield Engineering’s, replication happens automatically and frequently (within seconds via change notification). In multi-site deployments, replication schedules and site links control how often data synchronizes across WAN connections. Two essential diagnostic commands are:

# Check replication status between domain controllers
repadmin /replsummary

# Run a comprehensive DC health check
dcdiag /v

The repadmin tool shows whether replication is succeeding or failing between DC pairs. The dcdiag utility runs dozens of tests covering DNS registration, Kerberos authentication, SYSVOL replication, and more. Run both regularly and after any changes to the environment.

Monitoring AD health also means watching the Windows Event Logs. The Directory Service log (in Event Viewer) records replication events, schema changes, and errors. The DNS Server log tracks query failures and zone transfer issues. Centralized log collection (using Windows Event Forwarding or a SIEM) ensures you catch problems before users report them.

Other day-two concerns include managing the AD Recycle Bin (enable it so that accidentally deleted objects can be recovered without a full restore), monitoring FSMO roles (Flexible Single Master Operations, the five special roles distributed among DCs), and reviewing stale computer and user accounts that should be disabled or removed.

# Enable the AD Recycle Bin (one-time, irreversible)
Enable-ADOptionalFeature "Recycle Bin Feature" `
    -Scope ForestOrConfigurationSet `
    -Target "greenfield.local" `
    -Confirm:$false

# Find computer accounts that have not logged in for 90 days
$cutoff = (Get-Date).AddDays(-90)
Get-ADComputer -Filter {LastLogonDate -lt $cutoff} -Properties LastLogonDate |
    Select-Object Name, LastLogonDate

Comparing Linux and Windows Administration

Students in this course work with both Linux and Windows servers, and it is worth stepping back to compare the two approaches. The underlying goals are identical: manage identities, enforce security, control access to resources, and keep services running. The tools and philosophies differ.

In Linux, identity management is typically local (/etc/passwd, /etc/shadow, /etc/group) unless you integrate with a directory service like FreeIPA or join the machine to an Active Directory domain using SSSD or Winbind. Configuration is done through text files, and automation tools like Ansible push changes declaratively. The administrator composes small, focused tools (useradd, chmod, systemctl, iptables) into scripts or playbooks.

In Windows with Active Directory, identity is centralized from the start. Group Policy pushes configuration to machines automatically, replacing the need for an external automation tool for many tasks. PowerShell provides a consistent, object-oriented scripting environment that can manage local and remote systems. The administrator works within a more integrated (and more opinionated) ecosystem where Microsoft provides the tooling.

Neither approach is inherently superior. Linux environments tend to offer more flexibility and transparency (everything is a file, configuration is plaintext). Windows with AD offers a more turnkey experience for managing large fleets of Windows workstations, especially in organizations that rely on Microsoft productivity tools. In practice, most enterprises run both, and a well-rounded administrator is comfortable moving between them.

The table below summarizes the key parallels:

Task	Linux	Windows / AD
User management	useradd, /etc/passwd	New-ADUser, AD Users and Computers
Group management	groupadd, /etc/group	New-ADGroup, AD security groups
Configuration push	Ansible, Puppet, Chef	Group Policy Objects
File permissions	chmod, chown, POSIX ACLs	NTFS ACLs, share permissions
Service management	systemctl	services.msc, Get-Service
Authentication	PAM, Kerberos (via SSSD)	Kerberos (native to AD)
DNS	BIND, systemd-resolved	AD-integrated DNS
Firewall	iptables, nftables, ufw	Windows Firewall with Advanced Security

Understanding both ecosystems makes you a more effective administrator. The concepts transfer even when the commands do not: a security group in AD serves the same purpose as a POSIX group, an OU is conceptually similar to organizing hosts into Ansible inventory groups, and a GPO is analogous to an Ansible playbook that runs automatically at login.