The last week I have been working on a way to handle logs for multiple runbooks in Orchestrator. Opalis and Orchestrator will executes but as soon as they are done, they will drop everything, and will not “remember anything”. They only keeps data in memory during execution (and maybe in some logs). That is one of the reasons why it is important to log to a external system when working with Opalis or Orchestrator. You most likely want to store information in a external system so you can go back and review it later, for example what triggered the runbook to start, what files was it moving and with which parameters? Some scenarios can be solved by using Service Manager and change management. When someone submits a change, you will have all the information in the change request, that will trigger Orchestrator. But there will not always be a change request, you could then use for example a SQL database that each runbook writes to. In this blogpost I share some ideas around logging to a SQL database. I will use the Orchestrator beta build but most of this you can build exactly the same in Opalis.

In this example I have a runbook that creates the database I will use to store logs. Of course you can create the database manually, but it is easy to keep it in a runbook, easy if you copy the runbook to a new environment. Then you know that the database will be setup the same every time. The “Create LOG Database” runbook looks like

1. “Create log database”, creates the log database. If it works there is a 10 sec delay on the link before tables are created. If it doesn’t work it will go to 4
2. “Create tables”, creates tables in the database. If it works it will move on to 5, else it will go to 3
3. “Drop db”, deletes the database
4. “Error Event”, writes a platform event saying that the database or tables could not be created
5. “Get timestamp”, gets the current timestamp in a suitable format
6. “Insert test event”, test insert a event in the database
7. “Write Error Event”, if the test insert activity don´t work a platform event is generated
   
8. “Send OK event”, a platform event is generating saying the database has been created
9. Get a timestamp in correct format. I notice when I was moving this runbook between environment that the default time stamp is different, so I use this activity to format the data format to yyyy-M-d h:m:s
10. Insert a test event into the database
11. Send a platform event saying the database is created

After the database is created and is working we need to create the runbook that will add events to the database.  In the picture there is a example of a runbook that writes log data to the log database, the “write to log runbook”. When you trigger this runbook you need to send some parameters,

• Runbook, name of the runbook that trigger the log runbook
• Description, description of the event, for example “Service can´t start”
• Runbook Process ID, the process ID of the runbook module
• Severity, how serious is the issue. Try to use a standard here, like INFORMATION, WARNING and CRITICAL

If the severity is Critical there will be an alert generated in Operations Manager direct. Then the runbook creates a suitable time format. Next step is to insert the data into the database. As you can see in the picture below we insert all the data that was sent from the runbook that triggers this runbook.

If the runbook cant insert event into the database an Operations Manager alert will be generated and also a platform event. So we have the database setup and we have a runbook that insert events into the database. How do we use all this? We use the Invoke Runbook activity! Below I have a runbook that loooks for new files in a folder and then copies them and moves them around. I have a number of Invoke Runbook activities that triggers the “write to log” runbook when there is something that needs to be in the log. As you can see in the image I forward data from this runbook to the “write in log” runbook, like the description and severity. This is the info that will be written in the database.

Your runbooks will now write logs to a common database. You can review the database with any tool to see how everything has been working and if you need to review some parameter or some variable value, you can simple look in your database (presuppose that you wrote it there :)). If you want to change how to store logs you can change one place, the “write to log runbook”, and you don’t need to modify all your runbooks. If you want to trigger alerts or incidents you can also do that simple in the “write to log runbook” instead of modify all your runbooks. Remember that Opalis and Orchestrator “only” executes, you need to store your data somewhere else if you want to read it after the runbook/policy is done.

In this blog post I will show you how to build two custom activities based on PowerShell commands. I will be using the Orchestrator beta and Quick Integration Kit 3. The Quick Integration Kit (QIK) enables you to extend your library of activities, with new custom integration packs and activities. QIK features a Command Line Interface (CLI) Wizard that allows you to describe how to run Command Line Interfaces (such as Windows Commands, SSH or PowerShell) and capture their output as Published Data. The QIK CLI Wizard provides a mechanism for very rapidly producing activities without the need for programming, given the readily available libraries of PowerShell from Microsoft and other community sources. In this blog post we will build two activities, one for counting files in a folder and one for list all files with a specific extension (for example mp3 files) in a folder. We will use QIK CLI that will help us build an integration pack (IP) around in this scenario two PowerShell commands. Let´s start with the one counting files

1. Start Opalis QIK CLI. After default installation of QIK there will be a shortcut on your desktop
2. Welcome to the Opalis QIK CLI, click Next
3. Assembly QIK CLI, input a name for example ContosoFileAssembly
4. Assembly QIK CLI, browse and input where the file will be created, for example C:\TEMP\FILEIP\ContosoFileIPAssembly.dll
5. Assembly QIK CLI, click Next
6. Commands, click Add…
7. Add/Edit Command, General, input
   1. Name: Count Files in Folder
   2. Mode: Run Windows PowerShell
      
