Home Analyst Portal

Manually Created User CI's + Custom User CI's Not Appearing in User Picker..

Adrian_PaechAdrian_Paech Customer Advanced IT Monkey ✭✭✭

Hi All,

Getting some strange behaviour in the portal. Was hoping someone could help.

Am running v6.0 of the Portal.

We have some manually created user CI's (which are not created in AD, but manually created under the "User" CI container). No matter what I do, I cannot seem to get these manually created user accounts to be available under the User Picker in the portal. All of the accounts synced from our AD appear, but not the manual accounts.

I have even created a custom view in the portal for "Active Directory Users" and then created the user accounts under this view (so that the user account is created with the same class as a normal user), but even then these manually created users will not sync across into the "dbs.CI$User" database when re-syncing the database.

I am resyncing the database as follows:

  • TRUNCATE TABLE LastModified

Then restart the CacheBuilder service.

I did notice however that the user does come across as a "CI" instead, but I need the CI to come across as a User (available for picking in the user picker)

We would prefer not to create an AD User Account every time we need an internal only SCSM user.

Secondary to this, we do have a custom user class called "Customers" which inherits the abstract class System.User. We also wanted to have our list of generic customers available for picking in to user picker. Is there a way to add in these custom CI's into the User Picker also?

Thanks in advance!


Best Answer


  • Brett_MoffettBrett_Moffett Cireson PACE Super IT Monkey ✭✭✭✭✭
    I see what you are trying to do here @Adrian_Paech however, it is not the way SCSM is designed.
    The AD User and Group class is a class all unto itself that is for users being synced with the AD Connector.
    There may be a way to enter AD Users manually in to the DB but it would not be via the SCSM console, you would have to do it via a SQL Add query.
    Once it was in the system, I'm not sure how the AD Connector would treat the record....   If it could no longer find it in AD, it might delete it from SCSM thinking the record has been removed...   maybe...  not sure.

    Also, if you want these customers to be able to view the portal at any stage to review their WI's etc. then there will be no authentication method.

    Microsoft allows you to create an unlimited number of user accounts in AD. It's just if they have logon rights or not that then start to cost you licensing money. I've seen a federal agency create an AD account for every business in Australia before....   4.5 million records.....   Bit of a stretch for AD, but it worked.

    These AD Accounts can be in a sub OU and have ZERO rights on the domain.

    I believe this is how we, Cireson, do it in the background of Support.Cireson.com and Community.cireson.com.

    Hope this answers your question

  • Adrian_PaechAdrian_Paech Customer Advanced IT Monkey ✭✭✭

    Ok kind of answers my question, however I did notice that in the portal, I can refer to those user accounts no problem in the incident form user picker.. but not within the portal..

    Seems like the portal has some special criteria for pulling users into the CI$User table..

    If I have to create the AD user accounts I will, but just seems like the portal is lacking functionality that the console already has.

    Thanks for the quick response though. :)



  • Brett_MoffettBrett_Moffett Cireson PACE Super IT Monkey ✭✭✭✭✭
    It may be possible to change the Type Projection used by the Incident form in the Portal to not limit it's search for users by their type.

    I'd need to have a play and see what I can find.
  • Adrian_PaechAdrian_Paech Customer Advanced IT Monkey ✭✭✭

    Ok. Im pretty sure that the type projection used for the user picker is the same as what's used in the console, but might be wrong here.

    <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemAssignedToUser']$" Alias="AssignedTo" />

    But its like the portal is only geared to query the CI$User table for user picker objects. So, I would be interested to know what the criteria is for syncing data into this table, and if there is any way to change it, or to point a user picker on the form to an alternate class / source.

    Might not be possible, but cant hurt to ask :)


  • Adrian_PaechAdrian_Paech Customer Advanced IT Monkey ✭✭✭

    Perfect Joe.

    Exactly what I was looking for. Thanks for that! :)

    I will give it a go and let you know.

    Does it need to be a valid DN.. or can it just be gibberish?



  • Joe_BurrowsJoe_Burrows Cireson Devops Super IT Monkey ✭✭✭✭✭
    Na doesnt have to be valid, feel free to ping me if you need any help getting it working.
  • Adrian_PaechAdrian_Paech Customer Advanced IT Monkey ✭✭✭
    Cheers Joe.
  • Tim_ShackletonTim_Shackleton Customer IT Monkey ✭
    Interestingly with version 7.2 of the portal if the Affected User is populated in he console (or by the Exchange Connector) with an SM User, that user is brought through and displayed in the portal as the Affected User.  But the user picker is constrained to the Active Directory User class by design.
This discussion has been closed.