Manually Created User CI's + Custom User CI's Not Appearing in User Picker..
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 CI$User
- TRUNCATE TABLE CI$DomainGroup
- 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!
Adrian
Best Answer
-
Joe_Burrows Cireson Devops Super IT Monkey ✭✭✭✭✭Hi Adrian
The CacheBuilder can only bring in users from the AD.user class with a Distinguished Name value.
Some customers want to have users that dont exist in AD appear in the portal pickers, for this scenario I have them create the AD.User object using smlets and have them set a value for DN to get this to sync in the CI$user table.
Hope that helps!
Regards
Joe11
Answers
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
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.
Regards,
Adrian
I'd need to have a play and see what I can find.
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
The CacheBuilder can only bring in users from the AD.user class with a Distinguished Name value.
Some customers want to have users that dont exist in AD appear in the portal pickers, for this scenario I have them create the AD.User object using smlets and have them set a value for DN to get this to sync in the CI$user table.
Hope that helps!
Regards
Joe
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?
Regards,
Adrian