You are browsing the archive for 2010 September.

Avatar of kurtvh

by kurtvh

System Center Service Manager Cumulative Updates overview (CU3 released)

10:05 am in Uncategorized by kurtvh

Hello,

With this blog I want to provide an overview of the updates that are released the last months for System Center Service Manager 2010.

Begin of July 2010 the CU1 was released that included a limited set of fixes. KB information is still available – Description of Cumulative Update 1 for System Center Service Manager 2010

Begin of August 2010 the CU2 was released. It supersedes Cumulative Update 1 (CU1) and contains a superset of the fixes that are provided in CU1. It can be applied to CU1 or directly to a Service Manager 2010 installation. More information about this CU2 is available on MS Website -  Description of Cumulative Update 2 for System Center Service Manager 2010

The CU3 is released half September 2010. Same approach as the CU2, it supersedes Cumulative Update 2 (CU2) and contains a superset of the fixes that are provided in CU2. It can be applied to CU2 or directly to a Service Manager 2010 installation. Download and detailed information can be found on:

Pay attention on the installation of the CU3 for Service Manager, if you have the authoring tool installed an additional step is required to update the whole system. Little overview:

To install this cumulative update:

  1. Exit all Service Manager-related applications before you apply this cumulative update.
  2. Right-click the SCSM2010_RTM_X86_KB2390520.exe file or the SCSM2010_RTM_AMD64_KB2390520.exe file, and then click Run as administrator.
  3. Accept the Microsoft Software License Terms, and then follow the steps in the installation wizard.
  4. For the Data Warehouse Management Server, you have to manually start the System Center Management service after the cumulative update installation is finished.

On the systems that have the Service Manager Authoring Tool installed, follow these steps to update the management packs in the Authoring Tool’s Library folder:

  1. Download the KB2390520_MPLibraryUpdate_AuthoringTool.exe file from the Cumulative Update 3 download page to the local computer on which the Authoring Tool is installed. (Link provided above)
  2. Double-click KB2390520_MPLibraryUpdate_AuthoringTool.exe, and then wait for the files to be extracted.
  3. Browse to the folder %SystemDrive%\Microsoft System Center\Service Manager 2010\hotfix_KB2390520\AuthoringToolMPUpdate.
  4. Copy all files from that folder to the <Authoring Tool installation drive>\Program Files (x86)\Microsoft System Center\Service Manager 2010 Authoring\Library\ folder, replacing the existing files.
  5. If the Authoring Tool is running, restart it to load the updated management packs.

Have fun,

Kurt Van Hoecke

Avatar of kurtvh

by kurtvh

SCSM: Automate Status update in Incident Management

3:07 pm in Uncategorized by kurtvh

Hello,

The Status of an Incident in Service Manager is triggered on a certain action. It can be needed that more granular Incident Status levels are required for your environment. In this post I’m going to explain how we can extend the Incident status levels and how we can automate Status level update with a workflow when certain fields in the Incident Form are updated.

First, look at the default list in the Service Manager console – Library | Lists | Incident Status

As an example, the default list is extended with the following Status levels as sub status of the Active status: (Create a mgmt pack to store the console configuration)

  • Listed: is the default status in this example
  • Assigned: When the Incident is “assigned” (Assigned to field)
  • In progress: When the Incident has an “Owner” (Primary Owner field)

image   –> image

Once the status levels are defined, one Incident Template must be created for each status level that is added to the list.

Create the Incident Status Templates:

In the Service Manager console – Library | Templates | Create Template

  • Store the configuration is the just created mgmt pack.
  • The “Status” field is visible now and status can be set for the template.

         image

  • Repeat this procedure for the “In progress” and “listed” status.

Create the status update xml file:

The creation of the xml file is more or less the same as explained in following blog post: Custom notification workflow on incident assignment or re-assignment

  • Use your own naming in order to recognize that function of the mgmt pack.
  • The “Here is some explanation of some of the sections of the Management pack to better understand the “how” is the information where this mgmt is based on.
    • All info explained in this section can be used for this mgmt pack.
    • The Monitoring Section of the xml needs to be changed in order to get this functionality in SCSM.

Monitoring section of the XML file:

