A while back I wrote a blog post about why your custom views might be slow.  For background on this post please read that post first:

http://blogs.technet.com/b/servicemanager/archive/2010/12/02/faq-why-is-my-custom-incident-view-so-slow.aspx

Some people have asked me to create a similar set of type projections for change requests.

Here you go!

All those listed as being in the Change Request Projection Library MP are new ones provided in the MP attached to this blog post.

As before I have also provided the XML file and the Advanced change request type projection is in the XML so you easily create your own type projections by copy/paste and delete the components you don’t want.

Enjoy!

Here’s an example of how to update objects “in bulk” programmatically using the SDK.  In this example, I’ll get all the incidents in the system and set their status to Pending.

This examples uses the IncrementalDiscoveryData class which is essentially a “bucket” that you can add things to which are all submitted to the server at once with a .Commit().

Sample Visual Studio console application is attached.

We’ve had quite a few developers ask us for the Management Pack schema file (.xsd).  We’ve now made that available as part of the SM Jobs Aids downloadable package.  This is useful for any dev that is creating management packs by hand in XML in Visual Studio since it will provide for Intellisense support and real time schema validation.

Enjoy!

http://www.microsoft.com/download/en/details.aspx?amp;displaylang=en&displaylang=en&id=13605

One of our Senior Escalation Support Engineers, Richard Usher, has encountered this problem with a few customers now and his written a handy blog post for those of you that may be experiencing this problem. Thanks Richard!

=======================

I’ve seen a couple of instances of this issue recently where following an apparently innocuous change to SQL Server Config, the SDK Service is locked out. So I thought I’d walk through the cause and remedy as well as providing a little background on the problem.

On restart following the change to SQL Server, the SDK Service stops shortly after starting and presents the following three events in the Operations Manager Event Log.

Events

26325 Authorization store exception

26339 Exception thrown while initializing the service container

26380 Unhandled Exception

Each of these events points towards an Authorization issue. Authorization in Service Manager is important as it facilitates the designation of role based access control to the various capabilities of the product.

Authorization Manager

System Center Service Manager 2010 utilises a technology called Authorization Manager (or AzMan as it is commonly known) which is provided by Windows Server. AzMan permits an application to record detailed policy rules in an Authorization store that can be programmatically queried by the application to check access permissions.

One of the new AzMan features of Windows Server 2008 is the provision of SQL-based AzMan stores. In the case of System Center Service Manager 2010 this store is implemented in the form of a series of SQL tables in the ServiceManager database with the dbo.AzMan_ prefix.

Access to the store is available via the MMC Authorization Manager Snap-in, with a slightly tortuous connection string: MSSQL://Driver={SQL Server};Server={MyServerName};/ServiceManager/AzmanStore where MyServerName is the name of the SQL Server hosting the ServiceManager db.

However when attempting to access the store with the server in this state, even access to the store via the SnapIn fails:

SQL Changes

Returning to the “innocuous” changes to SQL Server that coincided with the problem commencing, on each occasion that change was described as “Changing the SQL Server Authentication from Windows to Mixed Mode” This in itself is a non-change, Windows authentication continues to be utilised as part of Mixed-Mode, however the likely motive for changing the Authentication mode is to facilitate further changes. Specifically the reason for changing is to enable the addition of a SQL Server “local” login in addition to the Windows authenticated logins.

Looking at the customer’s example we discovered that in addition to the “innocuous” change of flipping the Authentication mode to Mixed-Mode an additional local Login had been enabled. Checking in SQL Server Management Studio and drilling down to \Security\Logins – we could see that this login had been designated as a db_owner.

It would seem this is a fairly common practice in some Enterprises where SQL Admins choose to add an additional login to facilitate running in-house scripts and jobs.

Solution

Having a non-domain based login as db_owner of an AzMan store prevents access to the AzMan store itself. Flipping Authentication mode back to SQL is insufficient at this stage – the database has this local login defined as a db_owner.

Unless the AzMan store can be accessed the server is effectively down. Restoring to a pre-change state is one answer of course, but all other changes since the backup are also lost. However a simpler resolution is possible. Simply change the role membership for the local Login to something other than db_owner and restart the SDK Service. This time service is restored

Likewise the AzMan store can be accessed via the MMC SnapIn

.

The DataWarehouse in System Center Service Manager 2010 of course is a separate database and implements its own instance of an AzMan store, so if you’re particularly unlucky you may find that your SQL Admin has implemented this same change in each db. In which case then each db must be checked and remedied otherwise you may find SDK Service failures on both your Service Manager server and Data Warehouse Servers.

The first form customization people usually want to make to the incident form is to increase the size of the textbox so it can show more information at once without scrolling.  This is SUPER easy to do if you know how, but I’ve heard of customers spending a lot of time trying to figure out how to do it.  So – in hopes of alleviating some headaches for people down the road I put together a quick demo video of how to do this.

The key is to use the details pane to change the Height property.  Resist the urge to use the grab handles on controls when you are designing form customizations.  Use the properties in the details pane to be more precise!

Sorry the video is so grainy, but you should get the idea.  In bullets it is this:

• Create a new MP to store your customizations in
• In the form browser pane (View –> Form Browser) search for incident
• Select the Incident form (not the DCM incident form) and right click and select View
• Click the Customize button
• Select the MP you created from step 1 to store your customizations in
• Select the Description textbox
• In the Details pane, change the Height property to whatever you want
• Save the MP
• Import the MP

Make sure you run the video in full screen so you can actually sort of make out what is happening! Also – there is intentionally no audio so you don’t need to try adjusting your speakers!

Here is an alternative way to do it with Height = Auto.  If you do it that way then the description field will change size all the time to match the size of the contents.  That’s probably a good thing when the amount of content is small, but it could get out of hand when there is a large amount of content so make sure you set the MaxHeight attribute.

http://www.scsm.se/?p=28

Nigel Cain, one of the Program Managers on the System Center engineering team has created a solution for better visualizing Unix/Linux computers in the SCSM console.  The management pack he built provides a type projection and a new form which looks similar to the Windows computer form.  Thanks for creating this and sharing it Nigel!  Also – a BIG thank you to those people inside and outside of Microsoft that helped us test this solution!

You can download the new Unix/Linux Management Pack, but you’ll definitely want to read on to figure out how to get all the data to be discovered by SCOM and replicated to the SCSM CMDB first.

Please note that this community contribution is not officially supported by Microsoft.  If you encounter any issues, please post them on the forums or in the blog comments below and we’ll do our best to address them.

================

Overview

Given that most datacenters contain a number of computers running the UNIX operating system, it’s not surprising that a number of customers have asked whether they can use Service Manager 2010 to track incidents, problem records and track change requests for these devices.

As this blog outlines, you can import the UNIX/Linux Management Packs developed for Operations Manager into Service Manager and take advantage of the integration between SCSM and SCOM to populate the CMDB with information about these devices - once the data is in the CMDB, you can easily create incidents, problem records and create change requests with no additional work or customization.

If you want to be able to manage these devices in the same way as you would for a Windows Computer, however, by assigning an owner/custodian, reviewing the hardware configuration, components and installed operating system and version, you need to some additional work, essentially extending the CMDB to capture some additional information about the machine and building a Service Manager Form which presents all of this information to the user and allows them to view and change it as needed.

Fortunately, the Unix Computer management pack available from the download center contains a custom form and a couple of CMDB extensions that will support all of the versions of UNIX/Linux operating system discovered and managed by SC Operations Manager. As long as you import the required Operations Manager management packs into SCSM, you should be able to work with, manage and update UNIX/Linux computers in SCSM in exactly the same way you manage Windows Computers today.

1. Getting Started – using Operations Manager to discover UNIX/Linux Computers

As outlined above, the key starting point for including UNIX/Linux machines in Service Manager is the support for cross-platform discovery and monitoring features introduced in System Center Operations Manager 2007 R2 - see below for more information:

http://download.microsoft.com/download/6/8/4/68422F86-2DF8-426F-B1C8-AF6D21859E64/OpsMgrCrossPlatDS_Aug2008New.pdf

The process for enabling and configure cross-platform discovery and monitoring is explained in the following TechNet article:

http://blogs.technet.com/b/birojitn/archive/2010/01/20/monitoring-linux-using-scom-2007-r2.aspx

Note: The list of supported UNIX/Linux operating systems was extended in the Oct 2010 release of the Cross Platform Update (link below), worth checking for more recent updates and patches if you have later versions of the UNIX/Linux operating systems.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4a41a8be-0a37-4bd2-b5b1-026468b317fb&displaylang=en

Make sure that Operations Manager has discovered and is successfully monitoring the UNIX/Linux computers in your environment before moving to the next step. You can confirm this by looking at the Unix/Linux Server node within the Operations Manager console as shown below:

2. Extending discovery for to include hardware components

To optimize performance, discovery and monitoring of processor and physical disk is normally disabled (by default). However, details of the processors and physical disks installed in a computer can often be helpful to IT analysts supporting these machines and it would clearly be useful to be able to capture this information.

You can change the default discovery and monitoring behavior by right-clicking the object you want discovered (physical disk for example), selecting “overrides”, “override the object discovery”, “for all objects” … and setting the override value to True as shown in the following screenshot.

