Design access for a large company (View VS Queue) RRS feed

  • Question

  • Hi there 

    I and my team have implemented SCSM2012R2 for a large telecom company with more than 300 console users (14 support groups- 30 vendors which work just with MA in console). at first of the project we design accesses based on too many queues sometimes  complex ones. totally we made more than 650 queue in different work items. then we faced major problems in performance and loading everything (also we set the group calculation reg key on 2400000=40 min)  in system then by adding resources we made condition better but yet we have many problems. based on my design we can delete more than 450 queue and instead create about 280 typical views.

    1-can we solve our problems in this way?

    2- we should have about 70 SLO and I know this one make an extreme load on servers, what can we do for this one?


    track it, find it, make it


    • Edited by mam-pro Thursday, February 9, 2017 12:39 PM
    Thursday, February 9, 2017 12:33 PM

All replies

  • Hello,

    There is no specific number of SLO that Service Manager supports. For example, if an organization typically has few incidents, it can support more SLOs than it might otherwise be capable of.

    For SCSM performance, you may refer to the link below:

    Service Manager Performance


    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, March 3, 2017 7:06 AM
  • Hi

    Yes, I think going with views would help. The number of views, 280 is a lot, but when you break it down by support group it is not surprising. It does cause a bit more management overhead to assign AD groups that match the support groups to User Roles so they can only see the views appropriate to them. I would create folders for each support group to hold the views - this is for the admins benefit rather than the analyst as it makes the console a bit easier to navigate.

    Queues do put a load on the servers and usually I have found that Analysts do not like them or understand them. They add workflows that can get in the way and lock the work item or the Analyst will add the job to a queue and then they can't see the job or get it back.

    A queue provides a security boundary in the Console and operational database, but this does not translate to the data warehouse. Reporting can then be a problem where you want to restrict it along the same lines as the queue.

    You have to look at the reasons you have queues in the first place, If it is as a security boundary, I would suggest looking at separate Service Manager instances. This provides a more secure boundary, but obliviously comes at a server cost.  

    Views will separate the data, but will not provide a security boundary. A search with the work item ID and any analyst will be able to view the data. This may be a problem and if it is then you are stuck with queues.

    When creating views use targeted type projections - using the advanced type projection for this number of views will cause performance issues. 

    I am not sure what to say about the SLO's. It seems high and a lot of them must be very similar. I would try to compromise with the business areas about a more standardized approach. The only other suggestion is to take the SLO's out of Service Manager - just because it is there you don't have to use them.  Do you need this information in Service Manager, do the analysts rely on it, could you create a view to show the same information. So rather than rely on the breach status, have a view that has jobs that match the breach criteria. This means analysts have to monitor the view and possibly have to change their work processes.

    With some clients they are happy to implement the SLO's as reports. These can be automated daily, weekly etc. This has often been what the business area wants anyway - a report of the jobs that do not meet the SLO criteria - they don't care if the data is calculated and stored on the work item, they just want the report.

    I have written a couple of blogs that might be of interest:

    These are just ideas and rambling ones at that. Yan Li is right about there being no specific number that SCSM supports, and the reference provided is a good starting point. It all depends on your environment and what your business areas and analysts are willing to accept.



    Web: www.xapity.com  |   Twitter: @xapityapps  |   Facebook: xapityapps

    • Proposed as answer by Yan Li_ Friday, March 3, 2017 8:47 AM
    Friday, March 3, 2017 8:35 AM