Hi all, We run a relatively large OpsMgr R2 environment and as expected we have various users that have various levels of access (applied usng the standard OpsMgr User Roles). The problem is - when a user who has Read Only (or any other level) access tries to acces an area that he/she doesn't have access to, an event 26319 is logged on the RMS as shown below: Event Type: Error Event Source: OpsMgr SDK Service Event Category: None Event ID: 26319 Date: 7/9/2010 Time: 3:17:34 AM User: N/A Computer: xxxxxxxxxxxxx Description: An exception was thrown while processing GetTasksByCriteria for session id uuid:46f119fe-e2fe-4f8b-87e1-7abb1432a955;id=901. Exception Message: The creator of this fault did not specify a Reason. Full Exception: System.ServiceModel.FaultException`1[Microsoft.EnterpriseManagement.Common.UnauthorizedAccessMonitoringException]: The creator of this fault did not specify a Reason. (Fault Detail is equal to Microsoft.EnterpriseManagement.Common.UnauthorizedAccessMonitoringException: The user xxxxxxxxx does not have sufficient permission to perform the operation.). So my question is - how can i stop these annoying 26319 being raised, and does anyone know why they would be raised as an 'error' when I've purposefully set up the permissions so this user does not have access? These annoying 26319 'Errors' just put noise into my RMS' Event Log and makes my life more difficult to identify any real errors. Thanks, Kristian

Hi Kristian, Story about this bug is quite old :( http://social.technet.microsoft.com/Forums/en-US/operationsmanagergeneral/thread/c3bed796-3877-4756-8714-74f1e986fb2c I am escalate this thread to PG. Maybe they have some answers now?http://OpsMgr.ru/

The story of this bug continues, unfortunately. These events are a nuisance, but can be ignored. There is no way around this problem that I am aware of, since it is the SDK that logs these events. The product group would need to include this fix in a core product CU or hotfix. Let's see if someone from the product team can offer some feedback as to if/when we plan to roll this one.HTH, Jonathan Almquist - MSFT

Thanks for the feedback guys. If there is anyone from the Product Group who can shed some light/direction on this bug, it would be greatly appreciated. Thanks again, Kristian

I think it's perspective. Logs are there for all kinds of logging - you don't have to look at them, and the presence of an event in the log may be uninteristing to some, but interesting to others. There is virtually no overhead in terms of server performance, and no downside impact on the MG performance. As a result, a bug like this is going to nearly always be punted in favor of putting resources on a bug that impacts performance, or bumped by feature work to enhance the product.Microsoft Corporation

I agree with the idea of putting it into perspective and resourcing. I would also like to see more important 'bugs' fixed over this. I also agree that this isn't neccessarily a 'bug' as such. I can see value in receiving these events. However, these events clearly do not relate to an 'error' and should therefore be logged as Informational instead. The fact that they log as 'error' is inconsistent with normal application event logging. In my case, I have a large user base so as you can imagine that over time my RMS Event Log is filled with these 'errors'. The trouble is that investigating real problems becomes harder because of these 'errors' all throughout the RMS Event Log.

In my case, I have a large user base so as you can imagine that over time my RMS Event Log is filled with these 'errors'. The trouble is that investigating real problems becomes harder because of these 'errors' all throughout the RMS Event Log. This is where using Windows 2008 Event logs are invaluable.... "-26319". Done. :-)

Unfortunately for me this caused my system not to change any state. 80% of my objects are not monitored - no health cache, no maintenance mode helped that. Only alerts are coming fine, health state isn't changing. R.E.M. - YEAH!