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.
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'.
Clear Choice Test: Microsoft System Center: Data Protection Manager 2010 | Test methodology
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.
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.