Managing an Instance of SQL Server on a Windows Server Core Installation
Today two readers respond reminding us that most features of SQL Server can be managed from a remote server. As a result, even instances of SQL Server hosted on a Windows Server 2008 Core installation may be managed using GUI tools on hosted on remote machines.
James P Writes:
“So, DBAs wanting the most power available for their database engine need to bone up on their PowerShell and command line skills once again to take advantage of SQL 2012 features, and manage SQL Server in a world without the GUI.”
Have you seen the differences in how MS SQL Server 2012 is configured and managed as compared to other SQL server versions? Your statement, along with knowledge of how this actually works, makes it obvious you have not…
Maybe I am reading your daily emails with the wrong mindset. Should I start reading your daily as a joke?
A joke where you are being facetious, trying to sound like someone talking about things they know nothing about.
This would make them somewhat enjoyable.
Editor:
James. You make a good point that SQL Server is not a service only accessible or managed directly from the host machine. Since SQL Server Management Studio (SSMS), and other SQL Server tools, can connect to an instance of SQL Server hosted on a completely different system, those tools may be used over the network to manage an instance of SQL Server hosted in a GUI free instance of Windows 2008 Core. That is a point I did not clarify in the previous editorial.
If you were to work on the SQL Server from the host operating system console, you will not have access to SSMS. There are few scenarios requiring this kind of access. Were you in a situation where that was the case, then GUI tools are not available.
Personally, I don’t want to be restricted to only knowing how to work through the GUI. I use it ALL THE TIME because it is convenient or quicker. I also take the time to learn how to do things in a character based methodology…especially when that is the faster method.
James B Writes:
Very interesting, especially with more and more SQL Server being put in a virtual machine. Brings lots of questions too.
Once it is installed and running, I don’t need the GUI on the server since I would connect from my workstation and could still use Management Studio to do all the routine maintenance work.
However, I would need to be ready with scripts for those emergencies when I would then need to work at the server. I would need to have a test environment to match so I can test and practice my disaster recovery process.
I would like to see an article or two on setting this all up and some best practices with configuration.
Editor:
As I was doing my homework on this topic yesterday I did find a number of links to blogs and Technet articles regarding best practices in configuring and managing CORE installations. I think that is always a good place to start.
I would highly recommend folks look into the strategy behind Windows Server Core as well. As I have understood it, the key benefit is not to get rid of the GUI, etc. It is to pare down the features installed to only those components essential to the role of a particular instance of Windows Server.
If the only task your server is performing is hosting Internet Information Services, then loading up components for DHCP, Telnet, Printing Services, etc may all be a waste of resources. Windows Core allows you to specify the roles a server will support, and determines what components are necessary for those roles.
By reducing the number of components installed you not only optimize the installation for your specific role, but, you also reduce the risk of attack on your server by having less entry points.
Share your perspective by sending an Email to btaylor@sswug.org. Or, like James has said, simply have a laugh.
Cheers,
Ben
$$SWYNK$$
Featured White Paper(s)
Top 10 Tips for Optimizing SQL Server Performance
read more)