We’ve all had a good, long time to settle into the daily routine the goes with being a Windows Server administrator or engineer. We’ve had time to learn all of the nuances behind the graphical user interface. We know where to go to get our management consoles, what commands to run to make the tweaks we need and get the things we need to get done completed. And I, like many of my counterparts, looked at Server Core when it was first introduced with Server 2008 with apprehension. Why would I leave the confines of my comfortable UI for something so stripped down? What was this BS that Microsoft was feeding us? I’m not a UNIX guy!
Sure, you have a smaller foot print for your OS when it comes to storage; and yeah, it uses less compute and memory too. Sure, it requires less patching, and fewer reboots. But what about my tools!? What about my Start button!?
Truth be told, ever since I started working in PowerShell, I’ve found that I’ve used the administration consoles less and less. Oftentimes, working in the console requires a one-at-a-time mentality, whereas with PowerShell I can manage multiple machines at once. Even remoting to a server’s desktop was far too time consuming, especially if I could just get the information or execute the command I wanted through PowerShell Remoting. As a ConfigMan engineer, I’ve even challenged myself to move outside of the box and create my own modules to service SCCM Clients through PowerShell so I don’t even have to open my console to do any troubleshooting, and can share these tools with my colleagues so they too can troubleshoot without directly interacting with a console or the client.
So when it came to be time to start taking a good hard look at my environment, and the footprint it was leaving in virtualization resources, it was time to take a look at myself as an admin and engineer. To get a little philosophical – we, as architects and stewards of technology, can view the design of our environment as a mirror reflection of our own selves. Our knowledge and experience makes up just as much of the environment as the best practices and company directives that guide our hand in creating the infrastructure that will support our users for the next life cycle. Once I realized that the graphical interface served no purpose other than being that comfortable space that I’ve known for the last 18 years, it no longer made sense to incur additional costs in resources and a larger attack surface in my environment.
Of course, we have our ways of easing into the water. I’ve been testing the applications I’m responsible for in a core instance for a few months now. Some applications made the cut and were able to be used effectively in Core, and some just weren’t. When I was finally ready to take the leap with those that would, I was able to use a simple PowerShell script that removed the GUI and rebooted the server.
Piece of cake.
It’s since been a couple of weeks since that implementation, and so far so good. If anything, the most notable change that I’ve encountered is with myself. I wrote a lot of scripts when I began learning PowerShell, and now that I’m working with core, I’m writing new scripts more frequently and refining old ones as my knowledge grows. My environment is using fewer resources, and I’m becoming a smarter PowerShell Administrator. I’d say that’s a win-win scenario.