Be careful with this; make sure that your target schema is the same as your base schema, i.e. if you have extended your schema (i.e. added a new attribute to your User class) that this change is reflected in your test environments schema.
If you haven't extended your schema you should be fine, LDIF is pretty easy here is a great document.
http://www.microsoft.com/technet/treeview/default.asp?url="">
Also do yourself a favor and download ADAM from the Microsoft site, (http://www.microsoft.com/downloads/details.aspx?FamilyId=9688F8B9-1034-4EF6-A3E5-2A2A57B5C8E4&displaylang=en)
The LDIF exe there is an enhanced version of the one in the support tools with enhanced MACRO parameters.
HTH
Active directory programming http://groups.yahoo.com/group/adsianddirectoryservices
Carlos Magalhaes ADSI MVP
-----Original Message-----
From: Joe [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 18, 2003 2:02 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] User export
Password are not set until after the account is created so you would have a
disabled account on your hands.
joe
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Creamer, Mark
Sent: Friday, December 12, 2003 9:55 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] User export
Thanks Tony. Does the account get created with a blank password if I don't
create one myself? If so, what would happen if the domain policy is set to
not allow blank passwords?
<mc>
-----Original Message-----
From: Tony Murray [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 12, 2003 9:43 AM
To: [EMAIL PROTECTED]
Subject: Re: [ActiveDir] User export
There is one mandatory attribute that you need (sAMAccountName), but it is
generally useful to also have the following:
givenName
sn
displayName
userPrincipalName
userAccountControl
If might also want to set the password, which can be quite tricky with LDIF.
There's a KB article on
this:
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:
80/support/kb/articles/Q26
3/9/91.ASP&NoWebContent=1
If you're going to script part of it anyway, you may as well do the whole
thing (i.e. export and
import) without LDIFDE. Just a thought.
The main advantage of LDIFDE over CSVDE is the ability to modify existing
objects. CSVDE only allows you to create.
Tony
---------- Original Message ----------------------------------
Wrom: AUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZ
Reply-To: [EMAIL PROTECTED]
Date: Fri, 12 Dec 2003 09:25:19 -0500
I have a request to export the user objects from our production environment
and import them into our test environment.
If I use LDIF for this, are there required attributes I must include in the
export in order to make the import into the empty test domain successful?
I'd like to create a procedure with a script so next time one of the admins
can do it. Finally, are there any advantages to using ldifde vs csvde?
Thanks!
Mark Creamer
Systems Engineer
Cintas Corporation
Honesty and Integrity in Everything We Do
List info : http://www.activedir.org/mail_list.htm
List FAQ : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/mail_list.htm
List FAQ : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/mail_list.htm
List FAQ : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
------------------------------------------------------------- This email and any files transmitted are confidential and intended solely for the use of the individual or entity to which they are addressed, whose privacy should be respected. Any views or opinions are solely those of the author and do not necessarily represent those of the Trencor Group, or any of its representatives, unless specifically stated.
Email transmission cannot be guaranteed to be secure, error free or without virus contamination. The sender therefore accepts no liability for any errors or omissions in the contents of this message, nor for any virus infection that might result from opening this message. Trencor is not responsible in the event of any third party interception of this email. If you have received this email in error please notify [EMAIL PROTECTED] For more information about Trencor, visit www.trencor.net <http://www.trencor.net>
