Managing Windows Server Role Settings via System Center Configuration Manager

Context

Even though I exclusively work on the infrastructure side, I operate under the theory that if I do something more than once, I need to automate it.  As can be seen from the blog, I am spending more and more time exploring how to use System Center to minimize the amount of repetitive work I have to do.  Or at least do the same task in new ways to relieve the tedium.

Spending a lot of time in a lab, one of the challenges I have that scales to real world scenarios is that I constantly have to redeploy servers.  Since I have a wide variety of server configurations that I have to redeploy, I am continually looking for ways to reduce the amount of time I spend re-building.  For scenarios where I couldn’t find scripts that someone else was nice enough to share, my previous posts include links to some scripts I’ve built to help with these tasks.

Realizing that managing the library of scripts, trying to remember what I named the scripts in the past, manually  kick of the scripts, wasn’t the most efficient use of my time.  Meaning I needed to expand my knowledge of the tools available to for managing infrastructure.

My post “MOMCertImport – Is it all it’s cracked up to be?”, which included steps for configuring the servers via Application Management wasn’t quite as clean as I desired.  Specifically, I had to manage the script in multiple locations which meant updating multiple locations each and every time I updated the script.

Discovery

Goals:

• Validation that the system was properly configured prior to beginning any work efforts.
• Minimize the amount of time invested so that I could perform other tasks while the system was rebuilt.
• Increase the modularity of the script in order to minimize time and effort of future updates.
  Note:  I’ve seen some massive post build configuration scripts out there that are a nightmare to try and figure out what they do.  (my MOMCertImport script definitely falls into this category)
• Total build time is not a priority!  Total build involvement IS!

Research:

• PowerShell now has some really cool functionality for configuration management.  Unfortunately, this doesn’t come with a “platform” to deploy AND report on the configuration to the build servers.

• Here is a way to use DSC to automatically configure the system at boot:  https://blogs.msdn.com/b/powershell/archive/2014/02/28/want-to-automatically-configure-your-machines-using-dsc-at-initial-boot-up.aspx
  Note:  SCCM can also be used to deploy the configurations after the agent is installed.
• I did play around with this a little and it is really easy to work with.

• SCOM – I could have created a rule/monitor and response combination.  When it comes to managing groups of systems to scope rules, it is a little harder than SCCM.  Primarily that it is all bundled in MPs and the ability to delegate the group membership management has limited flexibility.
• SCCM Application Management – been there done that, see above.
• SCCM Compliance Management – simple, flexible interface that allows granular modularity of both compliance settings AND scope management.

Automation

There are 4 steps to doing this:

1. Create the script to detect and remediate the missing components.
2. Create the Configuration Item
3. Add the Configuration Item to a Configuration Baseline
4. Deploy the Configuration Baseline

1. The script

The script used is posted over on the TechNet Gallery:  Configure Exchange 2013 Server Role and Feature Dependencies.

As a basic explanation, there are 3 main sections:

• The list of Roles/Features required – This is the only portion that needs to be edited.  Just edit the list of features required here.
  Note:  If using the PowerShell Desired State Configuration use this reference:  Windows PowerShell Desired State Configuration Role Resource
• A comparison of the required list and how the machine is configured – shouldn’t need to edit
• Export of missing Roles/Features – shouldn’t need to edit

2.  Create the Configuration Item

• Setting type = “Script”
• Data type = “String”

Discovery Script

Make sure the remediate parameter is set to “False”

Remediation Script

Make sure the remediate parameter is set to “True”

Set the compliance rules

• Set “Rule type” to “value”.  Existential rules don’t allow for remediation.
• Set the operator to “Equals” and the value to (blank).  The current script design returns a null value if everything is installed.  This is my design, feel free to change it so the script outputs OK, 0, or something like that when the server is compliant.
• To automatically remediate “Check the box to “Run the specified remediation script when this setting is noncompliant.”  If it isn’t apparent, checking this box runs the script configured immediately preceeding this.

3. Add it to the Configuration Baseline

Note the revision column.  It’s kind of handy for managing the Configuration Items.  There can be one “Production” baseline that deploys a SPECIFIC version of the script and a “Development” baseline that deploys the latest/testing version.  That way trying to manage multiple, identically purposed Configuration Items can be avoided.
Why is this handy?  Have you ever gone into your script directory and tried to figure out which version of script.ps1, script.ps1.old, script-quicktest.ps1, etc. was the most recent tested version of what you were working with?  Now you have version control AND that means just by fiddling with the Revision the ability to roll back is provided.

4.  Deploy the Configuration Baseline

• Observe the setting “Remediate noncompliant rules when supported”.  To actually remediate, remediation needs to be enabled under the “Compliance Settings” AND the deployment configuration.  Meaning, only one Configuration Item needs to be created and actual remediation can be controlled.
• Remediation respects maintenance windows.
  Note:  Since all my servers “in production” should already be configured properly, I want this configuration baseline to remediate the servers as soon as possible after (re)installation.
• Schedule – there is a global client setting that controls how often Compliance Management is run, that can be overridden on a per deployment basis.

Other flexibility:

In a broader sense, if there is a scenario where the detection/remediation has to occur after an application is installed, there is an option to define that the application must be installed BEFORE the Configuration Item will start complaining.

In terms of Exchange, think of scenarios where you might want to have a member of the DAG rejoin the DAG after a reinstall.