Windows CORE Domain Controllers

Hey guys,
 We are considering to provision all our Domain Controllers as CORE edition servers 2016.   Wondering on others experience from manageability standpoint.  
How do you guys manage it.  Say you need ADUC, DNS, DHCP, AD Sites-services, etc, etc.  
I'm thinking to have at least one Regular Domain Controller with GUI interface.  Others are OK to have CORE.  Thoughts?

Thanks in advance.
LVL 17
Tiras25Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jeremy WeisingerSenior Network Consultant / EngineerCommented:
Why not make them all core and then manage them from a Windows 10 workstation with RSAT installed on it?
https://www.microsoft.com/en-us/download/details.aspx?id=45520
MaheshArchitectCommented:
if your server is installed as core, you cannot convert it with GUI mode and vice versa - specially true for 2016 server
in 2012 R2 you can switch between GUI and core if wanted to
https://www.technig.com/convert-server-2016-core-gui/

Though you install AD on core server, still you need to rely on AD management consoles on other servers having GUI because its very difficult to manage all AD aspects from core server from command line or from powershell
AD management tools will connect to your core servers for management
you can put 1st DC of forest (root dc with all FSMO roles) on GUI version and rest can be put on core
Cliff GaliherCommented:
All of my DCs are core.  I don't even worry about keeping one with a GUI. If a machine goes so sideways that it can't be remotely managed then it's probably too far gone for a "local" GUI to save it.  Easier just to retire and rebuild.  Core is very manageable remotely for day to day tasks. Local GUI offers no benefit (and is an extra step when you consider needing to RDP into it.)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
CEOs need to know what they should worry about

Nearly every week during the past few years has featured a headline about the latest data breach, malware attack, ransomware demand, or unrecoverable corporate data loss. Those stories are frequently followed by news that the CEOs at those companies were forced to resign.

Cliff GaliherCommented:
2016 and 2019 *cannot* be switched from core to GUI. That option was removed. 2012 R2 was the last version to allow that option.
MaheshArchitectCommented:
It would have make much more sense to deploy core DCs if Microsoft could provide single console to manage entire stuff of server management and active directory or other server roles just like network firewalls or security devices running on Linux / Unix based
If one is master on command line and powershell, he might be remain interested in core version rather than GUI
Here you need to rely on at least 10 different snap ins to manage server effectively and that also you will be connecting through other GUI based servers
Also basic networking must be configured from command line only
Removing GUI only saves server resource consumption and windows patches i believe but it actually not removing server management dependency on GUI, that is also installed on some else machine
Also in case server trouble shooting is required, it would be difficult witgout gui specially for administrators who are versed with gui (WINDOWS) version
Cliff GaliherCommented:
I'm not sure what argument is being made here.

Yes Microsoft still relies heavily on MMC snap-ins to manage a server (though 10 is an exaggeration.)  

HOWEVER!  That is true whether you run the snap-ins "local" (via RDP or at the console) or remotely.  So installing core doesn't change this either way.  Which means installing the GUI locally doesn't offer any management advantage.  You still have to RDP in (a new extra step) and *then* open the snap-in.  Remote management is just the snap-in.

This argument also holds true for local management via powershell (RDP in then manage) or remote (PS Remoting) ….one less step, RDP.

Regarding networking:  You have to set it up locally when you first install the machine whether you use the GUI or the command line (sconfig makes this *trivial!*) or you automate it.  MDT, SCVMM, DSC, etc can all automate your network config so you never have to log on locally, which is beneficial in true 100% remote deployments.  But if you aren't using a tool to automate the rest of the OS install then you'd be sitting at the console to configure networking locally anyways...and GUI offers no benefit here.  

So...again....this seems to be a new tangent apart from what the OP asked.  A local GUI offers little to no administrative advantage over core, and the benefits of core often outweigh the rare times that there is any (Arguable) advantage.  Faster patching.  Fewer reboots.  Smaller security target.  Core does have measurable benefits, and there hasn't been a good case presented where the GUI is a benefit for the roles (AD, DHCP) being discussed.
kevinhsiehCommented:
I run my DCs as core whenever possible. Unfortunately, NPS has historically required GUI, so my DCs with NPS are GUI. No issues managing via remote tools. Been using Core for DCs since 2008 R2.
MaheshArchitectCommented:
I suggest before installing all servers on core version, better you create one core DC and check how easy its manageable against GUI DC in terms of day to day server management and troubleshooting
Because with 2016 servers there is no toggle switch to switch between GUI and core and only fresh install is the option
Jeremy WeisingerSenior Network Consultant / EngineerCommented:
I want to emphasize that you shouldn't be doing day to day tasks on the DC itself. You should use a management server or workstation with the RSAT installed.

For AD troubleshooting, you're generally going to be at the command line anyways so a GUI would not be needed.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
IT Administration

From novice to tech pro — start learning today.