export and import with csvde or ldifde

[Tony]

I have a brand new domain setup 2003. In the old domain, I want ot be able
to export a bunch of users in an ou and import and create accounts for them
in this new domain.

What is the best way to do this? csvde or ldifde?

Also since many attributes are different for the users in each domain, what
should I or should not filter out when running the export?


Thanks

 

[Simon Geary]

Either tool can be used to import and export files to AD but you have a 3rd
option, to use ADMTv2 to migrate the accounts over between the two domains.
This would be the usual way to accomplish a user migration.

If you decide against this option and want to try csvde or ldifde I would
recommend ldifde. User passwords (unicodepwd, along with certain other
attributes) cannot be imported by these tools so you need a two step
process; import the users and then set their passwords. csvde cannot be used
to change passwords (or any other data, it can only import and export) so
ldifde is really the only choice here.

But like I said, you should consider ADMTv2 instead. This will allow you to
migrate users along with their passwords while still retaining access to
resources in the old domain thanks to sidhistory migration.

 

[Tony]

does ADMTv2 require domain admin rights to two domains? I only have domain
admin rights to the new one I am setting up.

 

[Simon Geary]

Yes, you need domain admin rights in both domains and a trust would need to
be configured between the two.

If this makes the ADMT plan impossible these links may help you with the
ldifde imports, but when it gets to this stage you may be as well creating
the new accounts from scratch, although this depends on the number of users
of course.

http://support.microsoft.com/?id=237677
http://support.microsoft.com/?id=263991
http://support.microsoft.com/?id=276382

 

[Tony]

I have about 1800 users in that ou to exportand import into the new domain.

Right now I am only concerrned with how to create the user in the new
domain.

 

[Cary Shultz [A.D. MVP]]

Good evening, Tony!

Simon, hope that you do not mind but I will jump in for a moment.

Tony, this is relatively easy to do. Now, I say this having done it many
times. The first few times ( in a test lab ) never went so well! But, that
is why you learn in a test lab so that when you do it for real you get it
done.

In the 'old' domain you are going to want to use ldifde to create a
'users.ldf' file. To do this you need to know the syntax for ldifde command
and a few of the switches. This is easy enough to figure out as you can
simply enter 'ldifde /?' and you will get a ton of examples ( going on
memory here....the links that Simon gave you look to be good, especially the
last one! ).

So, what we are going to do is to use ldifde to grab those 1800 user account
objects and export them to a text file, one that we can then slightly modify
( well, we will see if that is necessary in a moment ) and then import into
the 'new' domain.

So, here is an example of the ldifde command that you could run in the 'old'
domain:

ldifde -m -f users.ldf -s dc01.olddomain.com -t 389 -d
"dc=olddomain,dc=com" -r "(&(objectCategory=person)(objectClass=user))" -l
"DN,userAccountControl,sAMAccount,displayName,cn,givenName,sn,streetAddress,
l,st,postalCode,c,co,countryCode,telephoneNumber,company,department,physical
DeliveryOfficeName"

This would give you a text file named users.ldf ( the -f switch ) located at
c:\users.ldf on the server DC01 ( the -s switch ) in the 'olddomain' at the
domain level ( the -d switch tells you where to start this ). You are
filtering this to include only user account objects ( the -r switch ) and
you are specifying which attributes you want to be included ( the -l
switch ).

You could specify whatever attributes you want! You would just include them
in the -l switch.....

Now, let's assume that the new domain is called 'newdomain.local'. The .ldf
file that you have is not going to work because you have dc=olddomain,dc=com
all over the place. Well, this is easy to fix. In Notepad ( you must use
Notepad, not WordPad or MS Word...it must be Notepad! ) simply use the Edit
| Replace and then click on the Replace All... button. Simply replace
dc=olddomain,dc=com with dc=newdomain,dc=local and you will have a nice file
for the import.

So, put that on a floppy or a network location or CD or whatever and get to
the new domain. Copy that file to C:\ and -IMPORTANT- make sure to create
that OU so that it has the same 'path' as in the old domain. Remember that
each user account object is going to have a DN: cn=Cary
Shultz,ou=seniors,ou=class,dc=olddomain,dc=com. This indicates that you
have created an OU underneath the domain called Class and have created a
sub-OU called Seniors ( as well as Juniors and Sophomores and Freshman....we
are just worried about the Seniors for the moment - well, in this example ).
Now you can simply do the following:

ldifde -i -f users.ldf

In about five seconds you have all 1800 users. And all of them will now
have DN: cn=Cary Shultz,ou=seniors,ou=class,dc=newdomain,dc=local.

Now, the fun part comes in where you need to set each of their passwords.
1800 is a lot!

If this is a problem then you might want to take a look at addusers.exe
which will allow you to specify a password and then go behind that with
ADModify and fill in the blanks. However, this method involves a lot of
manual work ( in creating the 1800 user account objects from scratch ).

