www.contoso.se

In this post I want to share with you some ideas around auditing in Orchestrator. When Orchestrator gets more and more integrated into your IT environment auditing and change control within Orchestrator also gets more important. In Orchestrator you have a couple of different ways to do this. You have the possible to enable audit trail. Audit trail is a number of text log files that contacts information about activities in runbooks and who started which runbook. Depending on how your runbooks are working the audit trail log files can grows very large and consumes a large amount of disk space. If you enable audit trail you should also plan how to archive and purge these log files. To enable or disable audit trail follow these steps

1. On the Orchestrator management server open a command prompt and change folder to the Management Server folder in the Orchestrator installation folder , default  C:\Program Files (x86)\Microsoft System Center 2012\Orchestrator\Management Server
2. Run “ATLC.EXE /enable” to enable audit trail or run “ATLC.EXE /disable” to disable audit trail

In the Orchestrator Runbook Designer you can also see some auditing information. In the console there is an Audit History tab for each runbook. In the Audit History tab you can see all changes to a runbook, for example who change the name of an activity. Below there is figure that show an example of Audit History information. The information shown in the Audit History tab is a mix of data from two tables in the Orchestrator database, the OBJECT_AUDIT table and the CHECK_IN_HISTORY table.

To review all changes to objects in the Orchestrator database, for example a new setting on a activity run the following SQL query against your Orchestrator database. Note that the SQL query only show objects that have DELETED equals “0″, the SQL query only show objects that are non-deleted. You can change this setting if you want to see changes also to objects that are deleted.

SELECT P.Name AS [Runbook Name], O.Name AS [Activity Name], OT.Name AS [Activity Type], OA.Action,
CASE WHEN OA.Attribute LIKE '%[0-F][0-F][0-F][0-F][0-F][0-F][0-F][0-F]-[0-F][0-F][0-F][0-F]-
[0-F][0-F][0-F][0-F]-[0-F][0-F][0-F][0-F]-[0-F][0-F][0-F][0-F][0-F][0-F][0-F][0-F][0-F][0-F]
[0-F][0-F]%'
 THEN 'NEW ACTIVITY' ELSE OA.Attribute END AS Attribute, OA.OldValue, OA.NewValue, CIH.DateTime AS
 [Change Timestamp], S.Account AS [User]
FROM OBJECT_AUDIT AS OA INNER JOIN
 OBJECTS AS O ON OA.ObjectID = O.UniqueID INNER JOIN
 POLICIES AS P ON O.ParentID = P.UniqueID INNER JOIN
 OBJECTTYPES AS OT ON OA.ObjectType = OT.UniqueID INNER JOIN
 CHECK_IN_HISTORY AS CIH ON CIH.UniqueID = OA.TransactionID INNER JOIN
 SIDS AS S ON CIH.CheckInUser = S.SID
WHERE (O.Deleted = 0)
ORDER BY [Change Timestamp] DESC

Thanks to Fanjoy and Ahrens for SQL query support.

A runbook is executed with the Orchestrator Runbook Service service account. In most scenarios that are not an issue. But in some scenarios you need a runbook to run with a specific account, and all other runbooks run with the default service account. This can be done with an extra Runbook Server that uses another Runbook Service service account, or per activity or it can be solved at design level in the runbook by using the Invoke Runbook activity. To configure a runbook to run with a specific account, please see this post.

Specifying an account on each activity requires a lot of administration. If you need to specify the same account on multiple activities it is recommended to use variables. Variables minimize the risk of incorrect input and also make updates much easier. In Orchestrator 2012 you can configure a variable to be encrypted. If you store a password in a variable it will not be shown or stored in clear text, instead it will be encrypted.

If you want to see all activities in your Orchestrator environment that is not using the default service account you can run the following query

