CHAPTER 7
Service Manager configuration and customization

While Microsoft System Center 2012 Service Manager is a complete IT Service Management (ITSM) solution and many customers have successfully implemented it "out of the box," some situations call for additional configuration and customization. Service Manager can be configured through the console or customized externally to meet customer requirements.

One of Microsoft’s technical principles is "configure before customize," which leads one to ask: Why is there a section in this book on customizing Service Manager when Microsoft recommends configuration over customization? The answer is simple: The economy has changed and customers expect shorter value runways from IT solutions. Historically, IT has generally preferred customizing purchased systems before even understanding whether existing functionality could be leveraged to meet their needs. In this scenario, a lack of training and product knowledge frequently results in unnecessary customization as well as potentially problematic misconfiguration.

Existing out-of-the-box capabilities in Service Manager should be understood and exploited before customizing a solution. As you will see in this chapter, however, some areas of functionality specifically require customization. This chapter provides "safe" customizations and configuration recommendations that have been accomplished with or by Microsoft partners and customers.

The good news is that both customizations and configurations are stored in management packs as described in previous chapters, and for the most part these management packs "survive" upgrades. While such survivability is intended as part of the Service Manager architecture, upgradeability is not fully guaranteed. For example, if any reserved keywords used in a custom management pack by a customer are used later by the Microsoft product group, there could be a conflict.

The configurations and customizations described in this chapter are not required by any means, and should be implemented only when an actual justified business need is identified. They have all been implemented previously by Microsoft Services and partner consultants for Service Manager customers in order to address their stated requirements.

Configurations

Configurations are made through the Administration or Library workspaces within the Service Manager console and can be performed using either the Administrator or Author security role. While configurations are generally not laborious or complex, they can still create issues with the IT organization through inefficiencies and misunderstanding of values and usage. The following configurations are described in the sections below:

▪ Incident and service request support groups and assignment

▪ Incident categorization

Incident and service request support groups and assignment

Assignment of incidents and service requests is a "gap" in Service Manager. A traditional ticketing system typically includes a group selection and then individuals within that group selection. Since Service Manager doesn’t provide inter-field dependency, there is no connection between the enumerated list "Support Group" and the user/group relationship "Assigned To." This must therefore be implemented manually or using a template setting because if queues have been defined against support groups, an inaccessible incident or service request may be assigned.

Problem

Support Group and assignment of incident and service request are not related to one another.

Solution

Kurt Van Hoecke's solution on the SCUG.BE blog provides the ability to assign incidents and service requests directly to an analyst based on membership in a support group that aligns to an Active Directory security group set in the library settings. You can find the solution at http://scug.be/scsm/2013/06/23/scsm-incident-assignment-add-on/. A similar solution is commercially available from Cireson and is available from http://www.cireson.com/app-store/scsm-group-assign/.

Incident categorization

Incident classification category values must be modified in order to avoid duplicate configuration item data and to drive proper reporting/dashboards. Because these values are presented as an enumerated list in Service Manager, it is easy to modify this item. However, it is one of the most important values in incident management and also one of the most hotly debated.

Problem

The out-of-the-box classification category values included in Service Manager are an illustrative list of values meant to demonstrate the capabilities of the product. These out-of-the-box values are:

▪ E-Mail Problems

▪ Networking Problems

▪ Printing Problems

▪ Software Problems

▪ Hardware Problems

▪ Configuration Data Problems

▪ Enterprise Application Problems

▪ Other Problems

Category values can be a politically charged discussion because of their intended use and governance issues. In legacy ITSM solutions, category was often overloaded with terms like configuration item, service, problem (misused), organization, and even resolution. This was the world of ticketing. But with the onset of ITIL, ITSM best practices, and modern software development, most modern ITSM solutions use:

▪ Configuration item for the exact item or items the incident is about

▪ Service for the exact service or services the incident is about

▪ Resolution codes for how the incident was resolved

What still remains, however, is to use a classification category to describe the incident itself rather than what it is about.

