www.contoso.se

Cloud and Datacenter Management by Anders Bengtsson

Dynamic approval steps in Service Manager with a bit of Orchestrator magic

In Service Manager we can configure an approval step with “Line manager should review”. That means that the manager for the user who created the for example service request needs to approve. The manager is configured on user account in Active Directory.  This works dynamic and fine as long as it is actually the manager that needs to approve. But what if we request a service and the approver depends on who is requesting the service and what kind of settings of the service? Then we can’t use the “line manager should review” feature and we don’t want to create one template for each possible scenario.

In this blog post I will show how you can build dynamic approval steps in Service Manager together with Orchestrator. I will use Orchestrator and Service Manager 2012, but it works almost the same in Service Manager 2010 with the Service Manager Integration pack for Orchestrator or Opalis. The really cool thing is that we use a runbook to update an approval step within the same service request.

In my scenario engineers can request temporary permissions from the Service Manager self-service portal. Instead of engineers have accounts with all permissions that they can possible need, they need to request permissions when they need it, and the permissions are removed after X hours. If we lose an account it doesn’t have any permission after X hours and no engineer will have an account with too much permission.

High level steps

1. Engineers request permissions for a system from the self-service portal. The engineer fills in a form with all needed information based on a service request template. The engineer can select system from a drop down menu.

2. The service request template includes tree steps

2a. Update manual approval step (Runbook)

2b. Manual approval step (Default approval step in Service manager). This approval step is blank, no configuration by default. Instead it is the first runbook activity that updates this approval step with reviewers.

2c. Grant engineer permissions (Runbook)

3. The first runbook activity in the template run and update the approval step with suitable approval group based on which system the engineer request permission. For example if the engineer have request permissions to Exchange the manual update step will be configure with the Exchange Expert Team group.

4. An expert team approves the request. This step is blank in the template; the previous runbook activity will add a security group as reviewers depending on the permissions that were requested.

5. The second runbook activity run and adds the engineer to a suitable security group in Active Directory depending on what kind of permissions that was requested. The runbook also writes a log to a log database and updates the service quest with the result.

6. The engineer can track the service request during the process and also see the result of the service request in the self-service portal

 

Let’s look at the runbooks

 

This first runbook starts with the runbook activity ID; it then gets the related service request. After that it maps the service the engineer input to a security group in Active Directory. After that it finds related Review activity and creates a related reviewer object. It then gets the group of reviewers from the CMDB and creates a relationship between the new reviewer object and the group from the CMDB. The second runbook is the runbook that will grant the engineer permissions. It starts after the manual approval step that the first runbook configured.

The second runbooks goes from runbook activity ID to service request, and then it gets the requesting user from the input in the Service Request. The runbook creates a time stamp plus the number of hours that the engineer requested permissions for. Then it maps the service in the service request to a security group in Active Directory and adds the user to the group, it then writes the settings to a log database. The last activity triggers next runbook. This runbook updates the service request with the result.

Looking at the process from the self-service portal it will look like

The runbook that grants permissions to the engineer writes all settings to a database. This database will be used to figure out when it is time to remove engineers from security groups again.  The database in my example is very simple, see picture. You can schedule a runbook like the one below to Query the database every X minute to see if there is any expire date passed, and if there are the user will be removed from the security group. You can also use this database as source for a report showing current temporary permissions. You can use SQL Report Builder to build a report like that, download Report Builder here.

None of my example runbooks have any activities for error handling; please see this blogpost for more info around fault tolerance in runbooks. I have not uploaded an export file of these runbooks, as it is a lot of values to re-configure in every environment. Instead I have uploaded a ZIP file,  20120319, with screenshots of all settings in all activities.

 Please note that this is provided “as is” with no warranties at all.

« »

© 2019 www.contoso.se. Theme by Anders Norén.