Service Manager 2010 is the new workflow and incident response module that's been added to the Microsoft System Center suite of management applications. Conceptually, it's a process control application with two faces: a management console for network managers to perform workflow operations, and a Web-based help desk Self Service Portal for end users.
Service Manager 2010 needs to be purchased separately, but is heavily dependent on two other Microsoft System Center modules, Operations Manager (Formerly 'MOM') and Configuration Manager. Without these two modules as input sources, Service Manager is a pretty handicapped component, which made us wonder why, as these three modules are so heavily intertwined, they're sold separately.
The upside, however, is that they work well together. They don't mandate Microsoft infrastructure exclusively, although the joining of non-Microsoft apps, operating systems, and infrastructure is no easy task.
What it does
At the heart of Service Manager is an MS SQL Server database, called the Configuration Management Database (CMDB) that receives input from Service Manager workflows, and, more importantly, from Ops Manager and Config Manager via 'connectors'.
The flow of data from Ops Manager and Config Manager is usually one-way; they generally update the CMDB, and register their state into Service Manager, not the reverse.
Armed with configuration information and alerts from Ops Manager, Service Manager can trigger action items and workflow activities.
When we triggered rudimentary alerts, like disk-full warnings, the alerts popped up almost instantly, as Ops Manager informed Service Manager that the disk was getting full. Ops Manager has triggers that fit MS Exchange, SQL Server, and other server-based applications, and also knows a lot about Active Directory data, along with server-based states.
Configuration Manager manages software deployments and configuration details for Windows Servers, clients, and mobile devices. Its role for Service Manager is packaging, delivery, and application inventory/asset knowledge as a software and configuration fulfillment manager.
The devil of details
Service Manager takes configuration, operations and Active Directory data and stores it in the CMDB. When we installed Service Manager, we found the "connector" APIs were available immediately, and transferring already large stores of information from Config Manager and Ops Manager shouldn't take long over local networks.
The Configuration Manager and Operations Manager connectors are a one-way street, meaning that Service Manager doesn't in turn, update these two module's databases. Workflow in Service Manager spawns actions, which are in turn able to be marked as completed.
If we made a software delivery from a simulated user request, we could make part of the action contingent on Configuration Manager having observed the installation on the user's machine.
The Service Manager help desk function allows Active Directory users to fill in Web forms for service, help or downloads. On the home Web page for the Service Manager Self Service Portal, administrators can place systems information notes, like servers known to be out or applications unavailable. Another part of the page allows users to search pre-selected knowledgebase articles on administratively-designated topics.
Users can make requests for software on the Self-Service Portal, and be presented "automagically" with the desired product(s), or perhaps spawn an approval process that brings in Service Manager admins prior to the software package being delivered by Configuration Manager.
On the console side, a library of applications can be selected for distribution, each with conditions placed on the workflow. These conditions can be a compatibility check, and perhaps a signal from Configuration Manager that all's been delivered, or stipulation processes if the software can't be installed for some reason within a set period of time. The action items remained open as processes until the details of that set were satisfied. It's all very orderly.
What happens as a side effect is that Service Manager becomes a "best practices" task master for network admins who respond to the tasks, and in that process, document what they've done for archiving or compliance purposes.
The "best practice," actually the implemented task procedure, is a function of a Service Map defined in Service Manager. The Service Map can have information manually entered, or be an imported 'trigger' from Ops Manager. The source of the trigger message might also be e-mail, Self-Service Portal, or a systems message (like those found in TaskManager). Priorities can be assigned for events spawned by the trigger, so that urgent details are attended to first.
The trigger can be prioritized as critical, warning, or informational. Once the trigger's conditions are met, the network admin will see the alert inside of the Service Manager Console.
Context for the alert (who, where and what from the CMDB regarding the alert) can be drilled down to provide an administrator information needed to deal with fixing the problem that spawned the alert.
In practice, Ops Manager alerts typically took about a minute to reach the Systems Manager Console. Having the context of the alert available usually made short work of getting the information needed to fix the alert. However, while a full chain of information is available about the alert, admins unfamiliar with the context of the application may have difficulty assessing what steps might be necessary to fix a problem, and there can still be a lot of detective work needed to fix random problems.
While Service Manager is an able help desk system, there can still be gaps that require click-work to solve problems.
The systematic approach represented by Service Manager was easy for us to configure; installing connecting pipes to Ops and Configuration Manager was equally simple. Service Manager uses IIS to host its Self Service Portal/SSP application, which was also simple to configure. User choices on the SSP are understandable, and software downloads available via the page were immediate or required approvals as we had configured them.
Ops Manager alerts, while not instantaneous, arrived assuredly and the administrative steps that we mapped were dealt with as though in a script. The steps weren't finger-snapping fast, but good enough. Another module, Data Protection Manager or its equivalent, is recommended because an outage of any of the components (console, CMDB, or other modules) represents a break in the chain that must be quickly be remade if help desk production is to continue. We envision that a lot of dependence is placed on Service Manager, and its absence could cause a lot of workflow backup.
For most of this to work, one needs to have employed a fully Windows based Active Directory network. While Ops Manager has connections and some monitoring for other operating systems, it's not nearly as rich in management and alerting expertise as it is for Windows, especially Windows clients. Even one Mac or Linux box creates a significant amount of obstacle and exception handling, using Service Manager as a helpdesk remediation system.
Microsoft shops won't mind this, but any organization with a reasonably heterogeneous domain will want to eschew the really rich feature set of controls offered by Service Manager as they'll need a separate-but-equal set of applications to deal with non-Windows devices. Once an organization has wrapped their help/service capabilities around the Service Manager product, the work needed to add non-Windows products is a huge hurdle, excluding organizations from wanting to even think about adding other operating system components unless parallel functionality can be found in them.
We found that deploying Service Manager means buying into Ops and Configuration Manager, but these modules harmonize very well together towards help desk support and incident life-cycle management.
User Self Service Portal components are flexible in terms of spawning workflow, and the admin console in Service Manager allows flexible workflow choices to be made and enforced for network managers. The downsides are that this works largely on Windows only.
Henderson and Allen are researchers for ExtremeLabs. They can be reached at firstname.lastname@example.org.