Process automation with System Center Service Manager and Orchestrator – onboarding a new user

  • Article

System Center Service Manager 2012 R2 and Orchestrator are great and powerful tools when it comes to "service management" and "automation". Their full potential can only be revealed when they are combined.

I have been given the task to automate a common process, often seen in IT environments – the on-boarding of a new user.

Task requirements: A customer has revised the internal process for creating new user accounts. It has been concluded that the process is very time-consuming and there are too many people involved in the process of the user creation. Prior to the implementation of the solution, the process looked like this:

  • The personnel manager of the respective department gathers personal data of the new user (first name, name, addresses, contacts, workplace, etc. ) and forwards it to the higher management by e-mail;

  • The respective manager and a member of the human resources department have to confirm that the new user has a valid employment contract;

  • The IT support team receives a task by e-mail to create a new user account in Active Directory and to join it to the appropriate security groups. Depending on the user’s first and last name, his home share has to be created on a different file server. The IT support team informs the exchange team about the new user account and sends the initial password to the manager by e-mail. The Exchange team creates a mailbox for the new user.

  • The department “Infrastructure” receives the information about the new user by e-mail. The “Infrastructure” staff will now deploy the required hardware (computer, monitor, etc.) and other devices for the new user.

And now to the solution. It includes an Orchestrator runbook, service request templates including several review activities, requests and service offerings. But first, some requirements have to be met for this solution work: System Center Service Manager and Orchestrator must be integrated with Active Directory and an Exchange connector must be configured and running in Service Manager.

I will present one possible solution, but there are also other approaches to fulfill the requirements for this task, as you can see here:

System Center 2012 Service Manager and Orchestrator Integration Example Walkthrough Start-to-Finish – New Hire Provisioning Service Request

After completing my primary studies I have identified the following challenges:

  • The process for creating the mailbox and mapping the home share drive follows a certain logic and can only be achieved with PowerShell scripting. The default activities included in Orchestrator’s “Create User” (Active Directory Integration Pack) and “Create Mailbox” (Exchange Integration Pack) don’t offer the functionality I needed. Although there are several third party Integration Packs available with more functionality I have decided to use process PowerShell in this particular case.

  • Due to the fact I have used PowerShell remote sessions, initialized from Orchestrator to the domain controllers and exchange server, I had to find a way to publish some of the variables on the Orchestrator data bus. This was essential, so that the variables could be available for use in the following activities. Usually the variables are only available for the duration of the PowerShell session.

  • The “Runbook Automation Activity” template in SCSM Self-Service Portal does not offer enough parameter mappings to cover the customers’ requirements. In addition to the standard parameters, I needed additional five “string” and several “Boolean” parameters.

  • In Self-Service Portal, the creator of the new user should have the possibility to join the user to company role based security groups.

Here is the implementation of this solution, explained step by step:

**1. Preparing the Orchestrator runbook
**

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture.png**
**

The Orchestrator runbook includes the following activities:

Initialize Data

This activity includes the required parameters that have to be entered via the Self-Service Portal:

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture1.png

Important: Those runbook parameters should not be changed once the synchronization of the Orchestrator connector in Service Manager has completed. Otherwise, the corresponding runbook in the “Runbooks” library in Service Manager will change its status to “invalid” and will have to be deleted. In such cases the runbook has to be resynced and the parameters within the runbook automation activity will have to be re-mapped.

Get Group Relationship, Get Group Object, get Parent SR Relationship, Get SR Object

Those activities are part of “System Center Integration Pack for System Center 2012 Service Manager” and are used to identify the relationships between the service request in Service Manager, the Active Directory group and runbook automation activity. After getting those objects it is possible to automatically join the new user account to the Active Directory security group selected in Self-Service Portal. Travis Wright has written a very useful blog article about the complexity and functionality of those activities:

Working with Relationships in the SCSM Orchestrator Integration Pack

There is another article written by Bob Roudebush. He explains the configuration of each activity and provides detailed hints on how to set up requests and service offerings:

Add User to Group Automated Request Offering Walkthrough

Generate User Password

This activity is part of “Active Directory Integration Pack for System Center 2012 – Orchestrator”. It is used to set up the required complexity of the new user’s initial password.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture2.png

Create and Enable the User

This “Run .Net Script” (PowerShell) represents the core script of the runbook. I have modified the script to fulfill several requirements:

  • The SamAccountName will be automatically created based on the first name and name of the new user. Therefore the script has to check, whether the new user’s full name is unique in the domain. If not, the script will add numbers to the SamAccountName (as required by customer). Furthermore, umlauts (ä, ö, ü, etc.) will be replaced by „a“, „o“ or „u“.

  • The new user’s account will be created in the AD organizational unit, corresponding to the input field “Department”, which is selected on the Self-Service Portal.

  • The user’s home share drive will be created according to the user’s first and last name.

  • Account attributes, like address, phone numbers, websites, fax number and more will be set.

  • The initial password, which was created with “Generate User Password” will be set. The new user has to change it when he logs in for the first time. (ChangePasswordAtLogon:$true)