You may have to wait a few minutes for the agent running on the Unix/Linux machines to retrieve the updated configuration and for details about the newly discovered hardware components to appear in operations manager. To check that this is working as expected, go back to the Monitoring pane in SCOM 2007 R2, right click one of your Unix/Linux servers, select open from the menu and choose “Diagram View” – if the agent has successful completed discovery of these components you should see something similar to the following:

Note: you will need to override the default processor and hard disk discovery process for each different version of Unix/Linux monitored by Operations Manager.

3. Extending the Service Manager CMDB

Once the data is available in Operations Manager, the next step is to extend the Service Manager CMDB to include support for Unix/Linux Computers. Fortunately, Service Manager and Operations Manager share the same technology stack and you can therefore extend the CMDB by importing the Unix/Linux management packs built for Operations Manager directly into Service Manager.

Note that the following management packs should be imported regardless of the specific Unix/Linux Operating System(s) within your environment

Microsoft.SystemCenter.DataWareHouse.Library

Microsoft.SystemCenter.DataWareHouse.Report.Library

System.Image.Library.mp

WSMangement.Library

Microsoft.Unix.Library

Microsoft.Linux.Library.mp

Once these management packs have been imported, you can begin to import the management packs for the specific versions of the Unix/Linux operating systems that have been deployed in your environment. The following management packs would be required to support SUSE Linux Enterprise 10 for example:

Microsoft.Linux.SUSE.Library.MP

Microsoft.Linux.SLES.10.MP

One word of caution, unlike Operations Manager, Service Manager doesn’t automatically handle and resolve dependencies between different management packs and it’s up to you as an administrator to import these in the correct order.

4. Synchronizing data with Operations Manager

Once the management packs that support your chosen version(s) of the UNIX/Linux operating system have been successfully imported into SCSM, the next step is to configure the Operations Manager Configuration Item (CI) connector so that it can bring this information into the CMDB.

Changing the ‘Allowed List’

The first step in this process is to configure the connector’s “Allowed List”. Although the connector automatically synchronizes objects discovered in Operations Manager with the Service Manager CMDB, the default setting may exclude some of the classes from the management packs you have imported, as discussed in the following article:

http://blogs.technet.com/b/servicemanager/archive/2010/02/26/managing-the-allowed-list-for-the-operations-manager-ci-connector-with-powershell.aspx

Although many of the classes required to support Unix Computers will be synchronized by default, several are not and you will need to extend the extend the allow list to include, for example, Unix Operating Systems and Hardware (peripheral) Components. The PowerShell cmdlets required to configure the connector to import this information for both SUSE Linux Enterprise 10 and Linux RedHat 5 computers into the CMDB is included below as an example.

Note that the following cmdlets should be used regardless of the specific Unix/Linux Operating System(s) within your environment

Add-SCSMAllowListClass Microsoft.Unix.LogicalDevice

Add-SCSMAllowListClass Microsoft.Linux.Computer

The following management packs would be required to support SUSE Linux Enterprise 10 and Linux RedHat 5. You should ensure that the “Allowed List” is extended to support the specific versions of the Unix/Linux operating systems that have been deployed in your environment.

Add-SCSMAllowListClass Microsoft.Linux.SUSE.Computer

Add-SCSMAllowListClass Microsoft.Linux.SLES.10.Computer

Add-SCSMAllowListClass Microsoft.Linux.RedHat.Computer

Add-SCSMAllowListClass Microsoft.Linux.RedHat.5.Computer

Note that the connector’s ‘Allowed List’ can only be changed only via PowerShell, there is no GUI interface for this operation.

Synchronizing Data with Operations Manager

Although the Management Packs you imported have successfully extended the CMDB with the classes needed to support UNIX/Linux computers, you need to enable synchronization of these management packs if you want the CMDB to be automatically updated whenever new Unix/Linux computers are discovered and information about existing machines is updated in Operations Manager.

To enable management pack synchronization for Unix/Linux management packs, click on Administration, select connectors and open the properties page of an Operations Manager CI connector. By clicking “Management Packs” from within the Wizard, you will be able to see the list of management packs that are currently being synchronized with Operations Manager,

Click the Refresh button and provide your credentials to update this list.

The unchecked Management Packs indicate those which have been imported into SCSM but are not currently being synchronized with Operations Manager, Microsoft.Linux.SUSE.Library in the example above. Where you see a greyed out checkbox, this means that the version of the management pack in SCSM is not the same as the one loaded into Operations Manager. To enable synchronization, both versions must be the same.

To enable synchronization, check the box next to each of the Unix/Linux Management Packs you require, as shown in the example below, and click OK to save your changes.

Note: As a minimum, you should enable synchronization with the Microsoft.Unix.Library management pack. However, it is recommended that you enable synchronization for all management packs that have names starting with Microsoft.Unix or Microsoft.Linux, as illustrated above since this means that you have access to more detailed information about these computers within the CMDB.

Synchronization from newly enabled management packs will occur at the next scheduled interval but you can force this to occur earlier by selecting the Operations Management Configuration Item (CI) connector in the list and clicking the option to “Synchronize Now”

5. Viewing the Imported Data

Once the information from Operations Manager has been successfully imported into CMDB, you can create a new view in the Configuration Items space within the SCSM console based on the types of Unix/Linux computer that were defined within the management packs you have imported.

For example, creating a new folder called “All Unix Computers” and defining a view linked to the SUSE Linux Enterprise Computers object defined in the Microsoft.Linux.SUSE.Library management pack would result in the following being displayed in the console:

Although at this point you can see a list of Unix/Linux computers discovered by Operations Manager and even create and link incidents, problems and change requests to them, if you select a computer from the list view and click the “Edit” task or even double-click one of the computers, the generic form will open – as shown below.

Although this is helpful in the sense that it allows you to view basic information about the computer, IT departments often need to be able to determine who owns or is responsible for the computer and the (physical or logical) hardware the computer is hosted on.

To get a more useful representation of a UNIX computer, you need a Type Projection also known as a Combination Class which brings together data from multiple classes in the CMDB and allows you to treat them as a single object. For more information on combination classes and how to create them, take a look at the following blog post:

http://blogs.technet.com/b/servicemanager/archive/2010/02/02/creating-views-that-use-related-property-criteria-type-projections-software-views-example.aspx

In this case, you need a Combination Class which includes the Unix/Linux computer itself, the hardware on which it has been installed (including any peripherals), the user that is responsible for it, any work items such as change requests, incidents, etc. and knowledge articles that are related to it and so on.

Looking in the list of available combination classes already defined in the CMDB, there is already called Computer – and since a UNIX computer is just another type of computer we can use that one right? No, sadly. This combination class represents [Windows] Computers as you can see from the screenshot below and hence you can’t use either the Computer (typical) or Computer (advanced) combination classes for any computer that is not running a Windows operating system. In short, you need a type projection for Unix/Linux computers.

Incidentally, there are two type projections for [Windows] computers defined in the CMDB by default, Computer (typical) and Computer (advanced) for performance reasons and you will need both for Unix/Linux computers. The typical one has a minimal set of relationships and is used in list views to ensure fast performance; the advanced class brings together many more relationships and is most commonly used in forms and reports. You need the same (advanced and typical) for Unix/Linux computers to avoid any performance problems in views.

The other thing to note is that each form within is associated (bound) to a given class. This means that although the computer form provided out of the box with SCSM seems to present all of the information needed to manage any type of computer, you can’t use it with Unix/Linux computers or any other type of computer for that matter. As you need a new type projection for these computers, you also need a new form. This sure seems like a lot of work.

Fortunately, we’ve done this for you. The Unix Computers Management Pack available on the TechNet Gallery adds an entirely new object to the CMDB called “Deployed Unix Computer”, representing the physical host (hardware) onto which the Unix/Linux computer has been deployed. It also adds the two combination classes mentioned above and a new [Unix] Computer form which looks remarkably like one developed for Windows computers.

6. Importing and Using the Unix Computers Management Pack

Having downloaded the Unix Computers management pack, simply import it into SCSM as you would with any other management pack. Note that that the Unix Computers management pack will not import unless you have successfully imported all of the management packs outlined in “Extending the Service Manager CMDB” above.

Once the Management Pack has been successfully imported, a new folder “Unix Computers” and new view called “All Unix Computers” will appear in the Configuration Item space. Clicking on the All Unix Computers view will display a list of all of the Unix/Linux computers defined within the CMDB.

This time when you select a computer from the list view and click the “Edit” task or double-click one of the computers, the new Unix Computer form will open – as shown below.

Using this form, you can update information relating to computer identify, the installed operating system, physical (host) computer, hardware components (peripherals), see all of the related change requests, incidents and problems and even view the history of changes that were applied to the CMDB – just as you could with a Windows Computer.

Note that even having synchronized, a number of the fields on the form are likely to be empty (by default) given that this data is either not discovered or maintained automatically by Operations Manager. You can either add the information manually or use CSV import or SC Orchestrator to populate should it be available in an external system

Please note that there are a number of key differences between the standard [Windows] Computer form and this one:

· You cannot use the form to create new Unix/Linux computers manually. To create a new computer in the CMDB, either wait for the Operations Manager Configuration Item (CI) connector to synchronize information about newly deployed/discovered machines, use CSV import or use a SC Orchestrator Runbook.

