Are you afraid of deploying (or supporting) an instance of Windows Server Core?

Are you telling others to “stay away” because of your own fears of doing something new?

Then I am here to tell you that you’re doing it wrong.

Last month I decided that it was time to get down and dirty with Windows Server Core, SQL 2012, and AlwaysOn Availability groups. [Side note about AlwaysOn: it is ‘off’ by default…I’m just sayin’ is all.] I’ve seen other bloggers raise their objections to their readers regarding the deployment of Server Core so I wanted to see how difficult it would be to administer an instance of SQL Server running on Server Core.

As a Microsoft SQL Server MVP I am afforded the opportunity to take part in promotional programs from other companies that like to offer complimentary licenses to MVPs. One of those companies is VMWare. As part of the VM Guru program I have been allowed to use VMWare Workstation in order to create guests locally here on my laptop for just over a year now.

The plan now was to create three guests inside of VMWare Workstation. One would be my domain controller, and the other two would be my SQL 2012 instances on Server Core. I won’t go into the dirty details of getting the guests built in VMWare Workstation except to say that it was incredibly easy using VMWare Workstation to point and click at the .iso files and have everything installed. Configuration of the servers was a bit more involved but not too difficult and I had all three servers up and running in a short amount of time.

Joining the Server Core instances to the domain required me to use the command line. Luckily I know Joey D’Antoni (blog | @jdanton), one of the experts in the field of virtualization and server administration today. He shared with me a template for how he scripts out his Server Core installs and installation of SQL Server which saved me a bit of Googling to find similar scripts.

After I got everything built, named my domain (DALEK.local), and the instances (DOCTOR and ROSE) installed, etc. I wanted to then take a quick tour of how I would administer these Server Core instances. Since I was hearing about how difficult it would be for someone without any proper training I was curious to know what was the learning curve for this new platform.

First up for me was figuring out how to administer the instances of SQL Server. How would I ever administer that instance without the SQL Server tools being installed?

I simply used SSMS and connected to the instance. It’s the same experience. Nothing is different. SSMS doesn’t care if the engine is running on Server Core or not. Check out what it looks like:


Everything you know in SSMS carries over to Server Core instances. No need to panic. If you are used to using SSMS to administer SQL Server then you can continue to use SSMS for SQL Server running on Server Core.

What about other administration tasks, such as computer management? Turns out you can do that remotely with a right-click:


After I connect to the DOCTOR I see that the SQL Server Configuration Manager is available from within the Computer Management window:


That covers roughly 98% of any administrative tasks I would ever need to do against my Server Core instance, both inside and outside of SQL Server. The remaining 2% can be done through Powershell. However, with the reduced surface area of Server Core (i.e., less software running as part of the O/S) you aren’t likely to need to do as much administration against those servers anyway.

I can’t imagine why anyone would be afraid to use Server Core, or to support Server Core starting right now. I’d recommend you keep a few servers available with a full O/S, just in case you need to connect remotely to the instance of Server Core for something in that 2% of tasks. If you are concerned about working with Server Core then do what I do: create some VMs and have a try yourself. When it comes to the installation, configuration, and support for Server Core I find it all to be quite easy.

Your mileage may vary, of course.