Service Manger works best for changes that are known, repeatable and in these cases use of templates makes the change module easy to configure and use.

Identify the Change Management Process Requirements

Contoso’s change manager is responsible for managing all change records. Any person from within IT Operations is able to initiate a change request (Change Record).

Contoso implement the following change types; the definitions for each of these changes have been agreed to by the business.

• Standard changes include Server Reboots, Server Patch Cycles
  • These changes have been pre-approved, they are repeatable, low risk and usually happen during planned maintenance windows.
    
• Major changes which includes any change not considered a standard change and which is to be performed on a production system.
  • These changes require review from all Change Advisory Board (CABs).
    
• Emergency Change which include changes linked to high impacting incidents. Many business confuse, poor planning (changes that are urgent) with emergency changes
  • These changes require review and approval from a member of the emergency CAB

The Change initiator must provide as part of their Changer record the following details for CAB review and approval:

• Implementation Plan
• Risk Assessment Plan
• Functional Test Plan
• Roll Back Plan

These documents must be submitted with the Change Record (CR).

Upon creation of a Change Record the Change Manager is notified via email, the email contains all the high level information about the change (Change ID#, CI/Service/Change description, change risk/impact/urgency). After reviewing the change record for completeness and assessing the change risk, the change manager then decides if to approve, deny or put the change on hold.

Once the change approved it must be reviewed and approved by the appropriate CAB.

Contoso have three CABs:

• Emergency CAB – responsible for reviewing and approving changes related to Incident management process
  • CAB consists of CIO, IT Infrastructure Manager, Application Team Manager
  • At least one member must approve the Change before it can actioned
    
• Technical CAB – responsible for reviewing the Implementation Plan and Risk Plans
  • CAB consists of IT Infrastructure Manager, Application Team Manager, Change Manager and IT Service Manger
  • All members of this Technical CAB must review the change before it can be actioned
    
• Deployment CAB – responsible for reviewing all Plans
  • CAB Consists of IT Infrastructure Manager, Application Team Manager and Change Manager
  • All members of this CAB must review the change before it can be actioned

Once a change has been reviewed by appropriate CAB(s) the Change Manager is notified and is responsible for assigning resources from the appropriate team to complete the following tasks:

• Implement the Change
  
• Test the Change deployment * Note the same resource cannot both Implement and Test the change.

The Change manager is notified when each of the above tasks has been completed or if has failed and has the final task of marking the Change as Complete, or FailedFor failed changes, the Change Manager will hold a post implementation review, to review the change deployment, errors, issues and update the Change Record and communicate to the business.

Now let’s discuss how we would configure this in System Center Service Manger

Service Manager’s Change Management Process management pack provides the following components out of the box: Change Management Form and Workflow implemented as activities to support Approval, Manual and RunBook Automations.

Activities function as steps, and as each step completes the next activity step is automatically triggered. This concept or workflow ensures the change record actions and ownership are moved between teams and individuals available in scoped views.

Service Manager also provides the functionality to notify people based on trigger events i.e.  Change creation, update or modify, Activity assignment, status updates and supports use of content based templates.

Change Management Process General Settings

Unlike the Incident Management process pack, the change request settings are very simple. To modify the change request settings open the Service Manager console and select the Administration Workspace, expand Settings and double click Change Request Settings.

Out of the Box, the Change Management Process pack form

General Tab contains Title, Description, Reason, CreatedBy (Change initiator), Area, AssignedTo, Priority, Impact and Risk.

Note * this form has no mandatory fields. It is possible to make a Form Field mandatory through customisation however only for new Class(s) example here: https://marcelzehner.ch/2011/01/04/adding-a-custom-field-to-incident-forms/ using the Service Manager Authoring Tool available here:  https://www.microsoft.com/en-us/download/details.aspx?id=36214

Area Picker List displays the Values that have been entered into the Library\Lists\ Change Area List

Priority, Impact and Risk Pickers display Values that have been entered into the Library\Lists Change Priority, Change Impact and Change Risk Lists.

“Config Items to Change” instance picker allows the Initiator to add Configuration Items (CIs) from the Service Manager CMDB, this explicit relationship is very useful for reporting on CIs status amongst other things.

“Notes” Field for recording additional details if required

“Catalog Items” instance picker allows the initiator to add Service Catalog items, the benefit of creating this explicit relationship, a Service Catalog Item is a CI Type and all changes to CIs needs to be managed and reported on.

Planning Tab contains Scheduled start Date, scheduled End date, Implementation plan, Risk assessment plan, test Plan and Roll Back plan.

Service Manager by design archives all work item attachments as part of the grooming process. Further information about the grooming process can be found here:  https://blogs.technet.com/b/servicemanager/archive/2009/09/18/data-retention-policies-aka-grooming-in-the-servicemanager-database.aspx

Service Manager doesn’t provide document storage capabilities nor is it governed by Information Lifecycle polices as such, it is recommended to:

• Use URLs or DOC Links in the appropriate Form Text Fields to indicate the location of the supporting documentation
  Allow Change Initiators to add attachments to the Change Record however leverage Orchestrator to copy attachments to the File Share prior to grooming (be default 90 days)
  Anders has an excellent example here: https://contoso.se/blog/?p=3227

Change Types: Standard, Major and Emergency are implemented as Templates

Service Manager Templates allow the Change Manager to create a Change Type for each of the above with embedded Activities that trigger as part of the configured workflow.

Contoso’s Standard Change Template

Contoso’s Standard Change Template would look something like the image below.

General Tab – recommend to provide some instructions for the Change Initiator, the intention here is to provide change logging guidance.

Activities Tab – the first and only step which is triggered when the Change initiator selects ok

• Manual Activity - AssignedTo a person, a team – Action Change is actioned

Another option here would be to use RBA to automatically assign the MA to the Change Initiator, this supports use of additional logic i.e. from a specific group based on Change Classification. The RBA Activity would in this case be placed before the Manual Activity in the Change template.

Inclusion of RBA Activity in the Template

Activities Tab – the first step which is triggered when the Change initiator selects ok

• Manual Activity - AssignedTo a person, a team – Action Change is actioned
• RBA Activity – Updates the Manual Activity AssignedTo Field with the Change Initiator

Step by Step procedure on how to create the RunBook for use in the Optional scenario has been documented here:  https://blogs.technet.com/b/evmoreno/archive/2014/01/03/update-service-manager-related-manual-activity-fields-with-information-from-the-parent-change-request.aspx

Create a new Service Manger template documented here: https://technet.microsoft.com/en-us/library/hh495644.aspx

Add the Reviewer Activity documented here: https://technet.microsoft.com/en-us/library/hh519725.aspx

Add Manual Activity documented here: https://technet.microsoft.com/en-us/library/hh524244.aspx

Contoso’s Major Change Template

The differences between the standard and major change template are:

• All supporting change documentation includes Implementation Plan, Risk Assessment, Test Plan and Roll Back Plan to be submitted with the change record
• Requirement for review from the Technical and Deployment CABS before the change manager can assign for implementation
• After the change has been implemented it must be Tested and by someone other than the Change Initiator

Service Manager provides voting logic to support Approvals from multiple people. Let look at how the voting logic works.

The Reviewer Activity supports three types of Approval Conditions:

• Automatic – a single approval from anyone of the Approvers marks the Activity Completed (Approved)
  
• Percentage – determined by the number of Approvers, when the 0% is reached the Activity is Completed (Approved)
  
• Unanimous – all approvers must Approve before the Activity is Completed (Approved)

Note using the unanimous change feature has a drawback, changes could get stuck waiting for approval. In most changes using the Percentage approval is a better approach. 

Contoso’s Major Change Template would look something like this.

General Tab – again it is recommended to provide some instructions for the Change Initiator, the intention here is to provide change logging guidance and encourage good behaviour

Planning Tab – provide instructions to assist the Change Initiator in completing the necessary fields for entering in the change.

Activities Tab – the first step which is triggered when the Change initiator selects ok

• Reviewer Activity - AssignedTo (Change Manager), the Change Manager must approves the Change
• Manual Activity - AssignedTo all members of the dCAB, each must review the Change and mark as complete
• Manual Activity  - AssignedTo all members of the tCAB, each must review the Change and mark as complete
• Manual Activity  - AssignedTo the Change Initiator
• Manual Activity – AssignedTo Change Manager
• Manual Activity – AssignedTo Change Tester
• Manual Activity – AssignedTo Change Manager

Contoso’s Emergency Change Template

The emergency change template contains four activities and would look something like this.

• Manual Activity – AssignedTo Change Manager
• Manual Activity - AssignedTo all members of the eCAB, one must approve the Change
• Manual Activity  - AssignedTo the Change Initiator
• Manual Activity – AssignedTo Change Manager to Mark the Change as Completed

Activities TAB

As only a single member of the eCAB is required to approve the change use of the Percentage Approval condition logic ensures the workflow completes.

33% equates to a single Approve vote from either the CIO, IT Infrastructure Manager or Application Team Manager

Again here use of RBA activity could provide further logic for manual activity assignment could be implemented.

Contoso Notifications

All Notifications to the change manager, CAB Members and IT Staff who will action the change requests are configured as Subscriptions whose content is provided by a notification template.

• Notify Change Manager New Change Request
• Notify tCAB new Change Approval
• Notify dCAB new Change Approval
• Notify AssignedTo New Change Task
• Notify Change Manager Unassigned Change Task
• Notify Change Manager Change Completed
• Notify eCAB Change Approval

Creating a Notification a Subscription: https://technet.microsoft.com/en-us/library/hh519716.aspx

Creating a Notification template: https://technet.microsoft.com/en-us/library/hh519689.aspx

And an excellent blog on how to design HTML based Notification Subscription templates here: https://blogs.technet.com/b/servicemanager/archive/2009/09/28/creating-notification-templates-in-system-center-service-manager.aspx & here: https://scug.be/scsm/2013/01/02/html-formatting-email-notification-templates-in-scsm/

Contoso Work Item Views

To support the above process each person, includes the Change Manager, Change Initiator and CAB Members can View and Action all of the above Assignments in the following default views.

• Change Requests AssignedTo Me
• Manual Activities AssignedTo Me
• Review Activities AssignedTo Me

All of the above views are provided out of the box.

Detailed View Manual Activities Assigned to Me

To update the View Properties i.e. to show other attributes of the change is very simple - Right Click the View and Select Edit

Each Service Manger View contains General Tab, Criteria Tab and Display Tab

General Tab

Criteria Tab

Display Tab

If you need to show a Related Class attribute in a view consider using a custom type projection.

More information on custom type projections can be found here https://blogs.technet.com/b/servicemanager/archive/2010/02/02/creating-views-that-use-related-property-criteria-type-projections-software-views-example.aspx.

Pre-authored management pack which contains many useful custom type projections can be downloaded from the TechNet gallery here: https://gallery.technet.microsoft.com/Some-additional-type-a0f6cd02 and also at the Service Manager Team Blog here: https://blogs.technet.com/b/servicemanager/

Finally if Contoso were to implement the Exchange connector Reviewer Approvals could be submitted in response to email notifications for more information refer to here: https://www.microsoft.com/en-us/download/details.aspx?id=24957

That’s it for now, further posts, soon…

I’d like to thank Kathleen Wilson for taking time out of her busy role to review this Post :-)

