Service Manager User Import / Commissioning
This is gonna sound weird and I'm sure there will be a BIG "But Why!!!" after reading this. But just bare with me...
We are in the process of implementing SCSM and I have run into a problem regarding the import if users into SCSM.
Due to the complexity of our business systems and how we provision users, we only use AD for authentication. Meaning we do not carry any user details in AD. Only Username that is an 8 digit number, display name that is the same as the username and some other non-important data.
To compensate for the lack of AD user details, I have created a "system" to get the user details into SCSM:
- I created a standard AD connector in SCSM to import the users and groups needed.
- There is a DB that gets live updated user data from our "Identity Management" systems.
- From the DB mentioned above, I create a CSV that gets placed on the SCSM WF server.
- I then use Orchestrator with an XML file and the CSV file to update the users in SCSM.
- The data includes Display Name, Location, Capacity, Manager, Email address, etc.
- The Orchestrator process is scheduled to run after the AD connector.
The problem is that everytime the AD connector runs, the data is updated and all the values that Orchestrator updated goes back to what they are in AD. I then need to re-run the Orchestrator connector to update the values.
I have automated this process and has been running without an issue the past couple of months while we tested.
Our business analyst has informed me that this is an extremely inefficient process and that I will need to find an alternative solution to get the users with details into SCSM without using the AD connector or a CSV file. It was also suggested that I use some kind of REST API and web services to get the users and groups into SCSM.
So, here is my question, is there any other way of importing users into SCSM besides the AD connector and a CSV file.
I know that Orchestrator has an API and web services that can be used, but where do I start with a runbook to get the data from our system and import into SCSM with all the needed relationships.
I also investigated the possibility of updating the relevant tables within the SCSM DB live from our "Identity management" system, but there are just too many relationships within the DB to even think about creating a process. And this will probably break in the future if MS updates SCSM in a weird and wonderful way.
To give some background, we only have one AD and we can use it to authenticate with SCSM, just not as a "source of truth" to import users. So the option of adding the needed values into AD is also not an option.
I know there will be many questions regarding our use or misuse of AD, but it is what it is and I can not change it.
If anyone made it so far into the question and have any suggestions or solutions, it will be highly appreciated.
If there are any other questions please do not hesitate to contact me.
Regards
Gerhard
Best Answer
-
Brian_Wiest Customer Super IT Monkey ✭✭✭✭✭I will be the first to say " **************". I will be nice.so to answer your question.
Sounds like the best solution would be to turn off the AD connector and use a nightly powershell script that creates the users similar to the AD connector.
Where the PS will only search for AD objects created within the last sync cycle and then create an new user.
This post should get you started
https://social.technet.microsoft.com/Forums/systemcenter/en-US/364fa4b9-8170-4369-8d9c-53fbb0d0ec17/create-users-with-the-scsm-powershell-cmdlets
7
Answers
Sounds like the best solution would be to turn off the AD connector and use a nightly powershell script that creates the users similar to the AD connector.
Where the PS will only search for AD objects created within the last sync cycle and then create an new user.
This post should get you started
https://social.technet.microsoft.com/Forums/systemcenter/en-US/364fa4b9-8170-4369-8d9c-53fbb0d0ec17/create-users-with-the-scsm-powershell-cmdlets
If I am right about this, then I definitely agree with Brian's solution. The AD connector does not work much differently than any PS you would write, but it handles the logic of changes and deletions, etc. for you. In a script, you would need to tell it what to do in case something doesn't match, for example. But writing this type of script may actually require less effort in the long run.
Good luck!
All seems good, or so I thought....
The problem that this method creates is that the users cant authenticate and thus cant use the system.
The created accounts are also not imported into the Cireson DB.
I have done the Ultimate Cireson Cache reset SQL script and restarted all the services/application pools and as a final resort the server itself to force a cachbuilder refresh.
This might be because I deleted all the old connectors and users, I will do a complete rebuild of SCSM on my test env and test the process again...
Another solution...
When I look at the Users imported by AD, there is properties like Distinguished name, SID, ObjectGuid and FQDN.
I guess my next challenge will be to create a custom AD connector that only syncs the essential details mentioned above but that kind of defies the point of the webservice/ORCH workflow.
Any thoughts or suggestions will be highly appreciated
G
Hi,
@ PS import
maybe you need some additional fields from AD like SID and DN (take a look at the "extensions tab" on the SCSM User dialog.
regards
I will either have to config my script to talk to AD and get the SID, GUID etc of the users and add it as part of the user that is created.
Or I will have to create the custom AD connector to only import the above mentioned properties.
I will play around with the options
Thanks everyone
What is seen below is bit and pieces from all over the intertubes, so I'm just gonna give credits to the internet... :-)
Here is what the runbook looks like
In the first step, I get the data via a web service from our IDM solution.
In the Create User script, the following is happening:
Get Created User:
Update User Info
Get Manager
Link manager
Generate GUID
Create mail notification
And that is how it works, there was some stuff that did not want to work in the script, that I had to create extra steps in the runbook.
This all takes about 10 seconds to complete and after I restart the CachBuilder, the users are able to log into the Cireson portal and work.
I must admit that this was an awesome and equally frustrating journey and that I have learned a lot in the process.
Thank you to everyone here that contributed in guiding me in the correct path.
Like I said above, there are some issues that I will address like try-catch blocks and other error reporting within the runbook, but this provides an overview of the needed steps.