· The Unix/Linux computer form does not have a “Software” tab since Operations Manager does not detect installed software applications.

· The default Reports action in the console will open a [Windows] Computer Report. You can develop your own reports and console tasks to replace this default behavior

Nigel Cain

Senior Program Manager

System Center

Microsoft

Just a quick heads up that a new SCSM user group has been formed in Cologne, Germany.  You can find the web site for the group and more information here:

http://www.scsmug.de

As a reminder or if you didn’t already know there is also a US-based SCSM user group started by Chris Ross at http://www.scsm.us

I’ll add both of these to a new link section in the left nav for User Groups.  If there are other user groups out there that I should know about, please let me know via email or in the comments.

I know this is probably old news to all of you already, but I didn’t get a chance to blog it earlier this week when it happened because I was traveling.

SCSM 2012 public beta is now released on the download center!  You can get it from here:

http://www.microsoft.com/download/en/details.aspx?id=27844

A few important reminders:

• Only TAP customers are supported to use SCSM 2012 Beta in production.
• It will be technically possible to upgrade from SCSM 2012 Beta –> RC –> RTM but only TAP customers are supported doing so.
• CTP2 (TAP only build) is upgradeable to Beta

What’s new in SCSM 2012?

Key Features in SCSM2012

• New Self-Service Portal based on SharePoint 2010
• Service Catalog
• Service Requests
• Connector to VMM 2012
• Connector to Orchestrator
• Service Level Agreement support for Incidents and Service Requests
• Release Management with parallel activity support
• Enterprise Data Warehouse with BI Analytics (OLAP)
• Periodic query workflow and notification support
• More PowerShell administrative cmdlets
• Updated connectors to support SC 2012
• Parent – child support for incident and release management
• Authoring tool support for customer customizations.
• Performance improvements above SCSM2010 SP1 with larger datasets – details to come later after testing is complete
• Bug fixes for all areas including UX and customer / partner reported issues

The 2012 version of the GRC management pack and the management pack code named “Andes” will be available soon.

As the pre-RTM versions of each of the System Center products are releasing on slightly different schedules right now figuring out which version of each product can be connected to which version of SCSM can be a little tricky.  Use this table as a guide:

As you can see there will be a new version of the Exchange connector. The Exchange connector 1.0 and 2.0 will not work with SCSM 2012. I will provide a new version of the Exchange connector - 3.0 Beta - in the first part of November that will work with SCSM 2012 Beta. The same is true of the Send Email solution that comes with the Exchange connector. The 3.0 version of the connector will support service requests and other work item types among some other new features and of course bug fixes. Since I am sure someone will ask… at this point it looks like the Exchange connector will continue to be an out of band solution that is not officially supported by Microsoft.  We continue to evaluate ways that we can get it to a supported level.

At the same time that SCSM 2012 beta was released a couple of other releases happened :

• App Controller beta: http://www.microsoft.com/download/en/details.aspx?id=27843
• Orchestrator RC: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=27842

Read the release announcement on the Microsoft Server and Cloud Platform blog:

http://blogs.technet.com/b/server-cloud/archive/2011/10/27/announcing-new-system-center-2012-pre-releases-delivering-self-service-application-management-with-the-microsoft-private-cloud.aspx 

Some people have already started blogging about SCSM 2012 – here are some examples:

http://blog.scsmfaq.ch/2011/10/27/news-in-scsm12-beta-1-service-level-objectives-slo/

http://blog.scsmfaq.ch/2011/10/28/news-in-scsm12-beta-2-service-requests/

http://blog.scsmfaq.ch/2011/10/28/news-in-scsm12-beta-3-automation-of-service-requests/

http://blog.scsmfaq.ch/2011/10/29/news-in-scsm12-beta-4-enable-self-service-for-service-requests/

http://blog.scsmfaq.ch/2011/10/30/news-in-scsm12-beta-5-parentchild-incidents/

Please join the Connect site for SCSM 2012 and provide us feedback!

http://connect.microsoft.com/directory/?keywords=Service+Manager

Have you downloaded the Systems Center - 2012 Service Manager Beta and installed it yet?

If you have, we would like to hear from you!

If you have installed the beta, please tell us what you think by completing the Installation Survey.

Allow about 15 to 20 minutes to take the survey.

Once you complete the survey, you will be invited to enter the Systems Center 2012 - Service Manager Beta Survey Sweepstakes to win one of 3….

XBox 360 + Kinect’s

Official Sweepstakes Rules

We are conducting 2 surveys, Installation and Usage for the Systems Center 2012 Service Manager Beta. Complete both surveys and double your chances to win one of the three Xbox 360 + Kinects. Be sure to look for the Usage survey coming out in about 2 weeks.

Thanks for trying out Beta and providing  us this valuable feedback.  We look forward to reviewing the results!

This blog post was written by Neil Lydick,one of the developers on the Service Manager team.  Thanks for the write up Neil!  This is very comprehensive!

Before you read this post you should read Sean Christensen’s excellent overview of the Service Catalog.

===============================

The Service Manager Request Offering wizard is a powerful feature that allows customers to create Silverlight web forms that solicit input from end users and store the resulting information in the CMDB. A request author can engineer complex, automated, user-driven solutions without writing a single line of code.

Request authors rely on the Request Offering wizard to accomplish two primary objectives:

1. To design a set of questions (prompt text, UI, and field validation) that will appear to end-users initiating a self-service request on the SM2012 Web Portal

2. To map user responses to class properties and relationships in Service Manager’s modeled CMDB

This blog post will examine each of the decisions that need to be made in order to author a Request Offering and publish it on the Portal. It will also provide examples and guidance for achieving several common scenarios.

Configuring General Settings

The Request Offering wizard experience begins on the “General” page, pictured in Figure 1.

Figure 1: General Page

Here, a request author configures the following elements of the Request Offering:

1. Identifying UI: The title, image, and description that will appear in the Service Catalog are specified here.

2. Template: When a request offering is submitted through the self-service portal, a set of objects is created in the CMDB in accordance with the template selected in the “Select template” drop down. The drop down allows request authors to select Incident templates or Service Request templates. On a later wizard page (“Map Prompts”, discussed below), user responses to request offering prompts can be mapped to properties on the selected template object or any of its embedded activities.

Figure 2: General Page, Select template drop down active

3. Management Pack: In the “Management pack” drop down, the request author specifies the unsealed management pack in which the Request Offering will reside. Request Offerings are written directly into management pack XML and can be exported and imported seamlessly between SM 2012 installations.

Creating User Prompts

On the “User Prompts” page of the RO wizard, a request author configures the set of prompts that will be displayed to the end user. Each user prompt typically represents (1) a question that the service provider will ask the user in order to take action on his or her request or (2) read-only information that the service provider will supply to the user to so that he or she can better answer a question.

Figure 3: User Prompts Page

The text of each prompt is typed in-line into the corresponding row of the DataGrid (under the column “User Prompts or Information”). Questions are displayed in the web portal in the same numerical order in which they appear within the grid. Request authors may interact with the question grid using the “Enter” key, drag-and-drop mouse gestures, and a set of icon-themed menu buttons that allow the author to add a question, delete a question, and manipulate the order of existing questions.

Along with the text for each prompt, the request author must select a “Response Type” and a “Prompt Type.” The response type lets the author specify whether the question can be answered, and, if so, whether a response is required; the prompt type indicates the type of Silverlight control that will be displayed to the end-user alongside the prompt text (to either display information to the user and/or receive the user’s input).

The response type field assumes one of three values:

Required: the prompt can be answered by the user and a value must be provided

Optional: the prompt can be answered by the user but the user may leave the prompt unanswered

Display Only: the prompt cannot be answered by the user and exists only for informational purposes

Display-Only prompts can be useful when the request author wishes to convey information to the end-user so that the user can make an informed response to a later question. One of the available prompt types, Query Results, displays CMDB data to the user. In a computer-provisioning request offering, a display-only prompt could, for example, be configured to display the set of computers on which the end user is already a primary user. The user could then examine the configuration of the existing computers prior to requesting a new configuration.

Prompt Type

The Prompt Type drop down allows request authors to select the Silverlight control that will be rendered directly below the text of the configured prompt in the web portal. By default, each text-control pair appears on a “wizard” page in a group of 5 prompts. The number of prompts appearing on a single page can be configured in the Settings.xml file on the SCSM Portal Web Server (\inetpub\wwwroot\System Center Service Manager Portal\ContentHost\Clientbin\Settings.xml) by altering the value for setting key “DefaultNumberQuestionsPerPage.”

The default layout of an RO wizard portal page is displayed in Figure 4:

Figure 4: Layout of Request Offering wizard pages in SM 2012 Portal

The “Prompt Control” to be rendered includes any one of the nine different control types described below:

Table 1: Summary of Request Offering Control Types

The description column above indicates the type of interactive control that will display to the user for each prompt type. Just as UI controls in Windows Presentation Foundation or Silverlight deliver user input in a prescribed .NET format (e.g.: string, DateTime) to the application that hosts to the control, so too do Service Manager’s portal controls deliver user input to properties of class instances within Service Manager. The SDK property type into which each control’s user input can be written is summarized in column three of the table above.

