Tag: SNMP

If you have made your way through Part 1 then you have written your management pack complete with your own custom discovery and imported it into SCOM.  Once you have ensured that it is discovering only the devices you wish to manage in this pack it is time to begin writing the monitors and rules that will apply to the detected devices.   As was mentioned in Part 1a program such as MIB Browser can be very handy in assisting with sorting through all of the OID’s and the healthy values which correspond with each individual OID. 

Creating an SNMP Get Monitor in SCOM 2007 R2

I find the easiest way to create a new monitor or rule is to start with the System Center Operations Manager Console. I will admit it’s not the best and does not give you many of the options you probably want but I find it’s the easiest way to get the XML started, and then edit it to get exactly what we want after the fact.

We will start in the management console, Authoring tab, expand Management Pack Objects and right click on Monitors, Select Create a Monitor \ Unit Monitor.

From within SCOM click on the Authoring tab and then right click on Monitors which is listed beneath Management Pack Objects.  At this point we would like to choose Create a Monitor – Unit Monitor, once this has been picked you will see the following screen:

 First we will create a simple expression Get Monitor and later we will deal with TRAPS, so we pick SNMP – Probe Based Detection – Simple Event Detection – Event Monitor……

Be sure to create this in the management pack you created for the discovery of the object.

Now we have to name our monitor, Select a target (You are looking for the device type you defined in part one and you may have to click the “View all targets” radio button for it to appear) and add a parent monitor (this defines where in the health view tree your new monitor will appear)

Personally I always use the discovery community string but you could use something custom if you want. The frequency is how often you want the monitor to poll the device and the object identifier or OID. This is the bit this will be used in the SNMP get call I find it works most reliably if you don’t have a leading period.

We need to create an expression what causes an alarm. I will keep the expressions simple so you can get a feel for one that works. Click the +Insert at the top and you are presented with 3 fields.  The first field that appears parameter name is the magic field.

/DataItem/SnmpVarBinds/SnmpVarBind[1]/Value

This is the value you are going to compare it is based on the First SnmpProbe from the step before. I have read that if you have more than one SnmpProbe that the number in this case [1] is in reverse order so [1] is at the bottom and [2] would be just above it in the list. Personally I have only one OID providers right now so I don’t know. Let me know if you figure it out for sure.  The operator gives you a drop down of choices. I will get into it more below but thing about this one carefully. If you can use a simple equals or does not equal you can make things much easier. Think of it like this if a UPS battery charge of anything less than 100% is bad then use an expression like “/DataItem/SnmpVarBinds/SnmpVarBind[1]/Value – does not equal – 100” instead of  “/DataItem/SnmpVarBinds/SnmpVarBind[1]/Value – less than – 100” it will just save you a bunch of extra steps even if it is not quite as flexible.

