Latest posts by Paul Schnackenburg (see all)
- Use Azure Managed Service Identity (MSI) to store passwords in your code securely - Thu, Nov 9 2017
- Azure Data Lake overview - Fri, Sep 22 2017
- Moving from Office 365 to on-premises Exchange - Tue, Sep 19 2017
Connectors in System Center Service Manager 2012 ^
SCSM 2012 has a connector for Virtual Machine Manager that brings in information from its library such as Services, VMs, Templates, networks and so forth. The Active Directory connector brings in computer, groups and user accounts along with printers. The inclusion of groups is new in 2012; SCSM 2010 didn’t do group accounts. Active Directory groups are also a way to assign permissions in SCSM, simply put the user into the right AD group and they will receive the appropriate rights in SCSM, including what is offered to them in the self-service portal.
There are also two Operations Manager connectors; one for objects that is read only and another that turns alerts in OM into incidents in SCSM and maintains the relationship between them. If the alert is resolved in OM, the incident will be closed and vice versa.
The Orchestrator connector brings in a selected folder (or all folders) and their associated runbooks through the Orchestrator web service which means runbooks can be started from Service Manager and can be included in workflows. Finally there’s a connector to Configuration Manager (if Asset Intelligence is turned on in SCCM) that brings in devices and their associated hardware and software inventory.
These connectors continue to bring in new and changed information as it’s changed in the originating application. Note that there isn’t a connector for Forefront Identity Manager although the development team has looked at the engineering work required to make one.
Linking System Center Service Manager to all the other data sources in your environment will quickly build an accurate CMDB of all your IT assets.
To connect Service Manager to third party applications and in-house data sources you can use CSV import, which can be scheduled to update the data at regular intervals. A mapping file makes sure that the source “columns” are mapped to the right SCSM data values. There’s also import through PowerShell, and there’s an API / SDK available for writing custom connectors.
With so many connectors to different data sources it’s comforting to know that SCSM is smart enough to reconcile the data, so computers accounts for instance from AD, SCOM and SCCM are consolidated into one account in the database.
SLA and Release management in SCSM 2012 ^
Making sure that IT stays within its Service Level Agreements is helped in SCSM by having both a warning and a breach level, so processes that encourage dealing with incidents that have existed for some time and are heading towards a breach are more likely to be adopted. Warnings and breaches are color coded in the console and operators can also be alerted via email. There’s an option to build calendars that define business hours and holidays for use in one or more SLA definitions. Service level performance can also be related to Operations Manager alerts and counters.
Build your SLA monitoring for your IT services and include business and non-business times.
A new feature in SCSM is Release Management that handles the process of moving software from development to testing to production in a standardized way. When structuring release management each change can be a release or multiple changes can be encapsulated in the same release. It also handles sequential and parallel release activities to suit different types of deployments. To support Release Management there’s also new CIs for environments and builds; user roles for Release Manager and Activity Designer as well as parent/child relationships between activities and dependent work items.
The fourth part of this series will look at Service Delivery and Automation and how System Service Manager 2012 can help with this, along with how you can customize self-service for users through SharePoint tools.