+1 (866) 930-8356
Concurreny
Real Microsoft expertise. Real business value.

System Center Service Manager Scalability and Performance Tip: Isolate the Workflows!

As a follow-up to my presentation at MMS, I thought it might be fun to do a series of blog posts dedicated to the topic of System Center Service Manager performance and scalability.  The first topic I’ll address is “isolate the workflows”.  What do I mean by isolation?  This idea falls into two principal categories, including both the appropriate use of the primary management server and also the extensive use of Orchestrator in complex workflows:

 

Appropriate Usage of Primary Management Server

I’ve found it immensely valuable to have my first management server configured to be untouched by consoles or Orchestrator.  This provides all of the work processes associated with workflow its own sever.  It also allows me to restart the services on that server without causing problems for console connections.  I’ve also found that by not targeting that server for Orchestrator work, I’m able to ensure that Orchestrator has its own dedicated pool of performance.

 

Using Orchestrator for Workflows

I’ve found that for most complex workflows, I’m better off using the complex workflow engine in Orchestrator.  I use this for everything from incident categorization, to notifications, to change processes.  I walk through these processes in a recent user group meeting.

 

You can watch that meeting here:

http://www.concurrency.com/blog/incident-management-and-change-management-processes-with-orchestrator-smug/

 

If you want to see all the performance tips in one place, check out the MMS presentation “Configuring Service Manager for Performance and Scale”

http://www.concurrency.com/blog/configuring-service-manager-for-performance-and-scale/

 

Do you know if a workflow has fallen behind in Service Manager?  Use the queries that Travis Wright posted on the gallery.  I’ve written of a practical experience with them here:

http://www.concurrency.com/blog/scsm-a-monitoring-host-is-unresponsive-or-has-crashed-error-4000/

 

I hope this helps address a relatively simple, but from my perspective a very important aspect of SCSM scalability.

 

Cheers!

 

Nathan Lasnoski

 
 

Nathan Lasnoski is the Director of Concurrency’s Infrastructure Practice, a Datacenter MVP and a recognized leader in Core Infrastructure Design, SharePoint Infrastructure, Virtualization, and Unified Communications technologies.

Find Nathan on: Linkedin Twitter

 

Categories