SELECT OBJECTS.Name AS Activity, OBJECTS.ASC_Username, POLICIES.Name AS Runbook, OBJECTTYPES.Name AS [Activity Type]
FROM OBJECTS INNER JOIN
POLICIES ON OBJECTS.ParentID = POLICIES.UniqueID INNER JOIN
OBJECTTYPES ON OBJECTS.ObjectType = OBJECTTYPES.UniqueID
WHERE (OBJECTS.Deleted = ’0′) AND (OBJECTS.ASC_UseServiceSecurity = 0)

In this post I will show you what you need to configure to allow engineers connect remote to the Orchestrator environment without Orchestrator administrator permissions. After Orchestrator installation we have one security group, the Orchestrator User Group. If your Orchestrator environment is in an Active Directory domain you should use an Active Directory security group as the Orchestrator User Group. The Orchestrator User Group has full access to the Orchestrator environment. If you enabled remote connection during installation, members of the Orchestrator User Group can also remote connect to the Orchestrator environment, for example run the Runbook Designer console from a workstation. A common scenario is that other engineers and experts need access to the Orchestrator environment too, for example the Service Manager team wants to author some runbooks. At the same time the Service Manager engineers should not have access to every runbook, only runbooks created by the Service Manager team. In other Words you cant add the Serivce Manager team to the Orchestrator User Group. To solve this we need to perform the following steps

• Assign general Orchestrator permissions to a “Orchestrator Remote Users” security group. There are a number of general permissions that everyone that will work with Orchestrator remote needs. We will assign these permissions to a Orchestrator Remote Users group. By using one general group for this kind of permissions the administration gets a bit easier. In this example my group is named SKYNET\grp-sco-remoteusers.
• Assign specific Service Manager team permissions to a “Service Manager Team” security group. We will most likely have more teams then the Service Manager team working with runbooks. Each team will need specific permissions, which will result in one specific security group for each team. In this example my Service Manager team group is named SKYNET\grp-sco-scsmteam.

We will start by assign the Orchestrator Remote Users Group suitable DCOM permissions

1. On the Orchestrator Management Server, start Component Services from the start menu
2. In the Component Services console, expand Component Services, expand Computers and expand DCOM Config
3. In the list of DCOM applications scroll down and select omanagement. Right-click the omanagement DCOM application and select properties from the context meny
   
4. In the omanagement Properties window, click the Security tab
5. Click Edit in the Launch and Activation Permissions area, click Add and add the grp-sco-remoteusers security group from Active Directory. Assign the grp-sco-remoteusers security group Remote Launch and Remote Activiation permissions. Click OK
6. Click Edit in the Access Permissions area, click Add and add the grp-sco-remoteusers security group from Active Directory. Assign the grp-sco-remoteusers security group Remote Access and Local Access permissions. Click OK
7. In the Component Services console, right-click My Computer and select properties from the context menu
8. In the My Computer Properties box, select the COM Security tab
9. Click Edit Limits… in the Access Permissions area. Click Add and add the grp-sco-remoteusers security group from Active Directory. Assign the grp-sco-remoteusers security group Remote Access permissions. Click OK
10. Click Edit Limits… in the Launch and Activation Permissions area. Click Add and add the grp-sco-remoteusers security group from Active Directory. Assign the grp-sco-remoteusers security group Remote Launch and Remote Activation permissions. Click OK
11. Close the Component Services console 12. After all permissions are configured, on the Orchestrator Management server, start the Services console and restart the Orchestrator Management Service (ManagementService.exe ). If a user dont have correct DCOM permissions to access Orchestrator you will see a error message in the Runbook Designer console, like the one below

and on the Orchestrator management server you will see a event like this

All users that will work with the Orchestrator Runbook Designer console needs read permissions to the top level of the Runbooks folder navigation tree. To assign the grp-sco-remoteusers security group permissions to the root level follow these steps

