Increasing Query Result Max Sizes in Request Offerings

 In order to increase the query results in a Request Offering to a larger number, you’ll change the maximum query results configuration on the SCSM Portal Web Server.  You’ll open the XML at “\inetpub\wwwroot\System Center Service Manager Portal\ContentHost\Clientbin\Settings.xml” and modify the key to the value you want “<Setting Key=”DEFAULT_MAX_RESULTS” Value=”4000″/>”

If you’d like more information on this, check out Travis Wright’s blog here: http://blogs.technet.com/b/servicemanager/archive/2011/11/08/advanced-query-results-customization-for-request-offerings.aspx

You’ll need to be careful about using this option.  If you increase the maximum of query results size too large you’ll be causing unnecessary IO against your Service Manager infrastructure and could cause performance problems.  The general idea is that the maximum results returned should be no larger than you require to serve the customer.  I’ve rarely had a reason to go over 2,000 results, especially since a query result larger than that quantity is not as useful as it would seem.  The idea is that we want to make the return of data as effective at finding the right data to select as possible, vs. causing the end user to tab through the query results.

Using Query Result Filters

 I’ve found that when you are querying content from large data sets, such as 20,000 computers or users, you can’t simply increase the size of the query results, since it will cause a significant load on the server.  Also, users will spend too much time looking through results that don’t match their needs.  In order to deliver users more specific content to select from you can use pre-filters using previously entered data. 

 Let’s pretend that we want to return a list of workstation(s) for a primary user from inside our domain  You’d use this for requests such as self-service application deployment, workstation refresh, and settings pushes.  We don’t want to change our maximum query results, since returning 30,000 workstations for every request would be a bad idea.  Instead, we’re going to ask the user questions to filter the list of workstations that they are presented with.  In order to provide faster results and cause an immediate blank first pass, we’ll also use a pre-filter which aids our request process.   In our case, the desired result is a list of workstations which match our specific requirements.

 I started working on this type of request and immediately created a user search box and the CMDB query.  These two combined to form a functional search, but also resulted in a poor user experience, since the initial return was searching for blank data and took an extended time to return a useable user prompt.   The result was an initial screen load that looked like this:

I found that if I used “Token Portal Username” it worked perfectly and the response was almost instant.  However, in this case the workstation isn’t tied to that user, so I can’t leverage existing data.

 I found that by configuring simple lists with filtering criteria in combination with my search I was able to provide a very responsive interface and also better results for my request offering.  In this case I added a drop-down list to ask for the domain of the workstation, which then functioned as a filtering criteria through an AND statement to create my results.  I found that even when combining this with a filter criteria which included all workstations, this was drastically faster.  The trick was to setup the simple list to include no initial results, which provided very fast form load and quick search result return speeds. 

The query filter critera looks like:

Resulting in this:

I’ve used this same technique in searching for many other types of values, such as computer’s based on primary user, groups, or software items.  The key is to choose something that helps the user narrow down the result set.  Ideally I want the device, application, or group to be returned without the user needing to do any additional filtering to select it.

I hope this helps everyone out. 

Nathan Lasnoski

We know that different persons within the IT department are going to want to know different things, as in this slide I used from MMS, we describe that around our business services, we need both strategic and operational knowledge.  Check out the data around the service that provides visibility into the service at an aggregate level, across many service management functions.

In System Center Service Manager and Operations Manager we leverage the concept of the service.  In Service Manager we articulate the service in our Business Service listing in the CMDB.  In my example, you can see several individual services, each of which are listed with a different function, priority, etc.

As we open a service, such as Active Directory, you can see how we’ve included detailed contact, priority, and business information.  This is also the place where we’re aggregating individual incidents, service tickets, change requests, releases, and risks.  We can use this aggregate information in decision making, as well as operations such as approvals (a blog for another day). 

Also note that the configuration of this service from Operations Manager is synchronized into Service Manager, making up one model, from which we can manage changes as Operations Manager automatically detects them.  The reason why is because both Service Manager and Operations Manager share the same management pack structure.  The Business Services in Service Manager are the same as the Distributed Applications in Operations Manager.  Here is the view of that data in Operations Manager:

…and in Service Manager. (showing the same configuration)

You can see how this information is super-valuable.  It allows us to manage our efforts, configuration, and costs around an individual service.  This provides the visibility, such as through a scorecard, that IT Directors never had before.  It also provides the information to IT Analysts, who want to know the configuration of a business service.  Finally, it aids in automations, being used in approvals, releases, and service offerings. 

We also see the changes to the service and the associated work items tracked and logged in the history.  You can see in my case that I’ve been using Service Requests to automatically add Active Directory users and that the requests have been associated to my Active Directory business service.

 I hope this provides a new look at how to articulate your world within System Center!  In the next post we’ll talk about how you synchronize management packs and distributed applications from Operations Manager into Service Manager.

You can also learn more about this concept by listening to our MMS session:

http://blog.concurrency.com/infrastructure/top-10-production-experiences-with-service-manager-and-orchestrator/

Nathan Lasnoski

Digital MMS:  Get entire recorded presentation here!

http://www.mms-2012.com/digitalmms

 Nathan Lasnoski

The starting point for our request process is to gather information and construct our templates.  We’ll need to create the usual Service Manager 2012 components, including:

• A Service Request template
• A Change Request template
• A Service Offering

In my case, I’m gathering information from the customer using my Service Request, then sending the request information into the Change Request.  You would use this process for any Change Request with Service Manager, as Request Offerings are only used with Incidents and Service Requests.  Since we likely want to use the self service portal for Change Requests as well, I like to use Service Requests to gather Change Request data, then use the data to intelligently create a Change Request.  Pretty cool, eh? 

As with every Service Manager integration, we’ll start with initialize data:

You can see this maps up to the runbook which was synchronized to Service Manager through our Orchestrator connector.  Note that every time you modify the initialize data fields you will need to delete and resynchronize your runbook.  This is intentional to protect the integrity of the data transfer in automations:

Then we’ll get the runbook using the ID.  We’ll be doing this to pull additional information from the Service Request.  You use this technique to pull data from within a Service Request where you haven’t already mapped the fields in the initialize data process.

Next we’ll get the Service Request GUID.  This will enable us to get the Service Request itself.

Next we’ll get the Service Request.  We’ll use the Service Request to get its related items so we can map them to the Change Request (which we’ll create).

Following getting the Service Request we’ll create the Change Request.  There are a couple things to specifically note here.  First, you need to make sure your Change Request has a title.  Second, if you want your Change Request to have the correct naming convention, you’ll need to set it here.  You’ll see that I’m using the CR{0} structure, which will create CR with the appropriate ID.  This is the same structure as the SDK.  If you don’t set the CR you’ll have a really inconsistent CR naming.

Next we’ll create a relationship between the new Change Request and the Service Request.   You’ll see that the source class is the Change Request and is mapped up to the source object GUID.

Next we’ll get the relationship of the Service Request and its related configuration items.  This will enable us to map the configuration items to the change request.

Finally we’ll relate the configuration items from the Service Request to the Change Request. 

I hope this was helpful .  This should show you how to bring initialized data into the Orchestration, retrieve data using the ID, as well as creating relationships and new objects.

Happy automating!

Nathan Lasnoski