Figure 5 displays a sample Request Offering wizard page which contains five different prompt types:

Figure 5: Request Offering Wizard Page on SM 2012 Portal

Mapping to the Service Manager CMDB Model

Service Manager abstracts the SQL tables in its underlying relational database and instead exposes Classes and Relationships, which are object types that the user can create in order to store data. The objects that the user interacts with through the UI – Incidents, Change Requests, Computers, Software Items, etc. – all comprise instances (i.e.: SQL table rows) of specific classes and relationships in Service Manager’s type system. Many great blog posts already discuss Service Manager’s extensible database model, and we’ll omit some of the details of the SM CMDB model here.

Classes in service manager store individual units of data in Properties (i.e.: SQL columns) that assume 1 of 10 different property types: int, decimal, double, string, datetime, guid, bool, enum, richtext and binary.

Consider the Incident class, which is defined in the System.WorkItem.Incident.Library ManagementPack as follows:

<ClassType ID="System.WorkItem.Incident" Accessibility="Public" Base="WorkItem!System.WorkItem.TroubleTicket" Hosted="false" Abstract="false">

   <Property ID="TargetResolutionTime" Type="datetime" />

   <Property ID="Escalated" Type="bool" DefaultValue="False" />

   <Property ID="Source" Type="enum" EnumType="IncidentSourceEnum" />

   <Property ID="Status" Type="enum" EnumType="IncidentStatusEnum" />

   <Property ID="ResolutionDescription" Type="string" MaxLength="4000" />

   <Property ID="NeedsKnowledgeArticle" Type="bool" DefaultValue="False" />

   <Property ID="TierQueue" Type="enum" EnumType="IncidentTierQueuesEnum" />

   <Property ID="HasCreatedKnowledgeArticle" Type="bool" DefaultValue="False" />

   <Property ID="LastModifiedSource" Type="enum" EnumType="IncidentSourceEnum" />

   <Property ID="Classification" Type="enum" EnumType="IncidentClassificationEnum" />

  <Property ID="ResolutionCategory" Type="enum" EnumType="IncidentResolutionCategoryEnum" />

  <Optimization ID="System.WorkItem.Incident.Status.Index">

     <Property ID="Status" />

   </Optimization>

</ClassType>

If a CheckBox control is presented to the user and an Incident template designated to be created when the request offering is submitted, then, per the table above, the (True/False) output of that CheckBox can be transmitted to each of the properties of type bool contained within the Incident class and any of its parent classes (i.e.: Incident properties: Escalated, NeedsKnowledgeArticle, HasCreatedKnowledgeArticle; WorkItem properties: IsDowntime, IsParent). Likewise, a DateTime control can write its output values to TargetResolutionTime on the Incident class or compatible properties on Incident parent classes.

The ultimate goal of a Request Offering is to transfer input values from the prompt controls rendered in the user’s browser to database objects within ServiceManager’s CMDB. As the user enters values into each prompt control, the prompt records the user’s response and makes the value that the user entered available to:

1. Compatible properties in the template that will be created when the request offering is submitted (the specific available properties depend on the template selected in the “Select template” drop down on the General wizard page).

2. A Query Results prompt that has taken a dependency on the value that the user entered for the prompt (more on this below).

Configuring User Prompts

Once the Request Offering author has selected the type of control to display to the user, he or she can configure the parameters of that control on the next wizard page: “Configure Prompts.” This is the page on which the interactive behavior of each prompt control is defined.

Figure 6: Configure Prompts Page

Each prompt control (except True/False) is configured by:

1. Selecting the row in the DataGrid that corresponds to the prompt.

2. Selecting the “Configure” button (Alt+G) at the top left of the DataGrid

The True/False prompt type displays a CheckBox and does not include configuration options. As a result, it appears in a grey row within the list of prompts in the DataGrid.

All prompt types except Query Results and Simple List have default control configurations that can be used if no customization is required. The Query Results and Simple List control types require configuration by the user and surface in the DataGrid with a red row header until they have been successfully configured. The Query Results control accepts configuration input that specifies the type of object that it will display to the user; the Simple List control accepts a user-supplied list of string values to present to the user within a Silverlight drop-down. The configuration options for these controls are described below.

Each configurable prompt type supports the following configuration options:

Date

By default, the date control allows users to input any date. Two options exist for constraining the set of dates that can be input by the user:

1. Absolute Date Range (“Limit available dates to a specific range”): The request author can impose restrictions on the earliest and/or latest dates available to the user by selecting the desired calendar dates.

Figure 7: Setting an Absolute Date Constraint

2. Relative Date Range (“Constrain available dates using the user’s current time”): In many common scenarios, a request author would like to limit the end-user to a set of dates that appear within a certain range of today’s date (e.g.: make this change effective by/grant permissions to the user until). To accommodate such scenarios, the Date control configuration allows the user to limit the earliest selectable date to a relative starting date in days before or after the user’s current time and the latest selectable date to an offset 0 or more days after that starting date.

Figure 8: Setting a Relative Date Constraint

Figure 9 shows the Date control rendered in a browser window:

Figure 9: Request Offering Date Control

Decimal/ Integer

The integer and decimal controls share a similar configuration form that allows the user to limit the minimum and maximum values that can be entered into the Silverlight TextBox receiving user input. The Silverlight TextBox appearing in the portal determines if the number entered by the user is within the expected range and displays an informative warning if the value is incorrect.

Figure 10: Setting Decimal Constraints

File Attachment

The File Attachment control presents a “Browse…” dialog that allows the user to select a file on his/her local system for upload to the Service Manager server. When the Request Offering is submitted by the user with a valid attached file, a System.FileAttachment object is created for the file, and the bytes that compose the file are copied into the “Content” binary property of the System.FileAttachment object. After the System.FileAttachment object is created, a new System.WorkItemHasFileAttachment relationship is created to link the System.FileAttachment object to the template instance created when the request offering is submitted.

The File Attachment control accepts one configuration parameter: the maximum size of the file that the user can submit. The default value for maximum file size is 2 MB; the maximum allowable limit is 10 MB.

Figure 11: Configuring the File Attachment Control

Figure 12 shows the File Attachment control in the browser.

Figure 12: File Attachment Control

MP Enumeration List

The configuration form for the MP Enumeration List control allows the request author to select the parent enumeration type from which the child enumerations displayed in the portal will originate. When a parent enumeration type is selected for the MP Enumeration control, the enum output of the MP Enumeration List control is considered “bound.” When a parent enumeration type is not selected for the MP Enumeration control, the enum output is considered “unbound.”

Figure 13: Configuring the MP Enumeration List Control

If, for example, the request author wanted to allow the user to set the “Status” property of the incident created when the request offering is submitted (class: System.WorkItem.Incident, property: Status), he or she would select the Incident Status (i.e.: IncidentStatusEnum) enumeration (the enum type that can be assigned to the Status property of System.WorkItem.Incident).

In many cases, the desired parent enumeration value may not be apparent to the Request Offering author even though the desired target property (e.g.: System.WorkItem.Incident/Status) is. Recognizing this, Service Manager allows the Request Offering author to bind the MP Enumeration List control to an enum type on the “Map Prompts” wizard page by presenting the output of all unbound MP Enumeration List controls as valid inputs to any enum property. (The Map Prompts page is described later in this blog post. It allows users to map control outputs to properties.) Once an MP Enumeration List control’s output is selected as the input for an enum property, the MP Enumeration List control becomes bound to the enum type corresponding to that property.

Figure 14 shows the MP Enumeration List control bound to ActivityAreaEnum.

Figure 14: MP Enumeration List Control

Simple List

The Simple List configuration form allows request authors to enter a set of strings that will surface to the user in a Silverlight drop-down. Strings are presented to the user in the web portal in the same order in which they appear within the DataGrid. The order of strings can be modified with the up and down arrows located above the DataGrid.

In addition to specifying an ordered set of strings, the Request Author can designate any of the entered strings to be the default value for the ComboBox. This is done by selecting the row containing the desired default string and then selecting the “Set as default” button located above the DataGrid.

The example Simple List configuration in Figure 15 produces the browser control Figure 16.

Figure 15: Configuring the Simple List Control

Figure 16: Simple List Control

Text

The Text control presents a Silverlight TextBox to the user. User input to the TextBox can be validated against content and length requirements.

The following options are available for validating content:

1. Allow any string (the default)

2. Allow only E-mail addresses

3. Allow only 10-digit (U.S./Canada-style) phone numbers

4. Allow phone numbers entered in the ITU-T E.123 standard

5. Allow only website URLs

6. Allow values that conform to a custom regular expression submitted by the Request Offering author. The Request Offering author may also specify a ToolTip that assists the user when an incorrect value is entered.

In addition to the options above, the request author may supply a minimum and maximum allowed length for the input string.

When constraining the length of the string, it is important to consider the following: the string output of the Text control can be mapped to string properties in the template object selected for the request offering. These properties will have their own SDK-validated minimum-length and maximum-length requirements. It is good practice to set the minimum allowed length for the Text control to an integer value that represents the largest MinLength of all the SDK properties to which the output string will be mapped. Similarly, the maximum allowed length of the Text control should be set to the smallest MaxLength in the set of mapped properties.

