Service Strategy
Process Objective: To decide on a strategy to serve customers. Starting from an assessment of customer needs and the market place, the Service Strategy process determines which services the IT organization is to offer and what capabilities need to be developed. Its ultimate goal is to make the IT organization think and act in a strategic manner.
Service Design
Process Objective: To design new IT services. The scope of the process includes the design of new services, as well as changes and improvements to existing ones.
Service Transition
Process Objective: To build and deploy IT services. Service Transition also makes sure that changes to services and Service Management processes are carried out in a coordinated way.
Service Operation
Process Objective: To make sure that IT services are delivered effectively and efficiently. The Service Operation process includes fulfilling user requests, resolving service failures, fixing problems, as well as carrying out routine operational tasks.
Continual Service Improvement – CSI
Process Objective: To use methods from quality management in order to learn from past successes and failures. The Continual Service Improvement process aims to continually improve the effectiveness and efficiency of IT processes and services, in line with the concept of continual improvement adopted in ISO 20000.

ITIL in System Center

Change Management

  • Change Control
    The procedures to ensure that all changes are controlled, including the submission, recording, analysis, decision making, and approval of the change. Within information technology (IT), change control is a component of change management.

Certain experts describe change control as a set of six steps:

  1. Record / Classify
  2. Assess
  3. Plan
  4. Build / Test
  5. Implement
  6. Close / Gain Acceptance
  • Change Management
    The Service Management process responsible for controlling and managing requests to effect changes to the IT Infrastructure, or any aspect of IT services, to promote business benefit while minimizing the risk of disruption to services.

One can infer from these definitions that change control is a process that is largely internal to the IT department and focused on prioritizing and approving infrastructure changes based exclusively on their technical merit and technical impact. IT technicians, for whom change is a constant, almost daily occurrence, often see formalized change control as an administrative burden restricting their ability to react quickly to the rapid pace of change in an increasingly complex business/technology environment. For the great majority of changes–routine changes with no great impact on users or the business (e.g., moving an application from one server to another because of a conflict, etc.), the change control protocol seems a pointless formality that stands in the way of getting the actual work done. After all, everyone in IT probably already knows through informal communications what has to be done and why and in what timeframe, so the approval process functions as little more than a bureaucratic exercise, and is often ignored or only receives minimal compliance.

The problem is that changes to the infrastructure are not always routine and light in terms of impact to the infrastructure and to the organization both inside and outside of IT. It is in these cases that simple change control does not have the appropriate depth of process or organizational reach to handle the complex change events it is charged with regulating. On top of this, the weak compliance that the process receives for low impact changes is often little better for changes with a significant organizational impact. The results—poor decisions are made to go forward or deny changes, business impacts to areas of the business are not considered, changes are badly prioritized and implementations of changes are disruptive. In essence, many organizations with IT-focused change control process regimens have too much process for many simple changes and not enough process for the major changes that really matter.

Operations Deparments must realize that infrastructure changes need be managed not simply controlled. In fact, change control is an important but subordinate procedural component of a robust change management process. The additional significant components, the “secret sauce” of change management that makes it effective are procedures that emphasize assessing the business impact and ramifications of a change and the communication and coordination activities involved in evaluating, approving and implementing a change.

The broader goal of change management is to ensure that the service risk and business impact of each change is communicated to all impacted and implicated parties, and to coordinate the implementation of approved changes in accordance with current organizational best practices. The result of effective change management is that changes are handled quickly in a uniform way and have the lowest possible impact on service quality.

Release Management

Release management is a software engineering process intended to oversee the development, testing, deployment and support of software releases. The practice of release management combines the general business emphasis of traditional project management with a detailed technical knowledge of the systems development lifecycle (SDLC) and IT Infrastructure Library (ITIL) practices.

Release management usually begins in the development cycle with requests for changes or new features. If the request is approved, the new release is planned and designed. The new design enters the testing or quality assurance phase, in which the release is built, reviewed, tested and tweaked until it is ultimately accepted as a release candidate. The release then enters the deployment phase, where it is implemented and made available. Once deployed, the release enters a support phase, where bug reports and other issues are collected; this leads to new requests for changes, and the cycle starts all over again.

Organizations that have adopted agile software development are seeing much higher quantities of releases. More software releases have led to increased reliance on release management teams to track and execute complex application release processes. Operations teams have used methodologies—such as Information Technology Infrastructure Library ITIL 2011 Book: Service Transition (which contains a section on release management) to improve their release management capabilities as they relate to both business applications and internal IT services. Agile methodologies has also driven development and operations teams to collaborate more closely during production release events—this trend is referred to as DevOps.

Release management software allows release teams to plan, manage and control the release schedule and track the status of each release to ensure production worthiness. It also provides the added benefit of applying central governance and auditing over releases before decision-makers approve releases to production.

Incident Management (IcM)

Incident management (IcM) is an area of IT Service Management (ITSM) that involves returning service to normal as quickly as possible after an incident, in a way that has little to no negative impact on the business. In practice, incident managment often relies upon temporary workarounds to ensure services are up and running while the incident is investigated, the root problem identified and a permanent fix put in place.

