ServiceDesk

If you must have the CMDB solution installled when using ServiceDesk 7, why must all of your user information be synced from AD and not the user resource within the CMDB?  Has anyone built that? 

ServiceDesk synchronises the users into Process Manager via PM.ADMergeManagement , not sure if there are plans to change this to allow use of data in the CMDB, maybe 7.1 will give the option to choose, can anybody in Symantec PM advise

Cheers

Hi,

I think the only workaround that you can do is to tell users to check "Remember Me" check box when they log into the system. This option forces the system to use the same account every time he logs in from the same machine, until the user clearly logs out, by clicking "Log out" link.

That way, the users will not be challenged for user name/password every time until they use the "Log out" link in the ServiceDesk Portal.

I don't think that this relates to the original question, Mustafa... 

Since you are required to install the CMDB solution while installing SD why is there not a way to import user information from the CMDB to SD.  SD will only allow you to sync with AD unless you have a full verison of Workflow and write a custom component.  If you use Asset you have a lot more information in the CMDB than you do with AD.  Also when it syncs with AD it does not import some critical fields.  Like manager, location or telephone on the general tab and many others.

Oh, Sorry for my post. It was targeted to another topic and came here by mistake.

Anyway,
Regarding this one, I could read in other topics related to similar issues that there might be some improvements and more features related to AD Sync for user information in the coming ServiceDesk 7.1. However, this is an unofficial word.

But, I think that John is right. If we already have CMDB and it does the same function of synchronizing AD user data and supports more and more customization  features, so why no to use these data in the SD. I think it should solve all issues related to AD Sync for all clients.

Can we have any Symantec Employee to give us a feedback on the above words?


Regards,
Mustafa

I talked with Symantec support and was told that they were working on the ablility to sync more information from AD, but it wouldn't be available for a couple of months when SP1 releases.  Check out feature request KB 51079.  Really this still does not make any sense.  You would think you could use Workflow to bring this information in from the CMDB.

For sure I'm surprised ServiceDesk doesn't sync users from the CMDB.  Especially considering that most of us have tweaked out the Active Directory connector within the NS already to grab what we need.  Having ServiceDesk talk directly to AD doesn't seem like the best plan.

Let the NS do the AD sync (because it's better at it, anyway, and we have lots more options), pull what we want into the CMDB, then have ServiceDesk get it's data from the CMDB.

How confusing will this be once we do personality transplants or other user-based tasks in the new NS7?  If we have a servicedesk ticket for user-related NS procedures, the ticket is going to be tied to the SD contact, right?  But the task will need to be launched from the NS using the CMDB contact.  This could get confusing.

I hope Symantec comes up with a solution that does not involve purchasing the full Workflow.  There's no way I can get another $50k approved to my budget.

I wonder, what is necessary in the SD user table to allow AD authentication?  It might be worth some time looking at the tables to find out.  I think the questions to ask / test would be:

1. Can we create SD users via SQL query? (looks like derickab has some preliminary code to accomplish this)
2. Can we assign those created users to SD groups?
3. Can we assign those created users to authenticate through A/D without enabling AD sync?  I mean, build the SD user accounts manually but have the authentication pass through?

If this works, it wouldn't be hard in SQL or VB to also tweak what is used as the primary key field for the user account.  I know there are some other forum posts complaining about this - I want my primary field to be Pre-Win2kUserName@myDomain.com.  I don't want my primary field to be whatever-the-user-has-set-for-primary-email-address@myDomain.com .  That drives me nuts.

A method like this could also workaround the phone number field complaint, too.

Thats the part which  is that I used the email address as the primary key. Being that I have no AD just an OLEBD import straight from SQL I used it as my identifier. Its working to a point but its still leaving out some of the information I'm trying to pull in. Hopefully in a day or so I will be able to populate all my users information into the SD and then I should be golden. What I would like to do is have all users to use their employee id as they login but thats whats failing for me. Not sure on how to get the system to recogize that as the user instead of the email address. Once the users are in the database then they can be assigned to different groups such as the technicians, guests and so on. 

We shouldn't be having to do this much work around to get SD to work right.  Symantec needs to think like a customer instead of just developers.  To me this is common sense kind of stuff.

I wonder if you could just use a dummy email address as the initial one, just to get the user account created.  Then add the real email address as an additional email address, and switch it to the "primary" email in SD users after the fact.

I'm just starting to test on ServiceDesk, and I don't know anything yet, so maybe I shouldn't be making suggestions.  But it looks like, once a user is created, you can add whatever addtional email address, then set that new address as the "primary" email for SD communication.  But this change after the fact leaves the initial email because that appears to be the primary key field for the SD user account.  That also appears to be the login name.

So perhaps you could make your query create UserID@YourDomain.com as the initial email address / user name.  Then add each user's real email address as an additional email address.  I would think that would accomplish SD login = UserID.  I don't know from there how you'll assign those additional emails back to primary without using the GUI.

What I have tried to devise was to do an import from the NS7 database to the SD database where it pulls in all the information needed for the service desk.

EX:

I used the vusers(NS7) table and selected what columns I wanted and updated the user(SD) table. That populated all my users in and I had them all set to guest. Still didn't work but its a start just to throw some ideas out there.  Once I fine tune the sql query I'm using I'll throw it out there for you guys to toy with it.


This is all being done in my test enviornment for those that do have one. I wouldn't try this with a live one b/c it didn't work so I just snapped my VM back and all is well.  

Well the latest update! Here is the query that I am using to try and import the users.

insert into ns7sd..[user](userid)

select _resourceguid from Inv_Global_User_General_Details

set ns7sd..[password] to dominion

I know I said I was trying to import the email addresses but when I try to do that it will not work b/c the darn thing will not let you import the email address unless you have a guid assigned to each user. So then I went in to import the resourceguid (from the same table) it errors b/c you have to have a password assigned to each user.

Now the process is to figure out a way to have it set the password to whatever I want it to be. As you can see I tried a combination up top but my seatement is wrong. It seems that you can't do much importing into the SD without having everything populated at the same time.


Still testing!!!!!!!!!!