Solution

The classification category should describe the incident itself rather than what it is about. And if true self-service is a goal when implementing Service Manager, as it should be, classification category should be expressed in terms businesses and customers can understand. Simplicity is the key here. The following are some recommendations for incident classification:

▪ Keep the number of values to a minimum. A common rule is 10 x 10, which means no more than 10 parents with 10 children each. This helps facilitate reporting along classification category values.

▪ Eliminate other as an option.

▪ In non-IT terms, follow the KISS Principle.

▪ Minimize opportunities for overlap (e.g., a printer problem could be a hardware problem).

▪ Do not include the term problem in the value unless it is absolutely asked for by people outside of IT. Problem as a term has specific meaning in problem management.

▪ Classify the incident, not what it is about (that’s what configuration item and service are for).

▪ The process should seek to eliminate the need to change it more than once (a performance category should apply to both configuration item and service). If it is changed more than once, consider this a process failure.

Below are some recommended configurations in this area. These configurations have worked well for some organizations and can been modified and extended for your own.

▪ Access Parent container and general value for access-related incidents

• Access Denied Incidents as a result of Access Denied message

• Permissions Indication that user doesn’t have proper permissions

• Password Problem Password-related errors (not including password reset)

• Login Failed User and system-related login failures

▪ Fault/Failure Parent container and general value for faults or failures

• Alert Used for System Center Operations Manager alerts

• No Power Power-related issues

• Feature Failure Failure of a feature of service

• No Response No response issues

• Communication Communication issues

• Frozen Frozen service

▪ Performance Parent container and general value for performance-related issues

• Response Time Response time

• Outage Outages (can be confused with Failure)

▪ Data Parent container and general value for data-related issues

• Lost Data Missing or lost data

• Quality Quality of data issues

Customizations

Customizations take place outside of the Service Manager console and involve something being created and/or imported externally to the console. Customizations are almost always XML based using the Service Manager Authoring Tool, Visual Studio, Blend for Visual Studio, or other XML editors and development tools. They can also come from community-contributed or partner-provided management packs. The following customizations are described in the sections below:

▪ Work item custom labeled fields

▪ Notification Boolean

▪ Assignment notification for all work items

▪ More information needed and possible problem

▪ Location on form

▪ On Behalf Of on form

▪ VIP incidents and requests

▪ Change requests submitted from the self-service portal

▪ Change phase in change views

Work item custom labeled fields

When creating Service Manager request offerings, while defining the request, you must map user inputs from the Self-Service Portal to properties and relationships in the incident, service request, or child activities associated with the request offering. The challenge comes when there are more user inputs in the request offering than properties and relationships to support them in the related template.

Problem

The out-of-the-box work item classes (incident, request, change, and activity) have predefined fields and relationships. They do not have custom or generic properties, nor is there a means of displaying them for mapping request offering prompts.

Solution

Extend work item classes (particularly service request and incident, and also activity if necessary) with generic custom fields and text labels so the label can indicate that the property is purposed.

Customize the work item form with a custom fields tab that includes labels. Since the fields can be purposed differently, however, they should not be included in the data warehouse for reporting.

You can extend work item classes using the data types shown in Table 7-1. The custom field has the specified data type shown while the label is always a string.

TABLE 7-1 Properties and data types for extending work item classes for custom labeled fields

Customize the respective form and create a new tab on the work item (Service Request Form is used in the example shown in Figure 7-1) and position all of the fields in a table. Place the text label strings (Lbl) above the custom fields. Remember that the authoring tool records all updates to the form and "replays" them when the form is rendered.

FIGURE 7-1 A custom fields tab of a service request.

When creating templates, you can pre-populate the custom label fields by using the Extensions tab at the top of the template form, as shown in Figure 7-2.

FIGURE 7-2 The Extensions tab of a service request.

When an instance of the work item is viewed by a user from the console, the fields with labels are used and the ones without labels are not. These properties can then be used by workflows in Orchestrator and in notifications.

Notification Boolean

