Windows Server Roles Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A role is a job, and Server Core is still a server

A Windows Server can be a domain controller, a DNS server, a DHCP server, a file server, a web server, or a print server. Putting all of them on the first machine works until the patch or the disk takes every job down together. Split roles that have different lifetimes. Domain controllers are not also the only file server. DHCP and DNS can share a host in a small site and should not be a surprise when you rebuild that host.

Server Core has no full desktop. You administer it with PowerShell, remote tools, and the command reference. That is a feature: less to patch and a smaller place to click the wrong wizard. The command reference on this site is the reminder. It does not open a session. If your team cannot administer Core, the decision is training or a desktop install you accept, not a mix you discover at 2 a.m.

Upgrades have a path. An in-place upgrade is one path, and a new server with moved roles is another. The upgrade planner on this site lists the path between versions. A skipped version is not a detail. Read it before the window. Domain controllers have their own order: you do not raise or lower functional levels as a side effect of a file-server upgrade.

The Active Directory guide owns accounts. The Group Policy guide owns policy. IIS has its own pillar. This page decides which machine is allowed to be which role.

A lab with two roles on purpose

The lab has one domain controller that is only a domain controller and DNS, and one member server that is a file server. Write those sentences. Do not add DHCP, IIS, and print on the domain controller because the wizard was open. Confirm you can administer the file server from your workstation without logging on to the domain controller's console for ordinary work.

If you install Server Core for the member server, practise the commands you will need: service status, disk space, and who is logged on. If those commands are not in your notes, you are not ready for Core on a host you cannot stand next to.

Record the Windows version and edition. Run the upgrade planner against the version you intend to be on next year. If the planner says the path is a new build, believe it and plan a move, not an in-place hope.

A shared local administrator password on both boxes is the fundamentals mistake again. Separate accounts. The password is not in the ticket.

A change you can finish

A production role change is adding one role to the host the ticket named, or moving one role to a new host and leaving the old role running until the move is proven. Two role migrations in one window hide which one failed.

Rollback of a new role is to remove it before users depend on it. Rollback of a move is the old host, which you did not demote or shut off in the same window.

List the roles and which host owns each.
Keep the domain controller off the list of casual extra roles.
Choose Core or desktop and write the admin method.
Record the version and the planner's next step.
Add or move one role.
Prove the role from a client.
Leave the old host up until that proof is boring.

Mistakes that outlive the command

Windows Server roles fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Every role on the first server.
A domain controller that is also the only file server and the only web server.
Server Core with no notes on how you will manage it.
An in-place upgrade the planner said to skip.
Raising a domain functional level inside a file-server window.
Shutting off the old host in the same window as the move.
One shared local administrator password.
IIS configured from this page instead of from the IIS pillar.

Decisions to write down before the window

One decision for Windows Server roles: Each role has a host. Combined roles are a written exception. The domain controller's extra roles are DNS and what the AD guide already required, not a file share. Core or desktop is chosen, and the admin tool is in the ticket. The version and the upgrade path are filed. One role moves or is added in this window. The old host stays available until the client proof is done. Functional levels are untouched unless this ticket is about them. Accounts and policy stay in their guides. Local admin passwords are unique and not in the ticket. The command reference was used for Core, and the command you needed was actually there. And a second person read the role-to-host list.

Windows role checks before you remove the old server

Confirm this before you call the change done: The role list matches the hosts. The domain controller is not the file server. A client used the new role successfully. The old host is still up if this was a move. Version and upgrade path are recorded. Core hosts have a working remote admin path. No functional level changed as a side effect. Passwords are not in the ticket. IIS, if present, is delegated to the IIS guide. A second person saw the client proof. Rollback is the old host or the removed role, and it is still possible. DHCP or DNS changes were their own lines if they happened. The planner output is filed with the version. The hostname in the prompt matches the hostname in the ticket for Windows Server roles. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for Windows Server roles happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.