Home Analyst Portal

Template permissions

David_Morris1David_Morris1 Member Advanced IT Monkey ✭✭✭

We have multiple change management templates most of which are locked down to certain users/groups, because of this the analysts can only access scoped templates from the "new" draw at the bottom of the page. Seemingly randomly this scoping is no longer applied to some users / groups allowing them to see/use all change templates in the system. a Cache builder restart resolves this issue.

any ideas? Cireson support have claim this must be a workflow changing permissions or a SCSM issue and to contact Microsoft but as a cache builder restart resolves the issue I'm reluctant to believe this is the case



Best Answer


  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    I have run into a similar issue with permissions. 
    Enabled full logging on cachebuilder and found the following error
    WARN  [   3]:  cn=User, Name,ou=users,ou=noc,dc=localhost is a member of cn=scsm-noc-workflow,ou=noc_scsm,ou=groups,ou=noc,dc=localhost, but does not exist in the database.

    Performed a fix from MS that forces a FULL AD sync via the AD connector

    To do a FULL AD connector synchronization you need to reset the watermark on the AD connector. Steps below:
    -- Execute the following SQL Query to find the DataSourceID number for the AD Connector that is used to bring the users into SM Use ServiceManager
    Select * from LFX.datasource
    -- Update the line below replacing # with the corresponding AD connector DataSourceID from above to reset the AD Watermark for that connector. The Next AD Synchornization performed will be a FULL synchronization.
    [LFX].[ResetWatermarkForDataSource] #,'erroroutput'
    -- From the Service Manager Console select the AD Connector and then click "Synchronize Now".

    This cleared the sync error between SCSM and the Cachebuilder.
  • Justin_WorkmanJustin_Workman Cireson Support Super IT Monkey ✭✭✭✭✭
    @David_Morris1 - Did Brian's advice of doing a Full AD connector resync fix your permissions issue?
  • David_Morris1David_Morris1 Member Advanced IT Monkey ✭✭✭
    Hi, we have performed this fix and currently doing testing to see if it has helped, with the issue being intermittent we want to let it run for a little while before confirming
  • David_Morris1David_Morris1 Member Advanced IT Monkey ✭✭✭
    Unfortunately this hasn't fixed the issue
  • john_doylejohn_doyle Cireson Support Ninja IT Monkey ✭✭✭✭
    Hi @David_Morris1
    When you click New > Work Item > Change Request > From Template, the browser sends a call to http://portalserver/api/V3/Template/GetTemplates?classId=e6c9cf6e-d7fe-1b5d-216c-c3f5d2c7670c with an authorization token associated with the user. The server connects to the SCSM SDK as that user and calls GetObjectTemplates(). It is at this point that scoping occurs. SCSM should only return the objects on which the user is scoped.
    The portal takes the list of templates returned by SCSM, filters them by the class type, and returns that list to the portal user.

    The cache builder has no part to play in this process. I cannot explain why restarting the cache builder should remedy the situation. Perhaps the calls that the cache builder makes to the SCSM SDK cause it to re-evaluate the scoping on the users?

    It might be interesting when you find yourself in this situation again, to run a PowerShell session as the affected end user and then use the Get-SCSMObjectTemplate cmdlet from SMLets to check if the user can read that template.

  • David_Morris1David_Morris1 Member Advanced IT Monkey ✭✭✭
    Hi John,

    We actually have 3 separate portals to allow us to copy with multiple time zones, all installed on separate management servers with separate ServiceManagement DB all connecting back to one SCSM instance, we see this issue on all 3 portals intermittently across multiple users,

    at the moment of writing i currently have the issue showing on my non admin account on one portal and not the others, running the GET-SCSMObjectTemplate shows the 1 change template my non admin account should see and so does 2 of the three portals, the other shows all changes templates in the system both on the UI and by browsing directly to the API link you mentioned above
  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    Ok I have to ask

    "copy with multiple time zones"

    Seems like a heavy load on your SCSM instance to have three replicas for time zones.
    Just wondering the design.

    (I have one portal server servicing 8 time zones and 33K users) 
  • David_Morris1David_Morris1 Member Advanced IT Monkey ✭✭✭
    ok, how do you deal with Request offering dates having to be entered in a single time zone for automated self service like access requests?
  • john_doylejohn_doyle Cireson Support Ninja IT Monkey ✭✭✭✭
    Hi @David_Morris1
    I wonder if this is related to an issue we used to see in the portal, where the ServiceManager connection would timeout for the user and the portal would reconnect as the service account to complete the action. I know this was still an issue on some versions of V7.4. Typically you would see updates in the work item history showing as modified by the service account rather than by an analyst. In fact, the session timer was introduced to stop this from happening.
    I have not heard of this problem recurring in more recent builds. Would you consider upgrading the portal?
  • David_Morris1David_Morris1 Member Advanced IT Monkey ✭✭✭
    Hi John,

    this maybe the case so worth looking at, we will be upgrading but are heading into Christmas change freeze so wont be until the new year
  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    It is all localized in the portal to UTC time. So Any action item where I provide the requester the option to specify a start date I map the set option to the schedule start date field. Then SCSM and the portal display this value localized to the computer that it is being viewed from.

    The only issue I run into is if I use the ARO to map the date entered to the SR title or description. It is saved in the time zone for the entered user with no time zone information so it may not match the time zone of the support desk processing the request. 
    So I do everything I can not to map dates to free text fields when I can. And if the business case requires it I add to the ARO prompt to please enter the value in EST time. (All our support desks are EST)
  • David_Morris1David_Morris1 Member Advanced IT Monkey ✭✭✭
    All IR/CR/SR etc forms are localized to the timezone of the requestor but when raising an Request Offering the dates are saved back to UTC based on the Portal Management servers Timezone,

    I.E if a user in a US timezone at UTC -5 logs onto a portal where the management server is in UK time UTC +0 and requests access to a system for 10am it logs into SCSM as 10am UTC not the converted US Local time (5am UTC) meaning the access will be granted 5 hours early meaning without using a seperate portal for the US time zone the users that arent in the management servers local time would have to convert the times on input
  • David_Morris1David_Morris1 Member Advanced IT Monkey ✭✭✭
    Adding a prompt to "please enter in UTC" or any static time zone isnt an acceptable solution, and as our three portals run with minimal overlap we dont see and load issues. (it also lets me maintain the portals seperately without any downtime by scheduling it out of the local office hours)
  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    "but when raising an Request Offering the dates are saved back to UTC based on the Portal Management servers Timezone,"
    Not that I have seen. Any Date prompt that I have mapped to a date field IE Schedule Start Date That date gets saved in UTC in the database adjusted from the users workstation time zone. 
    If the portal is not saving the date correctly I would open a ticket.
  • David_Morris1David_Morris1 Member Advanced IT Monkey ✭✭✭
    I currently have 3 production portals and a test portal that all save back at the timezone of the management server i had two portals at a previous company that did the same, i have opened a ticket previously and was told this is by design but its now being looked at with my cireson account manager and passed on to the Dev team
  • john_doylejohn_doyle Cireson Support Ninja IT Monkey ✭✭✭✭
    I can confirm what @David_Morris1 is seeing. The date time is sent from the RO in the user local time, interpreted on the server as a local time and then converted to UTC. So if the end user is in a different time zone to the server, the time set on the server will be offset by the difference between the two time zones.
  • David_Morris1David_Morris1 Member Advanced IT Monkey ✭✭✭
    good to know, I asked @Katie_Dyer to request that this be changed so ROs dates are converted to UTC based on the user local time rather than the server time, and its been passed to dev
  • David_Morris1David_Morris1 Member Advanced IT Monkey ✭✭✭
    as for the template issue i will wait on this until i can update the portal as there has been a similar know issue in the past to see if that helps and if not i will then re-raise it
  • David_Morris1David_Morris1 Member Advanced IT Monkey ✭✭✭
    thats great much appreciated
  • Mike_StormsMike_Storms Customer Adept IT Monkey ✭✭
    I have a similar issue... I did what Brian suggested but no luck I have opened a case... this occurred when we moved from v7.4.2012.11 to v8.3.1 is there any resolution or workaround...
Sign In or Register to comment.