Second SnmpProbe lets you pick an OID just like for the first SnmpProbe personally all the monitor I have so far use the same OID as in the first provider as I am watching for a single value to be either good or bad. The second expression is exactly the same as the first. If you want a monitor that will not recover (you have to manually reset the health state  I use something like “/DataItem/SnmpVarBinds/SnmpVarBind[1]/Value – does not match wildcard – *” since any GET will have some result it will never not match and this will never recover.

Configure health lets you decide how the device health will change when the monitor gets tripped. I use second event raised as healthy and first event raised as warning or critical depending on whats going on.

The last option is if you want to create an alert or not, up to you.

Not so simple expressions

So lets say you don’t want a simple equals or does not equal kind of expression. It’s there in the drop down so whats the big deal you say? Well the SCOM Console make what I consider a bad assumption when creating rules and monitors. All the datatypes are strings. so although “100” does not equal “10” produces a true result “100” is greater than “10” when the values are strings has no meaning. Fixing this is actually not so hard and you have 2 choices. If the next bit is clear to use go for manual xml editing, if that makes you nervous then hold on for the second option.

Option 1 : Advanced

Export your MP to XML and open it in your favorite xml editor.

Way at the bottom you will find an ElementID linked to the text label you assigned to the monitor. Use this ElementID to find your monitor or rule and alter as follows.  I have highlighted the 4 places you must change “String” to “Integer”. Save the file and re-import it into SCOM and your monitor should be working.

<UnitMonitor ID=”UIGeneratedMonitor38d2a38d163b4c1f971885f7ea686f16″ Accessibility=”Public” Enabled=”true” Target=”GEUPS.Single.Phase.Management.Pack.SNMPDevice” ParentMonitorID=”Health!System.Health.AvailabilityState” Remotable=”true” Priority=”Normal” TypeID=”Snmp!System.SnmpProbe.2SingleEvent2StateMonitorType” ConfirmDelivery=”false”>
        <Category>Custom</Category>
        <AlertSettings AlertMessage=”UIGeneratedMonitor38d2a38d163b4c1f971885f7ea686f16_AlertMessageResourceID”>
          <AlertOnState>Error</AlertOnState>
          <AutoResolve>true</AutoResolve>
          <AlertPriority>Normal</AlertPriority>
          <AlertSeverity>Error</AlertSeverity>
          <AlertParameters>
            <AlertParameter1>$Data/Context/SnmpVarBinds/SnmpVarBind[1]/Value$</AlertParameter1>
          </AlertParameters>
        </AlertSettings>
        <OperationalStates>
          <OperationalState ID=”UIGeneratedOpStateId8a4572649aec48b58c336b84182c464b” MonitorTypeStateID=”SecondEventRaised” HealthState=”Success” />
          <OperationalState ID=”UIGeneratedOpStateId2bcf307948d14f4a892a99088603714a” MonitorTypeStateID=”FirstEventRaised” HealthState=”Error” />
        </OperationalStates>
        <Configuration>
          <FirstInterval>60</FirstInterval>
          <FirstIsWriteAction>false</FirstIsWriteAction>
          <FirstIP>$Target/Property[Type=”NetLib!Microsoft.SystemCenter.NetworkDevice”]/IPAddress$</FirstIP>
          <FirstCommunityString>$Target/Property[Type=”NetLib!Microsoft.SystemCenter.NetworkDevice”]/CommunityString$</FirstCommunityString>
          <FirstVersion>$Target/Property[Type=”NetLib!Microsoft.SystemCenter.NetworkDevice”]/Version$</FirstVersion>
          <FirstSnmpVarBinds>
            <SnmpVarBind>
              <OID>.1.3.6.1.2.1.33.1.2.4.0</OID>
              <Syntax>0</Syntax>
              <Value VariantType=”8″ />
            </SnmpVarBind>
          </FirstSnmpVarBinds>
          <FirstExpression>
            <SimpleExpression>
              <ValueExpression>
                <XPathQuery Type=”Integer“>/DataItem/SnmpVarBinds/SnmpVarBind[1]/Value</XPathQuery>
              </ValueExpression>
              <Operator>Less</Operator>
              <ValueExpression>
                <Value Type=”Integer“>96</Value>
              </ValueExpression>
            </SimpleExpression>
          </FirstExpression>
          <SecondInterval>60</SecondInterval>
          <SecondIsWriteAction>false</SecondIsWriteAction>
          <SecondIP>$Target/Property[Type=”NetLib!Microsoft.SystemCenter.NetworkDevice”]/IPAddress$</SecondIP>
          <SecondCommunityString>$Target/Property[Type=”NetLib!Microsoft.SystemCenter.NetworkDevice”]/CommunityString$</SecondCommunityString>
          <SecondVersion>$Target/Property[Type=”NetLib!Microsoft.SystemCenter.NetworkDevice”]/Version$</SecondVersion>
          <SecondSnmpVarBinds>
            <SnmpVarBind>
              <OID>.1.3.6.1.2.1.33.1.2.4.0</OID>
              <Syntax>0</Syntax>
              <Value VariantType=”8″ />
            </SnmpVarBind>
          </SecondSnmpVarBinds>
          <SecondExpression>
            <SimpleExpression>
              <ValueExpression>
                <XPathQuery Type=”Integer“>/DataItem/SnmpVarBinds/SnmpVarBind[1]/Value</XPathQuery>
              </ValueExpression>
              <Operator>GreaterEqual</Operator>
              <ValueExpression>
                <Value Type=”Integer“>96</Value>
              </ValueExpression>
            </SimpleExpression>
          </SecondExpression>
        </Configuration>
      </UnitMonitor>

Option 2 : Easy

Export your management pack to XML then Using System Center Operations Manager 2007 R2 Authoring Console open it.  You may be asked for dependencies that are usually found in “C:\Program Files\System Center Operations Manager 2007” but you can easily enough find *.mp

Once you find your monitor or rule of choice right click, properties. Configuration Tab.  Under each >>>XPathQuery and >>>Value you will see >>>@Type you need to change 4 Types to Integer.  You can see examples of the last two changed in the image below.

Then once you are finished just save the management pack and re-import it into SCOM and it should work.

Note: I am writing this in a somewhat sleep deprived state. I have not talked about rules at all but they are simpler than monitors so I hope it’s clear where the magic is. I will also thank David Allen for some blog posts that helped be although I can’t find them right now.  If things here are not clear or more detail is needed please comment or contact me and I will see what I can do.  

Part 1

Part 2

Part 3

If you have followed along this far, and have not ended up with a white jacket with really long sleeves then this next bit should be no problem.

The Problem :
Although it’s nice to be able to poll a device on a regular schedule and log this for the shiny graphs and alert on it once you have all the monitors working, what we really want is a real-time alarm when something goes wrong. When your UPS goes into bypass or your HVAC fails you may not want to wait for the next polling interval.

The Solution :
Strangely this is the whole reason I started these three articles, I found SNMP traps to be inconsistent and extremely frustrating. I almost gave up and got another product more suited to handling SNMP monitoring. Of course as with most things once you get it all sorted out it’s actually quite simple.

Step 1 : SNMP Services
On your Root Management Server, Management Servers and or gateways you need to have the SNMP Services installed.
Windows 2003 – Add Remove Programs, windows Components, Management and Monitoring Tools, Simple Network Management Protocol.
Windows 2008 – in the Server Manager, Features, SNMP Services
You should have an SNMP Service and a SNMP Trap Service, make sure both are set to automatic start and are started.

Step 2 : Configure your device
On your device, appliance, server etc you will need to go in and setup SNMP and Traps. First you will need to set a community name, remember this for later, and remember this is not really a useful security measure. With luck you can configure a community name, set your device to read only (personally I don’t trust making changes via SNMP) and configure a location for traps. Here is the first trick, at a minimum you need to direct the traps at the management server that your device is going to be managed by, I configured my devices to send to my RMS and both of my management servers. You can send traps to your RMS all day long and not get an alert if your device is discovered and managed by another management server.

Step 3 : Discover your device
In the SCOM Management console, Administration tab, you can right click on any entry and pick Discovery Wizard right at the top. Click Network Devices, next, enter the IP address or address range, entry the community string you configured earlier on the device, Pick the SNMP version (if you are not sure try V1) and pick a management server. This must be the server the traps are being sent to. I send the traps to all my management servers so that just in case I need to rediscover the device on another server I don’t have to go reconfiguring the device. SCOM will not send you duplicate alarms if it received a trap on multiple management servers.
Once teh discovery is complete you shodul be abel to select the check boxes of the devices you want to manage and finish.

Step 4 : Create a Monitor.
If you are following from Part 1 and 2 we will be creating this monitor in the management pack where we have set the discover for the device type that we are monitoring. If you are adventurous and don’t expect it to get too complex you can target this monitor at snmp network device, this creating a bulk trap monitor for every device. This may make it harder to filter what you want in the future but it’s up to you.
On the authoring tab, under management Pack Objects, Right Click on Monitors and select unit monitor. We are now looking for SNMP, Trap based Detection, Simple Trap Detection, Event Monitor – Single Event and Single Event. Place this in your management pack where your discovery is.
Give your monitor a Name, a Target and a parent monitor Next. Typically you would use the discovery community string, and for this example we are going to check the box “All Traps” at the bottom. Here is the next tricky bit. The expressions, this is an example for setting a critical state for any trap and requiring a manual reset.

First Expression
parameter Name : /DataItem/SnmpVarBinds/SnmpVarBind[1]/Value
Operator : Matches wildcard
Value : *

Second Expression
parameter Name : /DataItem/SnmpVarBinds/SnmpVarBind[1]/Value
Operator : Does not match wildcard
Value : *

The first express should fire on any trap, the second should never fire, So the First Event Raised is the critical state and the second is the healthy state.

Of course you seen to configure subscriptions etc if you want email alerts but this should change the state of the device and require that you go into the device and do a reset health to get things to go back to green.

If you get fancier with the expressions comment on this post so everyone can see, I have not had to yet so I can’t say.

Edit: Nov 24, 2009

Well that didn’t last long, I had to get more specific with my trap alerting so I figured I would update the people who are following this (all 2 of them)

It’s simple enough when creating your monitor on the “FristSnmptrapProvider” screen don’t check all traps, instead put the OID you are looking for under Object Identifier. The best way for me to find the OID is wire shark. In wire shark set a filter like “snmp.data==4” or “snmp.data==4 and ip.addr == xxx.xxx.xxx.xxx” now you should be seeing just traps from the device in question. 

Here you can see the OID of the TRAP  1.3.6.1.4.2254.2.4.20 and the specific Trap of 3

This gives us a complete OID of  1.3.6.1.4.2254.2.4.20.0.3 This is what you need to put under Object Identifier  for the FirstSnmpTrapProvider, the first expression remains the same as above, but in this case I will start doing automatic recoveries or for the SecondSnmpTrapProvider you need the recovery trap, in this case 1.3.6.1.4.2254.2.4.20.0.3 the second expression changes now to match the first expression “Matches Wildcard *” These examples are for utility failure and recovery of a GE UPS SNMP card using the deltav4 MIB.

Enjoy

Part 1

Part 2

Part 3

Recently I was encouraged to find a way to monitor many of our appliances with our shiny new deployment of  Microsoft System Center Operations Manager 2007 R2. Up until this point we had not used SCOM for SNMP monitoring little did I know the adventure I was about to embark on.

Requirements:

Log (SCOM Rule) various values from different SNMP appliances

Alert (SCOM Monitor) on various values from different SNMP appliances

Basic availability checks for all appliances

Receive and alert on SNMP TRAPS from all appliances

The Process : (no point in trying to skip to the solution)

The first thing I found was a lot of people in various blogs with a warning “Abandon hope all ye who enter here”. Usually I would save my ranting comments to the end but perhaps it’s best to give you a quick glimpse now. SCOM 2007 R2 is not exactly the pinacle of SNMP monitoring, but I will get into that more later 😉

In part 1 we will find a way to discover and differentiate between the different kinds of SNMP appliances so that we can target various monitors and rules at specific devices. No point is weighing down SCOM with monitoring all sorts of thinsg that don’t exist on a given device right?

Step 1: Install required tools

Here I have to start with a major and well deserved tip of the hat to 2 individuals without whom my adventures into SCOM and SNMP would have been long and likely fatal… or very short and almost painless (Hmmmm) either way, Thanks to Raphael Burry and his SNMP Discovery Provider for OpsMgr 2007 and Scott Vintinner with his Example SNMP Management Pack for SCOM 2007. Without these 2 pieces I would likely have left SCOM as an SNMP monitoring too altogether.

First download the sealed managed pack from Raphael rename it to a zip, break out the management pack and install it into you SCOM installation. This gives us the extensions to start writing out own custom management packs to start discovering different types of SNMP devices.

Second do your self a favor and download and install the iReasoning MIB browser and WireShark (formerly knows as Ethereal for those that missed the name change a while back) these tools will be invaluable shortly, trust me.

Step 2:  Figure out how to identify devices

First we need to figure out what makes this device different from any other device in our network, this is where the iReasoning MIB Browser comes in handy. After you have configured your device with an SNMP community name and allowed traffic from the machine you are running the MIB Browser from it’s time to pick an OID. Start the MIB Browser. You can load manufacturer MIB’s if you want but we don’t need them here. Enter the IP address of the device, clear anything that is in the IOD field and use the operations dropdown to pick walk. Then click GO!

Edit : Daniel Morrison makes a good comment – you may also need to hit “Advanced” and enter the SNMP community you configured on teh device for the walk operation to work. The default value is Public.  Just in caseyou missed it, you can see it below just between Address and OID. 

Now you can go down the list of OID’s that you see and find something specific that will be unique to this type of device. For this example we are looking at an SG series GE UPS.  In this case I am going to go with 1.3.6.1.2.1.1.2.0 that provides an answer of  1.3.6.1.4.1.818.1.100.1.1 with these noted it’s time to start editing our management pack.

Step 3: Your first custom SNMP discovering management pack!

Here again you will want a couple of tools to make life much easier.  First XML Notepad 2007 a Microsoft tool for editing XML, handy for when the next tool does not expose what you want. Second SCOM Authoring Console 2007 R2, from the AuthoringConsole directory in the root of your download or SCOM 2007 R2 CD. This is probably on the website somewhere but what isn’t anymore?

Now you are ready to download Scott Vintinner’s Example Management pack, (EDIT: or the updated version here) this is not installed just used as a framework to build our own custom pack for the device in question.  Make a copy and open it with notepad.  The first thing to notice is right near the top, <ID>RBH.Ecosaire.AC.Management.Pack</ID> we need to change this to match whatever we are doing like <ID>GEUPS.Example.Management.Pack</ID> so I do a find and replace on the whole XML from “RBH.Ecosaire.AC.” to “GEUPS.Example.” then I save and close the file. At this point you have to rename the file  to match the ID in this case GEUPS.Example.Management.Pack.xml

Now for the discovery bit. Open the XML with your preferred editor and look for <Discoveries> this section is all we plan to edit at this stage.  Within <Discoveries> you will find

          <SnmpVarBinds>
<SnmpVarBind>
<OID>1.3.6.1.2.1.1.2.0</OID>
<Syntax>0</Syntax>
<Value VariantType=”8″ />
</SnmpVarBind>
</SnmpVarBinds>

The key to this section is the OID this is what is queried to determine if this device is a GE UPS as defined by our management pack. A few lines further down you have another important section, we will start with a simple expression first.

<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery>/DataItem/SnmpVarBinds/SnmpVarBind[OID=’1.3.6.1.2.1.1.2.0′][1]/Value</XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value Type=”String”>1.3.6.1.4.1.8072.3.2.10</Value>
</ValueExpression>
</SimpleExpression>
</Expression>

A few important things to notice in this section. First on the line with XPathQuery you see an OID, if you changed the OID in the <SnmpVarBind> section above you need to change it here as well as this is the pointer to the variable that was read and it needs to match for the compare or who knows what will happen. I of course know one thing that will happen and that is that you will never discover anything. So I guess with further thought I do know what will happen.  The second thing to note is <Operator>Equal</Operator> so this is a simple X = Y expression, we will look at another option in a second. Third <Value Type=”String”>1.3.6.1.4.1.8072.3.2.10</Value> this is telling us that the data type of this variable is a string, so you can’t try and match based on > or anything like that, and the value we are looking for is 1.3.6.1.4.1.8072.3.2.10, of course this is the example value and not the value we determined above so I will replace it with 1.3.6.1.4.1.818.1.100.1.1 and save the XML.      Optionally You can look for <Interval>3600</Interval> this is the number of seconds between discoveries. This can also be altered once the MP has been imported but unless you like to wait (in which case you will get along great with SCOM) you may want to reduce this now for testing. Try not to forget to change it back later 😉

Now if a simple expression is not good enough you may need a regular expression here is an example for another device I recently used. To be honest I am still looking for a good source of documentation on all the options for e regular expression if anyone knows a good one. (EDIT – Thanks Steve for pointing out the document Regular expression support in SCOM 2007.docx from the OpsManJam website. )

Here is the sample

<Expression>
<RegExExpression>
<ValueExpression>
<XPathQuery>/DataItem/SnmpVarBinds/SnmpVarBind[OID=’1.3.6.1.2.1.1.1.0′][1]/Value</XPathQuery>
</ValueExpression>
<Operator>MatchesRegularExpression</Operator>
<Pattern>^.*SensorHawk .*$</Pattern>
</RegExExpression>
</Expression>

With the above section of XML if the txt SensorHawk appears in the result then it’s considered a match.

Edit: Ben needed a discovery that would detect 2 different kinds of devices. Together we found the following appears to work best.

<Expression>
<Or>

  <Expression>
<RegExExpression>
<ValueExpression>
<XPathQuery>/DataItem/SnmpVarBinds/SnmpVarBind[OID=’1.3.6.1.2.1.1.1.0′][1]/Value</XPathQuery>
</ValueExpression>
<Operator>MatchesRegularExpression</Operator>

              <Pattern>^.*RICOH .*$</Pattern>
</RegExExpression>
</Expression>
<Expression>
<RegExExpression>
<ValueExpression>
<XPathQuery>/DataItem/SnmpVarBinds/SnmpVarBind[OID=’1.3.6.1.2.1.1.1.0′][1]/Value</XPathQuery>
</ValueExpression>
<Operator>MatchesRegularExpression</Operator>

              <Pattern>^.*Canon .*$</Pattern>
</RegExExpression>
</Expression>
</Or>
</Expression>

As awesome as Scott Vintinner’s example one thing I believe it lacks is a view in the console so you can see whats going on.  We need to add just a bit of XML to the existing pack, to make this easy I have added it to base pack using the RBH.Ecosaire.AC naming so you can just edit it all at once if you prefer.  Download updated management pack example Here we have added a section just after the end of  </Monitoring>

<Presentation>
<Views>
<View ID=”RBH.Ecosaire.AC.Management.Pack.AlertView” Accessibility=”Internal” Enabled=”true” Target=”RBH.Ecosaire.AC.Management.Pack.SNMPDevice” TypeID=”SC!Microsoft.SystemCenter.AlertViewType” Visible=”true”>
<Category>Custom</Category>
<Criteria />
</View>
<View ID=”RBH.Ecosaire.AC.Management.Pack.EventView” Accessibility=”Internal” Enabled=”true” Target=”RBH.Ecosaire.AC.Management.Pack.SNMPDevice” TypeID=”SC!Microsoft.SystemCenter.EventViewType” Visible=”true”>
<Category>Custom</Category>
<Criteria />
</View>
<View ID=”RBH.Ecosaire.AC.Management.Pack.PerformanceView” Accessibility=”Internal” Enabled=”true” Target=”RBH.Ecosaire.AC.Management.Pack.SNMPDevice” TypeID=”SC!Microsoft.SystemCenter.PerformanceViewType” Visible=”true”>
<Category>Custom</Category>
<Criteria />
</View>
<View ID=”RBH.Ecosaire.AC.Management.Pack.StateView” Accessibility=”Internal” Enabled=”true” Target=”RBH.Ecosaire.AC.Management.Pack.SNMPDevice” TypeID=”SC!Microsoft.SystemCenter.StateViewType” Visible=”true”>
<Category>Custom</Category>
<Criteria />
</View>
</Views>
<Folders>
<Folder ID=”RBH.Ecosaire.AC.Management.Pack.ViewFolder” Accessibility=”Internal” ParentFolder=”NetLib!Microsoft.SystemCenter.NetworkDevice.AllDevices.ViewFolder.Root” />
</Folders>
<FolderItems>
<FolderItem ElementID=”RBH.Ecosaire.AC.Management.Pack.AlertView” Folder=”RBH.Ecosaire.AC.Management.Pack.ViewFolder” />
<FolderItem ElementID=”RBH.Ecosaire.AC.Management.Pack.EventView” Folder=”RBH.Ecosaire.AC.Management.Pack.ViewFolder” />
<FolderItem ElementID=”RBH.Ecosaire.AC.Management.Pack.PerformanceView” Folder=”RBH.Ecosaire.AC.Management.Pack.ViewFolder” />
<FolderItem ElementID=”RBH.Ecosaire.AC.Management.Pack.StateView” Folder=”RBH.Ecosaire.AC.Management.Pack.ViewFolder” />
</FolderItems>
</Presentation>

And a few display strings that will form our text labels for the above entries, these go in the <LanguagePacks> section just before </DisplayStrings>

        <DisplayString ElementID=”RBH.Ecosaire.AC.Management.Pack.AlertView”>
<Name>Alerts</Name>
</DisplayString>
<DisplayString ElementID=”RBH.Ecosaire.AC.Management.Pack.EventView”>
<Name>Events</Name>
</DisplayString>
<DisplayString ElementID=”RBH.Ecosaire.AC.Management.Pack.PerformanceView”>
<Name>Performance View</Name>
</DisplayString>
<DisplayString ElementID=”RBH.Ecosaire.AC.Management.Pack.StateView”>
<Name>State View</Name>
</DisplayString>
<DisplayString ElementID=”RBH.Ecosaire.AC.Management.Pack.ViewFolder”>
<Name>Ecosaire AC</Name>
</DisplayString>

Now all you have to do is install your new MP and you should see in the SCOM monitoring console

With luck now you can see your base device management pack and may have even have enough good karma to see some devices.  Of course if all you have done is followed my instructions you still won’t have anything because there is one last step.

Step 4: You need to discover the device in SNMP. This is done via the operations console, in teh Administration tab.  Right click on “Device Management” and run the “Discovery Wizard”

Simple enough, select network devices and select next.

Here enter the IP or range of IP’s that your devices user, make sure to enter the community name you configured on the device, and drop the SNMP version down to 1, unless of course you know your device is V2. Select the management server that you want to handle traps, monitors and rules and click discover.

If all goes well a couple of minutes later you will get a screen showing the devices that have been doscovered, check the box(es) of the ones you want to be managed ckick finish and you are done. Then wait a while and they should start showing up in the management console.  If things didn’t go well there is likely a problem with either the community name or the SNMP configuration on the device allowing your root management server to contact the device using SNMP. Best to configure the device to send SNMP traps to all you management servers and allow SNMP read-only from all of your management servers.

Here are the completed XML files for a few of the MP’s I created if they are of use to you. Download and rename to .XML

GEUPS.GreaterThen.Five.Management.Pack

GEUPS.Single.Phase.Management.Pack

RBH.Ecosaire.AC.Management.Pack

Stay tuned for Part 2 where we will look into createing rules and monitors for the discovered devices.

Part 1

Part 2

Part 3