How to discover a Windows Computer as a Network Device in SCOM 2012


 

I previously wrote about using the network device monitoring in SCOM here:  http://blogs.technet.com/b/kevinholman/archive/2013/05/29/simulate-monitoring-of-network-devices-with-jalasoft.aspx and then setting up SNMP trap monitoring here:  http://blogs.technet.com/b/kevinholman/archive/2015/02/03/snmp-trap-monitoring-with-scom-2012-r2.aspx

 

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:

image

 

Once discovered you will see the properties:

 

image

 

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:

 

image

 

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:  http://blogs.technet.com/b/kevinholman/archive/2015/02/03/snmp-trap-monitoring-with-scom-2012-r2.aspx  you will immediately see traps in SCOM from this server every time you bounce the SNMP service on the monitored Windows machine:

 

image


Comments (10)

  1. Peter Heslop says:

    Thanks Kevin,

    This was exactly what I needed to resolve an issue with a Windows application that would fire SNMP traps, but did not have an SNMP agent that could be queried (and therefore discovered). Setting up the Windows SNMP feature and following the instructions above
    allowed me to work around the issue.

    I actually took your instructions one step further by configuring SCOM to continue to discard Windows SNMP devices, except on the specific servers I was interested in. I did this by leaving adding a new check into the top of the ISWINDOWSHOST function (with
    the rest unchanged from the original installed state):

    ISWINDOWSHOST(systemObj) do {
    if (systemObj->sysName == "SERVER1.domain.net" || systemObj->sysName == "SERVER2.domain.net") {
    return FALSE ;
    }

    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 ;
    }

    Hopefully this will be of use for anyone who needs to be sure that no other Windows servers get discovered by accident.

    Thanks

    Pete

  2. Peter Heslop says:

    I should have mentioned in my comment above that the sysName check is case sensitive. However, you can check what is required by copying the display name of the computer object in SCOM. In my system the server names were uppercase with the domain in lowercase.

  3. Steven says:

    i have modified the file but it still show filtered in my discovery

    1. steven says:

      i managed to discover them now but the windows trap doesn’t seem reach the SCOM 2012 as mine other traps for linux box are working.

      1. Jonathan DeLong says:

        Steven, were you ever able to get this resolved? I’m having the same issue. After making the change to that file, I can now discover my Windows Server as a device. When it sends traps though, I get nothing in my alerts. I do get alerts from other network devices however.

  4. HectorMarcia says:

    Hi Kevin,

    As usual, it worked like a charm!

    Thank you…

  5. Sam says:

    Hi Kevin,
    As usually very good article.
    Thank you so much for this blog. You saved my day.

  6. Dethgiver says:

    Kevin, is there any substantial issues with the combined monitoring? I am looking at monitoring a Solaris box with both the MP from MS and SNMP and just wanted to make sure that there wasn’t a hidden gotcha.

  7. Bassam Maadarani says:

    Hi Kevin,
    As I read through your blogs, I find them spectacular. I however have a question that I need to answer. I am tasked with comparing SCOM 2012 with another product. In particular one of the questions is if there is a method through which Network Discovery can discover Windows servers based on an IP range. I have tried for the past few days, but have not been successful at all.

  8. eating means says:

    Ӏ һqve been browsing on-line more than three hourѕ today, yet I never found any fascinating article like yours.
    It iѕ pretty price ѕufficient for me. Personalⅼy,
    if all webmasters andd bloggers made good content material as
    you probably did, the internet will bee much more hеlpful than ever Ƅefore.

Skip to main content