If the portal end-user enters a string value that violates either the content or length requirements imposed upon the Text control, an informative validation warning will be presented on the portal wizard page.

Figure 17: Text Configuration Form

Query Results

The Query Results prompt type allows users to view and select CMDB objects from a Silverlight DataGrid.

Configuring a Query Results prompt encompasses several steps. A request offering author will typically:

1. Constrain the set of objects displayed in the grid to instances of a specific class or type projection, and, optionally, provide SDK query criteria as an additional filter

2. Select the list of object properties that will be rendered as columns within the DataGrid

3. Customize behaviors associated with the rendered grid rows

4. Determine the relationship(s) that will be added for the selected CMDB objects and the source object to which the objects will be attached (i.e.: the template instance or one of its embedded activities)

The Query Results configuration form is divided into 4 tabbed sections. The role of each tabbed section is as follows.

1. Select Class

Figure 18: Select Class Tab, Query Results Configuration Form

The “Select Class” tab allows users to select the type of instance (i.e.: Computer, Incident, etc.) that will display in the DataGrid on the portal. By selecting the “Combination Classes” entry in the drop-down at the top right of the tab, Users can display instances of a type projection that spans multiple classes and relationships. Type projections are used in cases when:

1. The set of instances displayed to the end-user contains properties from more than one class type (e.g.: an Incident and its Affected User)

2. The set of instances displayed to the user relies upon Relationship Criteria, criteria that filters the set of instances to display using related instances (e.g.: Incidents where the Affected User has first name “Bob”)

Figure 19: Selecting Combination Classes (Type Projections)

2. Configure Criteria (optional)

The “Configure Criteria” tab permits users to limit the set of class or type projection instances shown to the end-user. This control works almost exactly the same as the “Criteria” wizard page in the Create View wizard.

Figure 20 shows the Configure Criteria tab after the Incident class (System.WorkItem.Incident) has been selected.

Figure 20: Configure Criteria Tab (Incident Class Selected)

On this page, the request author can scroll through the properties available for the selected class and check (i.e.: in the CheckBox) the properties on which a filter should be established. Clicking the “Add Constraint” button establishes a filter on the checked properties.

Figure 21 illustrates the process of selecting properties for a filter. In the figure, the Incident “Impact” property, an enum property that an analyst can set to High, Medium, or Low, is selected.

Figure 21: “Impact” Property Selected For Filter

Once the Add Constraint button is clicked, filters for each selected property appear in the Criteria list at the bottom of the tab. Clicking the Add Constraint button for the selected property in Figure 21 results in the criteria list in Figure 22.

Figure 22: “Impact” Property Criteria

The user interface for setting a filter varies depending on the criteria operator selected (in Figure 22 the selected operator is “equals”) and the type of property on which a filter is being established. Since Incident Impact is an enum, the available filtered values appear in the above rendering within a drop-down.

Selecting other properties and clicking the Add Constraint button results in a filter that is the intersection (AND) of multiple filters. The filter below, for example, limits the set of Incidents displayed to those having “High” Impact AND a DisplayName that contains the text “VIP”.

Figure 23: Filter for Incident Using Impact and DisplayName Properties

If a filter for a property already exists within the Criteria list and a second filter is added by checking that same property and clicking the Add Constraint button, then the new filter is unioned (OR’ed) with the existing filter for the property.

The Criteria list in Figure 24 was produced by adding a constraint for “Impact” a second time. It expands the previous criteria to retrieve all Incidents with either “High” OR “Medium” Impact that also have a Display Name that contains the text “VIP”.

Figure 24: Filter for Incident Using Impact and DisplayName Properties, Second Impact Value Specified

To remove a filter, the request author can click the red “X” appearing at the right side of that filter.

Tokens

The Configure Criteria tab in the Query Results configuration form differs from the criteria configuration page on the Create View wizard in one important way: a “Set Token” menu option appears to the right of the user input control for each filter. The Set Token menu is highlighted with a red rectangle in Figure 25.

Figure 25: Set Token Menu

Using the Set Token menu, a request author can set a filter value to user input that is typed into a previously appearing prompt in the portal wizard. Since this filter value is derived from user input that is not known at the time that the request offering is authored, a database filter is created on-the-fly once a value is entered by the user. A Token, then, refers to the output of any previous prompt that is compatible (in type) with the property on which the filter is being set.

Suppose that the request author has defined 2 prompts: (1) a Text prompt that asks the user for the name of a computer and (2) a Query Results prompt that we would like to configure so that it returns all of the computers having a DisplayName that matches the string that the user typed into the first prompt. The prompts are defined as in Figure 26.

Figure 26: Initial Definition of Text Prompt and Dependent Query Results Prompt

To configure the Query Results prompt to show the expected data, the request author would select the corresponding prompt and click the Configure button. Figure 27 shows the “Configure Prompts” page for these prompts.

Figure 27: Configure Prompts for Text Prompt and Dependent Query Results Prompt

After opening the Query Results configuration form for “Computer List,” the request author would select “Windows Computer” as the class to display on the first tab of the Query Results configuration form (Figure 28).

Figure 28: Select “Windows Computer”

In the Configure Criteria tab, the request author would add a filter on the “Display Name” property. Clicking Set Token on this filter produces the menu in Figure 29.

Figure 29: Set Token for Windows Computer Display Name Filter

In the Select Token sub menu, two available tokens for this prompt appear:

1. Token: Portal User Name. This is a string property that is available on any portal Request Offering page. It contains the username of the account viewing the page.

2. 1. Search for computers named:: String. This is the output from the first prompt.

Available prompt outputs are formatted in the Select Token submenu as <Prompt Ordinal>. <Prompt Text>: <Prompt Output Type>. Here, the request author would select the token containing “Search for computers named:,” which is the prompt text from the first prompt. Clicking this token will result in the Criteria list in Figure 30.

Figure 30: Token-Enabled Criteria on Windows Computer Display Name

Note that the TextBox is now grayed-out and the selected token is displayed inside, indicating that a token is in use. If the request author were to insert additional Text prompts before the Query Results prompt, the output of these additional Text prompts would also appear in the Select Token submenu.

The request author can remove a filter’s association with a Token by selecting “Clear Token” on the Set Token menu. Clearing a token re-enables user input on the TextBox and allows the request author to enter a filter criteria manually.

The Criteria presented in Figure 30 introduces an ordering constraint on the Query Results prompt and its Text prompt predecessor. Because the Query Results prompt relies upon the user input of the Text control that precedes it, the Text control cannot be repositioned to appear after the Query Results control. Attempting to do this on the User Prompts page while the Criteria is active yields the warning in Figure 31.

Figure 31: Warning Message Resulting From Reordering Dependent Prompt

One interesting thing to note is that, for enum property filters, the set of available tokens includes output from all preceding MP Enumeration List controls that are bound to a matching enum type. For example: a filter on the Status property of System.WorkItem.Incident will only show available tokens from predecessor MP Enumeration List controls that are bound to IncidentStatusEnum.

Configuring Criteria for Projections

If the request author selects a combination class (i.e.: type projection) in the Select Class tab instead of a simple class, the property display on the Configure Criteria tab page adjusts to enable criteria on the relationships available in the projection. Selecting the “Incident (portal)” combination class, for example, produces the display in Figure 32.

Figure 32: Configuring Criteria on Incident (portal) Combination Class

The seed object of the projection (here: Incident) appears as the root node in the tree. All of the projection components appear under the root. Establishing filters on the root object or a projection component entails:

1. Selecting the node in the tree on which a filter should be applied (in the TreeView on the left)

2. Selecting a type constraint class that limits the type of object retrieved (in the drop-down on the top right)

3. Checking properties on the type constraint class and clicking the Add Constraint button

Suppose a request author would like to show the set of Incidents assigned to analyst John Doe. The criteria would be constructed in the following steps.

1. Click the projection component corresponding to the “Assigned To User” relationship (Figure 33):

Figure 33: Incident (portal) Criteria Configuration, “Assigned To User” Component Selected

2. Select the “Domain User or Group” class (System.Domain.User) class as a type constraint. System.Domain.User is the SM class for Windows users (Figure 34):

Figure 34: Incident (portal) Criteria Configuration, “Assigned To User” Component Selected, “Domain User or Group” Type Constraint Selected

3. Select the First Name and Last Name properties (Figure 35):

Figure 35: Incident (portal) Criteria Configuration, “Assigned To User” Component Selected, “Domain User or Group” Type Constraint Selected, “First Name” and “Last Name” properties selected

4. Click the Add Constraint button and set the required values (Figure 36).

Figure 36: Incident (portal) Criteria Configuration, “Assigned To User” Component Selected, “Domain User or Group” Type Constraint Selected, “First Name” and “Last Name” filter created

At step 4, the request author has a filter that returns all incidents that have a System.Domain.User Assigned-To user with name John Doe. We can append constraints from other parts of the projection, creating, for example a filter that returns all high impact incidents assigned to John Doe that contain an analyst comment with the text urgent (Figure 37).

Figure 37: Incident (portal) Criteria Configuration, Filter on Properties from Multiple Projection Components

3. Display Columns

