Removing internal connector from Virtual Machine Manager (VMM) and Operations Manager (SCOM)

Removing  Internal Connectors from Virtual Machine Manager.

While configuring PRO (Performance and Resource Optimization) in Virtual Machine Manager 2012 R2, I encountered and error saying that “A connection already exists”. I was not surprised as I had already tried creating an Operations Manager connector and ended up with a faulty connector.


The “remove” and “refresh” options were not active and hence I could not remove the faulty connector.In this situation, the best tool to use is Windows PowerShell. Run PowerShell with administrator privilege and type command Get-SCOpsMgrConnection


System will display the available connector. Now type Remove- SCOpsMgrConnection to remove the existing scom connection


Removing Unused Internal Connectors from Operations Manager.

Open Operations Manager console and select Internal Connectors from Administration section. A list of all the connectors configured in Operations Manager console is displayed there.


Unlike the other configurations, there is no simple option to remove a connector once installed. The graphical user interface does not provide option to remove.


The only alternate option is to remove the connectors from Operations Manager Database.

Please note that there is no officially supported way to remove an old connector, this process is demonstrated here for example purpose only. These steps are captured from MS newsgroup posting.

Before proceeding to Operations Manager Database, make sure that all the subscriptions from the connector you wish to remove are deleted.


Open Operations Manager Database through SQL Server Management Studio and run following queries:

Select DisplayName,IsInitialized,ConnectorID from Connector,BaseManagedEntity where Connector.BaseManagedEntityID=BaseManagedEntity.BaseManagedEntityID


This will return 3 Columns: The Display Name, Initialized Flag, and ConnectorID.

Make sure that the Connector is uninitialized.  If the IsInitialized is 1, then use following command to uninitialized the connector otherwise skip the below step and proceed to delete connector.

EXEC p_ConnectorUpdate ‘<connectorID>’,NULL,0

Cross check the initialize status by rerunning the initial query and ensure that the connector initialized state is now 0

Find the ConnectorID of the connector you want to remove.  Copy the ConnectorID it to Notepad for safekeeping. And then use the p_ConnectorDelete command to delete the connector.

EXEC p_ConnectorDelete ‘<connectorID>’,NULL,NULL


Go back to Operations Manager console and select Internal Connectors from Administration section, refresh the screen and notice that information about the removed connector is disappeared from the list.

Repeat this process if you deleted multiple connectors.


Configuring Cross Platform Monitoring Using System Centre Operation Manager 2007 R2

One of the more desirable features introduced in System Center Operations Manager 2007 R2 is the ability to monitor non-Windows servers. This indeed rose the System Center Operations Manager as one of the strongest monitoring tools for any heterogeneous environment. The total cost of ownership of maintain a centralized enterprise system monitoring solution became very low by the introduction of cross platform monitoring feature. However, we often noticed that many Microsoft solution experts have very little Unix/Linux experience and therefore configuration of the solution in always a nightmare. The objective of this post is to provide a step-by-step guide for configuring cross platform monitoring solution.

Following are the high-level overview of tasks (not in any particular order) involved in configuring agents in cross platform environment.

  • Update SCOM with latest CU and Management pack for cross platform monitoring
  • Check communication port availability
  • DNS name resolution in both directions
  • SSH and sftp  enabled
  • Certificates signature
  • Accounts with access rights on the cross platform system.
  • Define the required Run As Accounts and place them in the proper Run As Profiles
  • Pre-requisite software available cross platform machines, update the OS if any patch are missing.
  • Make sure to use the right installers when manually deploying agents.

The below link provides a detailed step-by-step guide for configuring Cross Platform Servers to be monitored through System Centre Operations Manager 2007 R2

Step-by-step guide for configuring cross platform system monitoring

Hope this post will be helful for someone who wanted to monitor Solaris (or any cross platform) system through System Centre Operations Manager 2007 R2

Unable to install System Center Operations Manager 2012 Agent on Windows Server 2012

You may encounter the following error while installing System Center Operations Manager 2012 Agent on Windows server 2012.

