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.

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)

A way to get the Operations Manager group in sync with the machine list is to use a runbook that creates a management pack including a group based on the list. This set of example runbooks reads a list of machine, creates a management pack with a group that includes the machines. The list of servers could be generated by another runbook or another tool. The last runbook also imports the management pack into Operations Manager.

This first runbook execute the following steps. In general this runbook checks if the machines in the list has a Operations Manager agent, if they are monitored by Operations Manager

1. Delete File. Deletes old Machines_IDS.txt file if it exists. Machines_IDS.txt is used later in the runbook and needs to be blank before we begin
2. Get Lines. Read all lines in the list. The list is simple a text file with servers, one server per row
3. Get Monitor. Check if Operations Manager have a Microsoft.Windows.Computer monitor for the servers in the text file
4. Append Line. For each machine that has a monitor, we write the machine name to a temporary file. This is the same file as step one deleted any old version of
5. Junction. We merge multiple threads together
6. Invoke Runbook. Trigger next runbook

1. Delete File. Deletes old MP files
2. Modify Counter. We use a counter to keep track of the management pack version number. This step adds one to that counter value
3. Get Counter Value. Get the counter value for the same counter as in step 2
4. Append Line. This steps writes the first half of the XML code that needs to be in the management pack. The GroupInstanceID is a random ID that the Operations Manager console generated when I test created a group in the console. You could replace that and all the other names in the management packs.
   
5. Read Line. This step reads every machine that we wrote in the machine list in the first runbook, step 4,
6. Append Line. This steps writes all the machines from step 5 into the management pack file
   
7. Junction. We merge multiple threads together
8. Append Line. Writes the end of the management pack, some more XML
9. Invoke Runbook. Starts the last runbook and pass the path to the management pack file

The last runbook inports the management pack file into Operations Manager

The result is that each time you run this set of runbooks they will generate a new management pack version with a group that includes all the machines from your list, that has a agent. The management pack is imported into Operations Manager and you can use the updated group. You could include a step to seal the management pack too. You can download my runbook example here, 20120410_GroupSync_WOLF.  Please note that this is provided “as is” with no warranties at all.

The runbook is trigger by a task in Service Manager, input parameter is only the incident ID.

1. Initialize Data. Input parameter is IncidentID. ID of the incident we want to “convert” to a service request
2. Get Object. Gets the incident from Service Manager. This step also verify that the incident don’t have Closed as status
3. Send Platform Event. If the incident is closed or cant be found a platform event is generated. For example if you trigger the runbook with a incorrect incident ID from the Orchestrator console it will not run
4. Get Relationship. Gets related Active Directory User to the incident
5. Get Object. Gets the user that step 4 found
6. Create Object. Creates a new service request and writes info to it from the incident
7. Create Relationship. Create a relationship between between the service request and the affected user (relationship type = user)
8. Create Relationship. Create a relationship between the service request and the incident (relationship class = is related to work item)
9. Format Date/Time. Gets the current time stamp in a correct format, will be used when creating comments on the incident and the service request
10. Run .NET Script. A small PowerShell script that generates a GUID. The GUID will be used as ID for the incident comment
11. Create Related Object. Creates a Trouble Ticket Action Log (action log comment) on and relates it to the incident. The runbook writes a comment saying the incident has been converted to a service request (relationship type = Trouble Ticket Has Action Log)
12. Update Object. Resolve the incident, change status to Resolved
13. Run .NET Script. A small PowerShell script that generates a GUID. The GUID will be used as ID for the service request comment
14. Create Related Object. Creates a Trouble Ticket Analyst Comments (log comment) and relates it to the service request. The runbook writes a comment saying the service request was based on the incident
15. Send Platform Event. Writes a platform event with service request ID and incident ID

That is the runbook, the next component is the task in Service Manager. We could trigger the runbook from Orchestrator console and input the incident ID manually, but it is easier with a task in Service Manager. In the Service Manager console, in the Library workspace you can create a new task with the following settings.

• General/Task name: Contoso - Convert Incident to Service Request
• General/Target class: Incident
• Categories/Categories: Incident Management Folder Tasks and Incident Support Groups Folder Tasks
• Command Line/Full path to command: C:\TEMP\ORT251\ORTRunbookLauncherCLI.exe
• Command Line/Parameters: /IncidentID=$Context/Property[Type='WorkItem!System.WorkItem']/Id$
  (the parameter is the work item ID that you can insert from the  ”Insert Property” button)

…the runbook runs and generates a platform event

…if we look at the incident it is now resolved and has a new comment

…also a relationship to the new service request

…and when look at the service request we can see that data has been copied over from the incident

Summary: We have built a task in Service Manager that use the Orchestrator Remote Tool to trigger a runbook. The runbook connects to Service Manager, copies the data we have in the incident over to a new service request, resolve the incident and update both incident and service request with relationships and comments.

You can download my runbook example here, 20120410_Incident2ServiceReq_WOLF.  Please note that this is provided “as is” with no warranties at all.

• 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