At a customer of mine a issue with Incident Requests in System Center 2012 R2 Service Manager was reported. Some users reported that they received the error:”Failed to execute Submit operation. Fix the reported error before… – The user <domain>\<accountname> does not have sufficient permission to perform the operation.
Full error in the console was:
Date: 11-11-2014 15:11:35 Application: Application Version: 7.5.3079.0 Severity: Error Message: Microsoft.EnterpriseManagement.Common.UnauthorizedAccessEnterpriseManagementException: The user <Domain>\<Accountname>AN does not have sufficient permission to perform the operation. ProcessDiscoveryData(Guid discoverySourceId, IList`1 entityInstances, IDictionary`2 streams, ObjectChangelist`1 extensions) |
After some investigation we were able to reproduce the error, by using the following use case:
A scoped user with the Incident Resolver role creates an incident, and adds some additional information right after the incident was created. If the user adds the information, clicks on Apply the error above appears. If he clicks Apply again the error also occurs until after a while the user is able to succesfully do an Apply and the error doesn’t return anymore.
In the eventlog on the Management Server eventid: 26319 was logged
The full error is pasted below:
An exception was thrown while processing ProcessDiscoveryData for session ID uuid:4f7f5ba3-7c71-4c56-a8d2-b919c25be84a;id=684. Exception message: The user <Domain>\<Accountname> does not have sufficient permission to perform the operation. Full Exception: Microsoft.EnterpriseManagement.Common.UnauthorizedAccessEnterpriseManagementException: The user <Domain>\<Accountname> does not have sufficient permission to perform the operation. at Microsoft.EnterpriseManagement.Mom.DiscoveryDatabaseAccess.ManagementStoreAuthorization.Authorize(DiscoveryDataInstance discoveryDataInstance, IAuthorizationService authService, Boolean useProcessContext, WindowsIdentity identity, DatabaseConnection databaseConnection) at Microsoft.EnterpriseManagement.ServiceDataLayer.DiscoveryDataManager.DiscoveryPackageIncrementalProcessingHandler. AuthorizeEntityObjects(DatabaseConnection databaseConnection, Guid discoverySourceId, IContext context, IList`1 packets) ProcessIncrementalDiscoveryData(DatabaseConnection databaseConnection) |
Luckely the behavior was also present in the Service Manager test environment of my customer, giving me some opportunities to test the scenario. Given the message in the error “does not have sufficient permissions”, I quickly suspected something might be wrong with the way I implemented RBAC in Service Manager. I tried to recreate the error with my own administrative account member of the Service Manager Administrator role but wasn’t able to reproduce it.
Luckely as an MVP there are the fellow-MVP’s to the rescue., Anders Asp (http://www.scsm.se/) pointed me in the right direction by asking me whether the user was scoped to any group or queue or if it had permissions to all objects.
Apparently group calculation occurs on a set interval which could explain why permission are lost for a while and then the user is able to edit it again later. I didn’t have any groups for scoping, but did use queue’s.
This was the setting for access to the Queue’s for the user:
After modifying this to “All work items can be accessed” and testing the use case the behavior was gone.
I did some further testing by doing a Select All, but didn’t didn’t help either, the issue still occured. Apparently the calculation doesn’t take place if you have the “All work items can be accessed” option enabled.
For this customer enabling the “All work items can be accessed” option was a acceptable workaround, since everyone involved into the Incident management has access to all the incidents no mather in which support group the incident is handled at that moment.
Since it’s calculation, which takes a long time I suppose giving the Management Server extra resources could also minimize the timeframe in which the behavior occurs. Nevertheless, the error description could be a little bit more “user friendly”.
Hope this helps.