System Center 2012 Service Manager and Orchestrator Integration Example Walkthrough Start-to-Finish - New Hire Provisioning Service Request – SECOND EDITION :-)
Introduction
Check out this video which is a great intro to this blog: https://vimeo.com/144258397
Who said all sequels were rubbish?! 
This is the sequel to my first blog on this with some changes:
1) In this sequel, we use the OOB Relationships rather than Custom Relationships. I have learnt over time that using custom relationships can add complexities such as the object they are set to not being visible in the extensions tab, and not being successfully populated when added via a request offering in at least one of the 3rd party self-service portals out there. It also requires some xml editing to replace OOB relationshipIDs with custom relationshipIDs. And also these custom relationships will not show anywhere on a OOB form unless we add and expose them within OOB fields such as title and description.
2) This time we have added functionality where a manual activity is added by orchestrator if a given field is checked true. Dynamically adding a manual or review activity is a common requirement for a multitude of scenarios. In this blog we will use the example of a manual activity needing to be inserted for Hardware Provisioning.
3) Because we are not using Custom Relationships, we are no longer required to create a custom form to show these, so it makes it easier to go through this process as less XML editing is required. Myself and other PFE colleagues like to call this ‘INHERIT EXPRESS’… Think Starlight Express, but just a pinch less dramatic and entertaining . My colleague Brian Barrington is the father of ‘Inherit Express – check out his blog for some cool SCSM stuff here - https://blogs.technet.com/b/brianbarrington/
4) We add important details from the Service Request to the title and description of the child manual and review activities, in order to assist the implementer / reviewer with the approval / completion of those activities.
5) The Username is automatically created within SCORCH using the firstname.lastname. (It is understood in a real environment you may need some kind of checking and tweaking of this to account for 2 different people in your organization having the same first and last name, but the intent of this blog is more to show how all the moving parts integrate and work together so you can expand on the bare bones.
6) Department (a list property) is created in it’s own separate MP, because I have come across scenarios where we may want to use lists such as this for other scenarios, which may use separate MPs / types of classes. Creating it in a separate MP like this, allows us to refer to it, and use it in other MPS. For example here we’re working on a new hire onboarding SR, but then what if we create a separate class down the road for employee job transfer, we would likely want the same list of departments available.
7) I recently learnt another trick from my colleague Jay Wodka about just having a single folder sync over from SCORCH to SCSM to help prevent a disorganized sea of runbooks from all over the place in SCORCH, showing in one convoluted view in SCSM. So now my Orchestrator runbooks are kicked off by other runbooks stored in a master ‘sync / initiation’ folder. This also makes it easier to implement a solution like this in different environments that inevitable will have their runbooks organized in different ways
8) Removed Create Review Activity section as in the sequel here, we will just use the default RA template to create our approval activity.
9) Added Select Domain Query filter – Please select managers domain. See appendix I for details on this technique which offers a search and prevents the ‘please wait’ dialog from showing in the OOB portal whilst a large number of results are queried and returned.
This will be / was demo’d at the Cireson Innovate conference on 10/8/15. Here is the recording - https://vimeo.com/144258397
NOTE: I have included SEQUEL NOTES through this post to easily help you distinguish differences between this and the first edition.
SHOUT OUTS: Here in Premier Field Engineering (PFE) we are a close team, so I wanted to give thanks and shout outs to BRIAN BARRINGTON (the inherit-express daddy), Chris Howie (the godfather of form authoring and many other SCSM internals) Rob Davies for his SCSM <> SCORCH sanity checking wisdom and also Jay Wodka for his SCORCH wisdom.
If this blog helps you, or you have any feedback, please leave comments.
Scenario
Alright so here goes. Grab the popcorn out of the microwave, pour out a nice glass of craft-brew and come get SCORCHICE-MANAGERIZED!!!!
I have been doing a lot of work lately at customers recently (you know who you are ) helping them create Service Requests in Service Manager that pass the values into Orchestrator, to allow for some form of automation whether it be machine provisioning, employee onboarding changes etc.
The steps in this blog post will produce the following end result:
An end user can go into the self-service portal and raise a service request to onboard a new employee. They provide details of a new employee such as phone number, first name, last name etc. and who their manager will be. They also specify if hardware provisioning is required for this user or not. An initial orchestrator runbook will complete the following tasks:
1) Insert the manager specified into a pre-created review activity.
2) Create an additional MA if needed for Hardware Provisioning and set the manager to be the activity implementer.
3) populate the child manual and review activities with the key details from the parent work item
Once the manager approves the review activity, another orchestrator runbook runs, which will complete the following tasks:
1) Determine a user name based on firstname.lastname and a new password generated using the orchestrator random text generator activity
2) Creates the user in Active Directory and enables them.
3) Creates a mailbox for the user
4) Adds the user to the appropriate AD groups
5) Sends an email to the new user’s manager, notifying the manager of the new user’s username and password via email.
As per the first edition of this blog, this one is still a relatively basic, minimal example, but the idea of this post is to show how all the pieces fit together and how this integration can be achieved, including lots of tips, guidance and best practices along the way.
Here are the high-level steps required to achieve this scenario:
High-Level Steps
1) Create Management Pack containing Department Custom Lists that can be Used with other Management Packs and Scenarios.
2) Seal the Custom List Management pack
3) Create Inherited Class in Authoring Tool
4) Seal, and Import the Extension Management Pack
5) Create the Orchestrator Runbooks
6) Synchronize the Orchestrator Connector in Service Manager
7) Create Runbook Automation Activity Templates
8) Create the New Hire Service Request Template and encapsulate the Activity templates
9) Create New Service Offering Category, or determine which existing one to use
10) Create New Service Offering Category, or determine which existing one to use
11) Create New Service Offering Category, or determine which existing one to use
12) Populate your Department List
13) Add request offering to service offering
14) Give Permissions to Offerings on the portal using Catalog Item Groups and User Roles
15) Verify Successful Onboarding of New Users!!
Here are the detailed Steps to achieve this scenario:
1) Create Management Pack containing Department Custom Lists that can be Used with other Management Packs and Scenarios.
1.1) Download the appropriate version of the Service Manager Authoring tool that corresponds to the version of Service Manager that you have, and install it
2012 RTM - https://www.microsoft.com/en-us/download/details.aspx?id=28726
2012 SP1 - https://www.microsoft.com/en-us/download/details.aspx?id=36214
2012 R2 - https://www.microsoft.com/en-us/download/details.aspx?id=40896
NOTE: If using the R2 version and you have problems installing on the pre-requisite check, try installing the pre-requisites from the SP1 version of the authoring tool, and then running the R2 authoring tool setup. This is the most reliable resolution I have found for this problem in the past.
1.2) Open the Authoring tool
SEQUEL NOTE: We are using the R2 authoring tool this time (figured I should move with the times ):
NOTE: If you want to follow along with these steps more closely, ensure your authoring tool layout is similar to the one shown below, and if not, you can choose Window>Reset Windows Layout as shown in this menu:
1.3) In the pull down menu choose File>New
1.4) Change the Filename from ManagementPack.GUID (ManagementPack.c8b265d2_f6be_4157_bf2f_62f27131e580) to something more meaningful like ContosoCustomListMP (NOTE: no spaces or special characters)
SEQUEL UPDATED NOTE: I will be storing mine in a directory called C:\Contoso Customizations\Contoso Onboard Second Edition It will be saved as an unsealed mp with the .xml extension – C:\Contoso Customizations\Contoso Onboard Second Edition\ContosoCustomListMP.xml
1.5) Right-Click Classes on the left hand side and select ‘Create Work Item Class’
1.6) Change the Internal Name and hit create:
1.7) Change the display name (Class name) as desired:
1.8) Scroll all the way to the bottom in the ‘Class Properties and Relationships’ Details pane (should be in the middle), and then you should see a custom property that the authoring tool kindly created for you (likely Property_24):
I always delete this, because once you name a property, you can’t change the ID. Even if you rename the display name of the property from Property_24 to my COOL NEW PROPERTY, you will be stuck with good old property_24 as the internal name which I don’t like So if you agree with the above note, hit the red X on the right, to delete property 35.
1.9) Create one of the lists we want as a property of this class. You may wish to add more lists for use in other scenarios. To do this, follow these steps:
Hit Create Property Button:
Give it an internal name (no spaces or special characters) and hit create:
NOTE: I am not adding new hire or onboarding to the name as we may use this in other scenarios such as transfer etc.
In the lower pane change the data type from the default of String to List, then hit enter.
In the bottom left of the ‘Select a list’ dialog, hit Create List:
Give it a name such as ContosoDepartmentList and click Create:
Click Contoso Department and then click ok in the ‘Select a list’ dialog:
1.10) Click the name of the Management pack in the Navigation tree on the left hand side and then rename it using the Management Pack name property:
1.11) Hit File>Save All to save the Management Pack
2) Seal the Custom List Management pack
We want to seal this Management Pack so that list values are not accidentally stored in it. If we didn’t seal it and then imported it into the console, and then added department list values to the same unsealed management pack, if we come back later and want to modify this MP (such as by adding another list) and then import it, we would lose all the list values we’d populated in the console (unless we exported with all the list values, and then modified that version in the authoring tool, but we are giving ourselves something extra to worry about here). So better to seal the list definition (note the definition, not the list values ) and force creation of values in an alternative unsealed MP.
in order for the customized class and properties to be synchronized to the warehouse, the MP defining the class and properties needs to be sealed.
See this blog for more on MP Best Practices
NOTE: In order to perform the sealing process, one challenging part of this process can be finding the sn.exe tool, which creates the key we use for sealing the mp:
I typically get the sn.exe tool from the Windows SDK Download:
sn.exe https://www.microsoft.com/en-us/download/details.aspx?id=8279
The sn.exe is part of the .NET development tools:
sn.exe is typically installed with most Visual Studio installs, so chances are you may be able to find it already out there in your environment somewhere.
2.1) Once you have obtained sn.exe, Run through the following command at a command prompt (navigated to wherever sn.exe is):
sn –k OrgNameKey.snk
2.2) Use this resultant snk file in the authoring tool to seal your management pack. To do this, right-click the Management pack name in the Management pack browser and choose ‘Seal Management Pack'
2.3) Fill out the fields and click Seal to seal the MP, then close the Seal dialog:
NOTE: remember to change the Output Directory, as by default it is the user profile’s documents directory
NOTE: When you click ‘Seal’ , the most recently saved unsealed .xml version of the MP will be preserved, and it will create a sealed version of the MP (.mp file) in the output directory (which you will likely want to change from the default user profile\documents directory) and automatically increment the version number by 1.
Now is a good time to completely close out of the authoring tool, so you can just open up the one sealed MP that we will need the list from, and start fresh with creating the onboarding SR.
3) Create Inherited Class in Authoring Tool
The NewHire Onboarding Scenario used in this post requires entry of the following specific values for this scenario:
- NewHire User First Name
- NewHire User Last Name
- NewHire Username (This will be automatically determined and populated by Orchestrator)
- NewHire User Business Phone
- NewHire User Other Phone
- NewHire User Department
- NewHire User Location
- NewHire User Manager
- NewHire User Provides Hardware (Yes/No?)
SEQUEL NOTE: The following is different regarding these properties from the first edition of this blog:
- For simplicity / time / (Lazyness ) removed Properties: Salutation, Initials, Mentor, Job Title
- Site is renamed to Location
- Removed Mentor (we didn’t really use it for anything in the first edition, but if anyone noticed they were too polite to point that out!!)
- As discussed in the intro, we will use OOB relationships rather than custom ones.
- Department is now an MP Enumeration list (was a simple list in the previous post), and is defined in a separate MP created exclusively for list definitions.
Because the above properties are not provided within the out of the box (OOB) general Service request class, we know that we will need to customize the service request class to add these properties.
TIP: In some cases you can get away with using the built-in properties that you don’t need as placeholders for your custom properties. For instance, I see ‘Alternate Contact Method’ used a lot as a placeholder for some kind of custom value. However in this case as we have 10 properties and 2 relationships we need placeholders for, we definitely need to customize the class. Even in a scenario where you only have one or two properties you need to add, it still can be better to customize the class so you have a set property in which to store that value, rather than re-using an OOB property that ultimately you may decide to start using for it’s original purpose.
The next question is to consciously decide whether we will use the ‘extend’ or ‘inherit’ option when we get to customizing the class in the authoring tool (NOTE: This is a fairly weighty life-changing decision, not for the faint hearted ):
As the above properties are specific to this scenario and we don’t want these showing in every service request, (for example it would make no sense to see new hire details in a new VM provisioning SR), I decided to use the ‘inherit’ option rather than ‘extend’ option in the authoring tool. Another option you have is to ‘extend’ and add fields such as customstring1, customstring2, customint1, customint2. Don’t go too overboard with that though as in one environment I saw 50 extended properties (10 string, 10 int etc) and it really hampered performance, causing every work item (as extending extends all of them) to take a very long time (almost unusable) to open up and save.
TIP: Use Extend if you want the property extension to show up in EVERY service request already created and that will be created going forward. Use the ‘Inherit from this class’ option if you are creating properties specific to a given scenario that you don’t want to see in all service requests, but just those for the particular scenario like new hire onboarding.
SEQUEL NOTE: In the first edition the notes about downloading the authoring tool and some of the detail about sealing etc were here, but as you do these now in the previous section, these are removed from this section of the second edition.
So now the theories out of the way, here’s how we go about doing this:
3.1) Using File>open and changing the Type to MP, open up the Sealed list MP we just created in the previous section.
3.2) In the pull down menu choose File>New
3.3) Change the Filename from ManagementPack.GUID (ManagementPack.c8b265d2_f6be_4157_bf2f_62f27131e580) to something more meaningful like ContosoOnboardNewHireMP (Note no spaces or special characters)
I will be storing mine in a directory called C:\Contoso Customizations\Contoso Onboard Second Edition It will be saved as an unsealed mp with the .xml extension – C:\Contoso Customizations\Contoso Onboard Second Edition\ContosoOnboardNewHireMP.xml.
3.4) As we want to extend the service request class, the first thing is to find the Service Request class in the sealed MP it is originally defined in. To do this, on the lower right hand side in the class browser, change the dropdown from the name of your management pack to ‘All Management Packs’ (you may have to scroll up to see this ‘All management packs’ option)
3.5) Once ‘All management packs’ is selected, where it says Search, type Service Request: (yes, keep typing at least all the way to Service R, it is narrowing it down )
3.6) Right-Click Service Request (you may have to click twice) and select View:
3.7) You will see the class open up from the Sealed MP it is contained in (System Work item Service request Library) on the left hand side:
3.8) Right-click Service Request in the management Pack explorer on the left-hand side, and choose ‘Inherit from this Class’ :
3.9) In the ‘Target Management Pack’ dialog, Leave the default of your custom unsealed MP selected, and click OK to store the class customization in there.
3.10) Change ClassInherit_1 to a name such as ContosoOnboardingNewHireSR (again no spaces here as this is the internal ID – you can create a more friendly display name in the next steps)
3.11) Now under Class and ‘Class Name’, you can change ‘Inherited from Service Request’ to a more appropriate friendly class name such as ‘Contoso Onboarding New Hire SR’
NOTE: For the next step, you may need to rearrange the windows or in my case pull the details window up to see the class properties and relationships:
3.12) Scroll all the way to the bottom in the ‘Class Properties and Relationships’ Details pane (should be in the middle), and then you should see a custom property (likely lucky number 35) that the authoring tool kindly created for you (or you can sort by name and scroll to ‘P’):
NOTE: So just like we did with the property_24 that showed up, I delete this too, as we cannot change the internal name of property_35.
3.13) So if you agree with the above note, hit the red X on the right, to delete property 35.
3.14) Now we will create the custom properties that we want. You may vary this (add extra / less properties) and /or use different datatypes for each property depending on your ultimate desired result and how you will use these properties, or how you will need to ultimately manipulate them in service Manager or Orchestrator.
The create property / create relationships buttons can be found just to the lower right of the class description:
Use these, together with the details window, to set the custom properties as follows:
SEQUEL NOTE: Remember the properties are slightly different and we’re not using custom relationships this time.
SEQUEL NOTE: Even though Orchestrator will create a username, rather than a user inputting it via the portal, we are creating a custom property to store that in, just for convenience so we have it displayed and available in forms / notifications, for convenient use in orchestrator etc.
NOTE: to see the details for the appropriate property click on the property and it’s details will be displayed in the details window
NOTE: down the line you may choose to create some of the strings below that use simple lists as list data types that use MP enumeration fields instead. Simple Lists are hard-coded when create the request offering. MP Enumeration Lists are the dropdown lists you see which can be modified via the Library>Lists section of the console.
Button |
Internal Name |
Display Name |
DataType |
Notes |
Create Property |
NewHireUserFirstName |
New Hire First Name |
String |
|
Create Property |
NewHireUserLastName |
New Hire Last Name |
String |
|
Create Property |
NewHireUsername |
New Hire Username |
String |
|
Create Property |
NewHireUserBusinessPhone |
New Hire Business Phone |
String |
|
Create Property |
NewHireUserOtherPhone |
New Hire Other Phone |
String |
|
Create Property |
NewHireUserDepartment |
New Hire Department |
List |
After selecting List data type, Choose Contoso Department. NOTE: This will only show up if you followed the steps in the previous section and most importantly of all, opened up the MP containing the list that we created in the last section. |
Create Property |
NewHireUserLocation |
New Hire Location |
Simple List |
Will be a simple List in SCSM, populated in the Request Offering prompt configuration |
Create Property |
NewHireUserNeedsHardware |
New Hire Needs Hardware Provisioned? |
Boolean |
Set default value to false. |
NOTE: When you get to the Boolean field remember, to set the default to true or false if you want this. Otherwise it will show as ‘null’ rather than false by default:
3.15) Click on the Management pack name in the navigation tree on the left and change the display name as desired:
NOTE: Now (as is any!) is a good time to save the MP. It is always best to save at milestones in the Authoring tool 
3.16) Save and close the Authoring Tool
SEQUEL NOTE: We just cut out 2 MASSIVE SECTIONS of creating the form and a bunch of XML hacking to get this how we wanted. In PFE circles, we have been known to call this methodology of avoiding these as ‘Inherit Express’
4) Seal, and Import the Extension Management Pack
NOTE: We seal the MP for the following reasons:
- to ensure that this MP will only contain this customization (properties) and other items in the console cannot be added to it. NOTE: if you had created the list in here, without sealing, you will be forced to store list values for list properties defined in this MP / templates based on this class in the same unsealed MP that has your class customization. This can be problematic should you want to make a change in the authoring tool later (class/form/properties) and then want to re-import it as it will wipe out changes made in the Service Manager console, since the original import.
- in order for the customized class and properties to be synchronized to the warehouse, the MP defining the class and properties needs to be sealed.
- See this blog for more on MP Best Practices
NOTE: We will use the same SNK file we used for sealing the last MP to seal your management pack.
4.1) right-click the Management pack name in the Management pack browser and choose ‘Seal Management Pack'’
4.2) Fill out the fields and click Seal to seal the MP, then close the Seal dialog:
NOTE: remember to change the Output Directory, as by default it is the user profile’s documents directory)
NOTE: When you click ‘Seal’ , the most recently saved unsealed .xml version of the MP will be preserved, and it will create a sealed version of the MP (.mp file) in the output directory (which you will likely want to change from the default user profile\documents directory) and automatically increment the version number by 1.
4.3) Navigate to Administration>Management Packs in the Service Manager console, and Import the 2 SEALED (remember to change Management pack type) Management Packs into SCSM (This is required now so that you will be able to select your custom class in the orchestrator runbooks we will create next):
5) Create the Orchestrator Runbooks
We will use 6 runbooks in total for this exercise.
Here is a quick overview of what each of these runbooks is for:
SET 1:
Contoso Onboard Master Runbook – Triggers from the first runbook activity and runs the child runbooks below.
Create Username and Populate into SR – Creates a new username from firstname.lastname and populates the custom username property we created earlier with this value.
Set RA Approver to Manager – Takes the selected Manager and inserts them as a reviewer into the Review Activity
(Optional) Create Provisioning MA if needed – If ‘true’ was selected for this value, it creates a MA at the end of the SR, and sets the manager as the activity implementer
Populate Child Activities – Populates child MAs and RAs Titles and Descriptions with key information from the parent SR.
SET 2:
Provision User – Creates a Password, User in AD, Creates an Enables a mailbox, Adds User to appropriate groups based on selected department and sends email notification of completion.
NOTE: It is a good idea to at least create and rename all the runbooks at this point, even if the runbooks require additional configuration / modification. Tweaking the runbook after all the following steps are complete will not cause problems, but renaming it or moving folder later could potentially cause problems with the synchronization of the runbook.
NOTE: (If you need help getting started with setting these up in SCORCH, I recommend you go through creating the runbooks in part 1 first until you’re familiar / comfortable.
HEALTH WARNIING: As you may notice, there is no fault tolerance or error handling built into these example runbooks, so I would recommend adding some of these mechanisms (and working with an Orchestrator expert if needed to do this) before implementing into a production environment.
ASSUMPTION: You have configured your Connections inside Orchestrator. If you have not yet done this, guidance to do it can be found in each integration pack guide. These will enable orchestrator to connect to the environments it needs to like AD, Service Manager, Exchange etc.
SEQUEL NOTE: SYNC / INITIATION FOLDER
Shout-out to my colleague Jay Wodka who I learn this tip from. Sometimes, depending on how you’ve organized your runbooks in SCORCH (EVERYBODY does it different ), the Library>runbooks view in SCSM can get a little convoluted and difficult to navigate, and also when things move / get renamed etc, this can cause sync problems.
Jays best practice is to have a folder designated to the SCSM <> SCORCH sync and then the runbooks in that folder call the other runbooks as needed in SCORCH.
So for example, here in SCORCH, I have a ‘Sync and Initiate’ Folder that has very small runbooks that simply kick off other runbooks in SCORCH:
So basically we’re letting SCORCH do the runbook navigating work, and we’re only synchronizing a minimum number of folders / runbooks into Service Manager. We will see less sync issues as we rename / move runbooks too.
Hers is how the runbooks that trigger the other runbooks look:
In SCSM, we just set up one connector to this folder and these are the runbooks that our runbook automation activity tempaltes will be linked to.
You end up with a really nice organized, easy to navigate Library>Runbooks view this way:
And my connector is configured to just sync the one folder:
Here are the Runbook Details (If you need help getting started with setting these up in SCORCH, I recommend you go through creating the runbooks in part 1 first until you’re familiar / comfortable.
Contoso Onboard Master Runbook
Create Username and Populate into SR
Creates a new username from firstname.lastname and populates the custom username property we created earlier with this value.
Runbook and Activity Configuration:
Set RA Approver to Manager
Takes the selected Manager and inserts them as a reviewer into the Review Activity
Create Provisioning MA if needed
LOOK OUT!!!! Whenever creating Work Items in Scorch, be sure to include the prefix (MA in this case) before {0}. {0} will use the next available work item number.
NOTE: we hard code Sequence 3 here because we always want the MA to go at the end (we start at 0 with 0 being my first RB, 1 being my RA, and 2 being my second RB), but see Appendix II at the end of this post, for details of a runbook that automatically figures out what the sequence ID should be.
Populate Child Activities
Populates child MAs and RAs Titles and Descriptions with key information from the parent SR.
NOTE `n creates a line space carriage return in the string, making the end result a little easier on the eyes
Provision User
Creates a Password, User in AD, Creates an Enables a mailbox, Adds User to appropriate groups based on . selected department and sends email notification of completion
Finally, ensure all runbooks are checked in.
6) Synchronize the Orchestrator Connector in Service Manager
6.1) In the Service Manager console, navigate to Administration>Connectors, click on your orchestrator connector and choose Synchronize now in the tasks pane on the right-hand side.
NOTE: If you don’t have the connector configured yet, steps for creating it can be found here in the TechNet documentation:
6.2) Navigate to Library>Runbooks and verify that your runbooks are present and showing with a Status of Active
NOTE: If your runbooks do not appear, these are the most common two problems:
a) The runbook was renamed between syncs and shows in an ‘invalid’ state. If this happens, delete any runbooks in the library>runbooks node showing with a status of ‘invalid’ or ‘missing’ from Service Manager and re-run the connector
b) You need to run the following truncate command against the orchestrator database as documented here:
TRUNCATE TABLE [Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache
7) Create Runbook Automation Activity Templates
7.1) In Library>Runbooks, click on the ‘1.Contoso Second Edition Onboard – Set 1’ runbook and then in the tasks pane on the right-hand side, click Create Runbook Automation Activity Template:
Give the template a name such as Contoso – RB – Onboarding Part 1
NOTE: I use the RB convention for Runbook Automation Activity templates
NOTE: I would normally store this in my Contoso RB MP following the best practice of storing all elements based on a given class in a custom MP created and used for elements created based on that class.
However this time, I am following the alternative approach of storing everything custom created in the console related to this scenario in a Contoso Onboard New Hire Custom MP (or a more technically appropriate name may be Contoso Onboard New Hire Console MP as this will contain all elements created via the Service Manager console). Storing in a ‘scenario’ MP like this will make the MP more portable between environments. For example if say I just wanted to implement this particular scenario’s functionality in a different environment – you would just be able to export the single MP and import it into the new environment. See here for ‘War & Peace’ on MP Best Practice
When specifying the class (Changing it away and then back to Runbook Automation Activity for example), this may change the Management Pack to a different one than the one you intend to store in, so be cautious of this and always verify the management pack before clicking OK.
7.2) Check the ‘Is Ready for automation’ checkbox:, and give the RB Activity a title such as Contoso Onboarding Part 1
NOTE: Do NOT populate a user into the ‘designer’ field on this page as this can cause problems when you try raising the SR containing one of the activities from the Self-Service portal
7.3) On the Runbook tab, click the Edit Mapping button, Expand Object and choose ID, then click Close in the Select Property Mapping box:
After step 7.3, the Parameter mapping box, under ActivityID should read ‘Mapped to property ID’ instead of the default of ‘Mapped to Property Text1’, so should look like this:
7.4) Click OK in the Runbook Automation Activity template to save it
7.5) Using the same steps, create a runbook automation activity template for your Part 2
7.6) Check the Is Ready for automation checkbox and give the RAA a title such as Contoso Onboarding – Part 2
7.7) On the Runbook tab, click the Edit Mapping button, expand Object and choose ID.
7.8) Click OK to save the template
8) Create the New Hire Service Request Template and encapsulate the Activity templates
8.1) In Library>Templates, select Create Template
8.2) Give the template a name such as Contoso - SR Onboard New Hire, select your customized SR onboard new hire class (Contoso Onboarding New Hire SR in my case) and then choose an appropriate management pack.
NOTE: The same guidance applies here as described at the start of section 7 in this blog post.
8.3) Click OK To open the template
8.4) Populate the title and any other fields you wish too:
NOTE: If you peek at the Extensions tab, you will see the extended properties:
8.5) Click the Activities tab
8.6) Click the Green Add ‘plus-sign’ button just above the Start Green line.
8.7) Select your Contoso Onboarding Part 1 Runbook Automation Activity and click OK:
8.8) Click OK in the Runbook Activity template.
8.9) Click the green add button, select the Default Review Activity and click OK:
8.10) Add a Title such as Approve Provisioning, and Click OK in the Review Activity template.
8.11) Click the green add button, select your Contoso Onboarding Part 2 runbook automation activity template and click OK:
8.12) Click OK in the Runbook Activity template.
Your Completed Template’s Activities tab should look like this:
TIP: If you click the far right ‘views’ button this can often give a more helpful view of the activities displaying the full title:
8.13) Click OK in the Service Request Template to Save it
9) Create New Service Offering Category, or determine which existing one to use
This diagram shows how Service Offering Categories and Service Offerings are displayed on the OOB Microsoft Silverlight / SharePoint portal:
Here is the example for this scenario:
When you click on a Service Offering, you see a list of request offerings categorized under that Service Offering.
For our scenario we will use a service offering category called ‘Contoso Employee Related Service Requests’ and a Service Offering called IT Onboarding and a Request Offering called Onboard New Hire To Contoso:
So here is how to create the service offering category:
9.1) Navigate to Library>Lists>Service Offering Category List:
9.2) Double click the list and click the Add Item button
If you receive the ‘Select Management Pack’ dialog, I recommend you create a new MP for your service offering category list values called something like ‘Contoso List Values – Service Offering Category’ . In this situation, it is not appropriate to choose the Onboard MP because wherever you create any new additional service offering categories they will be stored in whichever MP is selected here the first time round. Once you initially select a management pack to store list values, you will no longer be prompted which MP to store new values in. The only way to revert this is to delete all list values created so far and then once you’re back to no custom values and create your first one, you will receive the ‘select management pack’ dialog again.
TIP: To determine the MP that your list values are stored in, modify a value or it’s description and then look for the most recently last modified date in Administration>Management Packs.
9.3) Click the List Value that appears and then in the Name box, overwrite List Value with Contoso Employee Related Service Requests and click OK.
10) Create New Service Offering Category, or determine which existing one to use
10.1) In the SCSM Console, navigate to Library>Service Catalog>Service Offerings>All Service Offerings
10.2) In the task pane on the right hand side, click Create Service Offering
10.3) In the ‘Before you begin’ page, click next
10.4) In the General Page, give the Service Offering a name such as ‘IT Onboarding’.
10.5) Change the Category from General to the Contoso Employee Related Service Requests category, or whichever category you would like the Service Offering to be displayed under
10.6) Choose the MP to store the Service offering in – I will use Contoso Onboard New Hire Console MP
Note there are some partner / community icon packs available which you should be able to find by searching out on the net, should you wish to use these icons.
10.7) Optionally, fill out the Detailed Information fields
10.8) Optionally, add the related business services
10.9) Optionally, add any knowledge articles
10.10) Click Next on the Request Offering page as we do not have the Request Offering yet – we create that in the next section
10.11) In the Publish page, change the Offering Status from Draft to Published
NOTE: a service offering and request offering both have to be in the published status in order for either to approve on the self-service portal. This is typically the first thing to check in the case where a service offering or request offering unexpectedly does not appear on the portal.
10.12) Click Create and then Close
11) Create Onboarding Request Offering
We will create a Request Offering that prompts for all of the newhire values that we specified when customizing class in the first section above.
11.1) In the Service Manager Console, navigate to Library>Service Catalog>Request Offerings and in the task pane on the right hand side click Create request Offering:
11.2) In the general page, give the request offering a title such as Onboard a new Hire to Contoso.
11.3) Click the ‘select template’ button and select the Custom New Hire Service request template created in section 9 and select a management pack to store the request offering in:
NOTE: If you click the Words Select template you will just see Service request templates but if you click the down arrow to the right of select template, it will allow the ability to select a service request template, incident template and create template.
NOTE: I am keeping the request offering in my Contoso Onboard New Hire Console MP as I am storing everything relating to this scenario in this MP.
11.4) On the general page click next to get to the user prompts page
11.5) Optionally enter some form instructions and then add all of the prompts with the appropriate type as shown below, and then click Next:
NOTE: Please select Manager’s domain is here because this is called ‘Query Filtering’. This prevents the page from trying to load all users in the query results lookup box until this domain has been selected.
11.6) For each prompt, click the Configure button in the top right of the dialog, and configure each one as shown below:
First name, Last Name – Leave as Default
Business Phone Number an Other Phone number: – choose Phone number input mask:
Department:
New Hires Location:
Please select Manager’s domain:
Select New Hire’s maanger:
(Click the dropdown next to set token, choose select token and then choose 7. Please select Manager’s Domain
In display columns I added display name, first name , last name and department,
In options, choose the bottom check box:
NOTE: In here you can choose the activities of child activities in addition to the SR if you need more placeholders to store extra relationships and want to avoid creating custom relationships:
TIP: This diagram gives you a good idea of how the selected checkbox maps to the final work item and orchestrator:
The above diagram is from an earlier post of mine: https://blogs.technet.com/b/antoni/archive/2013/08/30/using-built-in-system-center-service-manager-relationships-in-system-center-orchestrator.aspx
When you’re done you should see the ‘All Prompts Configured’ message
11.7) In the Map Prompts dialog, click the top row Contoso Onboarding – (Contoso Onboarding New Hire SR}.
Map the properties as shown below:
NOTE: We don’t need anything in ‘New Hire Username’ because orchestrator will create and set that for us, and we don’t need to map manager as we took care of that in the previous configure prompts page, where we used the check box to map it to the Affected configuration Item relationship.
11.8) click next in the map prompts dialog
11.9) Click Next in the Knowledge Articles Dialog
11.10) In the Publish page, Change the Offering Status from draft to published and click next
11.11) Click Create and then close
SEQUEL NOTE: Took out section 13 (edit request offering XMl as this is no longer necessary, given we are using OOB relationships rather than custom relationships)
12) Populate your Department List
12.1) Navigate to Library>Lists>Contoso Department List and double-click the list to update it:
NOTE: You can sort by crated date to find it at the top
12.2) Double click the list and click the Add Item button to add a value:
In the ‘Select Management Pack’ dialog, I recommend you create a new MP for your Department list values called something like ‘Contoso List Values – Contoso Department. Once you initially select a management pack to store list values, you will no longer be prompted which MP to store new values in. The only way to revert this is to delete all list values created so far and then once you’re back to no custom values and create your first one, you will receive the ‘select management pack’ dialog again.
12.3) Click the List Value that appears and then in the Name box, overwrite the words ‘List Value’ with a Department name and click OK. Add additional values as desired.
13) Add request offering to service offering
13.1) In Library>Service Catalog>Published Request Offerings, select ‘Onboard a New Hire to Contoso’ and click the Add to Service Offering task on the right hand side:
13.2) Choose the IT Onboarding service Offering, click Add, then OK
13.3) Verify that the Service Offering and Request Offering have a status of Published
14) Give Permissions to Offerings on the portal using Catalog Item Groups and User Roles
Catalog Item Groups (Configured in Library>Groups>Catalog Groups) are used in conjunction with User Roles to determine what End Users see in the end user portal. Start by creating your Catalog Item group and add the grouping of published request offerings and service offerings to the catalog item group.
In Administration>User Roles create an end user role and add the catalog item group to the User Role.
TIP: You may need to take ‘authenticated Users’ out of the OOB ‘End User’ Role in order for your permissions to take effect
TIP: Permissions are cumulative, so be as granular as possible when creating your catalog item groups (least offerings possible) and grant users/groups to multiple end users catalog item groups as needed
15) Verify Successful Onboarding of New Users!!
15.1) Go to the self-service Portal and raise an Onboarding request.
15.2) Go to work Items>Service Request Fulfillment>All Open Service requests and verify you see your service request. Open it up and verify the new hire details is populated as expected.
15.3) In the SR you should see your MA that SCORCH created, in addition to the modified SR and Activity titles that include first and last name:
15.4) Go to activities and you should see that the first Runbook automation activity completed, and then the manager get inserted as the reviewer into the middle review activity:
15.5) Have this user Approve the activity through the portal / console or exchange connector.
In the manual activity, you should see that the Manager got set as the Activity Implementer:
15.6) In Orchestrator, you can use the log history and double click a line item in there to see the Runbook details and verify that all activities completed successfully:
15.7) In Active Directory for Users and Computers, Ensure the user was created, properties like phone number, title etc. were updated, the user was added to appropriate groups (sale / IT) and that the manager received an email with the username and password.
Thanks for reading and I hope this helped you out!
APPENDIX I – Query filtering trick
Use the following technique to allow filter/searching for users;
The trick is to change the default value of the simple list to something that will NOT match and make the query fail, such as ‘choose’ as shown above.
Then the portal user changes it to what it should be and something that will match. Above we are using display name, but you could just use first name or last name if preferred.
APPENDIX II – Figuring out dynamically inserted sequence ID
You can use a runbook similar to this for manipulating sequence IDs
The key piece of functionality here is that we use a SUM Function to work out a higher sequence ID than the one that is currently the highest:
Once we have that, we can set the newly created MA, RA to use this incremented sequence ID.
Comments
- Anonymous
January 06, 2016
Thank you for the post! I am stuck on the set RA approver to manager runbook. The return data activity step details tab is blank I am unable to configure it. Also I would like the username to be first_initial+Last_name and canot see how to adjust the username when it is created. Your assistance is appreciated - Anonymous
February 10, 2016
Awesome article, I really thank you for this sequel it made my life so much easier when it comes to creating forms in service manager using the authoring tool!! - Anonymous
February 12, 2016
Great post, thanks - Anonymous
February 14, 2016
We have a development SCSM and SCORCH environment. After I have sealed the MPs and created the runbooks in our development environment, then import the sealed MPs in production, do I still need to create the runbooks in our production environment? Thank you for the great post. Very helpful! - Anonymous
February 16, 2016
Very impressive blog post.
Please keep e'm coming :) - Anonymous
February 16, 2016
The comment has been removed - Anonymous
February 24, 2016
Awesome post. I keep running into one issue though. My create user step always fails and the error says "Device attached to the system is not functioning." Which with some research points to the samaccountname being too long. Regardless of how long I make the field that is mapping to samaccountname I get this error. What is strange is this did work about three times and it has failed ever since. I even whipped all the runbooks and mp and restarted.issue persists. Id be glad to provide any level of detail, Id like to get this to work.