User provisioning and management using #scsm and #scorch

I’ve been working on replacing our very manual user provisioning and management system for the last couple of months, and finally took it all to production in the last week. Before, we had a simple form in Sharepoint with some workflows in the backend to send emails, but users were provisioned manually by our server team. With all the admin that goes along with this process, it took around an hour per account – obviously not the best way to spend our server team’s time.

capture-20130621-132808In comes Service Manager, and Orchestrator in the backend, and changed the picture completely. We created the request offerings for user creations, as well as offerings around when users move in the organisation and when they leave the organisation. While this is by no means a full-fledged identity management solution or even a perfect solution, it has saved our server guys masses amounts of time already and works for our environment. I thought I would share some of my experiences and learnings from building ours.

Before you start building such a solution, it is very important that you draw the entire process out in Visio or similar. You need to identify every touch point and review point as early in your defining process as possible, because you will need to cater for each of these, either via an activity in the template or with an Orchestrator activity. You will want to identify the following, for example:

  • Who should review new user requests? Just the line manager, or do you have a HR or possibly security/compliance requirement too?
  • What kind of notifications should be sent, and at which intervals? What kind of information do you need to supply in the notifications?
  • What activities, other than creating the user account, can be automated or should form part of a new user take-on?

In our case, we have a couple of review activities (line manager, security, etc) and each department was very specific about the kind of information they need to see in order to approve a request. This information was required not only in the notification sent to them for new requests, but also in the review activity visible on the SSP.

For this reason, each kind of request uses at least 2 runbooks. The first runbook is triggered when a request is logged, and all it does is update the SR and review activities with this information and populate the Line Manager indicated in the request to the Line Manager review activity. The runbook looks a little like this:


I wrote here and here about creating the dynamic approval steps.

The request offering allows for the Line Manager of the affected user (new start/moving user) to be selected from a Query, and the Line Manager CI is then added to the Service Request as a Related item:


In the runbook, the link between Get Related User and Get User from CMDB is then configured like this:


Unfortunately, it is quite tricky to use just a Request Offering and a Service Request template to get the right information to display in the right way. This has been one of the biggest challenges I faced in building this solution, and figured that the best way to make things look the way we want them to is to manipulate the data a little with Orchestrator.

When we designed our forms, we were very aware of the kind of information required in the notifications, so we ensured that we collect all this information into the Service Request. We extended the SR class to include some custom fields so we can make sure we write that information somewhere safe. The runbook then retrieves this information, and updates the Service Request subject line and description with this information:


I also wanted to make sure I can configure the notifications as generic as possible using only the information that is easily accessible from the SR, and so wrote everything I could possibly want to translate into the notification into the SR in a way that will easily translate to a HTML email message. The end result is then a Service Request that looks like this:


And the resulting notification then looks like this:


If you are lucky enough (as I am) to have a separate development environment from your production environment and you build the entire solution in the dev environment, and then import the management packs from the dev environment into prod, you may run into some issues with the runbook activities in the SR templates. This is because the runbooks sync into each environment with different IDs and you will get an error like this:



You don’t need to recreate the runbook activity though, you can simply select the runbook from the catalogue (click on the Select button), update any mappings you may have and save.

bart-simpson-chalkboard-automationLastly, no solution is ever final, because as people discover the power of what you can do with the System Center suite, they will find new things for you to all the time. Just build in as much error checking as possible to make your own life easier and remember to look at things from different angles to find the best solution for your situation.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s