Okay Readers – Here we go!
Here is the first of six posts in the MVP Spotlight Series for the Automation Track…
–MVP Spotlight Series–
TFS and Service Management Automation – Better together!
Jim Britt of Microsoft gave us a really unique tool for SMA that is highly useful, the SMA Runbook Toolkit (or SMART as it is affectionately known). This is a wonderful tool for tracking your Runbooks and storing them in TFS. The solution we built internally uses Jim’s SMART as a foundation and inspiration but does not use it as a dependency. In our environment instead of using SMA as the source of truth and exporting changes to TFS we instead use TFS as the source of truth and sync the Runbooks and variables in TFS to SMA.
Here (color portion) is a look at where this post fits in to the overall example Solution Architecture:
TechNet Gallery Contribution and Download
Looking for the downloadable content?
Here it is!
This has some huge benefits!
- Every change inside of SMA can be back tracked to a developer and a change set in SMA (and ideally a user story or task!)
- Every change can be rolled back individually
- Branches can bet setup inside of TFS related to your different SMA environments
a. Dev / QA / Prod
b. You can use TFS merging to move changes up from Dev -> QA -> Prod (or whatever tiers you have)
c. This means we have automated change control (with auditing!)
Installation / Setup
Team Explorer Setup
- This solution assumes that you have a TFS client setup on your all of your Runbook workers.
- Jim did a great write-up on how to do that here. Follow Steps 1 and 2.
- If you don’t do this and follow it very carefully nothing will work
- Make SURE that you setup and install the TFS client on all of your workers (notice how this is listed two times, do it!)
- This solution assumes that you have the web service and Runbook worker roles installed on each Runbook worker
- Many scripts reference https://localhost as the web service endpoint for actions like invoking new Runbook instances.
- This solution needs to be configured on each of your SMA Environments
- If you have a 3 tier SMA deployment (DEV / QA / Prod) you need to follow these setup instructions on each of the environments.
- There is a configuration option later to tell the install which environment it is (Dev / QA / Prod). This setting is called TFSBranch
It is assumed that your structure inside of TFS follows the format below
In our environment this looks like…
Install the scripts into your environment
(here it is the download again)
Download the integration bundle from TechNet Gallery.
Once downloaded place extract the zip file onto your SMA server and edit the .\SMAContinuousIntegration\Environment\SMAContinuousIntegration.xml file.
This file contains a number of things that need to be configured to your environment. Everything but the credential object will be created for you installation script based on the values in this file. Simply modify the values in this file to correspond to your environment.
- CredName: The name of a PowerShell Credential object in your SMA environment that will be used for execution. Create this by hand first
- TFS Server: The name of your TFS Server
- TFS Collection: The name of your TFS Collection – often times this is just ‘DefaultCollection’
- TFS Source Path: The area that you mapped your local root to (back in the Team Explorer step above)
- TFS Branch: The branch to pull code from for this SMA environment (Dev if you want to follow my model and this is your development environment!)
- Change this for each SMA environment
- Ex QA for QA SMA, Prod for Prod SMA etch
Once this file is modified simply run the deploy.ps1script as a user that is a SMA Admin (on the SMA box itself)
This will import everything and start your monitor!
It will also take an export of all of your current Runbooks, variables and schedules and check them into TFS for you (anything in your environment that is not in TFS will be cleaned up and deleted in the future!). It places these files in a new ‘ExportedRunbooks’ folder in your TFS workspace
Usage / Walkthrough
Creating a new project
Use TFS to create a new folder
Create the branching structure under this project to relate to each of your SMA environments. Remember, you defined the TFSSourceBranch above. Each SMA environment should have its own source branch name. In our environment we have 3 SMA environment, Dev / QA / Prod so we make 3 branches. We use very basic features of branching (merge with a simple hierarchy). For more information on branching check out Channel 9.
Now all you need to do is author a workflow and check it into TFS. The scripts will do all rest (importing the script into SMA)
Using SMA Variables in your script
This solution allows you to define what variables and schedules are inside of your SMA environment as well. Each Runbook will have a configuration file created for you in TFS. In the configuration file you can put the information about your variables and schedules. This is very important to track in TFS as it facilitates good change control. When we promote our Runbooks from Dev -> QA -> Prod we do not want to modify the actual script files (PS1) we instead want to modify the configuration files. These configuration files should be treated much like web.config files from website development. Everything in your script that will change from Dev -> QA -> Prod should be pulled out into a SMA Variable and, in this solution, stored in a configuration file.
Now that your variables have been created, just reference them as normal in your script
Promote from Dev -> QA
Now you want to promote it to QA? Just do a merge and check it in!
Rolling Back Mistakes
This also works for rolling back changes with TFS
Hopefully you find these examples useful and a good starting place. With this in place you are one step closer to having a fully functional local development strategy for SMA! Another great resource to check out in this pursuit (and one that we leverage internally) is from Joe Levy of Microsoft fame. Check out his blog post Authoring SMA Runbooks in the PowerShell ISE.
And now a few notes from me (Charles)…
Be sure to check out Ryan’s session from TechEd North America 2014!
DCIM-B363 Automated Service Requests with Microsoft System Center 2012 R2
In this session, see a real-world implementation of a fully automated IT service catalog developed by a Fortune 500 company for supporting self-service requests. This service catalog is based in Microsoft SharePoint and utilizes the newly released Service Management Automation (SMA) engine. During the session we look at how the solution is architected, cover integration between SMA and SharePoint, build a new service offering from the ground up, and share the best practices we have developed for doing work with SMA along the way. So what’s the best part? You get access to the solution we create, so you leave with access to a working solution to help get you started!
Speakers: Ryan Andorfer, Mike Roberts
Link on TechEd NA 2014 Channel 9 Recording: DCIM-B363 Automated Service Requests with Microsoft System Center 2012 R2
And finally – As always, for more information, tips/tricks, and example solutions for Automation within System Center, Windows Azure Pack, Windows Azure, etc., be sure to check out the other blog posts from Building Clouds in the Automation Track (and http://aka.ms/IntroToSMA), the great work over at the System Center Orchestrator Engineering Blog, and of course, Ryan’s Blog over at http://opalis.wordpress.com!