Service Manager can send an email message on virtually any condition or trigger in the system. However, in certain scenarios, you might want to turn notification on or off with a template (as a default value) instead of enabling or disabling notifications. You might also want to do this on a per-work-item basis.

Problem

You need to be able to turn off notification on a per-template or even per-work-item basis.

Solution

Extend the work item with the new property NotifyYN. This property has a Boolean data type and the default value should be set to True.

Next customize the form to include "Notify Y/N" as shown in Figure 7-3. Include NotifyYN equals True in all notification criteria, including any management packs that provide notification from external providers.

FIGURE 7-3 A service request with a modified form.

Assignment notification for all work items

Configuring subscriptions in Service Manager provides the ability to send notifications based on specified criteria. Unfortunately there is no means of triggering notification based on any assignment change from the console. Non-specific subscriptions are often desired for assignment change notifications of incidents, service requests, changes, and activities so that a notification subscription for each assignment group is not needed. Defining discrete assignment notifications per assignment group is not recommended because that could become a performance issue in the workflow engine.

Problem

There is no means to configure modular notifications based on assignment change, and a large number of discrete notification workflows can cause performance issues.

Solution

There are a number of commercially available solutions for this problem as well as some custom solutions described in the Service Manager blog on TechNet. For example, there is a free and licensed version of notification from Microsoft Partner Cireson at http://www.cireson.com/app-store/. The only issue with this is that if other logic, such as NotifyYN, is applied to notifications on assignment, it won’t be checked. However, this is not common with assignment notifications.

Several easily implemented, open assignment notifications have been published in TechNet blog posts. Specifically, a blog post for incidents can be found at http://blogs.technet.com/b/servicemanager/archive/2009/12/15/custom-notification-workflow-on-incident-assignement-or-re-assignment.aspx?PageIndex=2, and a blog post for activities can be found at http://blogs.technet.com/b/servicemanager/archive/2010/03/12/custom-notification-workflow-on-activity-assignment-or-reassignment.aspx.

