SQL Server 2012 was the first version of SQL Server to support being installed on Windows Server Core Edition (Windows without a GUI to the rest of the world). With the impending release of Windows Server 2012 there are a lot of people who are excited about running SQL Server 2012 on Windows Server 2012 in their data center. Let’s look at what you’ll need to do to become fluent and productive with Windows Server Core.
You are sitting in front of a terminal. There is a keyboard here.
Connecting to Windows Server Core is a lot like firing up a text adventure game from the early 1980s. You’re greeted with a blinking cursor and not much else. Ready to get started? I am, too. Our first step is to change the default shell from cmd.pain to powershell.exe. You can only do make this change through the registry. Just fire up regedit.exe and LOL your way to pain.
Or, you can start PowerShell (type powershell.exe and press enter) and then make the registry change there. I found instructions through some random blog, to save you clicking, though, here’s the code:
[ps]$RegPath = "Microsoft.PowerShell.CoreRegistry::HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionwinlogon"
Set-ItemProperty -Confirm -Path $RegPath -Name Shell -Value ‘PowerShell.exe -noExit -Command "$psversiontable'[/ps]
That looks awesome, right? Now that you’ve made the change you’ll need to restart the server to see if it took effect. Just click on the Start icon and… oh yeah. Well, thankfully we can just use PowerShell to get this info through Get-Help reboot. PowerShell may have to go out to the web and download and index a help collection. Your servers can get out to the web, right? While you’re finding a network administrator to give you permission to download PowerShell help files, I’m going to sit here and play Zork.
After the Reboot
At this point, you probably think I’m behaving like a jerk. You’re right. But I’m doing it to prove a point – as much as I am excited by the idea of Windows Server Core, I’m completely terrified of it and you should be, too.
How comfortable are you solving problems without RDPing into a server? If you really want to test yourself, bribe that network administrator with an ice cream sandwich and have them block your use of port 3389 for a week. We’ll see how you feel after that.
If you’re still excited about the prospect of a world without RDP, take stock of everything that you do on a daily basis. Evaluate how comfortable you are with automating every task via either T-SQL, PowerShell, custom .NET code, or a combination of all three. This isn’t all that difficult if you’re a DBA. If you’re an admin of a different sort, this might start to get fun.
After the Double Reboot
The biggest hurdle is troubleshooting – it’s going to be difficult for you to troubleshoot hot production problems without a GUI. Sometimes you really want to remote into that server, admit it. Here’s what I want you to do: every time you solve a production issue, write down every step you take. Make sure you include all the poking around and false starts at solving the problem. Yes, I even mean staring at Task Manager and yelling. Do this for the next month.
After you’ve resolved each issue I want you to script out every step you performed through T-SQL and PowerShell. Some of those remote tasks aren’t looking so pretty, are they? Maybe there is additional logging you can enable to make the diagnosis easier. Perhaps there’s monitoring you can put in place. But right about now I’d be willing to bet a sack of chalupas that you’re getting nervous about a move to nothing but Server Core.
While you’re busy being nervous, I want you to stand up and walk over to everyone else who needs to access a server. Ask them to do the exact same thing that you’re doing – every big problem gets every step written down and then scripted out after the fact. DBAs aren’t the only people who need to access a SQL Server, so make sure that all of the other administrators are on board and are comfortable with performing their regular tasks through a combination of PowerShell and custom .NET development.
After a Month of Scripting…
I’ll be blunt – I’m excited about Windows Server 2012 No More GUI Edition, but I’m also nervous as hell about the first time I run into this scenario on a production system. You should be, too.
Windows Server Core makes an incredible amount of sense for professionals who are administering hundreds of servers. The people doing this right now already have tools in place that make their job easier, or they’ve solved the problem by hiring an army of off-shore administrators. Windows Server Core makes a lot of sense at a point when you have sophisticated monitoring and you are in a place where you can treat your infrastructure as an array of sensor covered parts – you need to know that something is about to fail before it actually fails so you can take action long before you end up putting out a fire.
This isn’t for everyone. If you’re managing less than 10 servers, Windows Server Core isn’t for you. If you’re managing a volatile number of servers, elastic demand, or a virtualized army of siloed application servers I bet you’ve already figured out how to solve your administration woes. If not, take a look into Windows Server Core. If you’re managing a critical piece of infrastructure, think long and hard about what you’re doing and take my advice – script everything you’re doing for a month and then see how you feel.
19 Comments. Leave new
Honestly it sounds a lot like working in DOS. You remember DOS right? Microsoft made a big deal out of creating a GUI to sit on top of it. It was called Windows. Seems like we are just going full circle again.
Of course I say this, and I remember fondly working in DOS and helping to manage a Novell network without a big fancy GUI, but the idea of going back would make me a bit nervious after all these years.
Going back to no GUI makes me a bit nervous, too. I’m getting used to it now before I run into headless servers in production. For bigger organizations, I’m guessing it’s just a matter of time. Thankfully, VMs and AWS instances make it really easy to get training time in early.
Hmmm! Sounds a lot like using Linux, UNIX, DOS, VMS, RSX, and a whole heap of other names and acronyms that we’ve used before. There used to be GUI systems available that just used the various drawing characters in the upper reaches of the character space to present a WIMP interface, and I’m sure that some of them will be swiftly revived!
For example, you can still get Windows 3 on TechNet, and that’s just a program, not an OS, so it might well run on your headless server! GEM was another one, from Digital Research. Of course, you may well be in violation of your Windows 8 licence by fronting it with one of these non-Metro GUIs! 🙂
I am very excited about Server core running SQL Server. Sure, at the windows level you will have to know some PowerShell in order to get things done, But I would argue that you should be using PowerShell already anyway. Not just as an OS tool but as a tool for the DBA. I use it everyday as a DBA and I know others do as well, @sqlvariant is a name that comes to mind. PowerShell is a great scripting language and is just getting better and better with time. And now that Jeffery Snover is on the Windows Server team, I would expect that we will see more and more PowerShell with every server OS release, starting with Server 2012.
I agree that you should be cautious and do your due diligence and testing, you do not want to run before you can walk and bring down a high priority production server, but you must adapt to the technology. I am looking forward to this as I think Windows will have such a small footprint in memory, SQL Server should be much better off. And please do not forget, that you will still be able to connect to SQL with SSMS from another machine. You are not running SSMS on your production instances now are you?
Just my two cents.
NoGui isn’t for you if you are handling few servers, and if you’re handling a larger bunch. I think this is where Microsoft System Center 2012 comes in handy.
By all means, learn PowerShell, I am currently on my way there, but for troubleshooting, System Center is the future. Check it out if you havn’t
prosql.se website is in Swedish, sorry about that my englishspeaking friends.
Regards Marten
Marten – System Center is indeed a nice piece of software, but it’s not free, and implementing System Center is usually a company-wide decision. There have been similar infrastructure tools out for decades, and usually the DBA doesn’t get to pick which one the company uses. I’d just be careful about telling everyone to learn System Center – I’d only bother learning it if you’re at a company who already paid for it and implemented it, and if you plan on staying there for a long time.
I was fault finding a performance issue on multiple servers recently, which turned out to be due to a third party antivirus app failing to receive scan exclusion policies, which was caused by duplicate guids in the windows server image. I have no idea how that could be found with only PowerShell..
Our team has been using SUA (now discontinued) and, more recently, Cygwin to manage SQL instances for years. Windows 2003, 2008, 2008R2, and SQL Server installs from 2005 onward. I’m looking forward to Server Core and will be particularly interested in getting our vast array of scripts up and running there, too.
One of the greatest benefits for us has been the ability to ssh into a server to manage it when we’re on the road and only have a smartphone and a 1-bar, 2G network. It’s saved our bacon several times and is in my arsenal for good reason.
Viva la command-line revolucion! 🙂
Kudos to you and your team, Gavin! You solved this problem when the only solutions involved a lot of DIY, voodoo, and luck. One of the really cool things about PowerShell is that, just like bash, you have a lot of ability to alias commands/strings of commands. Plus PowerShell supplies a few *nix equivalents to make the conversion easier.
Best of luck to you in your future automating our robot overlords.
THis reckons back to the ADMIN side of Windows going back to Windows Server 2000. So this isn’t really new, it is just more refined.
Powershell is an amazing tool that is just getting better and more useful all the time. I am currently using it to manage Jobs and SQL Servers in our DR site on the other side of the country.
Going to the Core server does not bother me since normal tools will still work as needed. When there is trouble, Powershell will allow you to diagnose it remotely as well. RDP across the country, not as efficient as using Powershell over the WAN. So I will be looking at the Core Server for the DR site upgrades.
Reminds me of this quote by the Russian navigator in Hunt For Red October: “Give me a stopwatch and a map, and I’ll fly the Alps in a plane with no windows.”
I’m enjoying PowerShell as I delve deeper into it, but I’m not ready to lose the GUI safety net yet, nor are the benefits of going to Core really valuable at my shop. But I can see the benefit for working with large amounts of similar systems.
The reason system developers came up with GUI interfaces was so we wouldn’t have to remember all those commands and parameters, just find the Start menu. Commands assembled together in scripts are great for commonly repeated tasks, otherwise command line interfaces remind me of vinyl records.
A much better analogy would be GUI = being able to use an iPod, command line = being able to a actually play an instrument.
I disagree – i think anyone who has been a DBA for some time and had to deal with very hairy problems knows that a GUI is critical as you can monitor real time activity and respond quickly.
I challenge the “pollyanna” brigade who consider trying to manage a blind system in the midst of a critical system down problem where they have to script their way around a whole series of unforseen issues to then turn around and tell me how great it is to be able to have to navigate around a burning room while blindfolded…..
I recognise you get the MS cheer squad who consider ( blindly ) everything MS does is just…well…swell, but those of us how have to by very responsive to complex and difficult problem recognise that SQL is a dynamic and complex system, and sure as eggs is eggs, were going to have the time to dig out that PS script for exactly that precise occasion….I say dream on……this should be a wake up call for serious SQL admins – dont accept server Core blindly.
Try a complex system down simulation first, then decide….nothing beats a real world situation to find the holes. I predict you’ll be horified…..
Core is probably fine if all you ever do is basic tasks and nothing really goes wrong, but for heavy duty complex stuff, I’d hate to be without a gui.
I can count the number of times that I RDP’d into a production server, during an outage, on one hand. Most things I’ve done remotely, including during outages.
Oh, and with server core you can still have a GUI, you just connect remotely.
Thanks for stopping by!
Not sure why people love the idea of a blind server…..
From experience, when we’ve had network issues, its usually catastrophic….a physical visit to a server is often required. We had multiple network links being cut by a contractor once which required forced cluster restart without quorum etc etc and the loss of data-center links for 4 days
I think if people want to run Core, just put in UNIX. Its way more robust.
The idea behind use Windows Server Core is to reduce attack footprint.
And, if you’d read the whole article, you’d have found the spot where I point out that you should have everything scripted, just in case you run into quorum issues.
Of course, you should have already had that scripted in the first place because, even if you weren’t using Core.
But I bet you already knew that.
cmd.exe is not a pain 🙂 Quick and Dirty is never pain. Tons of lengthy commands and switches to remember cannot compare to that. It’s a DOS (originally QDOS for Quick & Dirty Operating System) legacy what Microsoft should not abandon.
Howdy. Now, 10 years later, with tool availability like Windows Admin Center, has your opinion of core changed?