8. Add/Edit Command, Arguments,
   1. Click Add under Parameters
   2. Add/Edit Parameter, input
      1. Name: Folder
      2. Usage mode: Command Argument
      3. Display Style: Folder
      4. Echo as published data: Check
      5. Click OK
         
   3. Add/Edit Command, Arguments, input “get-childitem $(Folder) | measure-object -property length” as command line. Click OK
      
9. Add/Edit Command, Published Data, click Add
   1. Add/Edit Published Data, input
      1. Name: _Count (We use _ in front of all object-specific published data, then it is easier to see it in the list of published data when working in the console. Thanks to Robert Hearn for that tip)
      2. Property: Count
      3. Description: Number of files in folder
      4. Click OK
         
10. Add/Edit Command, Published Data, click OK
11. Commands, click Next
12. Click Finish

We now have a dll file, a .NET assembly. We can now use the invoke .NET activity in the QIK IP to test the DLL before we build the IP. Start the System Center Orchestrator Runbook Designer and build a simple runbook to use the Invoke .NET activity and a Send Platform Event activity. To get the Invoke .NET activity you need to import the QIK IP. It is located at C:\Program Files (x86)\Opalis Software\Quick Integration Kit 3\Integration Packs after default QIK installation. Don’t forget to input a folder under Properties of the Invoke .NET activity. Configure the Send Platform Event activity to publish the count data from the Invoke .NET activity. Run the policy and verify that you get a result in the Send Platform Event activity.

Time to add the second activity, that should list all files with a specific extension in a folder.

1. Start QIK CLI again, on the Welcome screen, click “Load from QIK CLI Assembly” and select your dll file (C:\TEMP\FILEIP\ContosoFileIPAssembly.dll)
2. Assembly Details, click Assembly Information and raise version to 1.0.0.1. Click OK
3. Assembly Details, click Next
4. Commands, click Add…
   1. Input the following settings
      1. General, Name: List specific files in folder
      2. General, Mode: Run Windows PowerShell
      3. Arguments, Parameters, add
         1. Name: Folder
         2. Usage mode: Command Argument
         3. Display Style: Folder
         4. Echo as published data: Check
      4. Arguments, Parameters, add
         1. Name: File Extension
         2. Usage mode: Command Argument
         3. Display Style: Text
         4. Echo as published data: Check
      5. Arguments, Command Line, input “(Get-childitem $(Folder) | where {$_.Extension -eq ‘$Extension)’})
         
      6. Published Data, add
         1. Name: _Fullname
         2. Property: fullname
         3. Description: File path
      7. Published Data, add
         1. Name: _Name
         2. Property: name
         3. Description: Name of the file
      8. Published Data, add
         1. Name: _Length
         2. Property: Length
         3. Description: File size
      9. Published Data, click OK
         
   2. Commands, click Next
   3. When the wizard complete successfully you can can test the new command in the console with the .NET Invoke activity. Else, to build the integration pack, click Build Integration Pack. It is the same wizard that you can start direct from the shortcut “QIK Wizard”
5. Opalis Quick Integration Kit Wizard, product details, input
   1. Category Name: Contoso File Management
   2. Manufacturer: Contoso
6. Opalis Quick Integration Kit Wizard, product details, click Next
7. Opalis Quick Integration Kit Wizard, objects, click Next
8. Opalis Quick Integration Kit Wizard, dependencies, click Next
9. Opalis Quick Integration Kit Wizard, Opalis Integration Pack File, input where to create the IP, for example C:\TEMP\FILEIP\ContosoFile.oip . Click Next
10. Opalis Quick Integration Kit Wizard, The QIK Wizard Succeeded, click Finish

Now, use the Deployment manager to register IP with Orchestrator Management server and deploy IP to runbook servers and runbook designers. You can then use your new integration pack and activities in runbooks 🙂

Please note that this is provided “as is” with no warranties at all. If you want to take a look at my demo files send me a e-mail, I will upload them after some extra activites has been added. Download QIK here.

Today I was building a runbook including a Send Exchange Email activity. Unfortunately it didn’t work, instead I had to troubleshoot for a moment. The error was “Error initializing MAPI”. This activity use a Outlook profile, so you need to have Outlook installed on the runbook server/action server that is going to execute the runbook/policy. In my case I had Outlook 2010 installed. Here are some of the things I checked to find the missing configuration, outlook profile on the action server for the correct service account 🙂

• Make sure you spell the Outlook profile name correct, else you will get a error saying it cant find the profile
• Make sure that Outlook profile exists on the action server that is going to run the runbook/policy. It needs to exist for the account that is executing the activity. In my case the action server service account. To make sure the profile exists, and to create it, logon to the runbook server/action server, start control panel, configure the profile. Then also start Outlook to make sure the profile is working.
• Make sure you execute the runbook/policy on the correct action server, where the service account has the Outlook profile
• Verify if the “Task fails if an attachment is missing” check box should be checked. If it is, and there is no attachment, the Send Exchange Email activity will fail.