Hey everyone, I’m one of the newer ServerFault sysadmins and I’ve got the fun job of explaining why we have been moving to Windows Server 2012 just almost as fast as WDS can deploy images.
What’s Wrong With Windows Server 2008 R2?
Where do I begin?
2008 R2 was a great operating system in its day. Automation was becoming a core part of the platform. PowerShell was shipped in the box, enabled by default, and supported several roles and features. Many of the kinks were worked out after the Vista/2008 release cycle and people were starting to acclimate to the User Account Control (or figured out how to turn it off).
Server 2008 R2 held up well for a long time, but was starting to show it’s age with our SQL Server cluster. There are a bunch of hotfixes required to make clustering have a chance of working with SQL Server 2012 AlwaysOn in our environment. Brent Ozar, in part based on experiences helping us, now recommends not building AlwaysOn Availability Groups on Server 2008 R2.
Additionally, the management story for Windows Server up to this point has been very focused on single machines. Server Manager in 2008 R2 targets one machine at a time. Most of the MMCs deal with one machine at a time. PowerShell remoting was not on be default. It is definitely work to build a multiple machine management story.
So, how does Server 2012 help?
First of all, Windows Server 2012 helps address our major pain point of how SQL Server 2012 Availability Groups interact with Windows Clustering. Clustering received a lot of attention in Windows Server 2012. The addition of dynamic quorum helps maintain the cluster state in the case of site-to-site VPN interruptions. Clustering itself has just become more resilient and offers a wider feature set.
The second (and I think most important feature) that Windows Server 2012 offers is SMB3. SMB3 fixes many of the performance considerations with access to files stored centrally on a file share. SMB Multichannel allows SMB clients and servers to leverage multiple network connections, makes SMB transfers resilient to TCP disconnects (by having multiple streams per transfer, even with one NIC), and provides the foundation for scale out file servers, providing a way for multiple servers to share the same connection concurrently, isolating storage transactions for single server failures and allowing connections to scale across multiple servers. SMB3 provides a number of opportunities to radically change the structure of your application data access and I talked with Richard Campbell about this at length on RunAs Radio.
The third huge win is how Windows Server 2012 supports three levels of GUI-ness. You have the traditional full UI to support the traditional administrative experience, and since this is the same codebase as Windows 8, you get the Metro/Modern UI start screen as a “bonus”. The next level of GUI-ness offered by Server 2012 is the minimal shell experience, or what I like to call “Server Core with Training Wheels”. The minimal shell removes Explorer, Internet Explorer and most GUI apps, but leaves behind Server Manager and the MMCs. This provides a bit of a security blanket for those admins who aren’t quite ready to give up managing a server locally, but want to break their reliance on the UI and grow up to be SYSTEMS administrators who can manage multiple systems. By removing explorer.exe and iexplore.exe, you’ve eliminated a huge source of patches, particularly the ones that require a reboot. Additionally, since there is no Explorer, the RDP experience is a command prompt and Server Manager – discouraging random RDP sessions. The final level of GUI-ness is full on Server Core. This is the DEFAULT install option for Windows Server 2012. Server Core lacks even the minimal GUI tooling provided by the minimal shell configuration. Server Core, as of Server 2012, is no longer a life choice. In Server 2008 and Server 2008 R2, when you selected Server Core as the install option, you were stuck in Server Core. With Server 2012, the GUI bits are features and can be added and removed through the standard feature management tooling. I talked a bit about this with Richard Campbell on RunAs Radio earlier this year.
Next up in the “pro” column for Windows Server 2012 is PowerShell V3 and the increased cmdlet coverage in the operating system. PowerShell v3 brings a number of great enhancements to the party like improved performance, resilient remoting sessions, commands for working with the web and REST endpoints, workflow, ISE enhancements and more. Windows Server 2012 also brought about 2400 commands across the in-box roles and features (up from under 500 in 2008 R2). This explosion in coverage was due to improvements in the WMI APIs and a new API in PowerShell for being able to take an XML mapping file and generate PowerShell commands from a WMI API. This got us tons of additional coverage, including the network stack. Since servers really aren’t intended to be managed individually (despite what some sysadmins, product teams, and third parties software vendors believe), the increased PowerShell coverage makes that a much more reasonable task. If you are interested in further talk about PowerShell V3, you guessed it, there was a RunAs Radio talking about that as well.
The final consideration we had for choosing Server 2012 was in-box NIC teaming. Server 2012 offers OS level NIC teaming with a variety of teaming options. Given the problems we’ve faced with third-party NIC teaming (http://blog.serverfault.com/2011/03/04/broadcom-die-mutha/ and some other fun stories), I was gung-ho to get switched over to the native teaming features (which I’ve monitored in production environments for over a year at that point). Having the network load-balancing and failover (LBFO) teaming included in the OS is a major plus. Don’t worry, I won’t point you to yet another RunAs Radio show this time.
Where are we now?
I’m currently working with our team to continue the roll-out of Server 2012. Part of that process is updating our installation and configuration management plan. Nick Craver, one of our developers who likes to help with the sysadmin work and has been featured on this blog, and I have spent a good amount of time tweaking our deployment scripts (server and application deployment) to facilitate the roll out of new servers. We’ve got our SQL Server and web tier installs fully scripted, to the point where we can go from bare metal to a fully functional web server in about 3 hours (mainly OS install time and running Windows Updates).
We are still working out the rest of our deployment story, looking for integration points with our Puppet configuration management, making the configuration idempotent, and creating artifacts that can be stored in source control to version our environment. But each week sees more Server 2012 (and PowerShell use… Pete’s started using a bunch of stuff I wrote and now I have bugs to fix… grrr.. ) in our environment.
Where do we want to be?
I would like to see our Windows deployments that are in a production capacity (internally or externally facing) under full configuration management control, with changes pushed via a configuration management infrastructure and configurations enforced regularly.
I would like to have most of our servers running Server Core (doesn’t make much sense to do that for our management stations, but for most servers it works).
Most of all, I would like our server deployment to help serve as a template for a different way of Windows administration, one with rigid standards but quick to respond to changing needs. I’d like to see our infrastructure as agile as our code base, where changing our OS configuration is as easy as pushing a build is for our development teams. I’d like to be able to validate infrastructure changes quickly, closing the feedback loop and allowing worry free infrastructure changes.
You all have a front row seat to our environmental changes and I plan to blog extensively about my configuration management efforts in the near future, giving you an opportunity to learn from my mistakes.