One of the challenges we face in SCOM 2012, is that we cannot treat a “Windows Computer” as a network devices. When network discovery runs, we actually filter out Windows devices from SNMP based discovery. This is a change in SCOM 2012 from 2007, and I am not sure why this was done, other than perhaps that’s how EMC did it, since we license the discovery technology from them.
This makes setting up certain types of monitoring a challenge, such as when we have an application that runs on a Windows Server, that sends traps. SCOM will rejects these traps because it wont allow discovery of the server as a device, which is a requirement for trap monitoring in SCOM.
I’m going to demonstrate how to edit the discovery filters in SCOM to allow for this. This is useful for your one-off cases where you just need to monitor a Windows Server as an SNMP device, or for lab testing trap reception without having to set up a Linux machine as in my previous example.
On the management server which will run the network discovery rules – browse to the following directory:
\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\NetworkMonitoring\rules\discovery
There is a file present in this directory named ic-post-processor.asl
Make a backup copy of this file, I like to name it ic-post-processor.bak, and place this backup copy in the same directly. Now, edit this file, and change the following lines:
ISWINDOWSHOST(systemObj) do {
if (systemObj->Type == “HOST” && systemObj->Vendor == “MICROSOFT”) {
return TRUE ;
}
if (SEARCHSTRING(systemObj->Description, “Windows”)) {
return TRUE ;
}
systemOIDCheck = “.1.3.6.1.4.1.311.1.1.3.1” ;
if (substring(systemObj->SystemObjectID, 0, sizeof(systemOIDCheck)) == systemOIDCheck) {
return TRUE ;
}
systemOIDCheck = “.1.3.6.1.4.1.99.1.1.3.11” ;
if (substring(systemObj->SystemObjectID, 0, sizeof(systemOIDCheck)) == systemOIDCheck) {
return TRUE ;
}
return FALSE ;
}
to:
ISWINDOWSHOST(systemObj) do {
if (systemObj->Type == “HOST” && systemObj->Vendor == “MICROSOFT”) {
return FALSE ;
}
if (SEARCHSTRING(systemObj->Description, “Windows”)) {
return FALSE ;
}
systemOIDCheck = “.1.3.6.1.4.1.311.1.1.3.1” ;
if (substring(systemObj->SystemObjectID, 0, sizeof(systemOIDCheck)) == systemOIDCheck) {
return FALSE ;
}
systemOIDCheck = “.1.3.6.1.4.1.99.1.1.3.11” ;
if (substring(systemObj->SystemObjectID, 0, sizeof(systemOIDCheck)) == systemOIDCheck) {
return FALSE ;
}
return FALSE ;
}
This is the file that handles post-processing of discovered devices, and normally would prune out any devices stemming from a Windows OS.
Once you have saved the file – you will be able to edit your discovery rule, and add the IP address of a Windows Server.
The Windows Server that you wish to Monitor/Discover will need the SNMP feature present, the service running, and the community string and access permitted:
Once discovered you will see the properties:
Make sure you don’t have any firewalls (windows firewall or hardware) blocking SNMP to be able to discover the server. If you have trouble – look in the OpsMgr event log on the management server – it will have verbose logging of the network discovery:
NOTE: Technically – making this change isn’t tested by the product group, and therefore isn’t supported. I am not aware of any issues caused by this, and since we fully allow SNMP monitoring of Linux devices, it makes perfect sense to work with Windows SNMP devices as well.
Once the device is discovered – if you implemented my SNMP trap monitoring MP here: https://kevinholman.com/2015/02/03/snmp-trap-monitoring-with-scom-2012-r2/ you will immediately see traps in SCOM from this server every time you bounce the SNMP service on the monitored Windows machine:
