Windows Server: the practices that actually matter

Search for Windows Server best practices and you get settings. Disable SMBv1, rename the administrator account, configure the page file. Useful, mostly, and none of it is what takes businesses down.

What takes businesses down is a server that stopped receiving security updates eighteen months ago and nobody noticed, a single machine running the domain controller and the file share and the line-of-business application, and a directory nobody has ever restored from backup because nobody was sure how.

Those three account for more genuine incidents than every registry setting combined, and all three are questions of process rather than configuration.

The dates, first, because they are closer than people think

Windows Server follows a Long-Term Servicing Channel model: roughly five years of mainstream support, then roughly five years of extended support, then nothing. Extended support means security updates only — no new features and no non-security fixes.

The dates below are Microsoft's published lifecycle figures. They are worth checking against your own estate before reading further, because for most businesses at least one row applies right now.

Windows Server 2022 leaving mainstream support does not require immediate action, but it does change what you are entitled to: security fixes continue, everything else stops. That matters if you are depending on a non-security bug being fixed.

The practice worth adopting is trivial and almost never done. Put every server's extended support end date in the same calendar the business uses for contract renewals, with a reminder eighteen months ahead. Eighteen months is roughly what a domain controller migration needs if it is going to be done calmly rather than in a panic.

One server, several jobs: why it happens and what it costs

Growing businesses consolidate roles onto single machines because each addition was individually reasonable. The server had capacity, the request was urgent, and putting the new thing somewhere else meant buying hardware.

The cost appears later, and it appears in four places at once.

• Patching. Each role has its own maintenance window and its own restart tolerance. When they share a machine, the reboot schedule is the intersection of all of them, which is usually never.
• Failure domain. One hardware fault takes out authentication, file access and the application together, so what should have been a partial outage is a total one.
• Security. A vulnerability in any one role is a foothold on a machine holding everything else. This matters most on domain controllers, which hold the credentials for the entire estate.
• Capacity. Load from one role starves another, and diagnosing it is harder because the symptoms appear in the wrong service.

The separation that matters most is the domain controller. It should do authentication, DNS and nothing else — no file shares, no applications, no management tools, no browsing from the console. It holds the credentials that unlock everything, which makes anything else running on it an unnecessary route to those credentials.

Virtualisation makes this affordable, and that is the argument for it here. Separate roles onto separate virtual machines on one host and you get distinct failure domains, independent patch schedules and independent restarts without buying four servers.

Server Core, and the reason to consider it

Windows Server installs either with the Desktop Experience — the familiar graphical shell — or as Server Core, which has no desktop shell and is administered remotely or through PowerShell.

Server Core is the better default for infrastructure roles, for a reason that is easy to state: components that are not installed cannot be vulnerable, and do not need patching. Fewer components means a smaller attack surface, fewer monthly updates, and fewer restarts.

The honest objection is real too. Server Core requires administrators comfortable with remote management and PowerShell. A team that is not will end up making changes rarely and reluctantly, and rarely-and-reluctantly is how servers drift out of date.

Check the application server case before committing. Some vendor installers and management consoles still assume a graphical shell, and discovering that after the build is a rebuild.

Active Directory: the restore nobody has tested

Active Directory is the system every other system depends on. If it is unavailable, nobody logs in anywhere — not to workstations, not to file shares, not to the applications that authenticate against it.

It is also the system whose recovery is least often rehearsed, because restoring a directory is not the same operation as restoring a file server and the difference is not obvious until you are doing it.

1. 1

   Run at least two domain controllers

   One is a single point of failure for the entire business. Two is the minimum, and they should not share a hypervisor host, a power feed or a storage array — a redundancy that fails together is not redundancy.

2. 2

   Understand that replication is not backup

   A deleted account, a bad group policy or a mistaken bulk change replicates to every controller within minutes. Replication protects against a controller failing, not against the directory being wrong.

3. 3

   Enable the AD Recycle Bin

   It makes recovering a deleted object routine instead of an authoritative restore. It is off by default and enabling it later does not retroactively protect anything already deleted.

4. 4

   Take real system state backups

   A file-level copy of a domain controller is not a restorable directory. Back up system state, and keep enough history to go back past the point where a problem was introduced rather than only to yesterday.

5. 5

   Rehearse a forest recovery once

   In a lab, from your actual backups, with the documentation you actually have. It is a genuinely awkward procedure, and the time to discover that is not during an incident.

6. 6

   Keep DNS with the directory

   AD depends on DNS completely. Most directory faults that present as authentication failures are DNS faults, and checking DNS first saves hours.

Licensing, briefly, because it changes the design

Windows Server licensing affects architecture, so it belongs in a technical article rather than only in a procurement one. The relevant difference between the two main editions is virtualisation rights: Datacenter edition provides unlimited Windows Server virtual machine rights on the licensed host, while Standard covers a limited number.

That single difference determines whether separating roles onto separate virtual machines is cheap or expensive. On Datacenter, the role separation recommended above costs nothing in licensing. On Standard, each additional pair of Windows virtual machines has a cost, which is why estates licensed on Standard tend to pile roles together.

Both editions include Hyper-V as a server role at no additional hypervisor licensing cost, which is the fact that most changes the virtualisation decision.

The patching practice, stated plainly

Windows Server patching fails for one of two reasons, and they are opposites. Either updates are applied automatically with automatic restarts, and a server reboots during business hours. Or nobody wants that, so automatic updates are turned off and never replaced with anything, and the server sits unpatched for a year.

The second is far more common and far more damaging. What works is unremarkable.

• A fixed monthly window, published, with a named owner.
• A defined order: test or least critical first, domain controllers last and one at a time.
• An emergency path for advisories that cannot wait for the window, with an explicit threshold for using it.
• A record of what was patched and when, so that a compromise investigation can establish exposure rather than guess it.

Domain controllers last and one at a time is worth emphasising. Restarting all of them together produces an authentication outage that looks exactly like a serious incident, and it is entirely self-inflicted.

What to check this week

1. 1

   List every Windows Server and its version

   Including the ones nobody thinks about. Compare against the lifecycle table above and mark anything past or approaching its extended support date.

2. 2

   Check what your domain controllers are running besides AD and DNS

   Anything else on that list is a finding.

3. 3

   Confirm you have more than one domain controller, and that they can fail independently

   Two virtual machines on the same host is one failure away from none.

4. 4

   Establish when a system state restore was last tested

   If the answer is never, schedule it. This is the single highest-value item here.

5. 5

   Find the last patch date on every server

   The gap between the oldest and the newest tells you whether a patching process exists.

6. 6

   Confirm the AD Recycle Bin is enabled

   It is off by default and cannot help retroactively.