HTH,

Cary

 

[Tony]

Dear Cary,

Thanks you so much in going into so much detail about this matter. I
appreciate your help very much. Thank you Simon as well.

Question I have is in the old domain, there are certain attributes that does
not exists in the new domain, will it automatically creat those attributes
if I specify them in the import process?

 

[Simon Geary]

No, adding new attributes to the new domain will be a schema change and the
syntax you have is for an import\export.

Although ldifde can indeed be used to modify the schema if you change the
syntax ( http://support.microsoft.com/?id=283791 ) I don't think that would
be appropriate in your case. The question is, do you actually need these new
attributes in the target domain? If not, you should filter out the
attributes that do not exist in the target domain when you do your export.
If you do need them, you should make the schema changes to add the new
attributes before doing your user import, either by installing the
application that made the changes or adding them manually.

 

[Tony]

How do I add an attribute manually?

No, adding new attributes to the new domain will be a schema change and
the syntax you have is for an import\export.

Although ldifde can indeed be used to modify the schema if you change the
syntax ( http://support.microsoft.com/?id=283791 ) I don't think that
would be appropriate in your case. The question is, do you actually need
these new attributes in the target domain? If not, you should filter out
the attributes that do not exist in the target domain when you do your
export. If you do need them, you should make the schema changes to add the
new attributes before doing your user import, either by installing the
application that made the changes or adding them manually.

 

[Steve Ireland]

Don't take anything I say as gospel. I mean that, I'm ropey around all this
stuff myself.

Cary's outline is excellent. And as Simon says, why would you want a new
attribute - can you not use an existing one?

LDIFDE will indeed create passwords for you. If you have a minimum password
length policy you must disable it (temporarily) while importing.
In your LDF file, include a blank line at the bottom.
I used Excel to convert lastname, firstname, student number and class into
everything I needed to populate all fields.
NCSV2LDF is a free download and converts CSV files into LDF quite nicely
(with a little tweaking).


ADSIedit (Support tools) lets you adit the AD structure, but LDIFDE is
better for adding one attribute. I wouldn't go marching around in my wellies
through ADSI if I were you.
be afraid, be very afraid.


Q305144 Values for userAccountControl
Q276382 What fields can and can't be imported


LDF Files:


here I'm channging the Account Options on a user account.
To modify an existing entry in AD (variation of this can create attribute
for you) import your own version of this file.
(Excluding the ****'s)
**************************************
dn: CN=Andrew Thompson,OU=HOL,OU=Manhattan,OU=Students,DC=University,DC=ie
changetype: modify
replace: userAccountControl
userAccountControl: 8389248
-
**************************************






I know this won't display properly but here's a sample of my own import
file. I wish someone had done this for me.
All OUs I created first manually.
(Excluding the ****'s)
********************************************
#This LDIF file was generated by the NCSV2LDF utility from Novell Consulting
version: 1

dn: CN=Stephen Simpson,OU=MM,OU=New York,OU=Students,DC=University,DC=ie
changetype: Add
accountExpires: 127700028000000000
streetAddress: FifthAvenue Avenue
codePage: 0
cn: Stephen Simpson
countryCode: 372
c: IE
department: Multimedia 2004
description: Students FifthAvenue 2004 MM2A
displayName: Stephen Simpson
givenName: Stephen
homeDirectory: \\DCServer1\Students$\SSimpson
homeDrive: H:
instanceType: 4
l: New York
distinguishedName: CN=Stephen Simpson,OU=MM,OU=New
York,OU=Students,DC=University,DC=ie
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=University,DC=ie
objectClass: user
physicalDeliveryOfficeName: FifthAvenue
postalCode: Co. Dublin
name: Stephen Simpson
sAMAccountName: SSimpson
scriptPath: Students-FifthAvenue-logon.bat
st: Dublin
sn: Simpson
telephoneNumber: 1800COLLEGE
co: IRELAND
userAccountControl: 640
userPassword: 04002
userPrincipalName: (e-mail address removed)
wWWHomePage: http://Students.University.ie/2004/SSimpson

********************************************

 

[Cary Shultz [A.D. MVP]]

Thank you, Steve.

ldifde is one of my favorite tools that can be used to do a lot of things.
In WIN2003 they have come out with the ds* tools that are even better ( or
so it seems! ). However, I have not really done anything of any
significance with WIN2003 ( yet ) so I am not really up to speed.

You are correct. You can indeed use passwords in the ldf file. It is
typically a very difficult thing to do ( well, maybe I should say that it is
not easy ) so I typically leave that part off. ldifde is already - from a
stand point of syntax - difficult enough so I do not want to scare people
away from it. I also really like the ADModify tool. If you have not
checked it out you might want to....

Cary

 

[Pat Coghlan]

Just one note on this example. I believe you need to add the
"objectclass" parameter when exporting to be able to import the file later.