Welcome back to ‘the blog’ and this series on Software Metering and automating the removal of unused software with 2012 Configuration Manager (and Orchestrator). If you have been keeping score, this is the third installment in this series. Thus far the post breakdown is as follows -
Part 1 - Software Metering Deep Dive and Automation Part 1: Use It Or Lose It - The Basics
Part 2 - Software Metering Deep Dive and Automation Part 2: Use It Or Lose It - The Collections
In this, the third posting of the series, I will be taking the automated software removal process to a new level with some System Center 2012 Orchestrator integration. I will demonstrate a sample solution that provides notification to an end user that unused software has been detected on their primary system, and that it will be removed in a specific amount of time. The Orchestrator Runbook solution will then provide a grace period in which the user can opt out of the software removal (by using the software). Finally, after the grace period has expired, the Runbook solution will send a final notification email and trigger the software removal process. In this post I will walk through the prerequisites, lay out the Runbook logic, and finally make available a downloadable copy of the sample Orchestrator Runbooks. This is going to be a pretty massive posting, there is allot to cover. While I will not go into detail (step by step) into the configuration of each component, I will discuss how each tie together. If you find yourself needing additional assistance with the solution please let me know, I will provide what assistance I can. Additionally if there is enough interest I can create a follow up post (potentially a video) detailing how to implement the solution start to finish.
Download Location for the Runbook Samples detailed in this blog - Gallery Download Location.
As always (broken record speech), this Runbook is only a sample and is provided in efforts to get the creative juices flowing. Without doubt, this Runbook solution is not feature complete for each and every environment. That said, this sample should provide foundation, and many example concepts from which to work from in your own environments.
The flow / result of the following process will be –
In order to use this sample solution, the following prerequisites must be in place.
If you have read part two of this series you will be familiar with the two tier collection structure previously discussed.
In post 2 I targeted Collection 2 with an uninstallation package. So as would have it, in that configuration, as any machine that contains the metered software, has not used the software in x days, the computer would automatically be added to the collection, and the software would be automatically removed. This in itself is an amazing feat.
How would this work from a collection perspective if we wanted to add a configurable delay, some notification, other automation and workflow?
For the sample Runbook solution that I will detail here, I add a third collection. So building off of the already discussed collection structure
Screen Shot of how I have organized these collections (click image for better view):
As we work though this solution, we will refer back to this collection structure and the purpose of each collection will be clarified even further.
When possible my goal is to build automation that does not include any external data source. That said, I have found this is not always possible. As I dug into the software removal process, I found that in order to give the user a grace period in which to opt out of the software removal, there was a need to track the elapsed time of this grace period. This is what the database is for. The database is very simple and consists of three Columns, ComputerName, State, and Date. You can see here that I've named the database OrchestratorOperation and the table Metering. You can name it whatever you like, but will need to make some adjustments to the Runbooks if using my exported samples.
The following script will create the database for you:
This process, while seemingly simple (send an email, wait some time, place machine in collection), I found to be quite complex when accounting for not just the software removal, but also external database maintenance, cleaning up the software removal collection, dealing with User Device Affinity, email address, etc. etc. While this process does include eight Runbooks, these Runbooks have been broken down into modular pieces. For instance at some point we will need to determine a user’s email address based on the user account. I've created a single Runbook for the purpose of determining the email address. The Address can then be used as Return Data which is fed into a separate Runbook for consumption. So while there are eight Runbooks here, really only the first three are specific to the Software Metering Process, the other five can be used as modules or functions in many Runbook solutions.
I will spend the majority of the Runbook Explanation on the first three Runbooks. These three truly make up the software metering / software removal automation piece. The remaining Runbooks should be for the most part self-explanatory. I will fill in any gaps that I think are not obvious.
1. Metering Start - this is where the process starts.
The New Record Runbooks adds a record into the external database, gathers the user name and email address, and then sends the initial email. Most of this is completed through modular Runbook execution.
The Begin Uninstallation Runbook adds the computer to the Uninstallation collection and sends the final email. Most of this is done through modular Runbook execution.
This Runbook simply adds the computer to the specified collection, waits 300 seconds, and the triggers a Configuration Manager Policy refresh on the client.
This Runbook will remove the computer specific collection rule once it is determined that the rule is no longer needed.
Here we are querying the Configuration Manager database for the User Device Affinity information for the computer. If no User Device Affinity is found, an email is sent to the administrative user specified in the Orchestrator variables. In a production scenario this email notification could be replaced with a Service Manager Incident or other more appropriate action.
Here I am gathering the users email address from active directory using the user name gathered from the User Device Affinity Runbook.
Finally, this Runbook sends an email. Note that throughout this sample several different emails that are sent, but only one send email Runbook exists. This is just another example of a modular Runbook that can be re-used across many different Runbook solutions. This is achieved by piping most of the email specific data into this Runbook using the Initialize Data activity (shown below).
In effort to make this Runbook solution portable (or so that you could import this into your own environment), I have created multiple variables that will need to be configured up front. These include items such as the SMTP server that will be used for email delivery. In using variables this information can be entered in one place (Global Settings) saving us the effort of identifying each specific activity and link that requires configuration. I have crafted the solution in such a way that it should work after only setting each variable, in other words there should not be a need to modify the Runbooks themselves. Once comfortable with the solution you may want to make adjustments to the amount of specified variables and re-craft the solution to use the standards established in your own environment. Each variable is provided with a description that should clue into how to populate the variable value.
Throughout this series of blog posting we have looked at the internals of software metering, collection creation based off of software metering data, basic software removal based on collection membership, and finally in this posting some sample automation that provides advanced warning of pending software removal and an orchestrated final removal process. This is yet but one more example of the cool automation that an be created when using Configuration Manager and Orchestrator together. This solution has many different parts that need to come together in order to work, if you need assistance on any of them please drop a line on this blog. If there is enough interest I will create a follow up post with detailed instruction (potentially a video) on how to configure each piece. I hope this has been helpful and as always please feel free to leave feedback or contact me directly.