Incident delay in recognizing queue - Analyst cannot see newly created incident RRS feed

  • Question

  • We just rolled out SCSM 2012 R2 and immediately experienced an issue related to security applied to incident queues. The basics:

    Analyst creates an incident and clicks Apply. No problem. Incident successfully created.

    Analyst quickly adds/changes incident and hits Apply again or OK. Error thrown reporting permissions issue. This is the same incident the analyst just created.

    Analyst goes to All Incidents view and the new incident is not visible. Early in the morning, waiting a few moments would allow the ticket to be visible. By two hours later when the system was under some load, several minutes (5+) would pass before the incident was visible if at all. Different views were selected, Console was closed/reopened with no effect.

    The cause turned out to be the custom queues and custom user roles we had applied. For example, we created a custom queue for all incidents for a specific support group. Then we created a custom user role that had permission to view only that queue of incidents (but all other properties). We did not go wild on this. There were only 6 custom queues and 4 custom user roles. However, putting all analysts back in the default Incident Resolvers role took care of the issue.

    This is something that we are going to need to be able to do. Can anyone advise what might be going on here and how to troubleshoot this issue? We looked at resource utilization on all systems (1 Mgmt Server, 1 DW, 1 SSP, 1 dedicated DB server) and did not notice anything stand out during the troubled period.

    Any suggestions?

    Monday, October 12, 2015 6:17 PM


All replies

  • The delay is by design as the SCSM workflows that process queues run on a schedule.  I am afraid that the only way around the delay is not to use the queues and give everyone visibility to everything.

    If it's any consolation, the team at Microsoft gave us a chance to vote on this issue https://connect.microsoft.com/WindowsServer/Feedback/Details/1751125.

    Hopefully they will work on this to reduce the queue assignment delay.

    Monday, October 12, 2015 7:13 PM
  • Well that certainly explains our experience. I think our solution will be to designate Service Requests only as workitems that can contain any information that needs to be segmented for security purposes. Those workitems have less immediate access needs than Incidents.

    Out of curiosity, what is the polling interval for queue assignment?

    Tuesday, October 13, 2015 1:03 PM
  • I do believe that it is supposed to run every minute but, from experience, that assessment is not accurate as I have seen queue assignments happen anywhere from 20 seconds to 10 minutes after the ticket is created.  The longest I have ever seen a ticket take to make it to its queue was well over an hour but this was caused by a huge, prolonged spike in disk access latency on the CMDB SQL server which delayed all workflows significantly.
    Tuesday, October 13, 2015 2:26 PM