In this context, an incident is an event that disrupts normal operation. A problem is an underlying issue that could lead to an incident; problem management consists of the measures taken to prevent that occurence.

Activities of IcM defined by ITIL v3:

  • Identification – detect or reported the incident
  • Registration – the incident is registered in an ICM System
  • Categorization – the incident is categorized by priority, SLA etc. attributes defined above
  • Prioritization – the incident is prioritized for better utilization of the resources and the Support Staff time
  • Diagnosis – reveal the full symptom of the incident
  • Escalation – should the Support Staff need support from other organizational units
  • Investigation and diagnosis – if no existing solution from the past could be found the incident is investigated and root cause found
  • Resolution and recovery – once the solution is found the incident is resolved
  • Incident closure – the registry entry of the incident in the ICM System is closed by providing the end-status of the incident

ISO/IEC 20000 was originally developed to reflect best practice guidance contained within the ITIL (Information Technology Infrastructure Library) framework.

Service Request Fulfillment

Request Fulfilment is the process for managing Service Requests, which more often than not are small, low risk changes initially processed via the Service Desk, using a process similar to that of Incident Management.
Incidents and Requests are often lumped together in the Service Desk as “calls” or “tickets”. And to some degree, they are both very similar – but Requests tend to get lost among the urgency of Incidents, and the result is unhappy customers.
To qualify as a Service Requests it is normal for some pre-requisites to be met, for example
  • Needs to be proven – it has been performed successfully before and has been reviewed and approved via Change Management
  • Repeatable
  • Preapproved
  • Proceduralized


SCOM 2012 Alert: DNS Client Service Stopped

In case you keep receiving notifications from your SCOM 2012 Server that state “The DNS client service on server *** has stopped running” you can follow these two steps:

1)Open Registry Editor and navigate to  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dnscache\Parameters.
2)Edit or create the Registry DWORD value “IdleTimeOut” and set it to “ffffffff” (hex).

With this value you can prevent system to stop DNS Cache service on idle.

SCOM 2012 Agent proxy not enabled

This alert indicates that an Operations Manager agent attempted to discover or generate data about an object that resides on another computer. This is not allowed by default, but is sometimes required for proper monitoring. For example, the agent might be running as part of a cluster, and trying to discover the virtual cluster node.

The agent will not be able to do this until agent proxy is enabled.


If you have reviewed that the agent should be able to discover and send data on behalf of another computer, you should enable proxying for that agent:

Go to the Administration space in the Operations Manager Console
Find the agent in the Agent Managed view
Open Properties for that agent
In the Security tab, check the Allow this agent to act as a proxy option
Click OK

SCOM 2012 Ports

If you are running a firewall similar to TMG, then you will need to open some ports in order to monitor your network with System Center Operations Manager:

You will also have to configure the local Windows Firewall on each machine you want to manage, or you can do this with GPOs:

1) Computer Configuration/Policies/Administrative Templates/Network/Network Connections/Windows Firewall/Domain Profile

Allow ICMP extensions -> Allow inbound echo request

Allow inbound file and printer sharing exception -> Allow from all IP addresses(*)

Allow inbound remote administration exception -> Allow from all IP addresses(*)

2) Computer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security/Inbound Rules


Activate SCOM 2012 SP1

To register your product key with Operations Manager 2012 and move from the Evaluation edition to the Retail edition you will need to launch the Operations Management Shell and run the following PowerShell cmdlet.

Set-SCOMLicense –ProductId YourProductKey

Once that is complete you will need to restart the Operations Manager RMS server for the key to validate.  After that is complete, if you check back in Help –> About you will see it is now a Retail version.

Prereq. for SCCM 2012 SP1

1. Add the following roles and features: IIS, BITS, Remote Differential Compression

2. Select the following roles for IIS: Basic Authentification, URL Authentification, IP and Domain Restrictions, Windows Authentication, Management Tools(All), ASP (from Aplication Development)

3. On the Domain Controller open ADSI.edit and create the following Container: System -> System Management

4. Next you have to give Full Control Permissions to the Configuration Manager Computer to access this container. After that you need to click the Advance button and select to apply these permissions to “This object and all descendant objects”.

5. Back from the Configuration Manager Server you need to extend the AD Schema. Mount the Configuration Manager ISO file and execute the “extadsch” file. After it has finished check the file C:\ExtADSch to see if the schema was extended succesfully.

6. We need to install an SQL Server Standard or Enterprise. The only required feature is the Database Engine Services.

7. Make sure you limit the Memory Usage of the SQL server.

8. In case you have installed the SQL Server on a remote computer you need to add the Configuration Manager computer to the local Administrators group on the computer with SQL Server. You will also have to open ports 1433 and 4022(Service Broker) on the firewall of the SQL Server computer.

8. Windows ADK is another prerequisite for SCCM. The following features are required when installing ADK: Deployment Tools, Windows PE, USMT.

9. Another prerequisite is the WSUS Administration Console. Install it by executing the following command in powershell:

Install-WindowsFeature -Name UpdateServices-Ui

10. Install SCCM 2012 R2.