Home » System Center Operations Manager 2007 » Override RunAs Logon Check Failed

Contoso.se

Welcome to contoso.se! My name is Anders Bengtsson and this is my blog about Microsoft infrastructure and system management. I am a principal engineer in the FastTrack for Azure team, part of Azure CXP, at Microsoft. Contoso.se has two main purposes, first as a platform to share information with the community and the second as a notebook for myself.

Everything you read here is my own personal opinion and any code is provided "AS-IS" with no warranties.

Anders Bengtsson

MVP
MVP awarded 2007,2008,2009,2010

My Books
Service Manager Unleashed
Service Manager Unleashed
Orchestrator Unleashed
Orchestrator 2012 Unleashed
OMS
Inside the Microsoft Operations Management Suite

Contoso.se

Welcome to contoso.se! My name is Anders Bengtsson and this is my blog about Azure infrastructure and system management. I am a senior engineer in the FastTrack for Azure team, part of Azure Engineering, at Microsoft.  Contoso.se has two main purposes, first as a platform to share information with the community and the second as a notebook for myself.

Everything you read here is my own personal opinion and any code is provided "AS-IS" with no warranties.



MVP awarded 2007,2008,2009,2010

My Books

Service Manager Unleashed


Orchestrator 2012 Unleashed


Inside the Microsoft Operations Management Suite

Override RunAs Logon Check Failed

The other day I needed to configure a web application check against a web service in a DMZ. This DMZ had its own Active Directory domain with no trust or connection to the internal domain where Operations Manager was installed. One of the criteria of the web application monitoring was to verify that we could log on to the web service. We ran into a challenge when configure the run as account for the web service. Operations Manager is trying to verify the account, as we didn’t have a trust or any connection to the DMZ domain that was not possible. We tried to override only for this account on the watch node, but unfortunately it was all account checks or none.

After some investigation we found that the event generated on the agent (the watch node in this case) included the account that did pass the check.

The solution to this was to disable the monitor for the watch node, then create a new monitor only for the watch node with the same criteria, but with one extra criteria, not to include events where event description includes LITWARE\Administrator. LITWARE\Administrator was the account that we didn’t want an alert on.


1 Comment

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.