In the “Display Columns” tab of the Query Results configuration form, a request author selects the set of columns to display to the user in the DataGrid that renders on the portal. Each column corresponds to a property in the selected class or type projection.

Figure 38 shows a Silverlight DataGrid that was configured to display System.WorkItem.Incident objects with two display columns containing the Id and Title of each incident. Figure 39 shows the display column configuration that produced the DataGrid in Figure 38.

Figure 38: Silverlight DataGrid Configured to Display Incidents

Figure 39: Incident Class with Two Display Columns Selected

A property is added to the set of columns to display by selecting the CheckBox adjacent to that property. Checking a property instantly adds the property to the “Columns to display” list view at the bottom of the tab, which shows the name, property type, and display name of the columns to display. By default, the display name of the column header in the Silverlight DataGrid defaults to the display name of the selected property. This column header can be edited inline and replaced with a string value.

Arrow icon buttons at the top right of the Columns to display ListView allow the user to change the order in which columns are displayed on the portal (the topmost row in the ListView corresponds to the leftmost column rendered in the Silverlight DataGrid). To remove a column, a request author can uncheck the corresponding property or select the column in the ListView and then click the icon button with the red “X” directly above the list view.

When a combination class is selected in the Select Class tab, the Display Columns tab includes a projection tree view that contains all of the “cardinality-one” projection components under the projection seed. The relationships underlying certain projection components cannot be created for more than one <source, target> pair. Objects at the other end of these projection components, referred to as cardinality-one, can always be rendered without the need to render some instance rows multiple times.  For example, an incident can only ever be assigned to one person at a time (“cardinality-one”).  Incidents can have more than one knowledge article related to them (not “cardinality-one”).

Selecting display columns for a projection instance is similar to selecting criteria for projection instances. A request author must select the object in the projection tree from which the properties will originate, select the class containing the properties to display from the drop down at the top right of the tab, and then check-off the columns that should be displayed.

Suppose a request author wants to display a Query Results control that contains a grid of Incidents with columns in the following order: ID, Title, Assigned To User’s First Name, Assigned To User’s Last Name, Status.

The goal DataGrid is presented in Figure 40.

Figure 40: Incident Type Projection Display with Five Columns (Id, Title, Assigned-To-User First Name, Assigned-To-User Last Name, Status)

To create this DataGrid using an Incident (portal) type projection, the request author would:

1. Select the root object in the Incident projection (Figure 41).

Figure 41: Display Columns Tab, Incident (portal) Projection Seed Selected

2. Select the incident class in the class drop down (Figure 42).

Figure 42: Display Columns Tab, Incident (portal) Projection Seed Selected, Incident Class Selected

3. Check the desired properties from incident (ID, Title, Status)

Figure 43: Display Columns Tab, Incident (portal) Projection Seed Selected, Incident Class Selected, {Id, Title, Status} Properties Selected

4. Select the Assigned To User relationship (Figure 44)

Figure 44: Display Columns Tab, Incident (portal) Assigned To Component Selected

5. Select the Domain User or Group class (System.Domain.User) (Figure 45).

Figure 45: Display Columns Tab, Incident (portal) Assigned To Component Selected, Domain User or Group Class Selected

6. Check the desired properties of the Assigned-To user: First Name and Last Name. The selected view columns are color-coded to match the projection component from which they originated (Figure 46).

Figure 46: Display Columns Tab Incident (portal) Assigned To Component Selected, Domain User or Group Class Selected, {First Name, Last Name} Properties Selected

7. Select the row representing the Status column and then click the down arrow twice to position it at the end of the column set (Figure 47).

Figure 47: Display Columns Tab Incident (portal), Status Column Repositioned

At step 7, the display columns are correctly configured.

A request author should note the following characteristics of display columns:

1. When the Query Results control queries the CMDB for data, the database query instructs the CMDB to return instances in sorted order using the first two display columns. The instances are later re-sorted in memory if a portal end-user clicks on a column header in the Silverlight DataGrid.

2. The Query Results control can present a maximum of 10 display columns.

4. Options

The last page of the Query Results configuration wizard allows the user to customize the behavior of the DataGrid control. Here, the request author can specify the relationship(s) that will be created to link user-selected objects in the DataGrid to an object on the target template selected for the Request Offering.

Figure 48: Options Tab

The options, depicted in Figure 48, are as follows:

1. Enable multi-select (“Allow the user to select multiple objects”): Checking this field allows users to select more than one object in the Silverlight DataGrid.

2. Hide portal generic form (“Do not show object details when object is clicked”): Each row of the DataGrid presents a subset of an instance’s properties to the user. The first column renders the text of its property as a hyperlink. By default, when a user clicks on this hyperlink, a details window emerges and displays all of the properties of the instance. For projection instances, related objects in the projection appear in a separate tab (see Figure 51). Checking this option disables the hyperlink and prevents the details window from appearing.

3. Add user-selected objects to template object as related items: If this field is checked, the portal will create System.WorkItemRelatesToConfigItem or System.WorkItemRelatesToWorkItem relationship instances to link each of the objects selected by the user to the target instance specified in the drop-down immediately beneath the check box. The appropriate relationship is selected based on the type of object being displayed in the Query Results control. The instances available in the drop-down include the target template instance selected for the Request Offering and any of its embedded activities.

4. Add user-selected objects to template object as affected configuration items: This field is enabled only if the objects being displayed in the Query Results control inherit from Configuration Item (System.ConfigItem). If this field is checked, the portal will create System.WorkItemAboutConfigItem relationship instances to link each of the objects selected by the user to the target instance selected in the drop-down. The instances available in the drop-down include the target instance and any of its embedded activities.

Query Results Control Features

Figure 49: Query Results Control

Figure 49 shows a Query Results control that has been configured to display Incident Projections to the user. Four columns from the underlying object have been configured for display (2 from the incident, 2 from the user assigned to the incident).

Figure 50: Query Results Control, annotated

Figure 50 highlights key features of the control, which include:

1. (red) Refresh Button: A refresh button that queries the CMDB and updates the set of instances displayed.

2. (blue) Apply Filter Button: A search textbox that filters the retrieved instances. The filter text is activated when the magnifying glass is clicked.

3. (yellow) Selection CheckBox: A row is selected by “checking” the CheckBox in the first column.

4. (green) Generic Form Hyperlink: If the Generic Form is enabled in the Options tab, clicking the hyperlink in this column displays the form.

Figure 51 depicts the Generic Form that is shown when the hyperlink for incident IR152 is clicked in Figure 50.

Figure 51: Generic Form Displayed in Child Window

Feeding Display Columns Forward

After a Query Results control has been successfully configured, each of the properties selected as display columns appear in the “Prompt Output” column of the “Configure Prompts” page of the Request Offering wizard.

Consider the Query Results prompt configured in Figure 52, which displays the Domain and UserName of Domain User or Group (System.Domain.User) objects to the user.

Figure 52: Query Results Control Configured to Display User Properties

Each selected display column (Domain, UserName) emerges from the Query Results control as an available output. Query Results controls are noteworthy in that they produce column-based output values from the user’s selection. Any of the column values present in the row selected by the user can be “fed-forward” into subsequent Query Results prompts. As a result, user selection in one Query Results prompt can influence the set of objects displayed in a following Query Results prompt.

Suppose we would like to take the Query Results prompt created above, which displays a list of users, and transmit the user’s selection to a second prompt that shows the set of incidents to which that user is assigned. To realize this scenario, a request author can create a second Query Results prompt on the Incident (portal) projection type with the criteria displayed in Figure 53.

Figure 53: Query Results Criteria Configuration That Uses a Previously Selected Instance

Here, the Domain and UserName columns selected by the user in the first prompt correctly constrain the set of Incident instances returned in the second.

The output values of a Query Results control are available as tokens to later prompts only when that Query Results control is configured with multi-select disabled (in the Options page). If multi-select were enabled in the Query Results control displaying user information in Figure 52, tokens from the control could not have been selected as they are in Figure 53.

Map Prompts

When a request author arrives at the Map Prompts page, he or she has already (1) designated the template that will be created when the request offering is submitted and (2) defined and configured the set of prompts that will appear to the end-user on the portal. On the Map Prompts page, a request author routes the output from each of the prompts into one or more compatible properties on the target template instance or one of its embedded activities. When the request offering is submitted by the user, output values from each control are saved into the properties to which they are mapped.  Thus, the values in the template are merged together with the input provided by the user to create the object that will be submitted to the database.

Figure 55: Map Prompts Page

The mapping is performed as follows:

1. First, the request author selects the target template instance or one of its embedded activities in the TreeView at the top of the wizard page (highlighted in blue in Figure 55). This is the object into which outputs will be mapped.

2. Second, the request author may choose to select the “Display all properties” radio button (pictured in yellow in Figure 55) so that all properties of the target object are visible.

3. Third, the request author selects the ComboBox drop down (pictured in red in Figure 55) to view the available outputs that can be mapped to the given property. Selecting an output value in this drop down links the output value to the property. The following rules apply to mapping:

a. A prompt output can be mapped to a property if its SDK output type (i.e.: string, enum, int) matches the SDK type of the property.

b. The first selectable output is always blank. This special, blank output clears any existing mapping for a property.

c. The same prompt output may be mapped to more than one property.

