Stop installing the desktop experience on your domain controllers

Every time I review an Active Directory environment, I find domain controllers installed with the Desktop Experience, which means a full Windows desktop on the most sensitive server of the company.

I understand why it happens: the GUI is familiar and the setup wizard offers it. On a domain controller, though, the desktop is not a comfort feature, it is an invitation to use the server for everything else.

The slope

It always starts the same way. The DC has a desktop, so it has a browser, and sooner or later someone opens Edge on it to download a tool or read a KB article. You block Edge. A few weeks later Notepad++ shows up because editing a file in Notepad is painful, then someone needs to open a Word document sent by a colleague, and two months later the DC has quietly become the company's Remote Desktop server.

I am barely exaggerating: when a server looks like a workstation, people end up using it like one. A domain controller should never, and I mean never, be a point-and-click playground where you log on and click around until something works.

The less an admin can do on a domain controller, the better for everyone, the admin included. I admit it sounds like a unilateral decision, and it is one, but reducing the attack surface of a DC is one of the top priorities in Active Directory security.

What Microsoft says

This is not only my opinion, and Microsoft's own documentation is quite clear on the subject.

The Server Core vs Server with Desktop Experience page recommends it directly: "We recommend that you choose the Server Core install option unless you have a particular need for the extra user interface elements and graphical management tools". Its comparison table describes the potential attack surface as "Greatly reduced" for Server Core and "No reduction" for Desktop Experience.

The What is Server Core page explains that Server Core "has a smaller disk footprint, and therefore a smaller attack surface due to a smaller code base", and that there is "no desktop in Server Core, by design", which also means no browser on the server.

For domain controllers specifically, Securing domain controllers against attack could not be more direct: "No web browser should be used on domain controllers." The same page mentions an analysis of thousands of domain controllers where privileged users were found browsing the intranet or the internet from them.

Avenues to Compromise goes further and states that domain controllers "shouldn't run any software that isn't required for the domain controller to function or doesn't protect the domain controller against attacks", with examples of admins who downloaded freeware utilities from the internet and installed them on DCs.

Server Core does not make any of this impossible, but it makes it much harder, and that is exactly the point.

One choice, made at install time

One practical detail to keep in mind before you start: unlike some older releases, current versions of Windows Server can't switch between Server Core and Desktop Experience after installation, and Microsoft's documentation says you need a clean installation if you change your mind.

For a domain controller this is not really a problem. A DC should be easy to replace anyway: you promote a new one, move the roles if needed and demote the old one. "Reinstalling is painful" is not a good reason to keep a GUI.

What you actually need on a DC

Very little, locally.

SConfig covers the base configuration (network, computer name, domain membership, updates, Remote Desktop and activation). Since Windows Server 2022 it launches automatically when you sign in, PowerShell is the default shell, and option 15 drops you to a PowerShell prompt for everything else.

Day-to-day administration does not happen on the DC anyway. You run the consoles from your admin workstation:

• RSAT for Active Directory Users and Computers, DNS, Group Policy Management and the rest
• Windows Admin Center, if you use it
• PowerShell remoting for everything that can be scripted

Microsoft says so in the same comparison table: Server Core "can be managed remotely using GUI tools, such as Windows Admin Center, Remote Server Administration Tools (RSAT), or Server Manager, or by PowerShell."

That workstation must be trusted at the same level as the DC. The tier model for Active Directory Domain Services says a Tier 0 session must start from a Tier 0 privileged access workstation, never from the device you use for your daily work. That is where the GUI belongs, not on the DC.

The rare case: the App Compatibility Feature on Demand

Sometimes you really do need a graphical tool on the server itself, usually for troubleshooting. For that case Microsoft provides the Application Compatibility Feature on Demand, which adds a subset of the Desktop Experience binaries to Server Core without bringing the desktop back.

It is available from Windows Server 2019 and adds the following components:

| Component | File | Since | | --- | --- | --- | | Device Manager | devmgmt.msc | Windows Server 2019 | | Disk Management | diskmgmt.msc | Windows Server 2019 | | Event Viewer | eventvwr.msc | Windows Server 2019 | | Failover Cluster Manager | cluadmin.msc | Windows Server 2019 | | File Explorer | explorer.exe | Windows Server 2019 | | Hyper-V Manager | virtmgmt.msc | Windows Server 2022 | | Microsoft Management Console | mmc.exe | Windows Server 2019 | | Performance Monitor | perfmon.exe | Windows Server 2019 | | Resource Monitor | resmon.exe | Windows Server 2019 | | Task Scheduler | taskschd.msc | Windows Server 2022 | | Windows PowerShell ISE | powershell_ise.exe | Windows Server 2019 |

There is no browser, no Office and no desktop in that list. Internet Explorer 11 can be added separately on Windows Server 2022 and earlier, but there is no reason to do it on a DC.

To install it from Windows Update, exit SConfig with option 15 and run:

Add-WindowsCapability -Online -Name "ServerCore.AppCompatibility~~~~0.0.1.0"

Then restart the server. Two things are worth knowing: it can only be installed on Server Core, never on a Desktop Experience installation, and an in-place upgrade to a newer Windows Server version removes it, so you have to install it again unless it is part of your custom installation image.

How Linux admins do it

On Linux, this debate simply does not exist. Servers are installed without a desktop environment and managed over SSH, with configuration management for anything that repeats, and nobody expects a graphical desktop on a production server.

It is the same for Active Directory: a Samba AD domain controller is set up and administered with samba-tool on the command line, while the Windows consoles run remotely from a Windows admin workstation. That is exactly the model Server Core pushes you towards.

A word on skills

I will be blunt here, on purpose: if the command line scares you, you probably don't have the skills to run a domain controller yet.

This is not meant as an insult but as a matter of responsibility. Active Directory is the cornerstone of the information system, and if a DC is compromised, the whole forest is. It should not be left to beginners or juniors working alone: they need to be trained, or supervised by someone experienced.

Conclusion

A GUI on a domain controller brings nothing you can't do better from an admin workstation, and it opens the door to everything you don't want on a DC.

Install your domain controllers with Server Core, configure them with SConfig and manage them remotely with RSAT, Windows Admin Center and PowerShell from a Tier 0 workstation. Keep the App Compatibility Feature on Demand for the rare troubleshooting session.

For me, a GUI on a DC is not even up for debate anymore.