Re: Export/import AD

Doh!

Okay, one stupid mistake and one typo! I am very sorry!

Yes, the -i switch is what you would need to specify where you importing a
..ldf file into your AD environment. Since ldifde defaults to exporting you
do not really need to specify anything for what are doing. That was a
hairball mistake. Sorry!

Now, for the sAMAccountType filter - this was simply my fingers not quite
interacting with my brain. You are correct: 368 is for user account objects
and 369 is for computer account objects ( which I honestly did not know! ).
See, from my typo I learned something! Thank you.

Anyway, if you have any more questions please feel free to ask. ldifde is a
really wonderful thing to know. It takes a lot of 'doing' to get it,
though. It has a brutal and unforgiving syntax. But, once you get it the
world opens up to you. It is essentially ldap-stuff.

Again, sorry for the two mistakes. I guess that I need to pay better
attention.

--
Cary W. Shultz
Roanoke, VA 24012
Microsoft Active Directory MVP

http://www.activedirectory-win2000.com
http://www.grouppolicy-win2000.com



"Peter Kaufman" <pmkdatabase_at_yahoo_dot_ca> wrote in message
news:f69eg1l33sqb00323s9rmrptihlmt4tm5r@xxxxxxxxxx
> For the archives, I think this is wrong (I am sure you will correct me
> if *I* am!).
>
>>Anyway, for the user account objects try something like this:
>>c:\>ldifde -i -f c:\users.ldf -s dc01.yourdomain.com -t 389 -d
>
> -i switch would *import* data into the production AD, would it not?
>
> Also, I think users is 805306368 not (sAMAccountType=805306369), which
> seems to be computers.
>
> Peter
>
>
> On Fri, 19 Aug 2005 06:37:11 -0400, "Cary Shultz [A.D. MVP]"
> <cwshultz@xxxxxxxx> wrote:
>
>>Peter,
>>
>>I would do a search in this NG for postings from me about five to eight
>>months ago. If you are using Outlook Express for your NG reader then this
>>should be easy to do.
>>
>>Anyway, for the user account objects try something like this:
>>
>>c:\>ldifde -i -f c:\users.ldf -s dc01.yourdomain.com -t 389 -d
>>"DC=yourdomain,DC=com" -r "(sAMAccountType=805306369)" -p subtree -l
>>"cn,sAMAccountName,objectClass,userAccountControl,displayName,givenName,sn"
>>
>>For the group objects try something like this:
>>
>>c:\>ldifde -i -f c:\groups.ldf -s dc01.yourdomain.com -t 389 -d
>>"DC=yourdomain,DC=com" -r objectClass=group)" -l "cn,groupType,member"
>>
>>Now, this is a very generic solution. Let's say, for example, that you
>>keep
>>all of your user account objects in an OU structure that looks like this:
>>
>>OU=Offices
>>
>> OU=Roanoke
>> OU=Richmond
>> OU=Blacksburg
>> OU=Raleigh
>>
>>
>>You search parameter for the user account objects could look like
>>his: -d
>>"OU=Offices,DC=yourdomain,DC=com" -p subtree. This might be a little bit
>>better.
>>
>>NOTE: if you use the -m switch, then you can not use -r
>>"(sAMAccountType=805306369)". You would have to go with the standard
>>filter
>>of -r "(&(objectCategory=person)(objectClass=user))".
>>
>>What does the -m switch do? It removed 'domain-specific information'.
>>Now,
>>what does that mean? Let's say that you have a mailbox size restriction.
>>One that you have created with a policy on the Exchange Server. I forget
>>the exact attributes but they are something like mbdefaultlimit,
>>mboverdefaultlimit and mbhardoverdefaultlimit ( going from memory
>>here.....something like this ). Each user account object that was subject
>>to this policy would have those attributes and the corresponding value.
>>Were you to use the -m switch then you would not see these attributes /
>>values since they are specific to that domain!
>>
>>So, this is what you would run on your production environment. Then,
>>recreate the environment on the test / lab server ( run dcpromo, et al ).
>>Then, simply run c:\>ldifde -f c:\users.ldf ( assuming that this is where
>>you have placed the .ldf file ). Next, run the c:\>ldifde -f c:\group.ldf
>>file.
>>
>>Just make sure that your OU structure is the same in your test environment
>>as in your producation environment. If it is not there will be a problem.
>>
>>Does that clear things up?
>>
>>Now, for a good into to ldifde and how to use it take a look at the
>>following:
>>
>>http://support.microsoft.com/?id=237677
>


.

Relevant Pages

  • Re: Export/import AD
    ... for the user account objects try something like this: ... For the group objects try something like this: ... this is what you would run on your production environment. ... > changetype: add ...
    (microsoft.public.win2000.active_directory)
  • Re: Export/import AD
    ... changetype: add ... >group objects from an existing domain and somehow 'import' them into another ... >without having to manually create each group object and user account objects ... >production environment is abc.com and your test environment is abc.local. ...
    (microsoft.public.win2000.active_directory)
  • Re: Export/import AD
    ... I really appreciate you and all the MVPs ... Since ldifde defaults to exporting you ... 368 is for user account objects ... this is what you would run on your production environment. ...
    (microsoft.public.win2000.active_directory)
  • Re: Export/import AD
    ... group objects from an existing domain and somehow 'import' them into another ... without having to manually create each group object and user account objects ... I would very much look at ldifde for this. ... production environment is abc.com and your test environment is abc.local. ...
    (microsoft.public.win2000.active_directory)
Loading