August 2008 - Posts

• Change the Primary Management Server

  Change the Primary Management Server We have had a few customers trying to "Change the Primary Management Server" of an agent (on the fly) unsuccessfully. This is done in the Admin pane of the UI (under agent managed, right click on the agent select Change Primary Management Server.     Once you have changed the Primary Management server, you will see your agent go Grey and no longer report back in to SCOM. In the Evt log you will see Event Type:    Error Event Source:    OpsMgr Connector Event Category:    None Event ID:    20070 Date:        8/26/2008 Time:        5:53:19 PM User:        N/A Computer:    servername Description: The OpsMgr Connector connected to servername, but the connection was closed immediately after authentication occured.  The most likely cause of this error is that the agent is not authorized to communicate with the server, or the server has not received configuration.  Check the event log on the server for the presence of 20000 events, indicating that agents which are not approved are attempting to connect. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. The heart of the problem is the Gateway receives the new Configuration before the Agent you are trying to change does. Thus the old Gateway rejects the agent and never pushes the new configuration to said agent. Since the agent can't get the configuration from the old Gateway, and doesn't know to look to the new Gateway it simply drops from being monitored, Also the RMS will continue to hold the current configuration information so the agent never fails over (even if you manually change the configuration locally on the agent). The fix to this problem is fairly straight forward. You have to configure Agent failover in the admin console (after running MOMADmin). Once you configure Agent Failover (again in the admin console, in the properties of each Management Server or Gateway) with the new gateway or management server you want to failover to you can use the "Change Primary Management Server" feature with in the GUI. Posted Aug 26 2008, 07:15 PM by Operations Manager 2007

• Alert Suppression

  Alert Suppression Another tip we found today is dealing with Alert suppression. Normally when you create rules/monitors you set Alert Suppression using the standard fields (i.e. Name, source, etc)   However in some cases we need to set more advanced criteria.  In this case we want to edit the configuration of the alert (1), Click on Alert Suppression (2), Click Advanced (3) and enter your Criteria (4).     In the example above we needed to suppress duplicate alerts from Syslog messages coming in to SCOM. The trick to what we had to do was suppress alerts and take in to account the time and date of the event (the way Syslog messages come in include the date and time so suppression can be tricky as the same message comes in at different times). Using the $Data/EventData/DataItem/Facility$, $Data/EventData/DataItem/Serverity$, and $Data/EventData/DataItem/HostName$ you can suppress the duplicate messages and avoid the sea of red in your console. The thing to be careful of is to make sure you are getting all the messages you want before you start suppressing alerts. Sometimes you will get the same message with a different time stamp in the Timestamp and Message fields causing the suppression not to work or causing it to work too well. Play around with the different options after you have your list of requirements.  Posted Aug 26 2008, 01:14 AM by Operations Manager 2007

• HP Blade Enclosure Applet

  HP Blade Enclosure Applet Over the last few weeks we have been working on building a couple of new Data Centers and getting SCOM up and running to monitor them. Obviously monitoring the HP servers was a top priority. Our client has a mix of standalone servers and C-Series Blade enclosures. For those of you that haven't played with the more recent HP MPs, let me just say they have changed a bit. In the MOM2005 days the HP monitoring was done with some simple MPs that monitored the HP Agents, SNMP, Evt logs etc. In SCOM 07 there are some applets that you have to install on a Management Server (or the RMS... Gateways are NOT supported (I tried)). These applets are collectors of sort, they gather the information from the hardware and pass it along to SCOM (this is completely simplified, and I know there is more to it than this). There are some MPs that have to be imported (as they all don't get imported, a little bug). There are two applets, one for standalone servers and one for Blade Enclosures. The Proliant server pack is very straight forward. There is a bit more to the Blade pack. Once you install it and make sure the MPs are imported, you have to discover the Enclosure (from within the applet). All the documentation I read said that communications from the applet to the Enclosure is over 5316. What we found today is the communication is actually over TCP port 443 (at least the discovery). We spent a couple of days trying to figure out why the discovery wasn't working. The Mgt server we are using as the Collector for HW is in a separate VLAN than the Enclosures; so knowing all the ports we needed was important. The only thing we could think of was HP figured 443 would be open by default, and/or user error reading the docs and we over looked all the port info. Long story short... you need 443 and 5316 (we are still wondering about 5316) to use the Blade Enclosure SCOM MPs. Hope this helps. Posted Aug 26 2008, 12:36 AM by Operations Manager 2007