“Error 25211.Failed to install performance counters.. Error Code: -2147024809 (The parameter is incorrect.).”

How To Fix it :-

Go to Server Manager and click on Manage and then select Add Roles and Features. Click next, next, next to go to Features page. Select .NET Framework 3.5 (includes .NET2.0 and 3.0) click Install.

In case the .NET Framework 3.5 feature installation fails on windows 2012 server, follow the steps given in the below post: Failed to install .Net framework 3.5 features in Windows Server 2012

Now, run the MOMAGENT.MSI again. If Manual agent Install option is set to Automatically approve new manually installed agents, the agent will appear under agent managed. otherwise, pick the server from Pending management and select approve.

Read more of this post

System Centre Operations Manager Prerequisites Installation

Installing the prerequisite windows features for System Centre Operations Manager (either 2007 or 2012) is always a pain and time consuming.  Here are the list of prerequisites to be installed for Operations Manager and also some easy method to install the same.

Windows Features:

Run PowerShell as administrator (click on Start, All Programs, Administrative Tools then right click on Windows PowerShell Modules and select Run as administrator).

Type Import-Module ServerManager  (press enter)

Type or copy and paste following command to PowerShell window:

Add-WindowsFeature NET-Framework-Core,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Asp-Net,Web-Http-Logging,Web-Request-Monitor,Web-Windows-Auth,Web-Filtering,Web-Stat-Compression,Web-Metabase,AS-Web-Support –restart


As an alternative, here is a PowerShell script which will run the above command for you. Note that by default the PowerShell script execution are in restricted mode, you need to set the script execution policy to unrestricted before running the script:

Set- ExecutionPolicy unrestricted –Force (the script will reset execution policy back to restricted mode).


Download the PowerShell script from here and change the file extension to .ps1

ASP.NET AJAX: ASP.NET AJAX is a set of technologies to add AJAX (Asynchronous JavaScript and XML) support to ASP.NET.  This integrates client script libraries with the ASP.NET 2.0 server-based development framework.

Download ASP.NET AJAX:


Microsoft Report Viewer: Microsoft Report Viewer control enables applications that run on the .NET Framework to display reports designed using Microsoft reporting technology. This redistributable package contains Windows and Web versions of the Report Viewer. (Required only for Operations Manager 2012)

Download Report Viewer:


If you installed .NET 4 Framework before installing the IIS part then you have to register the .NET 4 Framework in IIS and also register the CGI and ISAPI filters. You can do this by typing these commands…

WINDIR%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -r


Enable ISAPI and CGI restrictions in IIS: Select the web server in IIS manager, double-click ISAPI and CGI restrictions. Select ASP.NET v4.0.30319 and then click Allow. (Required only for Operations Manager 2012)


Select ASP.NET v4.0.30319 and then click Allow.


The SQL Server Reporting Services (SSRS) should be installed locally if you are planning to install Operations Manager 2012 reporting services.

Deploying System Center 2012 – Operations Manager

Single-server management group installation

The single-server management group scenario combines all the management group roles that can coexist onto a single instance of the Windows Server 2008 R2 SP1 operating system running as a member server in an Active Directory domain. This instance can be on dedicated hardware or on a virtual computer. The Operations console can be deployed to computers other than the single server, and the web console is accessed via a browser.

Available Operations Manager Services in Single-Server Deployment

  1. The single-server management group configuration supports the following services:
  2. Monitoring and alerting
  3. Reporting (available in the Operations console but not in the web console)
  4. Audit collection
  5. Agentless exception management
  6. Data (accessed by using the web console and the Operations console)


The single-server management group configuration is the easiest to deploy, but there are limitations to its capabilities and therefore limitations to what it is commonly used for.

High Availability and Redundancy

The single server, single management group resides on a single set of hardware. This configuration supports only one instance of each server role and therefore cannot support agent failover between management servers.

Gateway Server

This configuration does not include the gateway server role. Because of this, all monitored devices must be in the same Active Directory domain as the management server or you must use certificates on both the managed computer and the management server to provide for mutual authentication.

