SCCM, SQL, DBATools, and Coffee

Warning: This article is predicated on (A) basic reader familiarity with System Center Configuration Manager and the SQL Server aspects, and (B) nothing better to do with your time.

Caveat/Disclaimer: As with most of my blog meanderings, I post from the hip. I fully understand that it exposes my ignorance at times, and that can be painful at times, but adds another avenue for me to learn and grow.

I don’t recall exactly when I was turned onto Ola Hallengren, or Steve Thompson, but it’s been a few years, at least. The same could be said for Kent Agerlund, Johan Arwidmark, Mike Niehaus, and others. None of whom I’ve yet to meet in person, but maybe some day. However, that point in time is when my Stevie Wonder approach to SQL “optimization” went from poking at crocodiles with a pair of chopsticks, to saying “A-Ha! THAT’s how it’s supposed to work!”

As a small testament to this, while at Ignite 2016, I waited in line for the SQL Server guy at his booth, like an 8 year old girl at a Justin Bieber autograph signing, just to get a chance to ask a question about how to “automate SQL tasks like maintenance plans, and jobs, etc.”. The guy looked downward in deep thought, then looked back at me and said “Have you heard of Ola Hallengren?” I said “Yes!” and he replied, “he’s your best bet right now.”

Quite a lot has changed.

For some background, I was working on a small project for a customer at that time focusing on automated build-out of an SCCM site using PowerShell and BoxStarter. I had a cute little gist script that I could invoke from the PowerShell console on the intended target machine (virtual machine), and it would go to work:

Install Windows Server roles and features

Install ADK 10

Install MDT 2013

Install SQL Server 2014

Adjust SQL memory allocations (min/max)

Install WSUS server role and features

Install Configuration Manager

Install ConfigMgr Toolkit 2012 R2

and so on.

Since it was first posted, it went through about a dozen iterative “improvements” (translation: breaking it and fixing and improving and breaking and fixing, and repeat).

The very first iteration included the base build settings as well, such as naming the computer, assigning a static IPv4 address, DNS servers and gateway, join to an AD domain, etc. But I decided to pull that part out into a separate gist script.

The main thing about this experiment that consumed the most time for me was:

On-the-fly .INI construction for the SQL automated install

On-the-fly .INI construction for the SCCM install

On-the-fly SQL memory allocation configuration

Aside from the hard-coding of content sources (not included on this list), item 2 drove me nuts because I didn’t realize the “SA expiration” date property was required in the .INI file. The amount of coffee I consumed in that 12 hour window would change my enamel coloring forever. Chicks dig scars though, right? Whatever.

Then came item 3. I settled on the following chunk of code, which works…

I know that option 2 assumes a “bad practice” (dynamic memory), but it happens in the real world and I wanted to “cover all bases” with this lab experiment. The problem that it causes is that the values returned from a WMI query can fluctuate along with the host memory allocation status, so the 80% value can be way off at times.

Regardless, forget all that blabber about static values and dynamic tragedy. There’s a better way. A MUCH better way. Enter DBATools. DBATools was the brainchild of Chrissy LeMaire, which is another name to add to any list that has Ola’s name on it. (side note: read Chrissy’s creds, pretty f-ing impressive). There are other routes to this as well, but I’ve found this one to be most user friendly for my needs. (Feel free to post better suggestions below, I welcome feedback!)

This is ONLY AN EXAMPLE, and contains an obvious flaw: I’m not injecting an explicit 80% derived value for the -MaxMB parameter. However, this can be accomplished (assuming dynamic memory is not enabled) as follows…

You might have surmised that this was executed on a machine which has dynamic memory enabled, which is correct. The Hyper-V guest VM configuration is questionable…

This is one of the reasons I opted for static values in the original script.

Thoughts / Conclusions

Some possible workarounds for this mess would be trying to detect dynamic memory (from within the guest machine) which might be difficult, or insist on a declarative static memory assignment.

Another twist to all of this, and one reason I kind of shelved the whole experiment, was a conversation with other engineers regarding the use of other automation/sequencing tools like PowerShell DSC, Ansible, and Terraform.

The final takeaway of this is to try and revisit any projects/code which are still in use, to apply newer approaches when it makes sense. If that means shorter code, improved security and performance, more capabilities, greater abstraction/generalization (for reuse), or whatever, it’s good to bring newer ideas to bear on older tools. In this example, it was just replacing a big chunk of raw .NET reflection code with cleaner and more efficient PowerShell module code. Backing out 10,000 feet, the entire gist could be replaced with something more efficient.