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.
There are 4 steps to doing this: Create the script to detect and remediate the missing components. Create the Configuration Item Add the Configuration Item to a Configuration Baseline Deploy the Configuration Baseline
There are 4 steps to doing this:
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:
Make sure the remediate parameter is set to “False”
Make sure the remediate parameter is set to “True”
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.
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.