Home » Orchestrator (Page 7)

Category Archives: Orchestrator

Building a SLEEP activity for Orchestrator

When building runbooks you sometimes need to include a delay or a sleep. You can configure a delay on the links between activities, but it is not always a good solution. In the example in the image below I have a delay on each link. As you can see it looks like the runbook is on the first activity, but it is not, it is on the link, waiting. You don’t see the link as a step in the runbook and you cant see the link delay as a step in the history log either. A better alternative is to use a “wait” or “sleep” activity. In this blog post I will show you how you can build a “sleep” activity with Orchestrator Integration Toolkit. We will use a Powershell cmdlet named start-sleep and input number of seconds we want to sleep.

  1. Download and install the Orchestrator Integration Toolkit
  2. Start the Orchestrator Command-Line Activity Wizard
  3. On the welcome page click Next
  4. Assembly Details. Input a name a assembly file, for example ContosoSleep as name and C:\IP\ContosoSleep.dll as assembly file
  5. Commands. Click Add
  6. Add/Edit Command. Input
    Name: Sleep
    Mode: Run Windows PowerShell
  7. Switch to the Arguments tab, click Add parameter
  8. Add/Edit Parameter. Input
    Name: Number of seconds to sleep
    Usage mode: Command Argument
    Display Style: Text
    Default value: <leave blank>
  9. Click Ok
  10. On the Arguments tab, in the Command Line text field, input
    start-sleep -s
    then click Insert and Number of seconds to sleep
  11. Click Ok
  12. Commands. Click Next
  13. When you see “The wizard completed successfully” click “Build Integration Pack”
  14. Product Details. Fill in the information, for example
    Product Name: Contoso Sleep
    Category Name: Sleep
    Company: Contoso
    You can click Modify and change the icon. Click Next
  15. Activities. Verify that your Sleep activity is listed, then click Next
  16. Dependencies and included files. Our example don’t need any extra files so click Next
  17. Orchestrator Integration Pack File. Input a path where the Integration Pack will be created. Click Next
  18. The integration pack is created. Click Finish to exit the wizard

Now, register and deploy the integration pack with Deployment Manager. After that is successfully you can restart your Runbook Designer console and you will see a new Integration Pack with your new activity.

As you can see in the image below we can now easy see that the runbook is in “sleep mode” as Sleep is its own activity. More examples with the Orchestrator Integration Toolkit can be found here. You can download my sleep IP here. ContosoSleep . Please note that this is provided “as is” with no warranties at all.

The Configuration Manager dashboard with Orchestrator

A couple of years ago I wrote a blog post around using the Configuration Manager dashboard with Operations Manager, link. Now days Operations Manager have their own dashboard. But today I needed one for Orchestrator. I tried the Configuration Manager dashboard and it seems to work fine with Orchestrator. As you configure the dashboard with SQL queries you can query any database and show the result in the dashboard.

All SQL queries I used can be found in my “Runbook Validation” blog posts, found here. Instructions how to configure and install the dashboard can be found in my old blog post here.

Automate Operations Manager with Orchestrator and Service Manager

Lately I have been working with a number of automation scenarios where we use Service Manager and Orchestrator to automate Operations Manager. The scenarios have not really been target to end-users, instead to Operations Manager administrators and subject matter experts (SME). For example install agent and uninstall agent, maintenance mode and disable alerts. All this can be done from the Operations Manager console, but that require first knowledge and then of course permission. Another benefit with automate it based on a form is that is will be done the same everytime, independent on which administrator performing the task.

For example if you want to allow subject matter experts, like your Exchange team, to install Operations Manager agent on new Exchange machines, you will need to give them Operations Manager administrator permissions. Alternative they will contact your Operations Manager administrator’s team and request to get the agent installed. With Service Manager 2012 self-service portal you can publish this as a service request. Anyone with enough Service Manager permissions can request an agent in the portal, an operations manager administrator can approve it and then Orchestrator will install the agent.

Another common scenario is that a team gets an alert that they don’t want. For example a service is not running on server X. Instead of forwarding this ticket to the Operations Manager team they could simple disable it for the server themselves, after an Operations Manager administrator have approved it in Service Manager.