Due to the fact that I have worked via PowerShell remote sessions, some of the variables ($UPN, $Alias, $Identity) were unavailable for future activities as soon as the remote sessions was closed. I had to find a way to publish these variables locally on the Orchestrator data bus and ensure I can use them in the following activities. This is also pretty easy to achieve.

The variables had to be defined within the “Run.NET Script” activity:

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture3.png

To ensure their availability outside the PowerShell session, some small adjustments had to be done to the script:

1.Invoke-Command -Session $PSSession  -ScriptBlock{…} #PS-Remote session
2.$SamAccountName = Invoke-Command -Session $PSSession -ScriptBlock { $SamAccountName }
3.$UPN = Invoke-Command -Session $PSSession -ScriptBlock { $UPN }
4.$Alias = Invoke-Command -Session $PSSession -ScriptBlock { $Alias }
5.$Identity2 = Invoke-Command -Session $PSSession -ScriptBlock { $Identity2 }

You can use the “Runbook Tester” to check the if your variables are available outside the PowerShell session for the next activities (Assign a Mailbox to the User, Get User, Add User to Group, etc.).

Assign a Mailbox to the User

This “Run .Net Script” (PowerShell) activity creates the mailbox. Based on the first letter of the user’s name, the mailbox will be created on the appropriate mailbox database (total of three databases).

 

Get AD Group

This activity is also part of “Active Directory Integration Pack for System Center 2012 Service Manager” and gets the properties of the security group, to which the new user has to be joined. This is achieved by the following filter:

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture4.png
**
Name:** Sam Account Name
Relation: Equals
Value: {User Name from “Get Group Object”}

Get User

This activity gets the user, which will be joined to the security group. This is also achieved by a filter and the variable “$SamAccountName”, created in the “Run.NET Script” activity “Create and Enable the User” presented above.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture5.png

**
Name:** Sam Account Name
Relation: Equals
Value: {SamAccountName from “Create and Enable the User”}

Add User to Group

This activity is part of “Active Directory Integration Pack for System Center 2012 – Orchestrator” and joins the user to the required security group.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture6.png

Send Email

This activity is part of “Exchange Users Integration Pack for Orchestrator in System Center 2012” and is intended to send an e-mail to the configured recipients. In my case I had to use three different activities for different mail contents and recipients.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture7.png

Error handling

I have implemented a simple error handling mechanism, which ensures that the responsible person will receive an e-mail alert, in case one of the activities fails. You can modify this in the link properties, so that an e-mail is sent if the respective activity returns the status “failed”.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture_0.png

Of course, you can create your own error handling, based on your particular requirements.

2. Runbook automation activity configuration

Once the runbook was ready, the synchronization through the Orchestrator connector and ensured that the runbook is available under “Library -> Runbooks” and has also the status “active”. Based on this runbook, I have created a runbook automation activity template and have saved it in an unsealed custom management pack. The template is then available under “Library -> Templates”.

The most important is to check “Is Ready for Automation” option in the template’s General properties. If left unchecked, the runbook automation activity within the service requests will not trigger this runbook:

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture8.png

The next step is to assign the parameter mappings in the tab “Runbook”:

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture9.png

At this point I was confronted with the following challenge: The “Runbook Automation Activity Form” does not offer enough parameter mappings to cover all the parameters defined in my runbook. Per default, the Service Manager provides 10 “Text” (Text 1 – 10) and 5 “Long Text” (Long Text 1 – 5) mappings. With the help of the Service Manager Authoring Tool, I was able to modify the “Runbook Automation Activity” class in SCSM by adding more “String” (Text 11, Text 12 – 20) and also “Long Text” (6 – 10) properties. As a result of the extension, the “Runbook Automation Activity Form” now showed enough properties to map all the required runbook parameters from the “Initialize Data” runbook activity.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture10.png

Here it is pretty important to write down the exact mappings, you have configured (e.g. First Name -> Text1, Name -> Text2, etc.), as later on, when creating the request offering they must be recreated in the same way.

**

  1. Creating the service request template**

The next step is to create the service request template. When filling out the service request form in the self-service portal for creating a new user, this template generates a service request for each new user. It also includes the required approval activities for the request – approval of the manager, the human resources department and the IT-Support. After all three level of approval the “Provision New User Runbook Activity” fires and triggers the runbook, which then creates the user.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture11.png

Like in the properties of the “Runbook Automation Activity” you can modify the fields “Urgency”, Priority”, “Source” and “Area” according to your requirements. 

