...building hybrid clouds that can support any device from anywhere
Hey readers, well I have just updated the SMART for Runbook Import and Export and this post is all about discussing some of those updates.
First things first – if you don’t know what SMART is – go here Automation–Service Management Automation–SMA Runbook Toolkit Spotlight–SMART for Runbook Import and Export and get an idea of what you’ve been missing. Seriously, this solution is ideal if you want to port Runbooks between environments or just export in complete sets and check into TFS as discussed in this post Automation-Exporting SMA Runbooks to TFS on a Schedule in Windows Azure Pack with SMART!
If you already know what it is and just want to go download it right now without reading the rest click the download button below.
Note If you have a previously installed version of this solution, this update (when installed) will overwrite what you have in your existing environment unless you change the options in the Install-SMARTForRunbookImportAndExport.ps1.
So there are a handful of useful updates in this version that I think will be worthwhile to download the update.
So in the previous version we would export a credential or an encrypted variable but we didn’t export the secret within (encrypted junk). With this update we have the option now to export encrypted contents and save those in the XML file for import later into another environment or just to have for recovery in case of an issue, etc. This allows you to quickly get back up and running with your Runbooks / credentials / variables as they were when exported. The TFS for SMA link above gives you an idea of what you can do there – take that idea and expand.
Just add a switch (-ExportSecrets $True) in your SMA Runbook for SMART that does your exporting (Invoke-SMARunbookExport is provided as an example)
The result looks something like this. Now you’ll have what you need on the import process to create your credentials properly.
Note Access to the secrets can only happen during the execution of an SMA Runbook (not outside of SMA from PowerShell, not within an InlineScript within an SMA Runbook either btw). Why is this? Because the cmdlets that are leveraged to get access to the secrets are only available in SMA (they just don’t exist in PowerShell outside). This also means that the pure PowerShell scripts that are provided with this solution do not have the option to use ExportSecrets.
Just like above, the –ExportSecrets option (when specified) will allow you to also export the encrypted data for variables that are leveraged within the Runbook you are exporting. Even better, you can export string, Int32, DateTime, and Bool.
Note Integers get exported differently depending upon if they are encrypted or not. Encrypted Integers get exported with type Int32 and non-encrypted integers have a type of int. Don’t ask me, I’m just leveraging the data as it is given to me. Just wanted to point this out in case you see the difference in your XML file. Also, if you are wanting to create these values manually in the XML for import – INT and INT32 both work in both scenarios so don’t worry.
See below (It Takes a Village) but was able to work out some logic to update tags after Runbooks have already been imported into SMA through the web service. This is pretty slick actually and not too difficult to implement. Got my web service skills polished up a bit as well so bonus . I’m providing an example (similar to what I used in my script) to help those that are interested in interacting with the web service for SMA.
Note This works in SMA as well as outside of SMA with the PowerShell script provided.
See in the (It Takes a Village) reference below but in a “nutshell” this update was required to ensure that the cmdlets that were being called were running from within SMA. In the end, I wasn’t able to directly leverage this logic since compilation errors occur when the PowerShell cmdlets cannot be found that only exist in SMA. But! This may be useful for others in the future so I’m posting it below here.
The previous iteration of this script allowed for the creation of credentials but only with a default user account and password. The updates provide the ability to formulate your own XML for a Runbook and populate the required fields to allow you to create the credentials on import as expected. This ensures that you can get up and running immediately with a Runbook with its dependencies (without manual modifications in your SMA environment). So, essentially just provide the required details in your Runbook XML according to the schema below and you’ll be done!
What? Bugs? Yeah
So I wanted to call out the great collaboration during this update. Though the updates seem small, they were thought provoking and definitely needed to be done in a way that would support forwards and backwards compatiblity with the cmdlets as much as possible both inside and outside of 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!