If you open the properties of this alert rule, you’ll see that the configuration data source scans the Operations Manager log on the Management Server for event ID 11852. Filtering on this event and comparing to the Application or System log on your Operations DB server, you might notice that these events coincide with the MSSQLService being stopped. Of maybe you’ll see 6009 System events, indicating the server had rebooted.
This would obviously cause logon failures to the operations DB for the SDK or MSAA accounts. Take a look at the Application log on your DB server, and you’ll likely see a bunch of 18456 failure audit events at the same time this alert is generated. It appears as though the Management Server attempts a connection approximately every 15 seconds. So, the longer the DB is down, the greater the repeat count on this alert.
As this is targeted at Management Servers, and it seems this event is only generated when the Operations DB is unavailable for abovementioned reasons, I’m not quite sure what value this rule provides. If the Operations DB is unavailable, the management server will generate this event locally. When the Operations DB is available and Operations Manager can connect to it, only then will this event be collected and an alert generated.
Also, we cannot plan a Maintenance Mode scenario to circumvent the alert (http://blogs.technet.com/cliveeastwood/archive/2007/09/18/agentmm-a-command-line-tool-to-place-opsmgr-agents-into-maintenance-mode.aspx). I haven’t seen any other cases where this event generates an alert for this rule. My solution to this pesky problem – override the rule > For all objects of type: Management Server.