Ten years ago any Windows Server that you deployed in your environment had a graphical user interface (GUI) that included the standard Windows desktop plus a collection of easy to use administrative tools you employ to configure, manage and troubleshoot your server. Support for scripting common administrative tasks was still sketchy at best and involved either creating batch files to run Windows commands, using Visual Basic Scripting Edition (VBScript), or employing a third-party scripting solution like KiXtart (which believe it or not now supports Windows 10!)
Then along came two major changes to the Windows Server platform. First, Microsoft created Windows PowerShell, a task-based command-line shell along with a powerful new scripting language that is designed especially for system administration. Microsoft initially made PowerShell available as a downloadable application for Windows Server 2003 but then with Windows Server 2008 they included it as an in-box feature that you only needed to enable on the server. And second, Microsoft introduced brand a new installation option in Windows Server 2008 called Windows Server Core that provided a way for businesses to run Windows servers without a GUI, that is, without the traditional Windows desktop and its associated desktop programs. The objective with Server Core was that administrators would configure and manage their servers from the command-line, either by issuing a series of Windows commands or by running scripts.
Nirvana for datacenters
Server Core was an exciting new capability on Windows servers because it provided a number of potential benefits for IT departments including:
- Increased stability — fewer installed features means fewer moving parts which suggests that less can go wrong.
- Lower maintenance — fewer installed features means less bugs which should translate to fewer software updates that need to be applied to keep your server protected and up to date.
- Less attack surface – fewer parts should mean there’s less for attackers to sink their teeth into when they attempt to hack into your infrastructure.
- Smaller hardware requirements – Server Core systems can run efficiently on hardware that has less memory and disk space than would be needed for Server with a GUI installations.
The problem with the initial release of Server Core in Windows Server 2008 and 2008 R2 was that you had to decide at deployment time whether to go with the Full (later known as Server With A GUI) or the Server Core installation option, that is, there was no way of switching between them after installing your server system. Microsoft addressed that issue however in Windows Server 2012 in several ways. For while you can still select between either the Server With A GUI or the Server Core installation option when you deploy your server, you now also have the capability to use either Windows PowerShell or the Server Manager console to convert your server between the different installation options after you’ve deployed the server. Additionally, Windows Server 2012 also introduced a third option called Minimal Server Interface that includes various infrastructure components to support GUI management tools such as MMC consoles but does not include Windows Explorer, Internet Explorer, or the Start screen.
Finally, beginning with Windows Server 2012 you can now completely remove the installation binaries for selected features from the side-by-side store (WinSxS folder) from either a running Windows installation or an offline VHD on which Windows Server has been installed. You might consider doing this for reasons such as to further reduce the disk footprint of your Windows Server installation or to enhance its security by completely removing binaries for any features that will not be needed on your server. For more information on these installation options and some demonstration of their capabilities see Chapter 2 “Deploying Servers” in my book Training Guide Installing and Configuring Windows Server 2012 R2 (MCSA) which is available from the Microsoft Press Store.
The goal of all this on Microsoft’s part was basically to better align their Windows Server platform with the needs of the datacenter. In our rapidly emerging cloud-connected world, more and more IT processes and infrastructure are being hosted and run inside datacenters that are exposed as public, private or hybrid cloud computing environments. To be able to manage hundreds or thousands of Windows servers in a large datacenter can only be done efficiently by using automation, and that means scripting. And if you script the management of headless servers running on blades in racks, you don’t need a GUI on those servers, right?
The SMB side of the playground
Well, that’s true in the datacenter. But what about Windows servers in small- and mid-sized business (SMB) environments? Should administrators of these environments follow Microsoft’s advice and deploy Windows server using the default Server Core installation option so they can benefit from the increased stability, lower maintenance requirements, smaller attack surface, and reduced hardware requirements of Server Core? After all, if they change their mind later and decide for some reason that they need local GUI admin tools on a server they have the option starting with Windows Server 2012 to change from Server Core to Minimal Server Interface to Server With A GUI. So what’s the problem with deploying Server Core when you’re an SMB?
Well, there can be lots of difficulties if you go that direction. The biggest problem is that small businesses that have only one or two servers usually manage them locally unless they’ve outsourced their IT needs to a company that can manage their servers remotely. But what if the Internet connection goes down or the router dies or there’s a firewall problem? In that case someone has to come and log on at the server console to troubleshoot things, and that’s where having the Windows desktop and GUI admin tools preinstalled can come in very handy. For example, instead of the management company’s support person driving in to fix things, he or she might just phone the boss of the small business and ask him to go to the server and log on and open this and click that, and while most non-IT types can usually click their way around a GUI, they can get freaked out facing only a command line and being asked to type two or three lines of difficult-to-spell commands exactly as they’re instructed.
So what, you say? If it’s a Server Core machine and you suddenly need a GUI for troubleshooting reasons, doesn’t Windows Server 2012 or later allow you to add the GUI features if they’re needed? Yes but this is actually easier said than done for two reasons. First, while it only takes a couple of clicks to instruct Windows Server to add its GUI features, it can then take several minutes at least (and possibly longer) for the server to reboot, come back online, get settled, and start fully operating again. What’s several minutes, you might ask? Well, remember that in smaller environments like SMBs it’s common for Windows servers to function in multiple roles with each server hosting a variety of different business applications. So for example, rebooting that server to install the GUI might kill an invoicing application currently in use by an employee which might result in a lost sale, an annoyed customer, or some other consequence you’d like to avoid at all costs if you’re the business owner.
But even if rebooting the server to install the GUI would have no impact on your business operations, you should remember that any new features you add to a server might need to be patched to bring them fully up to date. In other words, when you add the GUI features you’re adding them in their in-box form, and if Microsoft has released any patches for that feature since product release, those patches will have to be applied later to make your server fully secure again. This means that there’s a window (between adding the GUI and updating it) in which your server is less secure than it was before you added the GUI feature. Unless of course you take your server offline, add the GUI, apply an updates needed, and then bring your server back into operation again. While that approach would ensure your server is always fully patched when in use, it means your server will be unavailable for more than the several minutes needed simply to reboot it, and for operations to continue in a smaller business this option will probably be unacceptable.
In conclusion then, if you’re deploying new Windows Server systems in any environment smaller than a datacenter, it’s probably a good idea if you select the Server With A GUI option at installation time instead of going with the default option of Server Core as you might just need that GUI in a pinch sometime and you don’t want to fiddle around with trying to add it in an emergency.