Sign in
 
Home2012Previous VersionsLibraryForumsGallery
System Center TechCenter >
> 
> 
Permission Denied Issue When Trying to Resolve or Close an Incident Created From a Template

Вопрос Permission Denied Issue When Trying to Resolve or Close an Incident Created From a Template

  • Sunday, July 22, 2012 3:14 PM
     
     
    Sign In to Vote
    0

    Hello,

    I am running SCSM 2012 RTM and have setup multiple Incident Resolver Roles to be able to limit what users in each department of IT can see in terms of views and work items.  

    A user can create, edit, resolve, and close any incident assigned to the queue scope with in their assigned role.  However, when an incident is created from a template the user can create and edit that incident but when trying to resolve or close the incident they receive an error that they do not have permissions.

    I have been trying to figure this one out for a while now, does anyone know what permissions need to be granted?  If I put the same user in the global Incident Resolver role they can resolve and/or close the incidents created from a template without issue so I know it is permissions issue.

    Here is the error:

    Date: 7/22/2012 11:07:07 AM
    Application: 
    Application Version: 7.5.1561.0
    Severity: Error
    Message: 

    Microsoft.EnterpriseManagement.Common.UnauthorizedAccessEnterpriseManagementException: The user DOMAIN\UserName does not have sufficient permission to perform the operation.
       at Microsoft.EnterpriseManagement.Common.Internal.ServiceProxy.HandleFault(String methodName, Message message)
       at Microsoft.EnterpriseManagement.Common.Internal.ConnectorFrameworkConfigurationServiceProxy.ProcessDiscoveryData(Guid discoverySourceId, IList`1 entityInstances, IDictionary`2 streams, ObjectChangelist`1 extensions)
       at Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.CommitInternal(EnterpriseManagementGroup managementGroup, Guid discoverySourceId, Boolean useOptimisticConcurrency)
       at Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Commit(EnterpriseManagementGroup managementGroup)
       at Microsoft.EnterpriseManagement.UI.SdkDataAccess.DataAdapters.EnterpriseManagementObjectProjectionWriteAdapter.WriteSdkObject(EnterpriseManagementGroup managementGroup, IList`1 sdkObjects, IDictionary`2 parameters)
       at Microsoft.EnterpriseManagement.UI.SdkDataAccess.DataAdapters.SdkWriteAdapter`1.DoAction(DataQueryBase query, IList`1 dataSources, IDictionary`2 parameters, IList`1 inputs, String outputCollectionName)
       at Microsoft.EnterpriseManagement.UI.ViewFramework.SingleItemSupportAdapter.DoAction(DataQueryBase query, IList`1 dataSources, IDictionary`2 parameters, IList`1 inputs, String outputCollectionName)
       at Microsoft.EnterpriseManagement.UI.DataModel.QueryQueue.StartExecuteQuery(Object sender, ConsoleJobEventArgs e)
       at Microsoft.EnterpriseManagement.ServiceManager.UI.Console.ConsoleJobExceptionHandler.ExecuteJob(IComponent component, EventHandler`1 job, Object sender, ConsoleJobEventArgs args)

    Thanks,

    Dustin



    • Edited by D. Elliott Sunday, July 22, 2012 3:14 PM
    • Edited by D. Elliott Sunday, July 22, 2012 3:15 PM
    •  
     

All Replies

  • Tuesday, July 24, 2012 1:07 AM
     
     
    Sign In to Vote
    0

    To add to my original post, if I edit the role that the user is in so that under the Queues section it is set to "All work items can be accessed" that user can then resolve and close incidents that have been created using templates.

    However, if I instead set the Queues section of the security role so that it is set to "Provide access to only the selected queues" but then use the select all check box so that all existing queues are selected the user can not resolve or close the incidents created using a template.

    I was under the impression that using the "Select All" would essentially be the same as "All work items can be accessed" but it appears that is not true.

    I now assume that this is either a bug or my understanding of the Queues setting is incorrect and to fix this I need to create another queue and grant the role permissions to it.

    If I do in fact need to create another queue does anyone have any suggestions as to what the criteria for it need to be?  I think the even better question is why would there need to be a queue for incidents that are not created using a template and one for those that are when all that I am using for criteria in the queue is what the "Support Group" name is.

     
  • Friday, July 27, 2012 9:24 PM
     
     
    Sign In to Vote
    0

    After working on this issue with MS Premier we have narrowed it down to a delay in the group/queue calculation processing. Because I am using customized security roles which are based on queues there is a processing step that needs to take place after an incident is created that basically determines what queues the incident should be a member of.

    Premier suggested that it should take between 20 seconds and 1 minute for that group/queue calculation processing to take place and then the user with the assigned role should be able to resolve or close the incident. In my environment this is true some of the time, of course when Premier is on the phone and looking over my shoulder the processing times were between 1 and 2 minutes. Sure enough, after that process ran the user could resolve and close the incident.

    However we went back and looked at some of the other incidents that I was testing with when I made this post initially and those took more than 24 hours to process which is why I could not resolve or close them at the time.

    My next step is to wait and see if those long processing times happen again and to do some logging on the SQL server if they do.

    If you see this happen in your environment you can use the History tab of the incident to see how long the calculation process takes. As you can see in the screenshot below the time difference between when the incident was first created (7/22/2012 10:24:17 AM) and when it was added to the "Support Group - GIS Help Desk - All Incidents" queue (7/23/2012 8:58:37 PM) was close to 36 hours when it should have been no more than a minute or two.



    • Edited by D. Elliott Friday, July 27, 2012 9:26 PM
    • Edited by D. Elliott Friday, July 27, 2012 9:27 PM
    •  
     
  • Monday, August 06, 2012 8:29 AM
     
     
    Sign In to Vote
    0
    i have the same problem with a delay in the group/queue calculation processing. But i can't understand what is the clue for this problem? What i need to do to resolve it?
     
  • Monday, August 06, 2012 3:50 PM
     
     
    Sign In to Vote
    0

    Unfortunately I don't have a definite solution for this yet, in my environment it was only a problem for a couple days and then it started working as expected on its own. It depends on the management server's work load but now it is taking between 1 and 3 minutes for the processing to take place.

    I do have a set of scripts to run on the SQL server if/when I experience the slowdown but so far that hasn't happened.

    What are the hardware specs of your management server where the workflows are processed?

     
  • Friday, August 17, 2012 11:34 PM
     
     
    Sign In to Vote
    0
    Curious, have you figured this one out yet? I have the same issue, but it seems the only way that I can get it to work around the error is if i open up the user's permissions to access every single queue, which we don't want to do because different queues go to different departments.
     
  • Friday, August 17, 2012 11:46 PM
     
     
    Sign In to Vote
    0

    LCarson,

    No "solution" other than waiting the 1 to 3 minutes for the group/queue processing to take place.  I did setup a second managment server and reconfigured all the conosle to connect to that so the first management server is reserved for workflow and this type of processing.

    If you look at the history tab of the workitem are you seing a long period of time between when it is created and when it is added to the queue?  See the screenshot a couple of posts up.

     
  • Tuesday, August 21, 2012 12:00 AM
     
     
    Sign In to Vote
    0
    Weird, becuase on mine even though I have all the permissions set correctly, no matter how long I wait, it still says that the user doesn't have permission to resolve the incident even though they should. I have an incident a week old and it still can't be closed, even by my god-power admin account.
     
  • Wednesday, September 05, 2012 1:55 PM
     
     
    Sign In to Vote
    0
    SM MS - separate virtual server(4 x2,66 Ghz, 8Gb Memory)