You are browsing the archive for 2013 March.

Aligning Business & IT using distributed applications

12:59 pm in #scom, #sysctr by Jan Van Meirvenne

There is no bigger struggle within the IT market than making IT transparent and understandable for the business it supports. We often fail to realize that IT has a supporting function within an organization, and that it only exists to make the core business processes easier to execute. This principle doesn’t always reflect on the way management software is used.

Specifically for monitoring, there are often misunderstandings or disconnections between the data the business owner is interested in and the data the IT administrator wants to see.



Business Owner

Which departments and business processes are impacted when this application goes down?
How much downtime has my HR department experienced due to IT problems?
How do I now which business processes own this application?

IT Administrator

What components fall under this application?
What happens if this database goes down?
Did I reach my SLA regarding my database-farm?

I believe that is is rather easy to satisfy both these guys their needs by only using the distributed application concept of Operations Manager:


Creating the business organigram


A distributed application is normally a skeleton for an application consisting of a set of components, where underlying components rollup their health to the overall state of the application. This has many similarities to a business: a set of departments and processes which report to an executive board.. So by just porting the company’s organigram to a DA you can very quickly set the first step towards a business-focused approach towards application monitoring.

Creating the application models


This will be a bigger hassle. If you really want a proper Business to IT overview, all applications used in the business have to be modeled in SCOM. This can be a small or big project depending on the company size, but Rome wasn’t built in a day either.

Bringing the worlds together

Eventually, you can start making the application DA’s components of your business DA’s, effectively linking them together. This will enable the following scenario:


By correctly scoping this system and using the correct medium (Sharepoint, Dashboard, Webconsole,…) to bring it to the respective consumer, you satisfy both the business’ as the IT department’s needs. Reporting and health-management is now possible on 2 levels without any chance on inconsistency. As long as the correct processes are implemented to keep this DA-hierarchy up-to-date this is a long-term solution for aligning IT and Business regarding business continuity. Note that not all applications have to be linked to business objects if they have only meaning to the IT department (eg an overview of all servers).

Authenticating agents on DMZ-servers reporting to a domain-joined gateway

5:04 pm in #scom, #sysctr by Jan Van Meirvenne


I heard of this issue when one of my colleagues was attaching a customer to our centralized SCOM infrastructure:


A SCOM gateway is deployed and domain-joined on the customer site. It is provisioned with a root and client certificate to allow communication with the central platform.

However, the customer has DMZ-systems which are not joined to a domain. When they are provisioned with SCOM agents which are pointed to the gateway, they fail to communicate:

Event on the agent:

Log Name:      Operations Manager
Source:        OpsMgr Connector
Event ID:      20070
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
The OpsMgr Connector connected to, but the connection was closed immediately after authentication occurred.  The most likely cause of this error is that the agent is not authorized to communicate with the server, or the server has not received configuration.  Check the event log on the server for the presence of 20000 events, indicating that agents which are not approved are attempting to connect.
see below error on agent opsmgr event log:

Events on the gateway:

A device at IP XX.XX.XX.XX attempted to connect but could not be authenticated, and was rejected.



The probable cause is the gateway cannot use kerberos or certificates to provide authentication to the DMZ-agents and thus refuses to allow communication with the management group.


The solution was to import the same root certificate which was used for the gateway in the trusted root certificate store of the DMZ-servers. This allowed a secure link to be established with the gateway server and the communication with the management group to commence.