Home› Analyst Portal

Analyst Can access the SCSM Console but not The Portal

Bill_CrumBill_Crum Customer IT Monkey ✭
in Analyst Portal

This specific user had a name change, and our AD Process for handling this causes a lot of issues with SCSM, because our team just changes the old AD Object and changes to the new name, and also changes the USERNAME to a new username. Microsoft is currently working on a process for me to fix this issue in SCSM on a consistent basis, but I did get this Analyst fixed in SCSM yesterday. She can access SCSM, and the Assign to me task assigns it to her new SCSM User Object.


However when she tries to login to our portal, she gets the error she does not have access.

I have restarted the cache builder service, recycled the app poll and restarted the website. Any other suggestions before I open a ticket short of manually adding her in a the portal admin level?

Best Answers

  • Bill_CrumBill_Crum Customer IT Monkey ✭
    Answer ✓

    I did trace the cause of this down, and I will be detailed since you might see this elsewhere. The users this impacted had Broken User Objects in SCSM. What we saw were warnings in SCSM that the AD.User object could not be created, and referencing the vw_Usermanager (Spelling probably wrong). These happened when the AD Connector ran.

     

    What I also noticed, was that the user had a instance in the System.Domain.User class, but not in the Microsoft.Ad.User class. Also they saw this in the SQL Tables as well, member of one but not another.

     

    Microsoft decided on running a script against these users (We had 13k total, but 8k were active users in AD so we limited it to them to start), that would record all of their Relationships. Once that was done, we deleted the user object, did a full sync by clearing the watermark on the AD Connector, and once it was imported, we rebuilt the relationships to the work items etc.

     

    The script took over 24 hours total, and we are seeing some impact with regard to reporting thus far, but was successful. However, I already see a user broke that I know we fixed as he was in testing, and part of the original problem, so we are still investigating the root cause of why these objects are breaking in SCSM.

     

    Once they are fixed in SCSM, and Cireson Syncs, they are good to go on the portal.

     

    I will post this on the forum, so others can reference it, and when we get additional info, I will try to post that as well.

     

    Thanks for your help!

Answers

  • Bill_CrumBill_Crum Customer IT Monkey ✭
    PS, I also ran the script to truncate the user, domaingrpoup and lastmodified tables, and restarted the cache builder to let them repopulate.
  • Mike_StormsMike_Storms Customer Adept IT Monkey ✭✭
    Make sure the new user is part of the analyst AD group that is defined in settings... then do what you did as above...
  • Justin_WorkmanJustin_Workman Cireson Support Super IT Monkey ✭✭✭✭✭
    @Bill_Crum - If the username changed, there are most likely 2 CIs in SCSM.  
    https://blogs.technet.microsoft.com/manageabilityguys/2013/06/17/managing-username-changes-in-service-manager/
    That link has a script that will update relationships in SCSM from the old CI to the new.  Once the Rels are updated, you can delete the old CI, truncate CI$user and LastModified again, then restart cachebuilder.  If you have a test or dev system, I would recommend trying this out there first and of course backup the ServiceManager DB before deleting CIs or altering relationships en masse.
  • Bill_CrumBill_Crum Customer IT Monkey ✭

    It seems we have a more serious problem than this. I had already ran those scripts, but something is causing the AD Connector to fail creating the AD User Object. I am on the phone with Microsoft now and working the issue.

    Thanks for all the input and assistance!

  • Bill_CrumBill_Crum Customer IT Monkey ✭
    Answer ✓

    I did trace the cause of this down, and I will be detailed since you might see this elsewhere. The users this impacted had Broken User Objects in SCSM. What we saw were warnings in SCSM that the AD.User object could not be created, and referencing the vw_Usermanager (Spelling probably wrong). These happened when the AD Connector ran.

     

    What I also noticed, was that the user had a instance in the System.Domain.User class, but not in the Microsoft.Ad.User class. Also they saw this in the SQL Tables as well, member of one but not another.

     

    Microsoft decided on running a script against these users (We had 13k total, but 8k were active users in AD so we limited it to them to start), that would record all of their Relationships. Once that was done, we deleted the user object, did a full sync by clearing the watermark on the AD Connector, and once it was imported, we rebuilt the relationships to the work items etc.

     

    The script took over 24 hours total, and we are seeing some impact with regard to reporting thus far, but was successful. However, I already see a user broke that I know we fixed as he was in testing, and part of the original problem, so we are still investigating the root cause of why these objects are breaking in SCSM.

     

    Once they are fixed in SCSM, and Cireson Syncs, they are good to go on the portal.

     

    I will post this on the forum, so others can reference it, and when we get additional info, I will try to post that as well.

     

    Thanks for your help!

Sign In or Register to comment.