The objective of Problem Management is to resolve the underlying root cause of incidents and consequently prevent incidents from recurring [ITIL]. Proactive Problem Management aims to identifying and solving Problems and Known Errors before the incidents occur.
The Problem Management Process Management Pack provides basic capabilities to document problems, link incidents and research the problems through basic search capability. Though it does not provide any workflows but the partners could extend it to include automated workflows to automate aspects of problem management process.
Some of the key terms associated with Problem Management are:
- Problem: ITIL defines a ‘problem’ as the unknown cause of one or more incidents.
- Incident: Any event that is not part of the standard operation of a service and causes, or may cause, an interruption to, or a reduction in, the quality of service (e.g. a service being unavailable or hardware failure). The incidents are stored in incident records.
- Error: A fault, bug, or behavior issue in an IT service or system.
- Root Cause: The specific reason that most directly contributes to the occurrence of an error
- Known Error: is a Problem that is successfully diagnosed and for which a work-around has been identified
- Known Error Database: A subsection of the knowledge base or overall configuration management s database (CMDB) that stores known errors and their associated root causes, workarounds, and fixes.
- Personas:
- Problem Analyst: Typically the person working to find underlying root causes of the incidents through investigation and diagnoses.
- Problem Manager: Typically a person identifies problems from incidents in order to prevent future incidents
A typical Problem Management Process Flow
In version 1 Service Manager offers basic problem management capabilities that includes basic customizations, problem creation from multiple incidents, capturing known errors, workarounds, problem review flag and auto resolution of linked incidents.
Customizing Problem Management
- Problem Management Settings (Administration –> Settings –> Problem Settings)
- Problem ID Prefix
- Number of Attachments and maximum size of attachments
- Problem Priority mapping
- Problem Classification (Library –> Lists –> Problem Classification)
- Problem Source (Library –> Lists –> Problem Source)
- Problem Status (Library –> Lists –> Problem Status)
- Problem Resolution (Library –> Lists –> Problem Resolution)
Linking Incidents to Problem or Creating a Problem from Incidents
Given below is one of the ways of creating problem record:
- Select “All Incidents” View or a you could select a particular Queue
- In the example shown below I have used filter to narrow down the incidents
- Note: You can used Advanced Search for incidents that allows you to provide more complex criteria on more properties of Incident
- Select all the filtered incidents
- Then Click Create Problem in the Task Pane
- This should open up the Problem Form with all the Incidents selected in Step 3
Problem Form and Problem Management Workflow
- The Problem Form will have all the incidents automatically linked to the problem record.
- In this case since Title and description of the problem is not captured since there were several incidents.
- You can also add the “Affected Service or Affected CI” if problem is about a particular configuration Item
- Problem Form allows you to capture known errors and workarounds.
- The problem management workflow shipped out of the box, allows you to auto resolve the linked incidents. In order to use this functionality you simply need to check the box “auto resolve” incident in the “Resolution Tab” for the Problem Form.
This post is the second in the series of implementing a sample helpdesk scenario in Service Manager.
Please refer to this earlier post for details on configuring Incident Management
Implementing Sample Helpdesk Scenario in Incident Management - 1
I’ll recap the sample scenario for reference
1. Joe analyst is a member of the Tier2 staff that is responsible for resolving incidents in the SQL and Network services the Ops team offers. There are 7 tier 2 analysts divided up handle incidents in each of the services the ops team offers. There are also Tier 1 and 3 analysts responsible for ops team’s services.
2. Joe analyst is associated with the SQL and network Queues. The SQL Queue has all incidents classified as SQL or the child SQL categories. Example: SQL parent classification category, SSRS, DB Management, Data replication are child categories.
3. SERVERXYZ SQL reporting services stop and Sally with the Service Desk (Tier1) creates an incident ticket for the server and needs to route the incident ticket. The incident classification is SQL parent, SSRS as child. The ticket is automatically routed to the correct queue via a workflow.
4. Joe analyst gets an email that a SQL incident 62 is created for SQL/SSRS and is unassigned. Joe analyst opens the console, looks at his SQL unassigned incidents view and assigns the ticket to himself.
In the prior post we did the basic customization of Incident Management, by creating custom category, templates and queues. Now we will use those customizations in this post and cover these topics:
1. Create Workflow so that all the incidents for SQL Issues are automatically assigned to Tier 2 Support Group (Optional step in this scenario)
2. Add the user Joe to the “Incident Resolver” role so that he has appropriate access.
3. Create a view for all “unassigned” incidents in the SQL Queue
4. Create a notification workflow that notifies Joe whenever an incident is created in the SQL Queue
1. Create workflow to route all the Incidents for SQL Issue to Support Group Tier 2 (Optional step)
In this scenario this step is optional, in the sense Sally could use the template that we created in the earlier post, and the template automatically sets the support group to Tier 2. Note that SQL Queue created in the earlier post is based on Classification categories and not on support group, as the Tier 2 staff could be responsible for more than one queue.
Let’s assume Sally doesn’t use the template and just sets the appropriate classification category to SSRS i.e. SQL Server Reporting Services:
a. Click on the Administration workspace
b. Navigate to Workflows -> Configuration
c. Select the Incident Event Workflow and Click on the Properties in the Task Pane
d. Now click Add to add a new Incident Event Workflow
e. Type in the name for Workflow and select the event “When incident is created”
f. Go through the wizard and set the criteria – such that if the classification category is any of the SQL issues or a Networking issue
g. Select the template SQL or Networking issue template that we created in the earlier post
h. Do not check the notification in this case, as we are going to setup notification for Joe separately.
2. Add the user Joe to the Incident Resolver role, so that he has appropriate access
a. Click on the Administration workspace
b. Navigate to Security -> User Roles
c. Select the Incident Resolver Role and click on the Properties in the Task Pane
d. Navigate to the “Users” in the left hand navigation pane of the property sheet
e. Add the user Joe to the role
3. Create a view for all “unassigned” incidents in the SQL queue
a. Click on the Work Items workspace
b. Select the Node Incident Management
c. You can optionally create a folder Tier 2 Queues (by right click on Incident Management Node and select Create Folder)
d. Select the Folder Tier 2 Queues
e. Click on Create view
f. Type in the name for the view (SQL Queue)
g. For the class click on Browse
1. In the class dialog, click on the drop down for classes and select All Combination classes
2. Type in the search box “incident” and the click on search icon
3. Select the “Incident (advanced)” class from the result set
h. Now in the criteria window click on the small expander to the left of the Incident node, this should show all the related properties on the incident
1. Select the property “Assigned to User”
2. Check username from the fields in the right window and then click Add
3. Now in the criteria box below select from the drop down “is empty”
i. Now select the criteria for Incident classification category as shown in the picture below
1. Go back to Incident node and then check the Classification Category property
j. In addition you could also add a condition if Status is equal to Active so you only see “Active” incidents
Below are the screen shot of two views -- (All Active Incidents and SQL Queue)
4. Create Notification Workflow for Joe
Before Joe can create his own notifications, you need to setup a Notification channel and a notification template.
a. In the Administration workspace navigate to Notifications -> Channel
b. Select the Email Notification channel and Click on Configure in the Task Pane
c. Enter your smtp host for the email notifications
d. Then Navigate to Notifications -> Template and create a notification template
1. You can review details here on how to create notification templates using html
Now Joe should be able to setup notifications himself
Provide these instructions to Joe to create his own notifications
a. Click on the Tools in the Menu bar
b. Select My Notifications
c. Type in the name for Workflow and select the event “When incident is created”
d. Go through the wizard and set the criteria – such that if the classification category is any of the SQL issues or a Networking issue
e. Select the template that was created in the earlier section
f. Finish the wizard
My earlier post provides a high level overview of Incident Management in Service Manager.
I also recommend reading on MOF and ITIL procesess.
The best way to learn about Incident Management in Service Manager is going through a real life scenario. I have outlined a scenario here that was requested by a customer and I have demonstrated how we fulfill this scenario in Service Manager in couple blog posts.
The scenario below tries to describe a few configuration and usability questions, mainly with the use of support groups, queues and incident classification categories.
Scenario:
1. Joe analyst is a member of the Tier2 staff that is responsible for resolving incidents in the SQL and Network services the Ops team offers. There are 7 tier 2 analysts divided up handle incidents in each of the services the ops team offers. There are also Tier 1 and 3 analysts responsible for ops team’s services.
2. Joe analyst is associated with the SQL and network Queues. The SQL Queue has all incidents classified as SQL or the child SQL categories. Example: SQL parent classification category, SSRS, DB Management, Data replication are child categories.
3. SERVERXYZ SQL reporting services stop and Sally with the Service Desk (Tier1) creates an incident ticket for the server and needs to route the incident ticket. The incident classification is SQL parent, SSRS as child. The ticket is automatically routed to the correct queue via a workflow.
4. Joe analyst gets an email that a SQL incident 62 is created for SQL/SSRS and is unassigned. Joe analyst opens the console, looks at his SQL unassigned incidents view and assigns the ticket to himself.
In this post we’ll cover:
1. Create Incident Classification categories.. (library->Lists->Incident Classification)
2. Create appropriate support groups
3. Create a template that Sally could use for all SQL incidents
4. Create a queue for all SQL related incidents
In the next post we’ll cover
· Create a notification workflow that notifies Joe whenever an incident is created in the SQL queue.
· Create a view for all “unassigned” incidents in the queue
· Add the user Joe to the “Incident Resolver” role so that he has appropriate access
Now let’s look at detailed steps covered:
1. Create Incident Classification categories
Please follow these steps to create the SQL Classification categories
a. Click on the Library workspace
b. Navigate to Library->Lists->Incident Classification
c. Click on Properties in the Task Pane
d. Add a new item SQL Issues at the parent node
e. Add the child nodes for the above parent (SSRS, DB Management, Data Replication)
f. See the screenshot below
2. Create appropriate support group if needed
The Support Group (denoted by Incident Tier Queue – I know a nomenclature mismatch – too late to change right now) is just another category that you could use to route the incident appropriately. Please note that this is not an AD group or SM Group, as there is no membership, but it is just a way of categorizing support teams so that you can create queues and route incidents. Another variance of the above could be that you could create a special support group named SQL Server Support rather than just using the generic Tier 2.
In some cases we will leave it alone and we will use the Tiers that are provided out of the box i.e. Tier 1, Tier 2 and Tier 3.
3. Create a template that Tier 1 analyst could use
In this case the template is pretty simple, but let’s create it any way just so that you can understand capability.
a. Click on the Library workspace
b. Navigate to Library->Templates->
c. Click on Create Template
d. Type in the name and description
e. Select Incident class
f. Select a Management Pack
· Note: It is advisable to create all your customizations in your own Management Pack.
· This makes your customization portable.
· You can simply import this management pack in new environment to transport your customization
g. Click OK – This should launch the template form
h. Set the appropriate fields in the template
a. Support Group -> Tier 2
b. Set the Impact / Urgency -> Medium (or as needed)
c. Have also added troubleshooting steps in the Action Log Comments
i. If it is known what services or CIs are affected by this type of issue then you can select the Affected CI.
4. Create a Queue for SQL incidents
The queues in Service Manager can be used for security scoping and reporting purposes.
a. Click the Library workspace
b. Navigate to Library -> Queue
c. Click create queue and walk through the wizard:
1. Select Incident Class
2. Select a Management pack to store your customization
3. Select the criteria for – specify classification category for SQL Issues and all its child categories (as shown in the picture below)
What the heck are WFs in Service Manager Authoring Tool?
A workflow (WF) is comprised of a set of one or more activities (also referred to as a WF activity). Each workflow activity performs a function, such as joining a user or a computer to a group in Active Directory or running a script. The Workflow is primarily triggered by one of two mechanisms: schedule or event based. If it is schedule based, the WF can fire periodically based on a predetermined schedule. If it is event based, it is based on some event or state change that took place in SM DB. For example, a new incident was recently created. This may trigger a WF to publish the incident to a SharePoint site.
Why do I need a WF in Service Manager?
The user can create an incident using the Service Manger Admin console. You will be surprised to know that WFs are being used to perform the task behind the scene. The customer is just not aware of it. You can’t escape WFs in Service Manager. WF is your friendJ. So the question is really not why do I need WFs in Service Manager, but why do I need a custom WF. There may be instances like user provisioning where SM does not provide any pre-canned WFs to fill this customer scenario. Well that is when the true power of the Service Manager Authoring Tool comes in handy. You can create customized WFs leveraging some of the out of the box activities we provide in the activity toolbox. You don’t have to be a developer to do this!! It mimics a lot of the Visio like behavior whereby users just drag’n drop activities onto the WF Designer and provide the property values to each of the activities via a property pane.
How do I use a script within a WF?
WFs created using the Service Manager Authoring tool allows for an unparallel level of customization. You can’t find an activity that you can use from the toolbox, but you have an existing script that does the job and you would like to use it in the WF without having to convert it into an activity. You can do that with this tool!! We do the heavy lifting to snap to any existing script and plug it in the current WF. For now we support Windows PowerShell and CMD scripts for SM Beta 2.
|
To use a Windows PowerShell script within a WF |
|
1. Drag and Drop a PowerShell Script Activity onto the WF Design Surface
2. Click on the ellipsis next to the “Script Body” in the Activity Property Pane (This should launch the PowerShell Activity Dialog – “Configure a Script Activity”)
3. Click on “Import” if you have an existing script or you can type the script in-line
4. If the script takes input parameters, you can specify them in the next tab (Script Properties)
5. Note: You need to specify the fully qualified name of the server you plan to run the script (even if it is localhost). |
I get this question at least once a month… How do I create my own workspace? Usually this kind of question comes from partners that want to add some functionality to Service Manager and really want to elevate the presence of that solution by creating a dedicated workspace for it.
Around here we call these buttons in the lower left of the console “wunderbars”, but the official name for them is “workspaces”. Don’t ask me where the name “wunderbar” came from. If you are going to TechEd EMEA in Berlin in a couple of weeks you can practice your German by calling them “vunderbars”. :) Since wunderbar is more fun to say that workspace we’ll stick with wunderbar for this blog post.
OK, let’s get down to it. It’s really pretty easy. The only thing you really have to understand is that the entire console navigation pane is broken down into a hierarchy of folders and views. The wunderbars are just special folders! Imagine that there is an invisible root folder. Each folder that is a child of that folder is treated by the console framework as a wunderbar.
So – here is what you need to do…
1. Create a 16x16 pixel .png file with the icon you want to show when the wunderbar is “collapsed”. For this example I just created a really plain green box icon.
2. Create a 32x32 pixel .png file with the icon you want to show when the wunderbar is full size.
3. Create a new management pack .xml file and reference the System.Library and Microsoft.EnterpriseManagement.ServiceManager.UI.Console management packs.
<ManagementPack SchemaVersion="1.1">
<Manifest>
<Identity>
<ID>Microsoft.Demo.NewWorkspace</ID>
<Version>1.0.0.0</Version>
</Identity>
<Name>Microsoft Demo For New Workspace</Name>
<References>
<Reference Alias="System">
<ID>System.Library</ID>
<Version>7.0.5229.0</Version>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Reference>
<Reference Alias="Console">
<ID>Microsoft.EnterpriseManagement.ServiceManager.UI.Console</ID>
<Version>7.0.5229.0</Version>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Reference>
</References>
</Manifest>
4. Next, you need to add a couple of Category elements to categorize the Image Resources (which come at the end of the MP) into 16x16 icons and 32x32 icons.
<Categories>
<Category
ID="Category.NewWorkspaceImage32x32" Target="Image.NewWorkspace.32x32" Value="System!System.Internal.ManagementPack.Images.u32x32Icon" />
<Category
ID="Category.NewWorkspaceImage16x16" Target="Image.NewWorkspace.16x16" Value="System!System.Internal.ManagementPack.Images.u16x16Icon" />
</Categories>
This simply tells the console framework what size each icon is so that the appropriate size icon can be used in the appropriate context. Make sure your icons are essentially identical except for their size.
5. Next we will declare the folders themselves.
….Sorry, I need to switch to using images here because there is some bug on the blog site here that won’t let me upload more than a certain amount of text…. You can get this management pack from the attachments to this post if you want to copy the text.
The first folder that is declared is the “wunderbar”. It’s parent is the magic root folder of the whole console. The other folder is a child of the wunderbar and represents the root node of the navigation tree within the new workspace.
6. Next, we’ll add image references for the folders. Two for the wunderbar – 16x16 and 32x32 and just one for the root folder in new workspace – 16x16 only. These ImageReferences create the relationship between the Folders created above and the Image resources created at the end.
7. Next, we define the display strings in the Language Pack section. Please see Localizing Management Pack Content for more information on localizing management pack content.
8. Lastly, we define the Image Resources. The FileName points to a file name which is in the same folder as your management pack XML file.
9. Now that you have created the management pack XML file and the images, you need to create a management pack bundle. Read Introducing Management Pack Bundles for more information. I normally copy the New-MPBundle.ps1 script into the same folder as my XML file and image resources and then run it like this:
10. Next I need to import the .mpb file using either the PowerShell cmdlet Import-SCSMManagementPack or the Import Management Pack wizard in the console.
11. After I’ve done that, I can restart the console and then see my new workspace in the console!
This post is a continuation in the series which describes the System Center common platform components implemented in Service Manager. Previous posts:
The System Center Platform in Service Manager Part 1: Introduction
The System Center Platform in Service Manager Part 2: The Model-Based Database
The System Center Platform in Service Manager Part 2: The Model-Based Database - Try It!
The System Center Platform in Service Manager Part 3: The System Center Data Access Service
The System Center Platform in Service Manager Part 3: The System Center Data Access Service - Try It!
The System Center Platform in Service Manager Part 4: The System Center Management Service
The System Center Platform in Service Manager Part 4: The System Center Management Service – Try It!
The System Center Platform in Service Manager Part 5: The Management Configuration Service
The System Center Platform in Service Manager Part 6: The Data Warehouse
In the last post in this series, we learned about the Data Warehouse and Reporting Infrastructure. In this post, I’ll show you how you can extend the data warehouse schema to store additional data we don’t store out of the box. Then I’ll show you the quick and dirty way to write a report over that data.
For most people (including myself when I first started this project) the data warehousing terminology can absolutely sound like a foreign language. If you are going to be working with the Service Manager data warehouse I strongly recommend that you become intimately familiar with these concepts:
Out of the box, we don’t provide a dimension or facts for installed software in Service Manager 2010. It’s easy enough to add those and to create a report for it so I’ll show you how in this post. Remember the purpose of this series of blog posts on the System Center common platform is just to give you an overview of each of the pieces of the architecture and a quick example you can try on your own to get some hands on experience. There is much more that you can do with the data warehouse and reporting than what I will show in this post.
First, let’s start by creating a new management pack. Remember to save your MP so that the file name is the same as the ID of the management pack. Here is the Manifest section. You can see that we need to make a reference to the system MP and the Data Warehouse base management packs. We also need to take a dependency on the Software Library MP because that MP contains the ClassType definition of the Software Item class we are going to create dimensions and facts for. We also need a reference to the Windows Library MP because the relationship fact we are going to create is going to store which software items are installed on each computer.
Please keep in mind that this MP will only work with Service Manager Beta 2 (recently released) or later.
<ManagementPack xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" ContentReadable="true" SchemaVersion="1.1" OriginalSchemaVersion="1.1">
<Manifest>
<Identity>
<ID>Microsoft.Demo.DataWarehouse.Software</ID>
<Version>7.0.5229.0</Version>
</Identity>
<Name>DEMO - Data Warehouse Software Extensions</Name>
<References>
<Reference Alias="System">
<ID>System.Library</ID>
<Version>7.0.5229.0</Version>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Reference>
<Reference Alias="SoftwareLibrary">
<ID>System.Software.Library</ID>
<Version>7.0.5229.0</Version>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Reference>
<Reference Alias="DWBase">
<ID>Microsoft.SystemCenter.Datawarehouse.Base</ID>
<Version>7.0.5229.0</Version>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Reference>
<Reference Alias="Windows">
<ID>Microsoft.Windows.Library</ID>
<Version>7.0.5217.0</Version>
<PublicKeyToken>9396306c2be7fcc4</PublicKeyToken>
</Reference>
</References>
</Manifest>
Immediately after the Manifest section we are going to start declaring data warehouse elements. First we start with the Warehouse element which contains all of the other elements related to the data warehouse.
<Warehouse>
Inside of there the first thing we are going to do is declare an Outrigger for the Publisher Name property of the Software Item class. This will essentially create another table in the data warehouse database where each unique value in the Publisher Name property of Software Item will be stored (i.e. Microsoft, Adobe, Google, etc.) We can later use this table to drive a drop down on the report parameter header so the user can choose to only show software items from specific publishers.
<Outriggers>
<Outrigger ID="Publisher" Accessibility="Public">
<Attribute ID="PublisherName" PropertyPath="$Context/Property[Type='SoftwareLibrary!System.SoftwareItem']/Publisher$" />
</Outrigger>
</Outriggers>
Next, we’ll declare a Dimension for the Software Item class:
<Dimensions>
<Dimension ID="SoftwareItemDim"
Accessibility="Public"
InferredDimension="true" Target="SoftwareLibrary!System.SoftwareItem" HierarchySupport="Exact"
Reconcile="false">
<InclusionAttribute ID="IsVirtualApplication" PropertyPath="$Context/Property[Type='SoftwareLibrary!System.SoftwareItem']/IsVirtualApplication$"
SlowlyChangingAttribute="false" />
<InclusionAttribute ID="LocaleID" PropertyPath="$Context/Property[Type='SoftwareLibrary!System.SoftwareItem']/LocaleID$" SlowlyChangingAttribute="false" />
<InclusionAttribute ID="MajorVersion" PropertyPath="$Context/Property[Type='SoftwareLibrary!System.SoftwareItem']/MajorVersion$" SlowlyChangingAttribute="false" />
<InclusionAttribute ID="MinorVersion" PropertyPath="$Context/Property[Type='SoftwareLibrary!System.SoftwareItem']/MinorVersion$" SlowlyChangingAttribute="false" />
<InclusionAttribute ID="ProductName" PropertyPath="$Context/Property[Type='SoftwareLibrary!System.SoftwareItem']/ProductName$" SlowlyChangingAttribute="false" />
<InclusionAttribute ID="Publisher" PropertyPath="$Context/Property[Type='SoftwareLibrary!System.SoftwareItem']/Publisher$" SlowlyChangingAttribute="false" />
<InclusionAttribute ID="VersionString" PropertyPath="$Context/Property[Type='SoftwareLibrary!System.SoftwareItem']/VersionString$" SlowlyChangingAttribute="false" />
</Dimension>
</Dimensions>
You can see that this maps exactly to the ClassType definition of Software Item in the System.Software.Library MP:
Note: don’t include ClassType definition this in your MP! This is just to show you what the ClassType definition looks like (in the System.Software.Library MP) that you are referencing from your dimension.
<ClassType ID="System.SoftwareItem" Accessibility="Public" Base="System!System.LogicalEntity">
<Property ID="IsVirtualApplication" Key="true" Type="bool" />
<Property ID="LocaleID" Key="true" Type="int" />
<Property ID="MajorVersion" Type="string" />
<Property ID="MinorVersion" Type="string" />
<Property ID="ProductName" Key="true" Type="string" />
<Property ID="Publisher" Key="true" Type="string" />
<Property ID="VersionString" Key="true" Type="string" />
</ClassType>
Next we want to declare the Relationship Fact about the relationship of software being installed on Windows Computers:
<Facts>
<RelationshipFact ID="ComputerHasSoftwareItemInstalled" Accessibility="Public" Domain="DWBase!Domain.ConfigurationManagement" TimeGrain="Daily" SourceType="Windows!Microsoft.Windows.Computer" SourceDimension="DWBase!ComputerDim">
<Relationships RelationshipType="SoftwareLibrary!System.DeviceHasSoftwareItemInstalled" TargetDimension="SoftwareItemDim" />
</RelationshipFact>
</Facts>
</Warehouse>
I’ts important to note here that the relationship type is defined as between SoftwareItem and Device (again this is from the System.Software.Library MP not the MP you are creating):
<RelationshipType ID="System.DeviceHasSoftwareItemInstalled" Base="System!System.Reference" Accessibility="Public">
<Source ID="Device" Type="System!System.Device" />
<Target ID="SoftwareItem" Type="System.SoftwareItem" />
</RelationshipType>
Because Microsoft.Windows.Computer inherits from System.Device and a dimension is already defined for Microsoft.Windows.Computer we can just point to that dimension (SourceDimension=”DWBase!ComputerDim” above) instead of creating a new Device dimension.
Now we just need to include the usual LanguagePack section and we are done!
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<DisplayStrings>
<DisplayString ElementID="Microsoft.Demo.DataWarehouse.Software">
<Name>DEMO - Data Warehouse Software Extensions</Name>
<Description>This management pack adds a Software dimension and a Software installed on Computer fact for demo purposes. Provided by Microsoft. No warranty expressed or implied.</Description>
</DisplayString>
<DisplayString ElementID="Publisher">
<Name>Publisher</Name>
<Description>A list of all unique publishers of software.</Description>
</DisplayString>
<DisplayString ElementID="SoftwareItemDim">
<Name>Software Item Dimension</Name>
<Description>All software items.</Description>
</DisplayString>
<DisplayString ElementID="ComputerHasSoftwareItemInstalled">
<Name>Computer Has Software Item Installed Fact</Name>
<Description>All software items installed on computers.</Description>
</DisplayString>
</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPack>
Note: The complete management pack is attached to this post.
Now, what you want to do is import this into Service Manager either using the UI or the Import-SCSMManagementPack PowerShell cmdlet. After the MP Sync process kicks off the Management Pack will by synchronized automatically to the data warehouse.
Following that the Deployment process will kick in and automtically create the schema for you in the DWRepository and DWDataMart databases.
In the end, you should see tables like this in both the DWRepository and DWDataMart databases:
Publisher Outrigger:
SoftwareItemDim Dimension:
ComputerHasSoftwareItemInstalled Fact:
There are also database views that are created automatically:
OK, now we are ready to create a report! For this example, I’ll show you how to use the SQL Server Business Intelligence Design Studio (“BIDS”) to create the report. This is a feature of SQL Server that can be installed using the SQL Server installation setup.exe. Please re-run setup and add it if you did not add it when you first installed SQL Server. You can install this either on your server or on a remote location like your desktop as long as you have network connectivity and permissions to publish the reports to the SQL Server Reporting Services server.
After you launch BIDS, you need to create a new project:
Provide a name for your project like ‘SoftwareReport’ and click OK:
In the Solution Explorer right click on ‘Shared Data Sources’ and choose ‘Add New Data Source’:
Provide a name for your Data Source like ‘DWDataMart’ ….
… and then click the Edit button to get to this dialog where you can enter your server name and select the DWDataMart database from the drop down.
Make sure you click the Test Connection to verify connectivity! Then click the OK button on the Connection Properties dialog and then on the Shared Data Source Properties dialog.
Now you should have a data source shown in the tree in the Solution Explorer:
Now, right click on the Reports folder in the Solution Explorer and choose ‘Add New Report’
Click Next on the Report Wizard welcome screen:
Make sure the new data source you just created (‘DWDataMart’) is selected and click Next
Click the Query Builder button:
Click the Add Table button in the toolbar:
In the Add Table dialog, select the Views tab and select the ‘SoftwareItemDimvw’ view and click Add and then click Close:
Select the properties you care about showing in the report:
And then click OK.
Now that you are back in the Report Wizard, click Next on this ‘Design the Query’ dialog:
Select Tabular and Click Next:
Add the fields to the report something like this:
Leave this screen as is and click Next:
Choose a style:
Give your report a name like ‘Software Items’ and click Finish:
Now you should have your report in the Solution Explorer:
And in the middle you should see the report design area:
You can play around with column widths, colors, and all kinds of other formatting options here to make it look how you would like, but for now let’s just go ahead and publish this report as is.
Right click on the SoftwareReport project node in the Solution Explorer and choose Properties:
In the Properties enter the path to the SQL Server Reporting Services reportserver URL and click OK.
Choose Build --> Deploy Software Report from the menu:
Now you should be able to view your report in the browser or the Service Manager console. To view in the browser navigate to the URL of your SQL Reporting Services server and click on the SoftwareReport folder:
And then click on the Software Items link:
And you’ll see a report like this:
In order to see this report in the Service Manager console you need to move this report folder to the System Center\Service Manager folder. You can do that by going back to the Home, and then clicking the Show Details button on the right. Then you’ll see all the folders in a list:
Select the SoftwareReport folder’s checkbox and then click the Move button on the toolbar. Then select the /System Center/Service Manager folder in the tree and click OK:
Now if you launch the Service Manager console you should see this report folder and its report:
And you can get the same report by running the report from there:
In future blog posts, we’ll describe some of the fancier things you can do to extend the data warehouse and create reports.
This post is a continuation in the series which describes the System Center common platform components implemented in Service Manager. Previous posts:
The System Center Platform in Service Manager Part 1: Introduction
The System Center Platform in Service Manager Part 2: The Model-Based Database
The System Center Platform in Service Manager Part 2: The Model-Based Database - Try It!
The System Center Platform in Service Manager Part 3: The System Center Data Access Service
The System Center Platform in Service Manager Part 3: The System Center Data Access Service - Try It!
The System Center Platform in Service Manager Part 4: The System Center Management Service
The System Center Platform in Service Manager Part 4: The System Center Management Service – Try It!
The System Center Platform in Service Manager Part 5: The Management Configuration Service
The data warehouse in System Center Service Manager provides three primary functions:
- Offload data from the main Service Manager database to improve performance of the Service Manager database
- Long-term data storage
- Provide data for reports
The data warehouse that ships with System Center Service Manager is actually its own management group. It has essentially all the System Center common platform pieces that you would see in a System Center product (SCOM, SCE, SCSM) built on the common platform:
- Model-based Database for storing configuration information about the data warehouse and for staging the data after it has been extracted from the ‘ServiceManager’ database. In the data warehouse management group, this instance of the mode-based database is named ‘DWStagingAndConfig’.
- Management Server
- System Center Data Access Service
- System Center Management Service
- System Center Management Configuration Service
In addition to a complete stack of the System Center common platform, the data warehouse has two other databases:
- DWRepository – this is where we store the transformed data which is optimized for reporting purposes
- DWDataMart – we load transformed data into this database and ultimately this is the database that the reports query
This data warehouse is completely new. We did evolve most of the common platform components in Service Manager from Operations Manager 2007, but the data warehouse is one area where we started from scratch. We wanted to build a data warehouse which was:
- fully extensible via management packs
- designed as more of a true data true warehouse – star schema, facts, dimensions, etc.
- designed for very large scale
At the same time, we wanted to preserve some of the concepts of the Operations Manager warehouse – for example the ability to send data from multiple management groups to a single central data warehouse installation.
The data warehouse portion of Service Manager is not yet used in any other System Center product, but it was built with the intention of being a redistributable platform component that other System Center teams could deliver as the data warehouse solution for their products.
The Automated Data Warehouse Infrastructure
Chad has already done a good job of describing providing a high level overview of the data warehouse and the various system processes of Management Pack Synchronization, Deployment and Extract/Transform/Load (ETL) that happen in the data warehouse so I’ll just link to those here:
Data Warehouse and Reporting Overview
Anatomy of Management Pack Synchronization
Anatomy of Data Warehouse/Reporting Deployment
Anatomy of Extract, Transform, Load (ETL)
A Few Important Note on Deploying the Data Warehouse
It’s important to note a couple of important things regarding the deployment of the data warehouse:
- Because the data warehouse is really it’s own management group, the data warehouse management server cannot be installed on the same server as a Service Manager management server.
- You can however install all of the databases on a single SQL Server instance if you wanted to (this is not a good configuration for a production deployment).
See this blog entry for more information on how you can install both Service Manager and the Data Warehouse on a single physical server for testing purposes using virtualization.
Brief Introduction to the Reporting Infrastructure
Lastly, I want to briefly introduce the Reporting Infrastructure. The Reporting Infrastructure is built on SQL Server Reporting Services. The SQL Server Reporting Services infrastructure provides for a lot of things including report level security, report subscriptions, browser-based access to reports, linked reports, and much more. I wont go into a lot of detail here because I assume you are already familiar with SQL Server Reporting Services.
What is important to know about the implementation of the Reporting Infrastructure in Service Manager is that it is pretty similar to the experience you have in Operations Manager. There is a Reports workspace which shows you the catalog of reports which users can run on demand. Also like Operations Manager, the reports can be run in context. For example, I could select a computer in a view in the console and run the Computer Details report about that computer.
So – here is what our updated architecture diagram looks like (in a “thumbnail” size view). Since the architecture diagram is really getting too large to show in the blog itself, I’ve attached a Visio file with the architecture diagram in it.
Now, you can Try It! by reading the next post in this series.
One question I hear pretty regularly is “How do I create a recurring work item every week (or day, or month, etc.)?” The usual case here is that there is some task that needs to be done on an ongoing regular basis such as backing up a database, checking a log file, etc. People are looking for a way to automatically create and assign that task to somebody at the appropriate time. First of all this serves as a reminder to do important things at the right time. Secondly, it makes sure that the completion of that task is tracked.
To accomplish this, I used to tell people to create a rule with a schedule data source module and a command write action module which would run a custom created .exe that called the Data Access Service to insert the work item. That’s certainly a great option as long as you know your way around XML, C#, and our APIs on the Data Access Service. If you have something sophisticated in mind, that might still be the best option. However, if your requirements are simple, you are in luck because now we have the authoring console!
The rest of this blog post describes how you can create a new incident on a schedule using the authoring console.
First, install the Authoring Console. It is available at the same place you downloaded (or Connect) the Service Manager product bits. Keep in mind that the VS shell needs to be installed first and there is a .bat file you have to run after installing the Service Manager authoring console. See the product documentation that comes with the authoring console package.
Next, start up the authoring console.
Select File –> New –> Management Pack and provide a location to save your MP to and a file name.
Next, right click on the Workflow Rules node in the Management Pack Explorer tree and select Create Workflow Rule.
Provide a Name for the Workflow Rule like ‘CreateIncidentEveryDayRule’ and click Next.
Leave the ‘Timer’ option selected and click Next.
Provide the schedule you want to create the incidents on and click Next.
Provide a name for the Workflow such as ‘CreateIncidentEveryDayWorkflow’ and click Next.
On the confirmation page click Create.
On the completion page click Close.
Now you should see the workflow designer.
Drag the Create Incident workflow activity from the Toolbox onto the workflow design surface.
Now select that activity on the design surface. In the Properties pane you will see a bunch of parameters. Fill them out as appropriate.
Right click on the Management Pack in the Management Pack explorer and choose Save.
There should be a new .dll created in the same folder where you created the management pack .xml file. Copy that .dll to the product installation directory on each Service Manager management server (if you have more than one). The product installation directory by default is C:\Program Files\Microsoft System Center\Service Manager 2010.
Next import the MP into Service Manager using either the MP import experience in the Management Packs view in the Administration workspace in the main console or the Import-SCSMManagementPack PowerShell cmdlet.
An incident should be created within a few seconds and from that point on according to the schedule you specified.
Similarly, using the authoring console, you could create other workflows that run on a schedule or using a database query subscription that looks for certain conditions to be true in the database.
Let us know what you think!
Our partner Provance Technologies, Inc. has released the beta version of their IT Asset Management MP.
Excerpt from their press release:
Microsoft ISV partner Provance has developed a Process Management Pack for Service Manager for Software and IT Asset Management. The supplemental capability provided by the Provance IT Asset Management Pack extends Service Manager with additional functionality to manage financial, contractual and organizational information necessary to support Software Asset Management, License Compliance, IT Asset Life Cycle Management, and more cost-effective and efficient IT Service Management.
The Beta 1 release of the Provance IT Asset Management Pack is available to qualified participants in the company’s beta testing and evaluation program. The program is open to Microsoft partners, customers and internal staff participating in the Service Manager Beta 2 program who have expertise in managing IT environments with Microsoft System Center solutions. Interested parties can apply for participation in the Provance IT Asset Management Pack Beta program at www.Provance.com or by e-mailing beta@Provance.com.
More information can be found here: http://www.provance.com/en/Products/Provance_Management_Pack.html
Congratulations on your beta release!!
Here’s a screen capture of Service Manager with the Provance IT Asset Management MP imported.
We had a Live Meeting the other day with our TAP customers and this question came up:
Can I display some of my other business/IT reports in Service Manager?
Absolutely! That’s one of the many benefits of having the Service Manager reporting solution built on top of SQL Server Reporting Services.
This is fairly easy to do actually. The Reports workspace in Service Manager displays whatever folders and reports are contained in the System Center\Service Manager folder on the SQL Server Reporting Services server.
As you can see, we just replicate the hierarchy in Service Manager. Each folder in the Reports workspace corresponds to a folder on SQL Server Reporting Services. Each report in the folder in SQL Server Reporting Services is a list item in the main view area of Service Manager when you select a folder.
To add a non-Service Manager report to Service Manager you can simply add the Data Source required and the Report to the SQL Server Reporting Services somewhere under the System Center\Service Manager folder.
For example here, I’ve add a new Folder in System Center\Service Manager called ‘Financial Management’:
… and inside of that new folder, a new Data Source called ‘Financials’ that points to my database with financial data:
…. and a new Report that uses that Data Source called ‘Rate Card’:
Now, open up the Service Manager console and there is my new non-Service Manager Financial Management folder and Rate Card report showing up in Service Manager:
… and I can run it from the Service Manager console just like any other report…
We’ll write a post in the future how you can combine data from multiple data sources including the data warehouse into a single report and then make that report available in the Service Manager console.
In this demo-heavy webcast, we provide examples of the power of integrating Microsoft System Center Service Manager with Active Directory and the Microsoft System Center family of system management products. Microsoft System Center Configuration Manager and Microsoft System Center Operations Manager integration scenarios are demonstrated, including configuration management database (CMDB), connectors, desired configuration management (DCM) integration, alert-to-incident integration, and service map
Presenters: Vladimir Bakhmetyev, Senior Program Manager, Microsoft Corporation and Marc Umeno, Senior Program Manager, Microsoft Corporation
Language(s): English.
Product(s): Microsoft System Center.
Audience(s): IT Generalist.
Duration: 60 Minutes
Start Date: Tuesday, October 13, 2009 1:00 PM Pacific Time (US & Canada)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032424296&EventCategory=4&culture=en-US&CountryCode=US
Cheers!
We just signed off on Beta 2, sprayed champagne on each other, and dunked each other in the pond to celebrate!! Next steps for you:
- First, please celebrate with us virtually by checking out these photos!
- Then go download Beta 2 from Connect!
- Tell us what you think on the public forum!
This milestone is the feature complete milestone for Service Manager. From here on out we will only be fixing bugs and responding to customer feedback. The end is in sight!!
What’s new in Beta 2?
- Problem management
- End user self-service portal
- IT analyst portal
- Inbound email to incident workflow
- New reports
- Full extensible data warehouse
- Authoring console for customizing forms and creating custom workflows (without writing code!)
- Operations Manager integration – alert to incident scenario and service/service component inventory sync
- Self-service software provisioning
- significant improvements in performance and scalability
Also, of note this is the first time that any System Center product has ever simultaneously shipped a beta release in multiple languages (English, German, and Japanese for now).
Enjoy!
Clare Henry, our product marketing manager, made a new video on managing compliance with Service Manager. Here is the abstract:
Clare Henry, technical product manager on the System Center team, introduces System Center Service Manager 2010 by showing how this new product from Microsoft, currently in beta 2 trials, can help lower the risk of configuration errors so you can can quickly and efficiently resolve incidents. The demonstration specifically shows how Service Manager delivers solutions for compliance management, from the detection of a non-compliant configuration scenario to full remediation.
This is really just the beginning. Check out Bob Muglia’s (President of Server & Tools Division at Microsoft) quote in this interview.
He also says the long awaited System Center Service Manager will finally be out in the first half of next year, but that Microsoft is beginning to take a different angle on that software. Service Manager, formerly called Service Desk, helps administrators work through trouble tickets but also anchors automated, pro-active service requests initiated via other system management tools, and can aid in compliance auditing.
"We are now really looking at Service Manger as something that deeply integrates across everything to provide business process integration in the context of systems management," Muglia says.
"We look forward to getting the first release out, but the future of that product will be much more around compliance management and policy management associated with business process and business process compliance. That is the direction we will take that over a longer period of time. "
Here is a simple example that demonstrates how you can add a column to an existing view.
Specifically, we will be adding a “Source” column to the All Open Unassigned Incidents view that is shipped out of the box. “Source” property enables you to see the Incident source (e.g. email, portal, console, SCOM or DCM).
The high level steps are as follows, further details about each step are provided below:
Step 1: Export the Incident Management Configuration management pack
Step 2: Edit the management pack xml and add the column
1. Add the “source” column to Column definitions for the View
2. Add the “source” string to the Viewstrings for the View
3. Add the “source” string to the StringResources Section
4. Add the “source” display strings to the LanguagePacks section for English
Step 3: Save the management pack and Import it in Service Manager
Step 1: Export the management pack that contains the view definition
Note you can only export the unsealed management packs.
In this case the view is defined in Incident Management Configuration pack.
- Go to Administration->Management Packs
- Filter for Incident management config
- In the task pane Click Export
- Save the management pack
Step 2: Edit the Management Pack to add the “Source” column
Open the saved management pack in your favorite XML editor or Notepad :-)
- Navigate to the Presentations section and find the view “System.WorkItem.Incident.Active.Unassigned.View”
- Insert the xml fragments in two places as shown below:
- In “Columns” section
<Presentations>
<Views>
<View ID="System.WorkItem.Incident.Active.Unassigned.View" Accessibility="Public" Enabled="true" Target="CoreIncident!System.WorkItem.Incident" TypeID="SMConsole!GridViewType" Visible="true">
<Category>NotUsed</Category>
<Presentation>
<Columns>
<mux:ColumnCollection xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:mux=http://schemas.microsoft.com/SystemCenter/Common/UI/Views/GridView xmlns:s="clr-namespace:System;assembly=mscorlib">
…….
<mux:Column Name="Source" DisplayMemberBinding="{Binding Path=Source}" Width="150" DisplayName="Header_Source" Property="Source" DataType="s:String" />
</mux:ColumnCollection>
</Columns>
<ViewStrings>
......
<ViewString ID="Header_Source">$MPElement[Name="System.WorkItem.Incident.Active.Unassigned.View.Header_Source"]$</ViewString>
</ViewStrings>
- Navigate in the same XML file to <StringResources> and insert the bolded line as shown below:
<StringResources>
.......
<StringResource ID="System.WorkItem.Incident.Active.Unassigned.View.Header_Source" />
</StringResources>
- The final edit is for the respective language pack section. Below is the example for the English
- Navigate to “LanguagePacks” and insert the bolded text below within the DisplayStrings
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
<DisplayStrings>
.....
<DisplayString ElementID="System.WorkItem.Incident.Active.Unassigned.View.Header_Source">
<Name>Source</Name>
<Description>Source</Description>
</DisplayString>
</DisplayStrings>
</LanguagePack>
Step 3: Save the management pack and Import it in Service Manager
· Save the management pack – Do not change the name of the MP
· Open the Service Manager Console
· Navigate to Administrations -> Management Packs
· In the Task Pane click Import
· Add the saved management pack and click Import
Navigate to the Work Items -> Incident -> All Open Unassigned Incidents. You should see the “Source” column now displayed in the view.
You can also refer to this post for authoring more complex capabilities through management pack
This is the last part in the series focused on System Center Service Manager (SCSM) 2010 Beta 2 Portal feature.
This video provides talking points for the entire self service portal in SCSM 2010 Beta 2 and includes design goals and mission. This is a good overview clip for the portal.