• A Blog Reference which contains Orchestrator RunBook ideas how to Manage Obsolete AD objects here:  https://myitforum.com/myitforumwp/2013/07/17/clean-up-active-directory-and-cm-2012-with-orchestrator/

Ensure each Configuration Item(CI) has a single source of truth.

• Create multiple AD Connectors *example 1 for each CI type to manage data set size and synchronisation times.

Do not synchronize AD Group objects unless required

 Ensure to select the option ‘Do not write null values for properties not set in Active Directory’.

• Using this setting ensures the connectors do not update CI values to NULL.

 Use LDAP filters to only import relevant types of objects.

• Printer Objects = (objectCategory=printQueue)
• Enabled User Accounts = (&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
• For more information on LDAP filters see here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa746475(v=vs.85).aspx

 When implementing multiple AD connectors stagger the schedule so they don’t all run at the same time and ensure they do not run during Backup or other Maintenance Windows

• A great blog reference here: https://blog.scsmsolutions.com/2012/03/update-ad-and-sccm-connector-scheduler-with-powershell

AD Connector Deletion

• Never delete an AD connector without first disabling the connector, creating a new AD Connector and completing a synchronisation further information here: https://technet.microsoft.com/en-us/library/ff461049.aspx & here https://technet.microsoft.com/en-us/library/ff461175.aspx 

Line Manger and User must be imported using the same connector

• Line Manager and User CIs must be importing using the same connector, this ensures the relationship in place for use Reviewer Activities which leverage the Line Manager refer to here: https://social.technet.microsoft.com/Forums/systemcenter/en-US/59b72a39-b2f4-4e17-b815-22e7231a7af7/scsm-2012-ad-connector-not-syncing-manager-information?forum=connectors

Mapping AD Connector Properties to Service Manager https://technet.microsoft.com/en-us/library/hh524307.aspx

Mihai Sarbulescu has an excellent blog covering AD connectors tweaks https://blogs.technet.com/b/mihai/archive/2013/08/14/tweaking-the-ad-and-cm-connectors-in-service-manager-2012.aspx

The Service Manager Product Group has also posted an excellent blog improving AD Connector performance
https://blogs.technet.com/b/servicemanager/archive/2014/03/19/improving-ad-connector-performance.aspx

“Copy Change Request Form fields into all Manual Activities in a Change Template. “

High level steps

The high level steps as per my first post here the differences are in the RunBook design as such this post will only demonstrate the RunBook Design Differences.

• Design Orchestrator RunBook
• Deploy the Service Manager Runbook Automation Activity Template
• Add the Runbook Automation Activity into the Service Manager Change Request Template

Design Orchestrator Runbook

This Runbook is triggered by the Service Manager Change Management Workflow, it is a RunBook Automation Activity associated with a Service Manager Change Request Template.

Service Manager 2012 IP Pack Activities used in this Orchestrator Runbook
https://technet.microsoft.com/en-us/library/hh832016.aspx

• Get Object - The Get Object activity is used to search for a record based on a set of filtered criteria. The Get Object activity supports incidents, changes, and activities.
• Get-Relationship Activity -  The Get-Relationship Activity is used to generate a list of objects from two different classes that are related by the criteria you specify i.e. Change Request and Manual Activity.
• Update Activity - The Update Activity Activity is used to make changes to activity records for the selected activity class.

In the Runbook below we are going to use the Get-Relationship activities to build a relationship between the Runbook Automation Activity Class and the Change Request Class – this relationship contains the Parent Change Request ID which we require in order to locate and update all related Manual Activities.

Initialise Data – Service Manager RunBook Automation Activity ID is copied to the Databus

Get-object - “Get RBA ID” – RunBook Automation Activity ID instance values are copied to the Databus

Get-Relationship - “Get Parent CR related to the RBA ID” – Builds the relationship between the RunBook Automation Activity and related Change Request and copies to the Databus

Get-object - “Get Parent CR ID” – Gets the Parent Change Request ID and copies to the Databus

Get-Relationship – “From Parent CR Get Child MAs” - Gets all related Manual Activities from the Parent Change Request.

Update Activity – Update All MA Description with CR ID, Title and Notes” – Updates all related Manual Activities with selected information form the Parent Change Request

Expand the Description Field

Check in the Runbook “Update MA Description from CR”

Copy the “Assigned To” field to all Manual Activities in a Change Template.

This can be achieved through creation of a custom Service Manager Workflow, Rob Ford has some samples available here and, through inclusion of an Orchestrator RunBook Automation Activity, Anders Bengtsson has an example here post for Service Requests.

Using a similar technique to Anders we are going to copy the Parent Change Request “Assigned to” Field Value to Child Manual Activity “Assigned to” Fields for use in a Change Request template.

High level steps

• Design Orchestrator RunBook
• Deploy the Service Manager Runbook Automation Activity Template
• Add the Runbook Automation Activity into the Service Manager Change Request Template

Design Orchestrator Runbook

This Runbook is triggered by the Service Manager Change Management Workflow, it is a RunBook Automation Activity associated with a Service Manager Change Request Template.

Service Manager 2012 IP Pack Activities used in this Orchestrator Runbook
https://technet.microsoft.com/en-us/library/hh832016.aspx

• Get Object -> The Get Object activity is used to search for a record based on a set of filtered criteria. The Get Object activity supports incidents, changes, and activities.
• Get-Relationship Activity -> The Get-Relationship Activity is used to generate a list of objects from two different classes that are related by the criteria you specify.
• Create Related Object -> The Create Related Object activity is used to create a new Service Manager object that is related to other existing objects either by membership or by a hosted relationship.

In the Runbook below we are going to use the Get-Relationship activities to build a relationship between the Runbook Automation Activity Class and the Change Request Class – this relationship contains the Parent Change Request ID and then build the relationship to the Related Active Directory User and Group Class which holds the AssignedTo value needed to update all related Manual Activities.

Initialise Data – Service Manager RunBook Automation Activity ID is copied to the Databus

Get-object - “Get RBA ID” – RunBook Automation Activity ID instance values are copied to the Databus

{SC Object GUID = {RBAId from “Initialize Data" }

Get-Relationship - “Get Parent CR related to the RBA ID” – Build the relationship between the RunBook Automation Activity and related Change Request and copies to the Databus

Object Guid = {SC Object GUID from “Get RBA ID”}

Get-object - “Get Parent ID” – Gets the Parent Change Request ID and copies to the Databus

{SC object GUID = {Related Object Guid from "Get Parent CR related to the RBA ID"}

Get-Relationship - “Get CR AssignedTo Class” – Build the relationship between the Parent Change Request and related Active Directory User or Group and copies to the Databus

Object Guid = {SC Object Guid from “Get Parent CR ID”}

Get-object - “Get CR AssignedTo User” – Gets the Active Directory user or Group Value and copies to the Databus.

SC Object Guid = {Related object Guid from "Get CR -assigned To Class"}

Get-Relationship - “From CR Get Related MAs” – Build the relationship between the Change Request and Manual Activities and copies data to the Databus

Object Guid = {SC Object Guid from "Get parent CR ID"}

Create-Relationship - “Update MA AssignedTo Fields with Parent CR AssignedTo Field Value” – updates each Manual Activity Active Directory User or Group Value

Source Object Guid ={Related Object Guid from "From CR Get Related MAs"}
Target Object Guid = {SC Object Guid from "Get CR Assigned to User"}

Check in the Runbook
 

Service Manager Runbook Automation Activity Template

Assumption -> that an Orchestrator Connector has been configured in your Service manager management group. Information on how to implement and configure the Orchestrator Connector available here.

A Runbook Automation Activity template is created in Service Manager and the RunBook ID is mapped to the RBAID string field for use in Runbook Data Initialise Activity.

Highlight the 1.1.0 CR Assign MAs Runbook and from the Task Bar select “Create Runbook Automation Activity Template” Task

The Create Template Wizard Launches, in the Name Type 1.1.0 CR Assign MAs RBA and select to Save the Template into a suitable unsealed Management Pack

When the Template loads enter the Title: 1.1.0 CR Assign MAs Runbook Activity

And Select “Is Ready for Automation”. Then Click on the Runbook Tab and select Edit Mapping in the Parameter Mapping Field

From the List of Available properties select Object ID

Click Close, Apply then OK to Finish Creation of the Template.

Runbook Automation into the Service Manager Change Request Template

More information on how to create Change Request Templates available here & here

Open the Change Request Template and add the RunBook Automation Activity into the Activities Tab.

Add all other related Manual Activities as required then Save the Template

Create a Change Request based on the above Template

* Note * Ensure that the “AssignedTo” User is an instance of the “Active Directory User or Group” Class and not type SMInternal user.