When I first read through the “assignment” a cold sensation ran down my spine. Of course! – all the cool guys (m/f) have checklists and maybe even scripts they run, when taking on a new setup. I don’t have any of that, yet. Although I have been working with SQL Server for more than a decade, I have not been cool, calm and collected enough to actually keep a goodie bag of “must apply changes”. Most of the cases I worked on as a consultant, always seemed to have a sense of urgency to them. Such urgency, that there really wasn’t time to collect such checklist of what worked and when. This to much regret. A good part of my tricks have been incorporated into Effektor (self-service Data Warehouse), which I was fortunate enough to work on for more than three years. But, since I no longer hold a license for Effektor, that quick win is not an option.
In my current position, most of my work is to advice on platform settings across Windows Server, SQL Server (incl. Analysis Services, Integration Service & Reporting Services), Team Foundation Server and Sharepoint 2010 (currently upgrading/migrating to 2013) within the BI division of Maersk Line IT. I am very much looking forward to seeing the checklists of all the others doing a post for this TSQL2SDAY. Actually I get the feeling of free loading all the cool scripts, tips and tricks that are to come from this blog party.
As I am writing this blog post, I am half way through an excellent book by Ravikanth Chaganti (b|t|l) called Windows PowerShell Desired State Configuration (DSC). As the title gives away, the topic is PowerShell and Desired State Configuration which enables a declarative way of scripting how you want your service environment setup. The only thing that puts me off in this book, is the parts where you yourself have to explore options that are not described in detail. To me it’s an odd half baked way of writing. Other than that it a great resource. Cudos to Ravikanth.
Find other, free, training resources here, here, here and of course on channel 9.
Update: Mike Fal (b|t|l) has this exellent blog post on the topic as well.
Even though I am only half-way through the book I see a wide range of areas where I can apply this technology. In my current situation, getting changes through to our production environment has to be declared nine (9) days in advance, and only single or very very simple changes can occur – otherwise you are doomed to fail. The quality of our service provider is apparently inversely proportional with the number of letters in their name, as we went from one with two (2) letters to one with three (3) letters, and the service got a lot worse. This is why I still go with some Defaults. Not because I want to, but because the hassle is way to much – my longest running support ticket (which is still open) was filed 08-08-2014. I smell anniversary coming up.
I dream myself in a position, where I declaratively can specify which changes I want to have applied, and also with DSC have the ability to enforce these settings. Yes, that is something that is part of this technology, that you can have the configuration “monitored”, to revert any changes back (or file an event in the Application Event Log if you’re the more forgiving type). Having this ability enables you to at least monitor changes to your environment, to have a dialog about why somethings was changed. Maybe the changes are for the better. In order to allow your environment to grow with new requirements, you should be open to change.
There are a lot of areas covered by DSC, and just to give you a brief overview, this is some of the use cases:
- Enabling or disabling server roles and features
- Managing registry settings
- Managing files and directories
- Starting, stopping, and managing processes and services
- Managing groups and user accounts
- Deploying new software
- Managing environment variables
- Running Windows PowerShell scripts
- Fixing a configuration that has drifted away from the desired state
- Discovering the actual configuration state on a given node
In addition, you can create custom resources to configure the state of any application or system setting. So in fact, I can hardly come up with anything I cannot manage through this technology.
PowerShell DSC is an OS feature of Windows Server 2012 R2 and Windows 8.1, so if you are running any of the following versions of Windows, you are required to download the Windows Management Framework 4.0 (WMF). This goes for Windows 7, Windows Embedded Standard 7, Windows Server 2008 R2, Windows Server 2012
Systems that are running the following server applications should not run Windows Management Framework 4.0 at this time.
- System Center 2012 Configuration Manager (not including SP1)
- System Center Virtual Machine Manager 2008 R2 (including SP1)
- Microsoft Exchange Server 2007
- Windows Small Business Server 2011 Standard
WMF is not supported on Windows 8 and be sure to download and read the WMF 4.0 Release Notes for important information about changes in behavior from Windows PowerShell 3.0, and a list of known issues with this release.
DSC builds on a push/pull model – where you choose to apply which ever suits your current situation best. See illustration below:
I know this blog post may not be entirely true to the topic set by Andy, but I hope that my few words on DSC will have spread the awareness of the technology even further. This is really powerful folks! Combine this with all the other tips and tricks from the trenches and you are hopefully off to a way better start.
Thanks for hosting Andy!