d. The Prompt Outputs from Query Results controls (listed on the Configure Prompts page) cannot be mapped to a property. Query Results output is only available as tokens for subsequent Query Results controls. (The rationale behind this is that any selected objects will be attached via a relationship, so individual properties need not be mapped.)

e. Unbound enum output from MP Enumeration List controls can be mapped to any enum property. Once mapped, the enum output becomes bound to the enum type of the property to which it is mapped.

f. If a property mapped to an enum prompt output is cleared and there are no other mappings that use that enum prompt output, the enum output returns to an unbound state.

g. Any prompt output can be mapped to a string property. The output is auto-converted to a string.

h. String prompt outputs can be mapped to richtext properties.

i. No output can be mapped to binary properties.

j. If a default value is specified for a property, that default value will be rendered in the Silverlight control whose output is mapped to that property. If a prompt is mapped to more than one property, the default value shown in the control is nondeterministic.

Knowledge Article

Links to relevant knowledge articles can be established on the “Knowledge Article” page. These articles are associated with the request offering when it is displayed on the web portal.

Figure 56: Knowledge Articles Page

Publish

Completing the “Publish” page ends the Request Offering wizard experience. On this page, request authors can designate an owner for the request offering and set the request offering status as either “Draft” or “Publish.” Only published request offerings are visible in the self-service portal. A request offering created in “Draft” status mode can later be promoted to “Publish” status.

Figure 57: Publish Page

If the status of the request offering is set to “Publish,” validation runs before the wizard completes to alert the user to any configuration errors in the request offering. Two common configuration errors include:

1. Failing to map a Required user prompt to at least one property on the Map Prompts page

2. Failing to specify a target relationship for a Required Query Results prompt when that prompt’s outputs are not transmitted through token criteria to a subsequent Query Results prompt. Checking either of the two relationship checkboxes on the Options page of the Query Results configuration form bypasses this error.

Next up….

We’ll post some demo videos of creating service catalog content in SCSM 2012!

This is a follow up post to the Request Offering Wizard Overview post and was also written by Neil Lydick.

Two Query Results settings cannot be modified in the UI and require manual edits to a configuration file or management pack. These settings include:

1. Setting the maximum number of instances displayed in all Query Results controls: The Query Results prompt type is unique in that it fetches live CMDB data to display rows to portal end-users. If the request author specifies a type and criteria that do not adequately restrict the set of instances displayed, then the performance of the portal server and CMDB can degrade. This degradation becomes more apparent as the number of request offering page views per visitor increases.

A global option exists in the SCSM Portal Web Server settings file (\inetpub\wwwroot\System Center Service Manager Portal\ContentHost\Clientbin\Settings.xml) to limit the maximum number of instances that can be displayed in any Query Results control. This setting applies to all clients and request offerings.

The key/value pair that can be added to the Settings.xml file is:

<Setting Key="DEFAULT_MAX_RESULTS" Value="100"/>

where Value=”” assumes an integer value. Result sets retrieved from the CMDB are capped at the maximum value specified.

2. Setting the number of instances displayed per-page in a Query Results control: By default, each Query Results control displays the set of instances matching its configured criteria in a series of pages containing 10 instances each. The number of instances displayed per page can be altered for a specific Query Results control by editing the XML of the Management Pack in which its parent Request Offering is saved. In contrast to the DEFAULT_MAX_RESULTS setting, the number of instances displayed per page is not a global setting affecting all Query Results controls: it can vary for individual controls.

The steps to configure this setting are as follows:

1. Identify the Management Pack in which the Request Offering is saved. This is found in the General tab of the Request Offering wizard.

2. Go to the Management Packs view in Administration -> Management Packs and select the Management Pack (MP) found in Step 1.

3. Once the MP is selected, click “Export” on the tasks pane to write this MP to a file.

4. Open the MP in a text editor and locate the XML for the request offering containing the Query Results control you wish to customize. You should see an <Extension> element within the MP containing <RequestOffering> sub-elements. Look for a RequestOffering that has a “Title” attribute that matches the title that you specified in the wizard.

5. Within the <RequestOffering> element, you should see a <PresentationMappingTemplate> element that contains a <Sources> subelement, which itself contains a list of <Source> child elements. Each <Source> element corresponds to a user prompt in the RO wizard. You can identify the Source element that corresponds to the Query Results user prompt you wish to customize by matching the text in the “Prompt” attribute to the text that you entered for the Query Results prompt. The ControlType attribute for the correct Source element will have its ControlType attribute set to “System.SupportingItem.PortalControl.InstancePicker,” which indicates that the corresponding prompt control is a Query Results control.

6. Under the correct <Source> element, you should find two additional subelements: <Configuration>, and, under <Configuration>, <Details>. To customize the number of instances displayed per Query Results page, add an attribute to the <Details> element with the name PageSize. Set the value of this attribute to the number of instances that you wish to display per Query Results page. Add only this attribute and preserve the surrounding XML.

A valid edit will look similar to Figure 54 (highlighted text added manually):

…

<Configuration>

    <Details IsMultiSelectAllowed="false" HideDetailsView="true" PageSize="5">

    <ClassOrProjection Id="7b070bc5-0f54-6663-f840-17affa1d6304" IsProjection="false" />

…

Figure 54: Customizing the Number of Instances Displayed Per Page

7. Save the edits to the MP file.

8. Import the saved MP file (Administration -> Management Packs -> (Tasks Pane) -> Import).

In preparation for your upgrade to SCSM 2012, you will want to set up a Pre-Production environment to test the upgrade in first.  You will want to make sure that the upgrade goes smoothly and that your customizations are preserved as expected.  Doing so will ensure a smoother production upgrade.  Customers often ask us how to replicate their production environment as a pre-production environment.

Here is how we worked with one customer – Fletcher Kelly (@fskelly) – to do it.

1. Promote a new DC into Production, wait for replication.

2. Add a admin account to Schema Admins (this is needed later on)

3. Do not reset any passwords of any run as accounts (learned this one the hard way)

4. Move DC into ring-fenced network.

5. Seize all required roles to the “Lab DC” (ntdsutil, this is where the Schema admin is needed for Schema Master)

6. Restored a DPM backup of the SM management sever VHD and DW management server VHD

7. Restored the required databases for SM (serviceManager LDF and MDF)

8. Restored the required databases for the DW (DWDataMart, DWStagingAndConfig and DWRepository)

9. Create the required Virtual Machines using the vhd’s you restored.

10. Present additional VHDs to replicate production drives. Each of the servers had two additional drives for MDF and LDF files respectively.

11. Copy the required MDF and LDF to the necessary locations on both the MS and the DW.

12. Restart both MS and DW

13. Once restarted, check the System Center Data Access Service, System Center Management and System Center Management Configuration Services

14. Check for a warning regarding SPN in the event log stating that a SPN must be created.

a. Log onto the server complaining about SPN (Usually MS and DW)

b. Run the following command (without quotes)

i. “setspn –U domain\username –A MSOMSdksvc/netbiosnameofMS”

ii. “setspn –U domain\username –A MSOMSdksvc/FQDNofMS”

iii. “setspn –U domain\username –A MSOMSdksvc/netbiosnameofDW”

iv. “setspn –U domain\username –A MSOMSdksvc/FQDNofMS”

For example mine – “setspn –U <some domain>\MySMSystemAcct -A MSOMSdksvc/MySMServer

For example mine – “setspn –U <some domain>\MySMSystemAcct -A MSOMSdksvc/MySMServer.mycomoany.com

15. If you got the error mentioned above, restart  System Center Data Access Service, System Center Management and System Center Management Configuration Services

Some other ideas I have but which I haven't tested yet:

1) Instead of introducing a new DC, try to P2V one of your DCs.

2) Instead of using a ring fenced physical network, put all your VMs on a private network on a host.

3) If your SM servers are installed physically try to P2V them.

Let me know how it goes for you in the comments below and we can all learn from each others experiences.

Read this bog post first:

http://blogs.technet.com/b/servicemanager/archive/2011/11/08/request-offering-wizard-overview.aspx 

In SCSM 2010 we had an Active X control that was used to look up the local computer name that the user was running the portal on.  If a computer record existed for that computer it would be added to the submitted incident as an affected computer.  That was good and bad.  It was good because it gave the analyst working on the incident some context about what computer could be having the problem.  The user didn’t necessarily need to know the name of the computer.  But it was also not ideal because it required an Active X installation on the client.  It also isnt necessarily always true that the computer the user is submitting an incident from is the computer that is having the problem.  It also wasn’t possible to select any other computer as the affected computer.

So, in SCSM 2012 the request offering wizard makes things a little more flexible. You can use the Query Results prompt type to present the user with a list of objects to choose from (and it could be multiple).  One of the more common things you will want users to provide when making a request from the service catalog is to choose a computer. Oftentimes you want this to be a computer that is related to them somehow in the CMDB – typically either through the Custodian or the Primary User relationship. The Primary User relationship is automatically populated from SCCM based on the logon history of the computer so this is a good way to determine which computers a user frequently uses.  In this blog post I’ll show you how to allow the user to select from only those computers for which he is the Primary Owner.

For this example, I have created a ‘PC Recycle’ request offering.