In order to start updating the monitoring section of the xml file it is important to gather the info of the fields that trigger a status update. For certain Incident Form fields it is possible to accomplish the goal by editing the rules in the ‘Incident Event Workflow’.  The wizard there only supports certain subscription criteria:

  • If a property field of the System.WorkItem.Incident triggers a status update, then the console can be used.
  • If relationship properties triggers an update, then xml coding is required.
  • SCSM product team is busy creating a complete model diagram. This will be your main source for finding this information. (I will update this post when this info is published.)
  • In this example the AssignedToUser property triggers the “Assigned” status of the Incident. The AssignedToUser property is and example of the relationship properties and needs xml editing.

As explained in the blog post above, in the Monitoring section we define the Rules. Each rule in generally includes a DataSource and WriteAction section.

  • DataSource define discovery of the instances based on certain criteria
    • In this case we want to discover any incident for which the “Assigned to” user is changed
    • “Assigned To” user is a relationship on the Incident – So whenever the assignment is changed the existing relationship is deleted and a new relationship is added
    • The criteria below discovers all instances of incidents for which a “AssignedTo” Relationship was added
  • WriteAction defines the “action” you want to perform on each instance that was discovered by the rule

DataSource section:

The following xml code creates a relationship subscription for the AssignedToUser relationship on the Incident.

<DataSources>
          <DataSource ID="DS" TypeID="SystemCenter1!Microsoft.SystemCenter.CmdbInstanceSubscription.DataSourceModule">
            <Subscription>
              <RelationshipSubscription RelType="$MPElement[Name='WorkItem!System.WorkItemAssignedToUser']$" SourceType="$MPElement[Name='CustomSystem_WorkItem_Incident_Library!System.WorkItem.Incident']$" TargetType="$MPElement[Name='System!System.Domain.User']$">
                <AddRelationship>
                </AddRelationship>
              </RelationshipSubscription>
              <PollingIntervalInSeconds>10</PollingIntervalInSeconds>
              <BatchSize>100</BatchSize>
            </Subscription>
          </DataSource>
        </DataSources>

For the other status (In progress) in the example used for this blog the RelationshipSubscription needs to be modified. PrimaryOwner is the property that triggers the status update.

<RelationshipSubscription RelType="$MPElement[Name='WorkItem!System.WorkItemPrimaryOwner']$" SourceType="$MPElement[Name='CustomSystem_WorkItem_Incident_Library!System.WorkItem.Incident']$" TargetType="$MPElement[Name='System!System.Domain.User']$">
                <AddRelationship>
                </AddRelationship>
              </RelationshipSubscription>

WriteAction section:

The following example updates the Incident status by applying the Incident Template. So, the same xml code can be used for both status updates, only the Template GUID must be changed.

To find the Template GUID:

  • In order to get the GUID for your own template from the DB you can use a simple query
  • "select Objecttemplateid from ObjectTemplate where ObjectTemplateName=’< Template Name here >’

<WriteAction ID="WA" TypeID="SystemCenter1!Microsoft.EnterpriseManagement.SystemCenter.Subscription.WindowsWorkflowTaskWriteAction">
            <Subscription>
              <EnableBatchProcessing>true</EnableBatchProcessing>
              <WindowsWorkflowConfiguration>
               <AssemblyName>Microsoft.EnterpriseManagement.ServiceManager.Incident.Workflows</AssemblyName>
               <WorkflowTypeName>Microsoft.EnterpriseManagement.ServiceManager.Incident.Workflows.

AutomaticIncidentChangeWorkflow</WorkflowTypeName>
                <WorkflowParameters>
                  <WorkflowArrayParameter Name="InstanceIds" Type="guid">
                    <Item>$Data/BaseManagedEntityId$</Item>
                  </WorkflowArrayParameter>
                  <WorkflowParameter Name="IncidentTemplate" Type="guid">8bf7765f-f372-debb-f924-e1ebd2ec7ac6</WorkflowParameter>
                  <WorkflowParameter Name="NotificationRulesEnabled" Type="boolean">False</WorkflowParameter>
                </WorkflowParameters>
                <RetryExceptions />
                <RetryDelaySeconds>60</RetryDelaySeconds>
                <MaximumRunningTimeSeconds>7200</MaximumRunningTimeSeconds>
              </WindowsWorkflowConfiguration>
            </Subscription>
          </WriteAction>
        </WriteActions>

In this way we can create a complete mgmt pack that takes control over the Incident Status updates. (like the default defined Incident Status entries like Active, Closed or Resolved)

I will post the complete xml file that can be used as an example to create your own. The xml file includes the workflows to update the three custom status levels.

Have fun with it!

Kurt Van Hoecke