[THIN] Re: OT-AD import from SQL
- From: "Pavlo Ignatusha" <pignatusha@xxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Tue, 29 Jun 2004 08:38:55 -0400
Neil,
Thanks a lot for your help and I will most likely ask you again once I'll
get more information from my payroll admin. The whole task is really a
nice-to-have thing for us at the moment but it may recieve a higher priority
soon. I also found a book about ADSI scripting on my shelf - so I have a
starting point here as well. I'll try a few things and let you know. Would
you prefer to be contacted off the list for this matter?
Thanks again,
Pavlo Ignatusha
Systems and Network Coordinator
Pembroke General Hospital
Tel. (613) 732-3675 ext.6150
Fax. (613) 732-9986
www.pemgenhos.org
"All that matters is love and work" - Sigmund Freud.
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]On Behalf
Of Braebaum, Neil
Sent: Tuesday, June 29, 2004 4:48 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: OT-AD import from SQL
Truly this will need some direction from you - there are a number of
ways to develop something - but I doubt anybody will do the whole damn
thing for you, unless you are prepared to pay.
Having said that, I will try any help you with some direction - but you
are going to need to make some decisions yourself. Namely:-
1. Write something to do it reading from your SQL base, then adding to
AD - kinda on-demand.
2. Have some selective export from your SQL base with just the details
required, then use that as source to import to AD.
3. Various methods of automating 2.
There are some mandatory fields for creating a use in AD. Believe it or
not, though, there are only 2 mandatory properties for a user account in
AD - namely sAMAccountName and the cn for the user object. Everything
else is optional. ADU&C is perhaps a bit misleading, here - but those
two are the only mandatory properties in the directory for creating an
object.
Odd as it may sound, sAMAccountName and the cn tend not to be the same
for users in AD, simply because of the default manner in which the cn is
created through the normal interfaces.
In the assumption that your export from SQL is truly selective - in only
having the details you want entered into AD, then you're part the way
there. After that, though, you'd have to consider how the other, likely,
albeit optional parameters are going to get populated.
If the SQL export was simply CSV with the three fields you mentioned, it
would largely be a trivial task to use CSVDE to import this, but from
the sounds of things, you want to apply some more logic as to the OU
where the account is created.
To do this, and develop something so bespoke, there's really no likely
way, without becoming relatively familiar with some sort of ADSI
scripting.
But the first and crucial thing you need to decide, and get clear
*before* you try and develop a technical solution, is the rationale, the
logic behind how you want to do this. After that, it's a relatively
trivial task to actually code it - as always, it's crucial to make the
design decision first.
I'm willing to try and help you in doing this via ADSI, but you're going
to have to get your hands dirty, too.
Neil
Other related posts:
