One of the reservations I see expressed when I talk to some server admins about Server Core is that it’s hard to manage.
When I ask why, they suggest that having to open a remote desktop session to use the command line to perform administrative tasks was a lot more work than opening a remote desktop session to use GUI tools.
This reminds me of the scene in Dr Who where River Song lands the TARDIS, but it doesn’t make any noise. When asked why it doesn’t make the usual TARDIS sounds, she says that it only makes that noise because the Doctor keeps forgetting to turn off the parking brake. In 900 plus years of driving the TARDIS through time and space, the Doctor has apparently been doing something fairly basic wrong.
While it is true that one of the great things about being a server administrator is that you can find a way to accomplish a task that is comfortable for you, sometimes the way that some people do things involves a lot more work than it really needs to.
This came into focus in the last day or so with the announcement around Nano Server. While we don’t have all the details of Nano Server and won’t really know more until BUILD and Ignite at which hopefully we’ll get a new technical preview that will allow us to go and take it out for a spin, we do know the following:
“There is no local logon or Remote Desktop support. All management is performed remotely via WMI and PowerShell. We are also adding Windows Server Roles and Features using Features on Demand and DISM. We are improving remote manageability via PowerShell with Desired State Configuration as well as remote file transfer, remote script authoring and remote debugging. We are working on a set of new Web-based management tools to replace local inbox (sic – perhaps “in box” - Orin?) management tools.” -
The thing that admins who use Remote Desktop to connect to Server Core never seemed to have fully picked up is that the best way to manage Server Core is remotely (RDP is pseudo-local if you think about it - it takes you *to* the server). One management workstation managing many servers – not through many Remote Desktop sessions, but by using scripts, commands, and consoles, like the Server Manager console, that connect to multiple servers. You don’t need to run Server Manager on 100 servers. You can run it on one computer and use one console to manage 100 servers.
The only time people really needed local access to Server Core was during initial setup. With all the new technologies that are available these days, you won’t don’t need to (and in the case of Nano Server I’ve the impression won’t be able to) be signed on directly to perform that installation/post installation setup.
While all of this sounds complicated and a bit difficult, the reality is that the process is likely to be terribly straightforward. The aim is to get people to use Nano Server when it is appropriate to do so – and if it’s necessary to go through the sort of mental contortions that would give MC Escher a headache to deploy that version of Windows Server, no one is going to be willing to do so.
I’m really looking forward to finding out more about Nano Server. I’m wondering if you’ll be able to take a traditional installation and strip it right down to Nano Server in the way that you can take the GUI version of Windows Server 2012 R2 and strip it down to Server Core (or conversely build it up by adding the relevant bits if they become necessary). In time (that time being BUILD and Ignite) all (or at least most) of the mysteries will be revealed. It’s going to be a long few weeks waiting to find out the answers!
--
Orin Thomas is an MVP, an MCT, a Microsoft Regional Director, and has a string of Microsoft MCSE and MCITP certifications. He has written more than 30 books for Microsoft Press on IT Pro topics including Windows Server, Windows Client, SQL Server, Exchange, and System Center. He is an author at PluralSight and is a contributing editor for Windows IT Pro. You can follow him on twitter @orinthomas
