...building hybrid clouds that can support any device from anywhere
Hello readers / viewers. I have a topic that I think will be valuable for folks looking to ensure they are backing up their SMA Runbook investments to the fullest extent within WAP (Windows Azure Pack) and storing those in TFS (Team Foundation Server) for any changes (for rollback / DR / etc.). If you look at the below diagram, it gives you a basic idea of what this scenario is end to end.
Download the supporting Runbooks for this solution here
And ensure you have SMART for Runbook Import and Export (required for the end to end solution)
Install Visual Studio (or Team Explorer 2012) on the SMA Runbook Worker
The easiest way to populate the GAC (Global Assembly Cache) for the TFS DLLs we are using is to install Team Explorer for Microsoft Visual Studio 2012 on the Runbook Workers. This gives you the ability to connect to TFS and execute the actions within the Runbook Invoke-TFSSourceUpdate. You could of course do a remote PSSession but you’ll also need to bounce back to the SMA server to capture the Runbooks.
Download: Team Explorer for Microsoft Visual Studio 2012
Note This post assumes you are executing this from the SMA Runbook Worker. Of course it may make more sense in your environment to use a UNC path to copy the files to and leverage a PS Session to execute the PowerShell remotely on that remote server so that all the TFS GAC requirements are localized to another machine. That’s out of scope for this blog post. You can also copy the GAC directly for TFS and avoid installing the Team Explorer (or Visual Studio) as another option.
My good friend Yao (Zhenhua Yao) has a great blog post that discusses a few other options and he talks about getting those GAC files in the right place if you want to avoid installing anything on your Runbook workers. TFS Integration Pack and Scripting using PowerShell. Yao – thanks for your support on some random questions on this TFS PowerShell topic. As always you are an awesome engineer to bounce things off of and your assistance was huge for this thank you!
Map a local folder on your SMA Runbook Worker that will hold your specific folder you want to source your SMA Runbooks in. Make sure this is setup with the Service Account for SMA or whatever ID you are actually using to update TFS (for this example, the service account is assumed). Ensure this account has rights in TFS, rights in SMA, and has a local TFS mapping on the SMA box to be leveraged by this account for syncing content with TFS (see next section). This is an easy step to miss and you will be kicking yourself later if you don’t actually do a “Run As” on Team Explorer as the service account for SMA and map your local path you’ll be using to update TFS.
Note You do not need to synchronize your entire TFS source down to your SMA box. You only need to map the specific folder for your Runbooks you are sourcing and updating in TFS. See below for more details.
Initially, you’ll see that nothing is mapped locally. This means you can browse existing content on the TFS server but can’t checkout / update / put files up on the TFS location.
Click on the Not mapped hyperlink to select a local folder to map to. I generally grab a root folder of a drive with plenty of space and name it the same as the main source root (ex: WSSC_CAT would be c:\WSSC_CAT)
Then just click Map and away you go! You could map lower down such as “SMARunbooks” in the above example and then you only need to worry about one folder – I chose to do it at the top in case I want to actually place some Runbooks in other locations. Think in terms of projects and using tags to tag your Runbooks by project and then sourcing those Runbooks in TFS by project. Do what makes sense for your company – the flexibility is there .
This next screen shows that if you click Yes it is going to download all source – answer appropriately. Yes downloads everything – no makes you do a right click, Get Latest Version when you get into Source Explorer. You can also be specific and only get source on a specific folder so answering No here may be best if you want to be granular on what you are pulling down to your SMA server.
Finally, you should see your directory mapped properly indicating things are setup and ready for the Imported parent Runbook in this solution to use SMART to export files to this location.
Click the Download Button to Get SMART for Runbook Import and Export. You’ll want to leverage this to get the most out of your exports from SMA. This solution will grab the pieces of a Runbook that are outside of just the standard PowerShell contained within.
To read more about this solution: Automation–Service Management Automation–SMA Runbook Toolkit Spotlight–SMART for Runbook Import and Export
This download contains the following Runbooks:
Review the Runbook Details section below to understand how these Runbooks are designed and ensure they are updated according to what you have in your environment.
If you are interested in having your Runbooks export on a schedule (so you don’t have to worry about keeping up with it) I highly recommend setting a schedule daily. The execution of this solution is very lightweight and has no real impact on your environment. Setting the schedule ensures you get a backup daily, and you can still execute this Runbook on demand at your whim if you are doing some updates and want to ensure you have a fresh backup. Run it a bunch of times if you want . The value here is that the source on TFS only gets updated if there has truly been a change in your PowerShell (or characteristics of your Runbook).
To set a schedule
First we have to establish the “environmentals”. This would be TFS server, collection, and source path you are going to source your files to. If you used the install wrapper explained in Step 5 above, it created the variables for you. Update these variables in SMA to ensure they reflect your target environment.
Note If you didn’t use the install wrapper to import these Runbooks (or if you opted to not import assets) ensure you either create these variables or update them with proper static values.
Finally, we need to ensure that our updates are refreshed on the TFS server. The nice thing about this process is that if the Runbook literally looks the same as what is already on the TFS server, no update actually gets pushed. You will only update Runbooks that have had modifications.
You can now track changes in TFS for your Runbooks (right down to who changed what) and roll back changes if you need to!
Small Footnote Here If someone happens to delete a Runbook in SMA, it will stay in TFS unless you remove it via Visual Studio or Team Explorer. Probably a good thing.
We start with the parameters that are leveraged within the Runbook to connect and check in changes for TFS.
Next we load the necessary assemblies and get connected to your TFS instance and location you are interested in updating
Then finally we check in our Runbooks into TFS for safe keeping .
This section describes a couple of potential issues you may run into after implementation or while getting things setup. These are issues I ran into as I put this into production in our environment.
Exception calling “CheckIn” with “2” argument(s)…
This can occur if one of the Runbooks has been deleted on the TFS server but your local source directory still has the Runbook, an update is made, and the Runbook is attempting to be checked in.
Launch TFS on the SMA server as the SMA service account and resolve the conflict by selecting “Get Latest Version” on the folder in question and answering the prompts to resolve the issue.
Exception calling “GetWorkspace” with “1” argument(s)…..
This can happen if you fail to map a local path for TFS for the account you are using in the SMA Runbook to synchronize with TFS.
Note You can only have one account mapping to local source on a machine. Ensure you are not mapping with your “interactive logged on account you use for administration and use the account that is synchronizing with TFS on your SMA box.
See STEP 2 above .
Well that’s it for this post. I hope you get some value out of this solution for your dev/QA/Production environments where you are leveraging SMA.
Until next time – Happy Automating!
And for more information, tips/tricks, and example solutions for SMA, be sure to watch for future blog posts in the Automation Track on http://aka.ms/BuildingClouds!
I don't see the point in exporting from prod into TFS (unless its just for backup). A natural workflow would be to have the admin/developer edit scripts locally and then check into TFS/GIT, and from there publish/import the scripts into prod. This blog post doest it all backwards.
@Trond Hindenes , thanks for the feedback. This post was mostly to get the ideas flowing and help generate ideas for new solutions based on this example that fit your organization. As it turns out, this solution fit our needs due to how we were leveraging our POC environment as pretty much a production environment with multiple DEVs updating all through SMA/WAP versus updating outside of SMA or even moving from dev to QA to Test. Your points are valid and definitely could fit here leveraging some additional logic to pick up when changes occur and move those changes into production from QA if they were preformed by a dev that had rights into the right environment that was also sync'd up with TFS. I chose to narrow in on one case but this case isn't necessarily going to fit all requirements as you stated.Ryan Andorfer (Orchestrator MVP) will be posting a continuation of my post on his site here: http://opalis.wordpress.com/ hopefully by the end of the month that will give you a scenario that likely fits more closely with what you are looking for. Stay tuned and thanks for the feedback.