While you can think of System Center Orchestrator as the glue that binds the System Center suite together, System Center Service Manager (SCSM), especially with the upcoming 2012 release previewed at places like MMS and TechED, increasingly seems to be the front end that makes it straightforward enough that Joel from Marketing can initiate Orchestrator Runbooks.
SCSM is one of those Microsoft products that most administrators aren’t aware of. If they know anything about it at all, it’s that it is some sort of service desk solution, something like Remedy. The current version of SCSM has a reputation that is shared by many first release products. That the product does some interesting things, but it needs to spend a bit more time in the oven before it finds itself more widely adopted.
SCSM can do some very interesting things - primarily because it’s designed to fully integrate with other products in the System Center suite. It’s this integration, these synergies between management products, that lead me to believe that in the next few years we’ll see SCSM getting a lot more attention.
Why do I think that?
Let me come back to Orchestrator. For those not up-to-date on their Orchestrator nomenclature, a runbook is a set of automated tasks that administrators can put together. It’s sort of like writing a script, but instead of doing it all in PowerShell, you use a drag and drop interface to link specific tasks together. Administrators who have the sort of enthusiasm for scripting that a 4 year old boy has for cabbage can put together automated processes in less time than it takes to explain what the term “Declarative Provisioning” means to anyone who is buzzword aphasic . When you build a runbook, you draw these tasks together from Orchestrator IP. An IP is a collection of product specific tasks. Depending on the IP, one task might be to get Data Protection Manager (DPM) to go and protect a specific data source, another task might be to create a new VM from a template, and yet another to recover an SQL database.
Although you can use runbooks to heavily automate processes, in some situations you need to pass information to that runbook for it to be able to do anything. For example: the details of the virtual machine template that you want use to provision a new VM using VMM, or the details of the database that you want to recover using DPM. By hooking System Center Service Manager into Orchestrator, you can create forms in SCSM that allow data to be passed directly to Orchestrator.
For example, you could create a runbook in Orchestrator that allows for the recovery of a SQL Server database by leveraging Data Protection Manager. You can then configure SCSM so that a portal page is available that allows users of that database to perform database recovery themselves. By linking SCSM to Orchestrator, you can query the DPM server to populate a drop down list of available recovery points, allowing the portal user to specify which recovery point they want to recover from rather than having to request a recover operation be performed by a DBA or DPM administrator.
As an administrator, leveraging SCSM, Orchestrator, and DPM, you can get all the back-end stuff working so that from perspective of a database user, recovery of a database becomes as simple as recovering a file from a folder using the Previous Versions of Files functionality.
SCSM can also be configured to automatically execute Orchestrator runbooks in response to jobs submitted through the SCSM Self Service portal. As with all the system center products, the whole is a lot more than the sum of its parts.
