<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Hardware Status Polling Question in Server Management - Systems Insight Manager</title>
    <link>https://community.hpe.com/t5/server-management-systems/hardware-status-polling-question/m-p/4456650#M38115</link>
    <description>In SIM, the Hardware Status Polling checks every 5 minutes to see if a server/device is up, by default. As it works with the default settings, we get alerted a LOT more than we want.  Every time a server is rebooted, there's a decent chance we'll get an alert.  So, ideally, I'd like to be able to configure it to wait to check a second time before sending out an alert.  &lt;BR /&gt;&lt;BR /&gt;I'm not finding any way to quite configure it like this, but was able to get it to sort-of function like that by changing the Global Protocol Settings for ping to a timeout of 60 seconds and 5 retries.  This seems to behave as we would like.  The down side is that the automated Discovery also uses these settings.  Since we inherited a messy network, we've got a range of almost 9000 IP addresses that it has to check--using the same 60 second timeout and 5 retries.  That means it takes around 450 hours for the Discovery to finish.  Not a practical situation.&lt;BR /&gt;&lt;BR /&gt;I've tried changing the timeout and retries on just the Hardware Status Polling task, but it seems to ignore that setting, for some reason.  When I had that set, it still whipped through the Polling in less than a minute--even with a test server powered off. (and, of course, it sent out an alert right away)&lt;BR /&gt;&lt;BR /&gt;Does anyone know of a way to accomplish what I'm trying to do with the Alerting/Polling without negatively impacting the Discovery?</description>
    <pubDate>Thu, 09 Jul 2009 13:39:04 GMT</pubDate>
    <dc:creator>jameskrolak</dc:creator>
    <dc:date>2009-07-09T13:39:04Z</dc:date>
    <item>
      <title>Hardware Status Polling Question</title>
      <link>https://community.hpe.com/t5/server-management-systems/hardware-status-polling-question/m-p/4456650#M38115</link>
      <description>In SIM, the Hardware Status Polling checks every 5 minutes to see if a server/device is up, by default. As it works with the default settings, we get alerted a LOT more than we want.  Every time a server is rebooted, there's a decent chance we'll get an alert.  So, ideally, I'd like to be able to configure it to wait to check a second time before sending out an alert.  &lt;BR /&gt;&lt;BR /&gt;I'm not finding any way to quite configure it like this, but was able to get it to sort-of function like that by changing the Global Protocol Settings for ping to a timeout of 60 seconds and 5 retries.  This seems to behave as we would like.  The down side is that the automated Discovery also uses these settings.  Since we inherited a messy network, we've got a range of almost 9000 IP addresses that it has to check--using the same 60 second timeout and 5 retries.  That means it takes around 450 hours for the Discovery to finish.  Not a practical situation.&lt;BR /&gt;&lt;BR /&gt;I've tried changing the timeout and retries on just the Hardware Status Polling task, but it seems to ignore that setting, for some reason.  When I had that set, it still whipped through the Polling in less than a minute--even with a test server powered off. (and, of course, it sent out an alert right away)&lt;BR /&gt;&lt;BR /&gt;Does anyone know of a way to accomplish what I'm trying to do with the Alerting/Polling without negatively impacting the Discovery?</description>
      <pubDate>Thu, 09 Jul 2009 13:39:04 GMT</pubDate>
      <guid>https://community.hpe.com/t5/server-management-systems/hardware-status-polling-question/m-p/4456650#M38115</guid>
      <dc:creator>jameskrolak</dc:creator>
      <dc:date>2009-07-09T13:39:04Z</dc:date>
    </item>
    <item>
      <title>Re: Hardware Status Polling Question</title>
      <link>https://community.hpe.com/t5/server-management-systems/hardware-status-polling-question/m-p/4456651#M38116</link>
      <description>The best thing to do is to use Suspend Monitoring when you are planning on rebooting a server.  That will suppress Automatic Event Handling during the time it is suspended.</description>
      <pubDate>Thu, 09 Jul 2009 15:11:27 GMT</pubDate>
      <guid>https://community.hpe.com/t5/server-management-systems/hardware-status-polling-question/m-p/4456651#M38116</guid>
      <dc:creator>David Claypool</dc:creator>
      <dc:date>2009-07-09T15:11:27Z</dc:date>
    </item>
    <item>
      <title>Re: Hardware Status Polling Question</title>
      <link>https://community.hpe.com/t5/server-management-systems/hardware-status-polling-question/m-p/4456652#M38117</link>
      <description>Yeah, I hear ya.  I'm part of a team that doesn't do that reliably, though.  This isn't just limited to reboots, however.  There can be odd hiccups that occur on the network that just make a ping fail--even though the server is fine.&lt;BR /&gt;&lt;BR /&gt;I'm trying to get SIM to be a reliable system for alerting us to issues.  As it is running currently, we get so many alerts that everyone on the team just ignores them.</description>
      <pubDate>Thu, 09 Jul 2009 15:30:37 GMT</pubDate>
      <guid>https://community.hpe.com/t5/server-management-systems/hardware-status-polling-question/m-p/4456652#M38117</guid>
      <dc:creator>jameskrolak</dc:creator>
      <dc:date>2009-07-09T15:30:37Z</dc:date>
    </item>
    <item>
      <title>Re: Hardware Status Polling Question</title>
      <link>https://community.hpe.com/t5/server-management-systems/hardware-status-polling-question/m-p/4456653#M38118</link>
      <description>I did a quick search and couldn't find the message about it, but our old friend Rob Buxton approached this problem with a custom script that is called for notification from Automatic Event Handling instead of sending an email.  His script will establish a counter when an offline status poll is encountered, and then will fire off an email using a CLI email tool only when it has remained offline for x counts.  Look it up.</description>
      <pubDate>Thu, 09 Jul 2009 17:02:21 GMT</pubDate>
      <guid>https://community.hpe.com/t5/server-management-systems/hardware-status-polling-question/m-p/4456653#M38118</guid>
      <dc:creator>David Claypool</dc:creator>
      <dc:date>2009-07-09T17:02:21Z</dc:date>
    </item>
  </channel>
</rss>

