Home » Articles posted by Anders Bengtsson (Page 9)
Author Archives: Anders Bengtsson
Overrides Explorer Utility
From Service Map to Network Security Group
List Status for Resource GroupsBuild your own write to log activity
In a number of blog posts I have been writing about how to create a log for your runbooks. The solution I like the most is to write to a SQL database. Even if you do that there is always a small risk that some colleagues don’t write the log in the same way. For example someone use 1-2-3 instead of low-medium-high when writing severity. One way to handle that is data validation in your log runbook. Another way is to create a new activity where colleagues can pick from menus.
First thing you need to build a “write to log” activity is a Powershell script that do the “write to database” part.
param($Argument1,$Argument2,$Argument3)
$DESCRIPTION = $Argument3
$DESCRIPTION = $description.replace("'","''")
$DATE = get-date -format s
$RUNBOOK = $Argument1
$SEVERITY = $Argument2
$conn = New-Object System.Data.SqlClient.SqlConnection
$conn.ConnectionString = "Data Source=SCO12SP1-01;Initial Catalog=OrchestratorTool;Integrated Security=SSPI;"
$conn.open()
$cmd = New-Object System.Data.SqlClient.SqlCommand
$cmd.connection = $conn
$cmd.CommandText = "INSERT INTO Log (DATE,RUNBOOK,SEVERITY,DESCRIPTION)
VALUES ('$DATE','$RUNBOOK','$SEVERITY','$DESCRIPTION')"
$cmd.executenonquery()
$conn.close()
As you can see the SQL server name (SCO12SP1-01) and the SQL database name (OrchestratorTool) is hardcoded into the script. This is because that will not change, when using this activity we will always write to the same log database. Once the script is ready we can use the Orchestrator Integration Toolkit to build an activity and an integration pack. When configure the activity, configure it to run the Powershell script and pass the arguments.
When building the integration pack make sure to attach the PowerShell script. The Powershell script will be deployed together with the integration pack to all your runbook servers. Note that the Severity parameter is configured as Selection. It is configured as a drop down menu where users can pick severity from a list.
When using the activity you can pick severity from a menu. Runbook Name is published by all activities by default.
You can download the integration pack and example files here, NOT SUPPORTED. Note that this is provided “AS-IS†with no warranties at all. This is not a production ready solution, just an idea and an example.
The System Center 2012 Orchestrator book has arrived
The book has finally arrived in printed format. I hope it will provide you with good information and ideas around Orchestrator. Thanks again to the team behind the book, has been great working with you. You can order the book at for example Amazon, or if you are in Sweden maybe Adlibris is easier. Happy reading!
Create Event Integration Pack
Some weeks ago someone asked me how to specify event ID, source and log name with the standard Send Event Log Message activity. Unfortunately the standard Send Event Log Message don’t provide a way to specific more than computer, message and severity. The event will always be generated with event ID 1 and source equals Orchestrator Runbook. The event is always written in the Application log.
To provide a way to specific more settings I created a new Create Event activity today. The activity is built around the EventCreate command. EventCreate enables an administrator to create a custom event in a specified event log, more info at Technet.
You can download the integration pack here. Note that this is provided “AS-IS” with no warranties at all. This is not a production ready management pack or solution, just an idea and an example.
Dashboard in SharePoint without any System Center database schema knowledge
Â
Some time ago I was working in a project were we needed a dashboard to display data from multiple System Center components. You can often find a dashboard to download with pre-populated SQL queries, but it works for one component at a time. We needed one dashboard to work with multiple components and different databases, and we didn’t wanted to write any SQL queries against the System Center databases. Writing SQL queries to get the right data from the System Center databases can be a very time consuming work. The solution was to use the “old classic” Configuration Manager Dashboard that I have blogged about before, here and here, together with Orchestrator as a connector. We also created a small database in the middle. The dashboard database.
Â
Â
A number of runbooks in Orchestrator gets data from System Center components and from a custom database. The result is written to the dashboard database. The SharePoint dashboard queries the dashboard database. We created a set of tables in the dashboard database, for example one table for incidents, one for service requests, one for VM and one for Operations Manager alerts. The table for Service Manager had cells to store information like number of total number of open incidents, closed incidents today, new incidents for today and number of incidents with top severity and priority. Each cell in the table was updated by separate runbooks in Orchestrator, as not all data needed to be updated on the same frequency.
The runbook in figure 1 show a runbook that gets number of open alerts in Operations Manager and writes that to the dashboard database. As you can see we use a counter to count number of alerts. The Get Alert activity don’t publish a “number of object” value, so instead we have to do the counting in the runbook.
Figure 1
Figure 2 show a runbook that gets number of incidents created today in Service Manager and writes that to the dashboard database. The Get Object activity publish a Number of Objects value that we write to the database, then we don’t need to use counters as in Figure 1. To avoid running the Write To Database activity multiple times the Get Open Incidents Created Today activity is configured to flatten the result.
A nice benefit with using runbooks to get the data from the source system is that we don’t need to know anything about the source system database structure. We use only default activities from different System Center integration packs and Orchestrator standard activities.
Figure 2
Figure 3 show an example of the dashboard. There is a number of charts, gauges and tables you can use to present the data. Figure 4 show the configuration for one of the gauges. As we use a custom dashboard database with a very simple structure each SQL query is short and simple.
Figure 3
Figure 4
Note that this is provided “AS-IS” with no warranties at all. This is not a production ready management pack or solution, just an idea and an example.
State tracking and logging in Orchestrator
If you have an Orchestrator environment with multiple runbook servers might have notice that when a runbook failover to secondary runbook server the runbook restarts at the first activity. Let’s say you have a runbook that creates a new user account, a user folder and deploy a computer to a client. If that runbook is interrupted between creating the user folder and deploying the computer it will failover to secondary runbook server and restart at creating the user account. The issues with this is this, in this example, is that you will end up with multiple user accounts for the same user, or the runbook will crash as it tries to create the same user account again. In other scenarios it could cause multiple installation of patches, multiple restarts of a server or multiple deployed of the same VM.
In this blog post I will show a couple of alternatives to handle state tracking. I will also include an example on logging for your runbooks. In my examples I use a SQL table to store logs from all runbooks.
SQL
For all state tracking you need to have a unique ID of the runbook job. If the runbook only runs in one instance you could use the runbook name or activity ID, but often the same runbook can run in multiple instances at the same time.
First alternative is to use a SQL table. I often create a database called OrchestratorTool or something similar to store logs, temp data and so on, in this database I create tables for different runbooks. It is often complicated to use the same table for state tracking from multiple runbooks.
Figure 1 show a “master” or “parent” runbook that invokes three other runbooks. This runbook is used from Service Manager when order a new user account, it creates an account, a user folder and a workstation. The “master/parent” runbook is the runbook that we use as a runbook activity in Service Manager. The Service Request ID (SR) from Service Manager is the unquiet ID that these runbooks use to do state tracking. After each Invoke Runbook there is a check to make sure the runbook returns “something” and not NULL. In the end of the runbook it updates the service request in Service Manager with the result, for example account name. If any of the three Invoke Runbook activities returns NULL I want the runbook to stop, I use the Fail Runbook activity to do this. The Fail Activity runbook is a Query Database activity with incorrect configuration. This will make sure the runbook stops. All the “Write to log…” Invoke Runbook activities invoke a runbook that will write data to a log table in a SQL database. Figure 2 show configuration example of a “Write to log” Invoke Runbook activity. Figure 3 show the runbook that writes to the log table.
Figure 1
Figure 2
Figure 3
Figure 4, 5 and 6 shows the different runbooks that the “master/parent” runbook invokes. Each of these runbooks starts by checks if for example a folder has been created for the service request. If the folder is not created it will create a folder and update the tracking database table with info. If there is already a folder in the tracking database table for this service request it will publish that information back to the “master/parent” runbook. Each runbook also includes a couple of “Write to log” invoke runbook activities to write data to the log table in SQL. If any of these runbooks fails the error will be written to the log table and the “master/parent” runbook will fail, with the “Fail runbook” activity. As you can see in figure 2 the severity is CRITICAL, when a runbook sends CRITICAL severity to the log runbook (figure 3) it will generate an alert in Operations Manager with the info and write it to the log table. This means that each runbook don’t have to include “Create Alert” activities to generate an alert in Operations Manager, they just need to write a CRITICAL event to the log table.
Figure 4
Figure 5
Figure 6
With the SQL alternative the “master/parent” runbook can be restarted multiple times and each “child” runbook will check if has already ran for the service request. We use a table in a SQL database to store the state of each service request. We need another runbook to clean up the state table in SQL, or do it as a last step in the “master/parent” runbook.
Service Manager
The second alternative is to use Service Manager to store the state of the runbook. In this alternative each runbook is independent of each other, we don’t have a “master/parent” runbook, and instead each “child” runbook is its own runbook activity in Service Manager. Servicedesk operators can easy re-start or skip an activity if needed and customer can track each step. If you have only one huge runbook activity, invoke a “master/parent” runbook that then invokes 50 other runbooks, it is very difficult to troubleshoot or restart.
When we build runbooks that handle success, warning and failure from all activities the runbook always ends with a success. Figure 7 show an updated version of the runbook shown in figure 5, to create the account I Active Directory. If for example the Create User activity fails the runbook will go to the Write to log – Can’t Create Account activity. That activity will invoke a runbook and write information to the log. That invoke runbook activity will most likely work, so the runbook will end as a success even if it was not a success, we couldn’t create the account in Active Directory. That is the reason for the “Fail Runbook” activity, which will make sure the runbook crash. The Fail Activity runbook is a Query Database activity with incorrect configuration. This will make sure the runbook stops.
In the end of the runbooks shown in figure 7, 8 and 9 you can see an “Update RB Activity” activity. This activity will write the result of the runbook, for example an account, to TEXT1 of the runbook activity. Each instance of a runbook activity has a number of text fields that you can use to store information. In figure 8 you can see that we use “Get Related RB activities” based on the Service Request to get the runbook activity named something with 9.2.1. 9.2.1 Is the runbook that create the account, shown in figure 7. The runbook in figure 8 then readers TEXT1 from that runbook activity and use it as input when create the folder.
Figure 7
Figure 8
Figure 9
The log table I use for these examples looks like the table in figure 10. The SQL state tracking table I use for the first example looks like the table in figure 11.
Figure 10
Figure 11
Download my example runbooks, StateTracking.
Note that this is provided “AS-IS” with no warranties at all. This is not a production ready management pack or solution, just an idea and an example
Schedule runbooks
From time to time there are questions around using Orchestrator as a batch robot, for example run a set of file copy jobs every night. In general Orchestrator was not designed as a job scheduler, even it if would work in small scale. Challenges you can run into when trying to this are
- There is not a single view to show when you have schedule which runbooks. For example if you want to check all runbooks configured to run every night you have to browse through all your runbooks in Runbook Designer.
- There is not a single view to show all the calendars you have configured and how they are configured.
- There is not a single view to see if all runbooks was successfully last ran, for example if you have a number of runbooks running every night you want to have one view in the morning to verify that everything worked.
- There is no easy way to import a calendar from another tool
- By default a runbook server can run 50 jobs at the same time. You can reconfigure this (http://technet.microsoft.com/en-us/library/hh420378.aspx) but you should consider the resource requirements of the runbooks on a particular server. Lets say you start one runbook that checks for new files in a folder and then for each new file you invoke another runbook. What if there are 1500 new files in that folder? 1500 running runbooks would require a lot of runbook servers to run all that at the same time. If you don’t have another runbook servers a queue would be built up, which could result in long delays and affect other runbooks.
If you still want to schedule a runbook, for example to run every 12 hours, you can use a Monitor Date/Time activity. A disadvantage is that the runbook will be running all the time, monitoring the schedule. As the runbook is running all the time, it will use one of the 50 (by default) slots on your runbook server.
If you want to run your runbook 01.00 on Sundays only you can also use the Monitor Date/Time activity, but you need to combine it with a runbook level schedule. Create a new schedule, check only Sundays, and configure your runbook to use the new schedule. You configure the runbook to use the schedule by right-click on the runbook tab, select properties and then click schedule.
After you have configured a runbook to run for example every Sunday at 1 am you start it. The runbook will get the green “running” icon and in the database it will be marked as pending. Once it gets Sunday at 1 am the runbook will run. After the schedule time window the runbook will stay in running status, until next schedule time window, even if it is not allowed to execute between the schedule time windows.  If the runbook tries to run other times a platform event will be generated.
Instead of using Orchestrator to trigger runbooks based on a schedule you can use Windows Schedule Tasks, see this blog post from the Orchestrator Engineering team. I have two related blog posts around this, one about execute runbook later and one about runbook servers in different time zones.
Note that this is provided “AS-IS†with no warranties at all. This is not a production ready management pack or solution, just an idea and an example
System Center Universe
At System Center Universe I will present two sessions together with Pete Zerger
- Iron chef Cloud: The Sequel – Cooking Up Gourmet Automation Solutions with System Center and Server 2012 R2
- 14 Tips and Tricks to bring your Orchestration Effort to the next level
It will be a mix of System Center R2, best practice, Swedish, English, lesson learned, demos, more demos and a lot of tips and trix.
See you there! 
Copy Notes between Manual Activities
Let’s say you have multiple manual activities in a service request. Each of these manual activities need the output of previous manual activities. For example the first manual activity creates a user account for a new hire. Then the second manual activity is adding this user account to a HR system. The first engineer can input a comment, the user account, when the activity is marked as completed in the self-service portal. But the second engineer need to click a lot to see the note from the first engineer.
- Parent work item
- See details
- Related Items
- Contains Activity
- Expand Manual Activity
- Find the correct activity and click it
- Scroll down and find the correct property
As you can understand it is not easy to find the information, special for some non-technical colleges that don’t understand parent work item and activities.
An alternative to this is to use a runbook between your manual activities. The runbook copy the information between your manual activities, engineers can then see all information from previous manual activities on the first page in the self-service portal. It is the comment/note that previous engineers have input when they mark activities as completed that are copied between manual activities.
In this example I have 3 manual activities in my service request template
It is the same runbook (runbook activity) between each manual activity.
- Initialize Data. Input Service Request work item ID and Runbook Activity work item ID
- Read the Runbook Activity
- Read the Service Request
- Get Related Manual Activities for the Service Request
- Read each related manual activity
- Compare Value. Checks if the manual activity sequence number is the one before the runbook activity sequence ID. All activities in the service request has a sequence ID, we need to find the one before the current runbook activity. This Compare Value activity checks if the manual activity sequence ID equals “runbook Activity sequence ID minus 1”
- Reads the manual activity before the runbook activity
- Again, gets all related manual activities
- Again, read each related manual activity
- Again, compare values. Same as previous compare value but this time we look for the manual activity with sequence ID after the runbook activity
- Update the manual activity after the runbook activity with information from the manual activity before the runbook activity
- Return data without any configuration
You can download my example runbook, 20130708_CopyMA_wolf . Note that this is provided “AS-IS” with no warranties at all. This is not a production ready management pack or solution, just an idea and an example
Update Service Manager SLA thresholds with Orchestrator
From time to time I get the question if it is possible to pause a SLA in Service Manager. You should write your SLA in a way that you never have to think about pause them. For example if you have a SLA saying you will fix hardware issues in 8 hours, but your hardware vendor has agreement saying they will send you spare parts in 4 days, you need to re-write your SLA. Another example could be a SLA saying an incident will be resolved within 8 hours. If you are dependent on end-users that might be difficult to fulfill, instead write SLA based on first response. Why write a SLA that you can never fulfill?
In this blog post I will show how to modify the SLA endtime with a runbook. This runbook dont pause the SLA, it just adds minutes to the TargetEndDate and the TargetWarningDate for incidents in a “Waiting for end-user” status.
- Monitor Date/Time. The runbook trigger every 5 minutes
- Get Object. Gets all incidents in “Waiting for end-user” status
- Link. If there are more than one incident
- Get Relationship. Gets related Service Level Instance Time Information
- Get Object. Reads the Service Level Instance Time Information instance
- Format Date/Time. Takes the current TargetEndDate as input and adds 5 minutes on Format Result output
- Format Date/Time. Takes the current TargetWarningDate as input and adds 5 minutes on Format Result output
- Update Object. Updates the related Service Level Instance Time Information instance with new TargetEndDate and TargetWarningDate
The result is that every 5 minutes when the incident is in “Waiting for end-user” state the runbook will add 5 minutes to both the SLA Warning time and the SLA End time. You can download my example file, PauseSLA_wolf. Note that this is provided “AS-IS†with no warranties at all. This is not a production ready management pack or solution, just a idea and an example
Show Status of the last Review Activity (with a pinch of Orchestrator magic)
A friend asked me if it is possible to show the status of a related review activity in the “All Open Service Requests” view? After a while we realized that a requirements was to show the status of the last review activities, so if there were multiple review activities we just wanted to show the last one. The reason why they needed this view was that customer called service desk and asked about service requests. With a view like this the operator could easy see if all the manual review activities was completed, if the service request was still waiting on more approvals or if someone was building/working on the requested service.
We started by extending the Service Request class in Service Manager with two new properties, one to show the last review activity status and one to show when we last updated that status.
We use a runbook to update these properties
Comprehensive description of each activity in the runbook
- Monitor Date/Time. The runbook runs every 30 minutes
- Query Database. Truncates a database that is used to store data temporary. The runbook use a database table to store review activity information temporary.
- Get Object. Gets all open Service Requests, from the extended Service Request class.
- Get Relationship. Get related Review Activities for each open Service Request
- Update Object. If there are no related review activities it will update the “LastStatus” property with “No Review Activities”
- Get Object. If there are related review activities it will get the review activity and write review activitiy and Service Request information to the database
- Junction is used to merge all threads together to one
- Format the current time/date to a format that works with Service Manager
- Query Database. Query the database to get last review activity for each Service Request and status of it
- Update Object. Updates each Service Request that is in the database with review activity status
The result in the Service Manager console can look like this
You can download my example runbook and Service Manager class extension here, 20130616_SRStatus
Note that this is provided “AS-IS†with no warranties at all. This is not a production ready management pack or solution, just a idea and an example.
Recent Comments