1. Start the Orchestrator Runbook Designer console as an Orchestrator administrator
2. Right-click the Runbooks folder and select Permissions from the context menu
3. In the Permissions for Runbooks dialog box, click Add.. and add the grp-sco-remoteusers security group from Active Directory
4. In the Permissions for Runbooks dialog box, un-selected everything except Read as permissions for the grp-sco-remoteusers group
5. In the Permissions for Runbooks dialog box, click Advanced
6. In the Advanced Security Settings for Runbooks dialog box, select the grp-sco-remoteusers security group and click Edit…
7. In the Permissions Entry for Runbooks dialog box, change the Apply To drop-down menu to This object only
8. In the Permissions Entry for Runbooks dialog box, click OK
9. In the Advanced Security Settings for Runbooks dialog box, click OK
10. In the Permissions for Runbooks dialog box, click OK

Depending on your environment the different teams need different access to runbook servers. To assign the grp-sco-remoteusers access to all Runbook Servers follows these steps:

1. Start the Orchestrator Runbook Designer console as an Orchestrator administrator
2. Right-click the Runbook Servers folder and select Permissions from the context menu
3. In the Permissions for Runbook Servers dialog box, click Add and add the grp-sco-remoteusers security group from Active Directory. Click OK
4. In the Permissions for Runbook Servers dialog box, un-select all permissions for the grp-sco-remoteusers group except Read. Click Ok

Your different teams will also need access to Global Settings. To give the grp-sco-remoteusers security group permissions to list Global Settings follow these steps:

1. Start the Orchestrator Runbook Designer console as an Orchestrator administrator
2. Expand Global Settings, one by one, right-click Counters, Variables and Schedules. Select Permissions from the context menu
3. In the Permissions dialog box, click Add, add the grp-sco-remoteusers security group from Active Directory. Click OK
4. In the Permissions dialog box, select the grp-sco-remoteusers group and click Advanced
5. In the Advanced Security Settings dialog box, select the grp-sco-remoteusers security group and click Edit
6. In the Permission Entry dialog box, change Apply To to This object only, and select only List Contents and Read Properties permissions. Click OK
7. In the Advanced Security Settings dialog box, click OK 8. In the Permissions dialog box, click OK

You have now configured the grp-sco-remoteusers security group with general permissions to remote connect to the Orchestrator management server with the Orchestrator Runbook Designer console. The security group doesn’t have access to anything in the Orchestrator Runbook Designer console (except Runbook Servers), when a user in this group click for example Variables an error like the own below will show.

The next step is to configure permissions for the different teams, in this example the Service Manager team, group grp-sco-scsmteam. We will create a new Runbook folder where the Service Manager team can work with Runbooks.

1. Start the Orchestrator Runbook Designer console as an Orchestrator administrator
2. Right-click the Runbooks folder and select new folder
3. Name the folder Service Manager Team
4. Right-click the Service Manager Team folder and select Permissions from the context menu
5. In the Permissions for Service Manager Team dialog box, click Add and add the grp-sco-scsmteam security group from Active Directory. Click OK

By default all activities are executed with the account you have specified on the Orchestrator Runbook Service on your Runbook servers. In some scenario you need to configure a activity with a specific account, you can do that on the security tab on each activity.

But it is a lot of work to update each activity in the runbook with new security credentials information. What if you want to use the same runbook, but with different input parameters and different accounts? The solution to that could be to trigger the runbook with the Invoke Runbook activity and specify a account, instead of trigger the runbook direct. Then you can specify a account each time you trigger the runbook. In this example I have built two runbooks. Runbook A and runbook B.

Runbook A writes its credentials to a text file (command “whoamI” and writes pure output to C:\temp\Iam.txt) and triggers runbook B that does the same. The result will be a text file with two lines, both lines is SKYNET\svc-sco-sa. SKYNET\svc-sco-sa is my Orchestrator Runbook Server service account, and that is the account that executes runbooks by default in my sandbox.

If I now configure the Invoke Runbook activity, on the security credentials tab, to run with the SKYNET\andersbe account instead, we will see a difference in the result

As you can see the second runbook is now running with the SKYNET\andersbe account instead of the default account.

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.