In this blog post I want to share with you a runbook that disable a rule or monitor based on ticket ID from Service Manager. The scenario is that a team, for example the Exchange team, gets an incident in Service Manager; the incident is generated from an alert in Operations Manager. After some thinking they realize that they no longer want to monitor that for that server. They browse to the self-service portal and input the incident ID (ticket ID in Operations Manager), after approval, Orchestrator find the rule or monitor generate that alert and disables it for the machine. The Orchestrator runbook also handle override management pack. The Exchange team could also browse to the Orchestrator console and start the runbook.

Another discussion is if this is a service request of a change request. The current build of Service Manager 2012 allows us to publish service requests direct in the portal, not change requests. Therefor I will use Service Requests in this example.

  1. The first activity, gets Ticket Id and target server name as input. Which Operations Manager management server the runbook is using is controlled by a variable. All activities use the same variable to contact the same management group.
  2. This activity is used to format date and time which is used for the management pack backup folder
  3. Powershell script, loads the Operations Manager module and gets the alert with the ticket ID we input when the runbook was started. The script then checks if the alert is from a rule or a monitor. As we need to use different cmdlets to disable a rule or a monitor we need to know if the source is a rule or a monitor. Next step finds out the orginal management pack, the management pack that stores the alert source. The script checks if there is a suitable override management pack. The override management pack name is “Organisation – orginal name” for example “Contoso – Microsoft Unix Library”. “Contoso” is controlled by a variable. All steps will echo to the logfile, default path is C:\TEMP\logfile.txt
  4. If there is no suitable override management pack this activity creates it, as a XML file in the C:\TEMP folder
  5. Imports the override management pack created in step 4
  6. Overrides the rule or the monitor
  7. If there is a override management pack already step 7 makes a backup of the management pack. The backup of the management pack is stored in C:\TEMP by default. The script will create a folder with the current timestamp and then stores the management pack in it
  8. Overrides the rule or the monitor

An example of this could be that first an alert is generated in Operations Manager and syncronized to Service Manager. Service Manager writes back the incident number to Operations Manager

A SME finds out that this rule or monitor can be disabled for this or a machine. The SME can then navigate to the Orchestrator Console or browse to the Service Manager self-service portal and input the ticket ID and the server for which the monitoring should be disabled

Either way the runbook will be executed and create the override

Summary: Self-service can be target to engineers and SME teams, not only end-users. We use self-service with the Service Manager self-service portal or with the Orchestrator Console to execute tasks that the engineer normally dont have deep skills of or permissions to do. In this example disable a rule or monitor in Operations Manager. We save time both for the engineer and the Operations Manager team. With the Orchestrator console we can use Orchestrator as a “proxy” to carry out complex tasks in a very simple way. With Service Manager we can build a approval flow to make sure every change is approved in a correct way.

If you want to build a runbook that deploys agent to untrusted networks or workgroup machines, where you need certificate based authentication, look at, Deploy OPSMGR agent to untrusted zones with Opalis. Also look at the posts around fault tolerance and logging. If you want to build a runbook to uninstall (and install) the Operations Manager agent, that can be triggered from the Orchestrator console and the Service Manager self-service portal, this is an example

You can download the runbook here, 20111227_DisableRuleMonitor. Please note that this is provided “as is” with no warranties at all.

Update Operations Manager 2012 alerts with Orchestrator

System Center 2012 is soon here and many are already playing with release candidates and beta versions. As you might notice the current Orchestrator integration pack (IP) for Operations Manager only support Operations Manager 2007 R2. But what if we are running Operations Manager 2012 and Orchestrator in a sandbox and want to try connect them? Some of the activities in the Operations Manager 2007 R2 integration pack might work with Operations Manager 2012, but as it is unsupported it is not a good idea. But in Orchestrator we have a generic activity named “Run .NET Script”. This activity can be used to run PowerShell script, for example Operations Manager 2012 command shell. To do this we need to first install Operations Manager 2012 console and command shell on each runbook server, then we need to change execution-policy on them, to allow our script. Note that Orchestrator is running PowerShell in 32-bit mode. More info about that here.

When you have done this you might need to reboot your runbook server to load Operations Manager dlls. If you get a event in the application log like the event below, solve it with a runbook server reboot.

Time to build the runbook. It is a pretty simple example but I think it gives you a idea what you could do. The first example will return alert name and alert id for all alerts with resolution state equals new (0). As you can see we first load the Operations Manager module, we then create a connection to the Operations Manager management group. In this example it is running on a server named FIELD-OM8381. We then get name and if for each alert with resolution state 0. On the second image you can see settings to output information from the PowerShell script to the Orchestrator data bus. In this example we publish alert name and alert id to the data bus.

