Home » Posts tagged 'System Center'

Tag Archives: System Center

Change Management in System Center Service Manager

I have been testing Change Management in System Center Service Manager beta 1.

ITIL defines the change management process this way:

The goal of the Change Management process is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently improve the day-to-day operations of the organization.

Change management is responsible for managing change process involving:
* Hardware
* Communication equipement and software
* System Software
* All documentation and procedures associated with the running, support and maintenance of live systems

Source: en.wikipedia.org

System Center Service Manager has a connector to System Center Configuration Manager that synchronizes hardware information and other relevant information to Service Manager. When creating a change request it is possible to pick/select objects syncronized from Configuration Manager. For example if you want to create a change request, regarding a security group in Active Directory, then you can select the group from the list. You can also open the object direct from the change request form, that is a convenient method when you need to verify some information.

 
Another alternative to start a change request is to select a object and then click create change request from the task bar. Then related items are already filled in. In the example below we want to create a change request involving Vista Service Pack 2.

 

When creating a new change request there are a couple of templates delivered out of the box. It is possible to create your own templates with pre-defined attributes like area, priority, people to notify, risk level and impact.

On the Related Items tab, of the change request, the creator can add related items like objects from Configuration Manager, Active Directory, documents and files and other work items. Work items can be for example incidents that are related to this change request. 

When a change is submitted the creator can track the change request on then process tab.

 

When all activities are carried out and the change request is filled in you can close the change request from the console.

It is possible to configure notification to get notified when something is happening. For example if someone creates a new change request you want to send a notification to all change reviewers.

It is reasonably easy to configure change management templates and notifications based on them. But it is a number of steps to take and a name standard has never been more important. If you don’t have a good name standard you will lose yourself pretty quick. Something that I think most Operations Manager 2007 administrators recognize. There are a couple of notification scenarios where I could see a need of more detailed criteria parameters. But as this is Service Manager beta 1 I guess we will see a lot more features in later beta versions and the RTM version. I think that the biggest obstacle will not be to how to configure Service Manager but instead how to plan and design all your workflows within your organization before you can input them into Service Manager.

If you are interesting in change process flow there is a lot of good information here at TechNet.

Incident Management in System Center Service Manager

I have been testing Incident Management (IM) with focus on the notification part of IM in System Center Service Manager beta 1.

The main goal of the IM process is to get back to a normal service operation as quickly as possible and to minimize the impact on the business, in other words ensuring that the best possible levels of service quality and availability are maintained. “Normal service operation” is defined within Service Level Agreement (SLA).

 In my test environment I built the following workflow:

Incident templates can be utilized to achieve IM flexibility. Incident templates include common settings for different types of incidents. For example when a service desk receives a call from a user who can´t access a network folder, the service desk operator can then apply the network issue incident template and make sure all the necessary information is collected from the user reporting the incident. The templates also guarantee that incidents are configured with correct owner, category, priority and other related items.

System Center Service Manager has a connector to System Center Configuration Manager that synchronizes hardware information and other relevant information to Service Manager. When a service desk creates an incident and selects which machine the affected user is working from, the service desk can see all information synchronized from Configuration Manager.

In Service Manager there are a number of workflows out of the box and you can also create your own. One of them is Incident Change.

In my test environment I built the following four workflows:

1. One workflow sends e-mail to the affected user when new incidents are created. It is always good for the user to have the incident ID and to know which service desk has begun working on the incident.

2. One workflow sends an e-mail notification to the operator who is configured as “assigned to” in the incident. If it is not the same operator creating the incident who will be working on it, it is good to send a notification.

3. One workflow sends an e-mail notification to the operator who is configured as “assigned to” in the incident. If another operator adds a comment or information to the incident a notification will be sent to the operator who is assigned to the incident.

4. One workflow sends an e-mail notification to both the affected user and the operator who is configured as “assigned to” in the incident.

Service Manager synchronizes information from Active Directory through an AD connector so e-mail addresses and other account information already exists in Service Manager. Here we don’t have to create recipients the same way as we do with subscribers in Operations Manager.

It is reasonably easy to configure incident templates and notifications based on them. There are a couple of scenarios where I could see a need of more detailed criteria parameters. But as this is Service Manager beta 1 I guess we will see a lot more features in the RTM version. I think that the biggest obstacle will not be to how to configure Service Manager but instead how to plan and design all your workflows before you can input them into Service Manager.

Query a database with a monitor

I have seen a number of questions about how to run queries against a database and verify the answer. One way is to run a script inside a monitor. In this blog I wrote how to setup a script in a two state monitor. The script in this post will count number of  fields, if there are more then five, status of the monitor will be changed. Note that counting starts at 0 with fields collection.

 Const adOpenStatic = 3
Const adLockOptimistic = 3

Set oAPI = CreateObject(“MOM.ScriptAPI”)
Set oBag = oAPI.CreatePropertyBag()

Set objConnection = CreateObject(“ADODB.Connection”)
Set objRecordSet = CreateObject(“ADODB.Recordset”)

objConnection.Open _
“Provider=SQLOLEDB;Data Source=R2B1;” & _
“Trusted_Connection=Yes;Initial Catalog=ContosoConfiguration;” & _
“User ID=CORP\Administrator;Password=;”

objRecordSet.Open “SELECT * FROM roles”, _
objConnection, adOpenStatic, adLockOptimistic

varNo = objRecordSet.Record.Count

If varNO > 5 Then
Call oBag.AddValue(“SQL_Status”,”Error”)
Else
Call oBag.AddValue(“SQL_Status”,”Ok”)
End If

Call oAPI.Return(oBag)