You can see that there are only two computers shown in the list even though in my test environment I have quite a few more than that:

Those two computers show up because they are the only two for which I am the primary user:

Let’s take a look at how I configured the request offering to limit the list of computers to just those for which I am the primary user.

Here’s the General information:

Here is where I create the user prompt for the user to choose a computer.  Notice it is a Query Results prompt type.

On the Configure Prompts page, I select the computer prompt and click the Configure button…

…. which brings up this dialog:

In the Select Class tab I choose ‘Combination Classes’ from the drop down because we are going to use a “type projection”.  Using a type projection allows us to specify query criteria which spans over relationship types.  For example – ‘all computers where the related primary user’s username = twright’.

I then chose the Computer (Advanced) combination class (aka type projection).

On the Configure Criteria tab I select the Primary User relationship on the left and then check the ‘User Name’ checkbox on the right and click the Add Constraint button.

Now, this is where the magic happens!  First select ‘Equals’ from the operator drop down.  Then pull down the Set Token menu and select the ‘Token: Portal User Name’ option.

The result will look like this:

The effect of this is that whatever the logged in user’s user name is for the user that is accessing the portal will be passed in at run time to this criteria.  The result is that only those computer which are related to the user over the Primary User relationship will be displayed.

On the Display Columns tab I choose which columns I want to display:

On the Options tab I choose to relate the selected computer as an affected configuration item to the service request that will be submitted.

Configuring the rest of the request offering is just standard stuff so I won’t go into that here.

The result of someone submitting a service request like this is:

You could use this same approach for displaying other types of objects that are related to the user logging into the service catalog such as:

• CI custodian (this would work for any kind of CI, not just computers)
• Work items where the user is the affected user
• Work items where the user is the assigned to user
• A manager’s direct reports
• etc.

Neil Lydick, one of the devs on our team, came up with this handy PowerShell script with a recursive function that displays the data model in a PowerShell window.

• Blue classes are abstract.
• White classes are non-abstract (aka “concrete” classes).
• Red text are the key properties for that class.

The script takes two parameters:

1) The class name you want to start from.

2) The server name to connect to (example: localhost or scsm.contoso.com)

We will also add this to the SMLets CodePlex project.

Just for fun try passing in System.Entity as the class name.  That’s the base class.  See how many classes you come up with. I have 753 in my installation of SCSM 2012. 

Here’s the script. Just copy/paste it into a notepad window and save it as PrintClasses.ps1 and then run it as describe above.

$className = $args[0]

$Host.UI.RawUI.buffersize = new-object System.Management.AUtomation.Host.Size(150,9999)
$Host.UI.RawUI.windowsize = new-object System.Management.AUtomation.Host.Size(150,80)

[reflection.assembly]::loadwithpartialname("Microsoft.EnterpriseManagement.Core") | out-null
$emg = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup $args[1]

$selectedClass = $emg.EntityTypes.GetClasses() | ?{ $_.Name -eq "$className" }

$global:countOfClasses = 0;

function PrintClasses($class, $levelString)
{
   $keyProperties = @($class.GetProperties(0) | ?{$_.Key -eq $true});
   $keyString = "";
 
   if ($keyProperties.Count -gt 0)
   {
       $keyString = "{" + [string]::Join(",", $keyProperties) + "}"
   }

   if ($class.Abstract -eq $true)
   {
      write-host -foregroundcolor cyan $levelString $class.Name " " -nonewline
      write-host -foregroundcolor red $keyString
   }
   else
   {
      write-host -foregroundcolor white $levelString $class.Name " " -nonewline
      write-host -foregroundcolor red $keyString
   }

   $global:countOfClasses++;
   
   $derivedFromClass = @();
   $derivedFromClass += $class.GetDerivedTypes();
  
   foreach ($derivedClass in $derivedFromClass) 
   {
      PrintClasses $derivedClass ($levelString + "  ")
   }
}

PrintClasses $selectedClass "  "
write-host "==============================";
write-host "Number of classes: " $global:countOfClasses;

In order for a Request Offering to show up in the Service Catalog all of the following must be true:

1) The Request Offering Published property must be ‘Published’

2) The Request Offering must be included in a Service Offering

3) The Service Offering that includes the Request Offering must have the Published property equal to ‘Published’

4) The Service Offering must be included in a Category (list).  The Category list can be edited in the Lists view.  It’s called ‘Service Offering Category’.

5) The Service Offering Language must match the language of the browser you are using to connect with.  A common mistake is to choose ‘English’ as the language when you are connecting with a ‘English (United States)’ browser.

The Service Catalog is organized like this:

Category 1

                Service Offering 1

                                Request Offering 1

                                Request Offering 2

                Service Offering 2

                                Request Offering 3

Category 2

                Service Offering 3

                                Request Offering 4

If you’re doing it right every Request Offering should have a Service Offering and a Category shown in the List View:

The Category view would look like like this:

Background blog posts for this blog post:

Introduction to Service Manager 2012 Service Catalog - Part 1

Request Offering Wizard Overview

=========================

Nobody wants to be the poor guy that has to fulfill the routine service requests manually.  Service requestors don’t want to wait for the person behind the scenes to get around to working on their requests.  Manual fulfillment of service requests is slow, prone to error, and not cost effective.

That’s where the power of SCSM-Orchestrator integration comes in to automate those routine requests.

This is a tutorial video showing how to set up an Orchestrator runbook to do something automatically and then include that runbook as an automated step in the process of a service request that is published the the Service Catalog as a request offering.

I’ll follow up this video with some more “real world” scenarios in a separate demo video/blog post.  Definitely watch this video in HD and full screen to get the full effect!

The Microsoft Solution Accelerators team is pleased to announce the System Center Cloud Services Process Pack beta.   This project was code named “Andes” if you have heard us refer to it by that name before.

 Download the System Center Cloud Services Process Pack Beta.

System Center Cloud Services Process Pack Beta is Microsoft’s Infrastructure as a Service solution built on the System Center platform. With the System Center Cloud Services Process Pack, enterprises can realize the benefits of Infrastructure as a Service while simultaneously leveraging their existing investments in the Service Manager, Orchestrator, Virtual Machine Manager, and Operations Manager platforms.

Corporate datacenters are in transition. The recent shift from physical to virtual environments is now being replaced by an interest in moving to the cloud—specifically both private and public cloud infrastructures. Private cloud management assets are being delivered with System Center 2012 and a key part of this solution is the self-service experience. This experience is now significantly enhanced by the System Center Cloud Services Process Pack.

I’ll post some blogs on how to use this awesome MP in the near future.

This is a follow up post to Demo: Automating Service Request Fulfillment from the SCSM Service Catalog with Orchestrator.  You’ll definitely want to watch that one first so that this one makes more sense.

In this demo video I show some real world examples of using SCSM and SCO together to automate service request fulfillment. Just click the video thumbnail to view it on SkyDrive.

One of our implementation partners – Acceleres – is hosting a webinar on implementing SCSM 2012 this week.  Here’s the details.

Microsoft System Center Service Manager 2012 Implementation Webinar 11/17/2011 10:30AM PDT

Service Manager 2012 RTM version will be here soon, with new features (service catalog, service request, release management, VMM integration, and reporting analytics) and improvements (Better incident SLA support, more robust portal, parallel execution of activities, better subscription infrastructure, email lifecycle support, and more). Whether you've implemented SCSM 2010 and are looking to migrate, or are finally ready to move on Service Manager with the v2 release, this session is for you. It features the most up to date information provided by the implementation partner, Acceleres. Learn from the experts what is new and improved, along with the implementation consideration you must know to help you size scope, effort and your organization's readiness.

Register today.

It supersedes SP1 Cumulative Update 2 (CU2) and contains a superset of the fixes that are provided in SP1 CU2. It can be applied to SP1 CU2 or directly to a Service Manager 2010 SP1 installation.
This update contains a set of bug fixes to the Service Manager 2010 SP1 release. It should be applied to all Service Manager 2010 SP1 server installations and to any Authoring Tool installations. There are three executable files available:

1. SCSM2010SP1_CU_KB2588492_i386_7.0.6555.128_EN.exe or
   SCSM2010SP1_CU_KB2588492_AMD64_7.0.6555.128_EN.exe
   These executables contain the cumulative update package and should be applied to all Service Manager server installations.
2. KB2542118_MPLibraryUpdate_AuthoringTool.exe
   This executable contains the updated management packs and should be applied to any local Authoring Tool installations to make them compatible with the server.

• MP Import: When a data type is a decimal sometimes the decimal becomes an integer
• Corruption of the Type ManagementEntity table when importing a type extension
• Updates to properties are not brought forward to DW if updates to the instances happens in the same transaction or right before deleting the instance
• AD Connector not bringing in new updates
• When creating a new CR using the new CR form, clicking the Apply button sometimes creates a duplicate record
• Console intermittently freezes when updating/creating incident and clicking apply
• HealthService fails to stop at the end of SP1 DW patch if previous start action takes too long
• When launching the SCSM console on client machines and server the Reporting Wunderbar doesn’t appear
• High CPU in monitoringhost.exe when creating or updating an incident that triggers a notification workflow

Download it here:

http://www.microsoft.com/download/en/details.aspx?id=28159