The Microsoft community has also created notification management packs for Service Manager request and release work items (see http://www.bctechnet.com/scsm-notification-workflow-on-work-item-assignments-part-2/). Because these are unsealed management packs, you can add logic to the XML to test a Boolean such as NotifyYN or other logic.

More information needed and possible problem

Commonly, issues exist between different escalation levels of a service desk. All too often the service desk quickly transfers an incident to a second level resource, and the second level resource sends it back, indicating there isn’t enough information in the incident or request to complete it.

Since this scenario indicates a process defect, there should be a capture of information any time an incident that hasn’t adequately followed good first level resolution procedures is passed along to second or third level resources. Furthermore, to drive improvement of first level service desk personnel, there should be a capture of what information is required in order to escalate. This can be in the form of a text property in the incident or a related knowledge article.

To further complicate matters, there is usually no means by which to alert problem management that a possible problem exists based on the incidents that are coming into the service desk.

Problem

Other than the action log, there is no means for highlighting inadequate information sent from higher support tiers back to lower ones, nor any means to highlight the possible problem.

Solution

To address this problem, extend work item classes with the properties shown in Table 7-2.

TABLE 7-2 Properties and data types for extending work item classes when more information is needed and for identifying a possible problem

Customize the incident form on the Resolution tab to include Possible Problem, Inadequate Information, and Inadequate Information on the form.

Set up a trigger to notify the problem manager when an incident is saved with Possible Problem checked.

Set up a trigger to notify the incident manager when an incident is saved with Inadequate Information checked.

Establish a view of incidents for problem managers and analysts so they can see all active and resolved incidents where a possible problem has been flagged.

Location on form

An incident or service request frequently includes either editable properties for location or information about where one can find the person when servicing the incident or request. But in our mobile world, what is recorded in Active Directory may not always be accurate. In service management, an incident or service request therefore needs dynamic properties that contain the location information about the affected user and the particular work item.

Problem

The location needs to be overwritten for an incident or request when the customer (the affected user) is not at their normal location, for example in the case of a remote worker or traveling employee.

Solution

To address this problem, create properties that map from user information such as department, location, office, or other customer properties in Active Directory. This information should be bound to the properties in the work item in such a way that they are populated with Active Directory information but can also be modified if necessary. This requires a OneWay binding between the work item location property and the user location in Active Directory.

The following binding modes are available in the authoring tool for editing forms:

▪ OneWay This binding mode causes changes in the source property to automatically propagate to the target property, but changes to the target property are not propagated back to the source property. This type of binding is appropriate if the control being bound is implicitly read-only.

▪ TwoWay This binding mode causes changes to either the source or target property to automatically propagate to the other. This type of binding is appropriate for editable forms and other fully-interactive user interface scenarios.

▪ OneWayToSource This binding mode is the reverse of the OneWay mode and updates the source property when the target property changes. You might use this, for example, if you only need to re-evaluate the source value from the user interface.

▪ OneTime This binding mode causes the source property to initialize the target property, but any subsequent changes do not propagate. This means that if the data context undergoes a change or the object in the data context changes, then the change is not reflected in the target property. This type of binding is appropriate if the data is static or if you are using data where a snapshot of the current state is appropriate to use.

On Behalf Of on form

Customers often have users with administrative assistants, as well as situations when a user’s computer is unable to access the Self-Service Portal and he or she wants to submit "on behalf of" another person. This is accomplished by leveraging the already existing relationship for Requested By in incidents and service requests and simply exposing it in the forms.

Problem

Need to add On Behalf Of for the affected user for incidents and service requests.

Solution

Incidents and service requests already have a relationship called Requested By User that can be used for this purpose. Alternatively, an additional relationship can be added to the class. The forms can then be modified to include another user picker as in the Requested By field in the form shown in Figure 7-4.

FIGURE 7-4 An example of a Requested By user picker.

This user relationship for Requested By can be included in any notifications along with the affected user. It will simply be ignored if the relationship doesn’t exist.

VIP incidents and requests

A very common need in ITSM is identifying important individuals in leadership, representatives, and power users. Often they need to be given "VIP Status" because of who they are and why they are contacting the service desk.

An effective incident and service request process should not automatically escalate impact or urgency just because an individual is a VIP. These callers should, however, be given the option to indicate their VIP "management override" in order to get higher priority. Procedurally, they should be offered standard status based on impact and urgency, but given the opportunity to trump priority based on their VIP credentials.

Problem

Service Manager doesn’t provide a means of identifying VIP users.

Solution

To address this issue, extend the User object with a text property for special status (this can be used for more than just VIP). Indicate "Special Status" or "VIP" in the text field.

Customize the incident or service request form to provide a label that is bound to the affected user special status. Use coloring such as red to highlight it on the screen.

Add a VIP value for Urgency or Impact, depending on how the organization wants to define terminology, and set priorities accordingly for the VIP row or column in the table.

Submitting change requests from the Self-Service Portal

Customers frequently request the ability to create change requests from the Service Manager Self-Service Portal. This capability is not provided out of the box, and one could argue that this is actually not a bad thing. Change management should strive for a high level of quality. That means proper intake, execution, and completion of changes. If this isn’t taking place, change management is not working properly. The idea here is that service requests make a good change request intake mechanism for several reasons:

▪ The end user can be asked a series of change questions as a request offering, and information can be captured and used when the requested change is implemented.

▪ Changes that should have never been submitted can be eliminated via service requests, allowing for better optimization of the change management process.

Problem

Submitting change requests via the Self-Service Portal is not possible out of the box.

Solution

The solution requires at least one service request template and one change request template. System Center 2012 Orchestrator is also required.

The template shown in Figure 7-5 is a real-world example where a customer wanted IT managers to:

▪ Complete a review of a submitted change (as manual activities) to decide on a category, and add and update the change request and activities.

▪ Automatically proceed with the change request when two managers or at least 33 percent of all assigned approvers have approved the change.

The service request contains a dependent activity (DA) which keeps the service request "in progress" until the change is completed and then completes the dependent activity and finally the service request.

FIGURE 7-5 Service request template to create a change request using Orchestrator.

Note that the final activity in the Service Request is a dependent activity. This "holds" the service request in "in progress" and is completed or failed using a runbook from the related change.

As Figure 7-6 shows, the first runbook is triggered when the service request-based change request is approved and the appropriate change request is created. As the figure shows, different types of changes can be created from the contents of the service request.

FIGURE 7-6 Runbook to create a change request from a service request.

The runbook also links the service request and change request (see Figure 7-7) so that when the change is completed, another runbook can be leveraged to complete the dependent activity in the service request (see Figure 7-8).

FIGURE 7-7 Runbook activity to create a change request.

FIGURE 7-8 Runbook activity to create a relationship between a service request and a change request.

The change request template should include an appropriate set of activities and a runbook activity at the end that finds the related service request, finds the dependent activity, and completes it as shown in Figure 7-9.

FIGURE 7-9 Runbook activity to complete a dependent activity in a related service request.

Change phase in change views

In one real-world customer scenario, a change manager wanted to view change requests grouped by phase or stage of the change. Change requests in Service Manager can be New, Submitted, In Progress, Failed, Cancelled, Completed, or Closed, and changing these status options is not advised since they are driven automatically by change management workflow.

Ideally, similar to service requests, change requests should go from New to In Progress to Complete to Closed. In reality however, change requests typically have a staged lifecycle and different levels of governance and review based on change category. Here are some examples of definitions taken from the Microsoft Operations Framework (MOF) and from the experience of the authors:

▪ Standard change This category is low risk because it has a proven set release path. It has minimal business impact and a known set of release procedures. Typically, standard changes do not include review activities for approval.

▪ Minor change This category typically affects only a small percentage of users and resources. Also, the risk of an outage is less because of the organization’s experience in implementing this type of change. Minor changes are low-risk, low-scope changes that require only a minimal amount of management oversight. Minor changes should be targets for becoming Standard changes and usually require a single level of approval (e.g., Deployment CAB or Change Manager approval).

▪ Significant change This category has a moderate effect on users, resources, and the business. It might involve downtime of services and may also involve a situation in which the organization has less experience with the product, infrastructure, or the client involved in the change. Significant changes do not include business approval and are for high-risk, high-scope changes. Often, significant changes can be modeled or created via a template (Microsoft calls these Known Change Types) and have multiple levels of approval (e.g., Technical CAB and Deployment CAB).

▪ Major change With both high risk and high cost, this category involves the greatest potential impact to users and resources. It might also affect a business-critical systems and could involve downtime of the service. Major changes involve the business (external to IT, or COOP, etc.) if services are being changed, added, or removed and have a material impact on business. These changes are typically minimally modeled or created via a template and have multiple levels of approval (e.g., Planning CAB, Technical CAB, and Deployment CAB).

▪ Emergency change This category is high risk because of the urgency of release and the minimal time available to test the change. It is relatively uncertain if the change will succeed, and there is a big impact on the business if it fails. This type of change is often a result of an urgent incident. These changes are escalated to the Emergency CAB for fast-track approval.

▪ Unauthorized change Unauthorized changes should be tracked when they are detected to report and minimize their occurrence. This level involves changes that occur outside of the agreed-to change management policies or changes that are specifically forbidden. Activities should focus on correcting the CMS or backing out the unauthorized change, depending on what makes business sense.

You can use the enumerated list values of the Stage property to identify phases by the activities of the change request. Out of the box, these values include Initiate, Approve, Develop, Test, Release, and Validate and Review. Since this is an enumerated list, these values can be modified, but it's important to note that they are used by all activities across all work items.

Problem

There is a need to group change requests into views based on the stage of the change request.

Solution

To address this need, confirm the enumeration list values for activity stages, then extend the Change Request property with a text field. For example, it might be called Change Request Stage.

Customize the change request form to view Change Request Stage as a label (non-editable).

Monitor completion of activities that are child activities of a change request, and if the value of Stage is set to something other than blank, set the Change Request Stage of the parent change request to the stage specified in the activity.

Create or modify a change request view to group changes by Change Request Stage.

Additional resources for configuration and customization

Many great sources offer numerous other configuration and customization options. The source identified in the previous sections are not so common and involve Microsoft recommendations for best use of Service Manager.

To find almost any customization management pack for Service Manager, simply use Bing or some other search engine to search for SCSM 2012 <functionality sought>. For example, a search for:

SCSM 2012 incident auto closure after five days

brings up as its first result an article titled "SCSM 2012: Auto Close resolved incidents after x days" from the System Center User Group Belgium website. Often, multiple possible solutions can be found in this way.

Also, a System Center 2012 Service Manager Survival Guide links to TechNet articles and to many blogs where you can find community-contributed management packs that close up gaps in the solution. You can find the Survival Guide at http://social.technet.microsoft.com/wiki/contents/articles/8113.system-center-2012-service-manager-survival-guide.aspx.

Customization risk areas

The customization of Service Manager is not without risk. Customizing or even configuring any process-centric system, such as Service Manager, can create a number of inherent risks that the guidance in this book is intended to minimize. These risks can include:

▪ Not using properties and relationships for their intended purposes, thereby invalidating some of the out-of-box workflow, reporting, and analysis capabilities of Service Manager (e.g., classification and support groups on incident management).

▪ Driving inefficient or risky work patterns in both human and system-centric processes.

▪ Making modifications that might limit future upgradeability and supportability of the solution.

One of the design criteria Microsoft had for Service Manager was to specifically address the third risk mentioned above, which is one of the industry’s biggest issues, that is, allowing customer modifications to the functionality of the system in a way that won't limit the ability for the system to be upgraded and supported. By keeping customer configurations and customizations within management packs, Service Manager is able to preserve and separate customer specific settings, workflows, and notifications, from the underlying Service Manager engine provided by Microsoft.

However, neither Service Manager nor any other ITSM solution can completely mitigate the first two risks since these are design and implementation choices made by the customer. It's very important, therefore, to understand the desired outcome of a Service Manager implementation. Having knowledge of only a legacy ITSM tool is dangerous to take into a new Service Manager deployment.

Orchestrator versus Authoring Tool for workflows

Workflow can be accomplished in Service Manager through several different means:

▪ Activities in Service Request, Change, and Release Management Incident work items can have activities, but there is no capability to sequence them and any activities go into "In Progress" immediately.

▪ Workflow Settings in Administration These are work-item specific and you can change property and relationship values only through the application of templates. Notifications can be configured, but this should be done only when the notification is desired in conjunction with the template.

▪ Service Manager Authoring Tool This tool provides a graphic workflow design based on Windows Workflow Foundations (WWF). Most workflow configuration is done through .NET or Windows PowerShell scripts.

▪ System Center Orchestrator Formerly known as Opalis Runbook Automation, Orchestrator provides an Integration Pack for Service Manager.

Although using the Service Manager Authoring Tool for workflow is still supported through Service Manager 2012 SP1, with the acquisition of Opalis (Orchestrator), no further enhancements are planned for workflow in the Authoring Tool. Microsoft therefore recommends that Orchestrator always be implemented along with Service Manager. Because Orchestrator is a scalable solution, only a small footprint is needed for Service Manager-specific automation. Broad Orchestrator implementation can come later where the larger benefits of Orchestrator can be realized, which can be significant.

Some other benefits of using Orchestrator instead of authoring workflows using the Authoring Tool include:

▪ Orchestrator runbooks that leverage the Service Manager Integration Pack require less time and knowledge of Windows PowerShell and scripting.

▪ There is better error/fault handling in Orchestrator in case the runbook should fail.

▪ Authoring workflows using the Authoring Tool will result in a management pack and DLL file. The management pack must then be imported into Service Manager, and the DLL deployed to all management servers.

Below is an example of some Windows PowerShell that can be used to "close" completed, failed, or cancelled service requests as well as resolved incidents:

cd 'C:Program FilesMicrosoft System Center 2012Service ManagerPowershell'
Import-Module .System.Center.Service.Manager.psd1

$SomeDaysOld = (get-date).adddays(-7)
$UNC_Now = (get-date).ToUniversalTime()
$IncidentClass = Get-SCClass -Name System.workitem.incident
$Inc_resolved = Get-SCClassInstance -Class $IncidentClass -Filter "Status -eq
IncidentStatusEnum.Resolved" | ?{$_.ResolvedDate -lt $SomeDaysOld}

If ($Inc_resolved -ne $null)
{
foreach ($Inc in $Inc_resolved)
{
$Inc.Status = "bd0ae7c4-3315-2eb3-7933-82dfc482dbaf"
$Inc.ClosedDate = $UNC_Now
Update-SCClassInstance -Instance $Inc
}
}

$SRclass = Get-SCClass -Name System.WorkItem.ServiceRequest
$SR_completed = Get-SCClassInstance -Class $SRclass -Filter "Status -eq
ServiceRequestStatusEnum.Completed" | ?{$_.CompletedDate -lt $SomeDaysOld}
$SR_failed = Get-SCClassInstance -Class $SRclass -Filter "Status -eq
ServiceRequestStatusEnum.Failed" | ?{$_.CompletedDate -lt $SomeDaysOld}
$SR_cancelled = Get-SCClassInstance -Class $SRclass -Filter "Status -eq
ServiceRequestStatusEnum.Cancelled" | ?{$_.CompletedDate -lt $SomeDaysOld}

If ($SR_completed -ne $null)
{
foreach ($SR in $SR_completed)
{
$SR.Status = "c7b65747-f99e-c108-1e17-3c1062138fc4"
$SR.ClosedDate = $UNC_Now
Update-SCClassInstance -Instance $SR
}
}
If ($SR_failed -ne $null)
{
foreach ($SR in $SR_failed)
{
$SR.Status = "c7b65747-f99e-c108-1e17-3c1062138fc4"
$SR.ClosedDate = $UNC_Now
Update-SCClassInstance -Instance $SR
}
}

If ($SR_cancelled -ne $null)
{
foreach ($SR in $SR_cancelled)
{
$SR.Status = "c7b65747-f99e-c108-1e17-3c1062138fc4"
$SR.ClosedDate = $UNC_Now
Update-SCClassInstance -Instance $SR
}
}

Remove-Module System.Center.Service.Manager

The above script would have to be run as a scheduled task either through the Service Manager workflow engine or as a server-based scheduled task. The same functionality can be provided through Orchestrator by using a runbook that leverages the Service Manager Integration Pack. The sample runbook shown in Figure 7-10 includes only resolved incidents and completed services requests; adding failed and cancelled service requests would require only a few more activities in order to be functionally equivalent to the Windows Powershell script above.

FIGURE 7-10 Runbook activity to close both completed service requests and resolved incidents.

The Format Threshold activity in this runbook provides the ability to "offset" from current time. This is important because whenever you are dealing with dates and times in Orchestrator and manipulating data in Service Manager, the date/time data is stored as UTC. You therefore should use the UTC option in Orchestrator. In Figure 7-11 the offset is "-5" which subtracts five days from the end of the previous activity time.

FIGURE 7-11 Runbook activity to subtract five days from current date/time.

The SCGetObject activity can be used to select service requests and incidents that meet the criteria of "Resolved" for incidents and "Completed" for service requests and respective dates greater than five days prior. Other criteria could also be added if necessary.

FIGURE 7-12 Runbook activity to get all resolved incidents that have been resolved five days prior than current date when running the runbook.

Finally, the UpdateObject activity can be used to update the work item. It's important to update Closed Date with the current UTC date and time since that is not set automatically.