The “PVA Review Activity” is the most interesting activity, because the option “Line Manager Should Review” is enabled. This option needs a proper synchronization of the configuration item (user, computer, printer, etc.) from Active Directory over the Active Directory Connector in Service Manager. Based on the “manager” attribute of the user’s account, filling the new user account form on the Self-Service Portal, the activity knows to which manager the approval request has to be sent to.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture12.png

Opposite to the “PVA Review Activity”, the other two review activities (“Personal Review Activity” and “IT Support Review Activity”) have static reviewers in the “Reviewers” field.

The “Provision New User Activity” will only start the runbook when all three instances have approved the request.

Here it is time to mention how you can leverage the Exchange Connector for Service Manager to send e-mail to all reviewers and let them “Approve” or “Reject” the respective service request. You just have to configure workflow for the review activity (Administration -> Workflows -> Configuration -> Activity Event Workflow Configuration -> Review Activity”, which sends an e-mail every time the status of the review activity changes from “does not equal – in Progress” to “equals – In Progress”. For the purpose you have to ensure that the workflow triggers on “when an object is updated”.

For the mail I have used html based notification template, which contained all the needed information for the approver. Furthermore, the template created two keywords, used by the Exchange connector to update the respective review activity. So the approver needed to click on:

  • Approve and a mail with the keyword [Approved] is sent. As a result the respective activity gets approved only by mail from the reviewer.

  • Reject and a mail with the keyword [Rejected] is sent. As a result the respective activity gets approved only by mail from the reviewer.

This is especially effective when you don’t want to force your reviewer to logon to the Self Service Portal or use the Service Manager console to initiate further actions.

You can take a look at the example provided here:

Tricky Way to Handle Review Activity Approvals with the Exchange Connector

If you need ideas on how to create better notification templates you can refer to the following guide:

Creating Notification Templates in System Center Service Manager**

  1. Prepare and publish request offerings**

A request offering is defined as follows:

“Request offerings are catalog items that describe the item, assistance, or action that is available to end users in the service catalog in System Center 2012 – Service Manager. Request offerings are normally placed in logical groups of service offerings. Both service offerings and their request offerings are available to Self-Service Portal users when the status of the offerings is set to “Published” and if end users have been assigned a corresponding Service Manager user role."

*Source: Microsoft TechNet

*

So, a request offering defines what input is needed from the Self-Service Portal user and which information the user gets back. Some input fields are self-explanatory (i.e. title, description, etc.), so I would like to tell you more about the specifics of some of the other mandatory prompts, which need to be filled out by the user on the Self Service Portal. The first step is to define the necessary fields (first name, name, division, etc.) and the related prompt type (text, simple list, date, true/false, query results). Afterwards you have to configure them individually.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture13.png

This is how the configuration of a string looks like:

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture14.png

For further information regarding string configurations, I would recommend the Microsoft blog article written by Neil Lydickg:

Request Offering Wizard Overview

In our case, one of the most interesting configuration represents the user prompt ”Role” (prompt type “query result”). This prompt will query the security group in Active Directory of which the new user will be a member. When you select “Role” and click on “Configure” it will open a wizard. I would like to explain the configuration of that wizard:

  • “Select Class”

“Domain User or Group” is the target class for the query.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture15.png

  • “Configure Criteria (optional)”

I have limited the query output by adding the criteria “Display Name contains ROLE”, because all relevant security groups contained the word “ROLE” in the display name and wanted to get only them in the query result field on the portal.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture16.png

  • “Display Columns”

This option lets you choose the displayed columns.  I have chosen the format “Domain\Display Name”. The minimum is “Display Name”.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture17.png

  • “Options”

The query result (security group) must have a relationship to the service request template (related item) and to the runbook automation activity. This can be achieved by selecting the options as shown in the picture. Otherwise the runbook activity “Get Relationship” will not be able to get the desired relationships.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture18.png

The next important step in the creation of our request offering is the mapping of the prompts displayed in Self-Service Portal. These mappings must be configured exactly in the same way as depicted in “Runbook automation activity configuration” before. This is also the reason why it is a good idea to write them down the first those are configured.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture19.png

Finally we optionally can add a knowledge article to the request offering and change the status to “Published”. Request offerings with the status “Draft” will not be available on the Self-Service Portal.

**5. Publishing the service offering

**

As I have already mentioned, a service offering can contain several request offerings and displays them on the Self-Service Portal in a logically grouped view. To publish a service offering on the Self-Service Portal we need to set its offering status to “Published” as we did with the request offering too.

https://blog.pohn.ch/wp-content/uploads/2015/04/Capture20.png

Once the service offering is published, it appears on the Self-Service Portal. When selecting the service offering you will see the containing request Offerings.

Now the Self-Service Portal user only needs to fill out the request form for a new user account, send the request and wait for the approvals. The rest will be automatically handled by Service Manager and Orchestrator.

This automated process creates economical, technical and functional added value for the customer. In addition to the time and cost savings, this automated process ensures the creation of the users is done the same way every single time and is also a way to eliminate manual input errors.