For information about deploying single-server management group scenario, go to Single-Server Deployment of Operations Manager.

Distributed management group installation

The distributed management group installation will form the foundation of 99 percent of System Center 2012 – Operations Manager deployments. It allows for the distribution of features and services across multiple servers to allow for scalability and also provides availability. It can include all Operations Manager server roles and supports the monitoring of devices across trust boundaries through the use of the gateway server.

The following diagram presents one possible option for the distributed management group topology

For information about deploying distributed management group scenario, go to Distributed Deployment of Operations Manager

System Center 2012 – Operations Manager Cross Platform Visibility

Microsoft System Centre Operations Manager 2007 introduced Distributed Application Models and Synthetic Transactions as part of extending the visibility of monitoring solution.  In the later version, SCOM 2007 R2, Microsoft enhanced the visibility by introducing Cross Platform Monitoring.  The cross platform monitoring provided the ability to monitor non-Microsoft operating system such as HP-UX, AIX, Linux and Solaris.

The introduction of native network monitoring and .NET / J2EE Application monitoring support in SCOM 2012 provides the ability to capture all components within your networks that are part of providing services to the users.

Following diagram represents the Components, Applications and  Operating System platforms  monitored out of the box through system Centre 2012 – Operations Manager.

More about network monitoring capabilities:

SCOM 2012 includes significant new network monitoring capabilities that make it a much more comprehensive monitoring solution for network admins. Some basic features have been present in older versions, but SCOM 2012 expands on these capabilities.

Following features are Included in SCOM 2012 out of the box:

  1. Network device discovery, monitoring and reporting
  2. SNMP v3 support. Previous versions of SCOM supported SNMP v1 and v2.
  3. IPv4 and IPv6 support
  4. Port/interface monitoring which includes: Up/down monitoring, Traffic volume, Utilization, Dropped packet rate, Broadcast traffic stats etc..
  5. VLAN health monitoring (Auto discovery of all the VLANs)
  6. Overall connection health
  7. Hot Standby Router Protocol (HSRP) group health
  8. New visualization/dashboards which includes : Overall network health summary, The health of a device on the network, its  interface-level statistics, its neighbors and connected windows servers monitored by SCOM etc..

Checklist for Upgrading to System Center 2012–Operations Manager (Single-server Upgrade)

The upgrade to System Center 2012 – Operations Manager is supported only from Operations Manager 2007 R2 CU4, or from the latest available CU. Before beginning the upgrade process, make sure that all the servers in the management group meet the minimum supported configurations for System Center 2012 – Operations Manager.  For more information, see Supported Configurations for System Center 2012 – Operations Manager.

There are four upgrade paths. The path you choose depends on your current topology and system configurations. The following table describes the upgrade paths in more detail.

Single-server Upgrade (Simple)

Use this upgrade path when you have an Operations Manager 2007 R2 management group where all features are installed on the same server, and the hardware and software meets the minimum supported configuration for System Center 2012 – Operations Manager

Single-server Upgrade (Complex)

Use this upgrade path when you have an Operations Manager 2007 R2 management group where all features are installed on the same server, and the hardware and software do not meet the minimum supported configuration for System Center 2012 – Operations Manager. If the operating system on the server is 32-bit, a new, 64-bit server is required.

Distributed Upgrade (Simple)

Use this path when you have an Operations Manager 2007 R2 management group where various features are installed on separate servers, all of which meet the minimum supported configurations for System Center 2012 – Operations Manager.

Distributed Upgrade (Complex)

Use this path when you have an Operations Manager 2007 R2 management group where various features are installed on separate servers, and where one or more servers do not meet the minimum supported configuration for System Center 2012 – Operations Manager. For example, if the RMS is clustered, you must follow this path. If the operating system on any of the server is 32-bit, new 64-bit replacement servers are required.

Pre-Upgrade Tasks for Operations Manager

There are number of pre-upgrade tasks to be performed before you upgrade from System Center Operations Manager 2007 R2 to System Center 2012 – Operations Manager. The order in which you perform these tasks will vary depending on your upgrade path.