If we want to update each alert to a new resolution state we could add another Run .NET with a script like the example below. As you can see we use the output from the first activity (alert id) as input to this activity. We configure each alert with resolution state 1, 1 is equal to Orchestrator in my Operations Manager sandbox.

Active Directory Integration with Orchestrator

I guess many of you have start playing with System Center 2012 Orchestrator already, if not, download it here. A common question around Orchestrator is integration with Active Directory and multiple Active Directory forests. Earlier versions of integration packs for Active Directory required the runbook server to be member of the target Active Directory forest, which could be a challenge when working with multiple Active Directory forests. Tonight I did a test with the System Center 2012 Orchestrator Beta Integration Pack for Active Directory (download here) and it seems to work fine between different Active Directory forests, even without a trust. I have Orchestrator RC installed in the field.local AD forest and creating Active Directory objects over in the Contoso.local Active Directory forest. There is no trust between the two forests. Great!

Validate your runbook design – part V

I have updated the Orchestrator Community Runbook Check again. The last version was unbelievable slow. It seems like every time the runbook invoke another runbook it took at least five seconds, operations that took one second if I keept it in the same runbook. For that reason I have added activities to a number of runbooks, instead of using library runbooks. I have also re-written a couple SQL queries to make things a bit faster, and added 0 rows result. It now takes around 15 minutes in my sandbox, instead of two hours.

I have also added one check to see if there is any delays configured on links and another check to list runbooks that are checked out during the check.

You can download the new version of the runbook, Orchestrator_Check_wolf_20110925. If you have any ideas what I should add, please post them as comment to this post or send me an e-mail.

Please note that this is provided “as is” with no warranties at all. Also please note this is all based on my ideas and is not a “Health check” or Microsoft official guidelines.

Validate your runbook design – part IV

Using the Run Program activity can sometimes be a bit tricky. This activity will report success if the command execute ok, even if the command execute with a bad result. For example, if I use it to copy a file, but the target folder does not exist, it will still report success, as the command, COPY, worked fine. As you can see in the image below, the activity report back success, but if we look at the program output we see that the copy job did not work.

A way to handle this is to add validation as the next step in the runbook. For example in this scenario verify that the target file exists

I have added a check to the SCO Validation Runbook, that checks if you are using any run program activities, just as a reminder to verify that you check the result of the command. You can download the new version of the runbook 20110909_scoCheck_WOLF. Please note that this is provided “as is” with no warranties at all. If you have any ideas what I should add, please post them as comment to this post or send me an e-mail. Also please note this is all based on my ideas and is not a “Health check” or Microsoft official guidelines.

Best of MMS Sweden 2011

Best of MMS is approaching! Only a couple of weeks away now! I will deliver a session at Best of MMS in Stockholm/Sweden, session title is “How to build A+ runbooks”. It is a level 300 session around runbook design, how to build good looking runbooks that works in the real world. There will be a large number of System Center Experts speaking at the event, so bring all your System Center questions.

See you in Stockholm! More info about the event here.

Validate your runbook design – part III

I did some minor updates to the runbook this morning. I added a check for runbook duration, how many minutes a runbook took. Also added a check to see if the runbook have timeout configured. There is also some small updates to the report file.

You can download all runboks here, SCO_check_20110903-1_wolf. Please note that this is provided “as is” with no warranties at all. If you have any ideas what I should add, please post them as comment to this post or send me an e-mail. Also please note this is all based on my ideas and is not a “Health check” or Microsoft official guidelines.

Validate your runbook design – part II

I made some updates to the “SCO Check” runbook posted in this post.

  • Updated the report. I added some color and a better format of the information
  • Added 4.6.1 Statistics to give you a summary of your runbooks and the result of each instance of them, for example how many times it has failed.
  • Removed the check that looked for links with default names, updated 4.5.1 to include that too
  • Updated 4.5.1 Default Names to check all activites we use in runbooks against all activities in the database, to find activites with default names
  • Some other small updates

You can download all runboks here, Export File. Please note that this is provided “as is” with no warranties at all. If you have any ideas what I should add, please post them as comment to this post or send me an e-mail. Also please note this is all based on my ideas and is not a “Health check” or Microsoft official guidelines.