July 2007 - Posts
Operations Manager 2007 kb for SNMP discovery hotfix
Out of the box Operations Manager 2007 supports discovering network devices using version 2 of the SNMP protocol. This hot fix will add support for discovering devices using version 1 of SNMP protocol.
From the KB:
After you apply this hot fix, a new Simple Network Management Protocol (SNMP) Community version list appears in the network device discovery wizard. This list contains an SNMP v1 item and an SNMP v2 item. If you select SNMP v1 from the list, the network device discovery wizard uses SNMPv1 to detect network devices.
KB link:
http://support.microsoft.com/kb/939364/en-us
More information from Clive Eastwood's Blog
http://blogs.technet.com/cliveeastwood/archive/2007/07/27/kb939364-system-center-operations-manager-2007-cannot-find-some-network-devices-by-using-the-network-device-discovery-process.aspx
This looks like it will be an awesome resource if you want to know how Microsoft is doing Operations Manager.
http://blogs.technet.com/MonitoringMicrosoft/
The RSS feed is http://blogs.technet.com/monitoringmicrosoft/rss.xml
Enjoy
WSUS 3.0 MP for MOM 2005 State Based Success Alerts
I recently implemented the WSUS 3.0 MP for MOM 2005 (Version 05.0.3000.0000).
Soon after implementing this MP there were one thousand or more Success Alerts sitting in our SMS/WSUS Alerts view. With out digging into the alerts and rules I dismissed it as a problem thinking that the Success Alerts get groomed every few hours, and this should not be a problem.
A few days later the Success Alerts were still there and the repeat count was more than twenty for each Success Alert.
I then looked at the WSUS rules, and noticed that of the twenty one rules, twenty of them were state based rules. As it turns out 19 of the 20 state based rules had an Alert Success Severity Calculation.
Workaround:
Don't forget to make copies of each rule that will need to be modified, disable the original rule, and rename the modified rule, so when you upgrade the WSUS 3.0 MP to the next version your modifications will be kept.
To clean up the SMS/WSUS administrators Alert View I removed the Success Alert Severity Calculation from the WSUS 3.0 Event Rules.
This is found in the Event Rule properties, on the alert tab click the Edit button, select the
Success Alert Severity entry and click the remove button.
Active Directory Management Pack Checklist by Pete Zerger on the Operations Manager Product Team Blog. This is the second posting from last week worth a read. The check list is on the Operations Manager Product Team Blog:
http://blogs.technet.com/momteam/archive/2007/07/19/active-directory-management-pack-checklist.aspx
While this is an excellent resource don't forget to read the Active Directory Management Pack Guide too.
http://download.microsoft.com/download/7/4/d/74deff5e-449f-4a6b-91dd-ffbc117869a2/om2007_mp_actdirmgmt.doc
From the Operations Manager Product Blog entry:
Operations Guide Available
My collegues Chris Fox, John Downing, and Kim Simmons have just released the Operations Guide! The guide is a comprehensive resource that can be used to understand and use your Operations Manager 2007 implementation to your best advantage. It teaches an Operations Manager administrator what to do after successfully deploying a Management Group for the first time.
The following topics are covered:
- Understanding Initial Configuration
- Configuring Operations Manager for Use
- Deploying Agents
- Processing Manual Agent Installations
- Managing Management Packs
- Investigating and Resolving Alerts
- Changing Passwords for Operations Manager 2007 Accounts
- Keeping the Core Infrastructure Healthy
- Backing up the Root Management Server Encryption Key
- Heartbeat and Heartbeat Failure Settings
- Using Active Directory to Assign Computers to Operations Manager 2007
- Identifying the Root Management Server
- Removing a Management Server from a Computer
- Configuring the Customer Experience Improvement Program (CEIP)
- Configuring Client Monitoring
- Configuring Error Reporting
- Configuring Operational Data Reports
- Managing Gateway Servers
- Managing Web Console Servers
- Managing Reporting
- Backup and Recovery
Pick up your copy here: http://download.microsoft.com/download/7/4/d/74deff5e-449f-4a6b-91dd-ffbc117869a2/OM2007_OpsGuide.doc
Useful information if you're going to be creating custom queries against the OperationsManager db Alert table or AlertView.
Resolution State
ID Resolution State
0 = New
255 = Closed
Severity Values for Alerts
0 = INFORMATIONAL
1 = WARNING
2 = CRITICAL
Example Query using OperationsManager database, this query will display all alerts that are Critical:
select * from dbo.Alert where Severity = '2'
Expect a few more example queries in a few weeks.
This query utilizes the SDKAlertView (SQL View) in the OnePoint Database.
This query will count the number of alerts per server for a specified period of time.
-- SQL CODE
-- Count alerts from SDKAlertView by computer name for specified period of time
Declare @StartDateTime DateTime
Declare @EndDateTime DateTime
-- >>>>>>>>>>>>>>>
SET @StartDateTime = '07/08/2007 12:00:00 PM' -- type a date time in UTC time i.e. -- 3/29/2006 12:00:00 AM
SET @EndDateTime = '07/09/2007 12:00:00 PM' -- type a date time in UTC time i.e. -- 3/30/2006 12:00:00 AM
-- <<<<<<<<<<<<<<<
SELECT ComputerName AS 'Computer Name', COUNT(*) AS 'Alert Count'
FROM SDKAlertView
WHERE (TimeOfLastEvent BETWEEN @StartDateTime AND @EndDateTime)
GROUP BY ComputerName
ORDER BY 'Alert Count' DESC
-- END of SQL CODE
The following query uses the SDKAlertView (SQL View) to show the number of alerts by severity between a users specified time period. This can be used on both the OnePoint and SystemCenter Reporting Databases.
-- Created by Scott Moss
-- Count Alerts between specified dates. OnePoint Or SystemCenterReporting DBs.
Declare @StartDateTime DateTime
Declare @EndDateTime DateTime
-- >>>>>>>>>>>>>>>
SET @StartDateTime = '07/07/2007 12:00:00 PM' -- type a date time in UTC time i.e. 3/29/2006 12:00:00 AM
SET @EndDateTime = '07/08/2007 12:00:00 PM' -- type a date time in UTC time i.e. 3/30/2006 12:00:00 AM
-- <<<<<<<<<<<<<<<
SELECT Severity = Case
When Severity = 10 Then 'Success'
When Severity = 20 Then 'Informational'
When Severity = 30 Then 'Warning'
When Severity = 40 Then 'Error'
When Severity = 50 Then 'Critical Error'
When Severity = 60 Then 'Security Issue'
When Severity = 70 Then 'Service Unavailable'
Else 'Unknown'
End,
COUNT(*) AS EventCount
FROM SDKAlertView
WHERE (TimeRaised BETWEEN @StartDateTime AND @EndDateTime)
GROUP BY Severity
ORDER BY EventCount DESC
-- END SQL CODE
SQL Server 2000 Long Running Agent Job and where is its alert?
Ran into s strange one today that I wanted to share, that deals with alert suppression with MOM 2005. If your SQL team cares about getting alerts about long running jobs then this is probably going to be a rule change that you might want to make.
This morning I was informed that the SQL team was not getting alerts about long running SQL jobs on a SQL 2000 server this weekend. I looked at the operator console and created a view to look at that servers specific alerts for the past 48 hours showing all alerts, all resolution values etc. I found an alert where the long running job script created an alert which was a Error. Any alert Error or higher should have fired off to their notification group. The Alert had a repeat count that was about 100. I looked at the history of the alert and it only showed:
7/1/2007 4:07:04 AM: NT AUTHORITY\NETWORK SERVICE
Changing AlertLevel of Alert from 30 To 40.
7/1/2007 3:07:03 AM: NT AUTHORITY\NETWORK SERVICE:
Alert is created by Script SQL Server 2000 Long Running Agent Jobs.
Where was the notification event? To figure out what's going on I need to take a look at the rule that runs the script, as well as the script to get a better understanding of what's going on. The script is SQL Server 2000 Long Running Agent Jobs. The script has three parameters, ErrorThresholdInMinutes value 120; InformationEvent value of False; WarningThresholdInMinutes value of 60; This is only interesting because this script can create alerts with two different Alert Levels.
The rule Microsoft SQL Server\SQL Server 2000\SQL Server 2000 Health and Availability Monitoring\SQL Server 2000 Long Running Agent Jobs
Looking at the Alert rules suppression settings gives a good clue of exactly what happened. Suppress duplicate alerts is enabled on the following fields.
Alert Name, Computer, Domain
Like it says below the Enable Suppress Duplicate alerts: Fields must be identical for the alert to be considered a duplicate and suppressed.
Well this alert was created by the same rule, and was unresolved, so until the severity field is added to the Alert Suppression field list no one will get an alert if the severity changes from Warning to Error for this rule. To properly fix this create a copy of the original rule, and paste it in the same folder, rename to "Modified - SQL Server 2000 Long Running Agent Jobs". Do this so when you upgrade the SQL Management Pack you don't loose your changes. Disable the original rule. Edit the "Modified - SQL Server 2000 Long Running Agent Jobs" click on the alert suppression tab, and click the check box next to the Severity field, and click ok. Don't forget to Commit Configuration Change.
This rule/script can easily change the severity of an alert however, the alert suppression settings allow the rule to change the severity level of the alert with out creating a new alert with a new severity, which could cause an alert to get by on the weekend when folks are not looking at the console all day.
Enjoy!