In a single-server management group upgrade, you must perform all the applicable pre-upgrade tasks before you start the upgrade process. Service will be interrupted until the upgrade process is completed. If your single-server management group does not meet the minimum system requirements, or you do not want to experience downtime, you can add a secondary management server, and then follow the distributed management group upgrade process.

The following table shows the tasks that you must complete before you upgrade from Operations Manager 2007 R2 to System Center 2012 – Operations Manager.


Downtime, Risk, and Mitigation

Import   the Upgrade Helper Management Pack No   downtime or interference; low risk.
Back   up the RMS Encryption Key No   downtime or interference; low risk.
Review   the Operations Manager 2007 R2 Event Logs No   downtime or interference; low risk.
Check   for Gateway Servers Reporting to the RMS No   downtime or interference;low   risk if the management servers have the necessary certificates.
Remove   Agents from Pending Management No   downtime or interference; low risk.
Check   the Operations Manager 2007 R2 RMS for Active Connected Consoles Consoles   might lose connectivity to the RMS during upgrade.
Disable   the Notification Subscriptions Interference:   no notifications are sent during the upgrade.Mitigation:   after the upgrade, check for any alerts that were missed.
Stop   the Services or Disable any Connectors Connectors   do not function during upgrade.
Verify   that the Operational Database Has More Than 50 Percent Free Space No   downtime or interference; low risk.
Verify   the SQL Server Collation The   management group upgrade does not succeed if unsupported collation   configurations exist.
Back   up the Operations Manager Databases Depending   on the backup technology that you use, some backup methods might lock a   database during backup.
Restore   the RMS Encryption Key on the Secondary Management Server No   downtime or interference; low risk.Required   only if the root management server (RMS) does not meet the supported   configuration requirements for System Center 2012 – Operations Manager. This   should be performed just prior to management group upgrade.
Upgrade   SQL Server Reporting Services The   reports will be unavailable, but data will not be lost.

The attached checklist walks you through an upgrade of a System Center Operations Manager 2007 R2 single-server management group that already meets the minimum supported configurations for Operations Manager.

download the Upgrade task Checklist  here…

Upgrading to System Centre 2012 – Operations Manager

Direct upgrade to SCOM 2012 is supported only from SCOM 2007 R2 with CU4. All SCOM 2007 R2 management servers to be upgraded must be 64-bit on x64 hardware and be running Windows Server 2008 R2 SP1.

Order of Upgrade:

The general order of upgrading is secondary management servers, gateways and agents first, then the Root Management Server (RMS). The upgrade will be blocked if any management servers or gateways are still SCOM 2007 R2. It will be highlighted during the RMS upgrade if any agents are still SCOM 2007 R2, but it won’t block the upgrade. Those agents just won’t be able to report until they’ve been upgraded to SCOM 2012 agents.

In a smaller environment with an all-in-one SCOM 2007 R2 server, an in place upgrade can be done if the server meets the hardware and software requirements. All the agents must be upgraded to SCOM 2012 before upgrade so that they will report to SCOM 2012 after successful upgrade.

Microsoft TechNet Library provides different flow diagrams to help with migration planning. It also provides links to checklists with step-by-step instructions.

Upgrade pre-requisites:

  1. Check if all the requirements listed in the TechNet site are met
  2. Minimum cumulative update version installed must be CU4, confirm the version number (6.1.7221.61) from SCOM console about tab under help.


You might have a blend of SCOM 2007 R2 and SCOM 2012 management groups and servers in your environment for a while, so it’s good to know SCOM 2012 agents will communicate with SCOM 2007 R2 servers. It won’t work the other way around, however, so it’s important to upgrade your older agents as soon as possible.

Management Packs:

The Management Pack schema remains unchanged so all MPs that work with SCOM 2007 R2 should work in SCOM 2012. Some exceptions include some third-party MPs requiring new modules on the agent, new MP templates or new view types due to API changes. Network monitoring MPs leveraging Simple Network Management Protocol (SNMP) will continue to work, but might require updating to integrate with the new network monitoring framework.

%d bloggers like this: