Export/import AD

Archived from groups: microsoft.public.win2000.active_directory (More info?)

For various reasons, I want to recreate, not rebuild, a domain Put
another way, replace the domain with another one of the same name,
which will contain the same users, groups, and eventually mailboxes
and mail.

Right now my concern is not with the workstations but AD and Exchange.
Will tools like csvde or ldifde allow me to import *just* users and
groups into the new domain - are they designed for different forests
like that?

Playing around with this on virtual machines I am not getting very
far, but would like to know if I am working in the right direction.

Thanks,

Peter
12 answers Last reply
More about export import
  1. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    There is ADMT. Google it you will find that you can copy Exchange and AD
    info across but it not going to allow the same domain name since dns will be
    needed. You could use a different name with the destination domain being
    w2k3 and once done rename the domain.

    --


    Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA

    This posting is provided "AS IS" with no warranties, and confers no rights.


    "Peter Kaufman" <pmkdatabase_at_yahoo_dot_ca> wrote in message
    news:5lj3g1tupl4ucibud1fr33ht7hqhnartq3@4ax.com...
    > For various reasons, I want to recreate, not rebuild, a domain Put
    > another way, replace the domain with another one of the same name,
    > which will contain the same users, groups, and eventually mailboxes
    > and mail.
    >
    > Right now my concern is not with the workstations but AD and Exchange.
    > Will tools like csvde or ldifde allow me to import *just* users and
    > groups into the new domain - are they designed for different forests
    > like that?
    >
    > Playing around with this on virtual machines I am not getting very
    > far, but would like to know if I am working in the right direction.
    >
    > Thanks,
    >
    > Peter
    >
  2. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Peter,

    I will take a different approach from the one that Paul is suggesting. And
    here is why ---- just to make sure that I am reading your post correctly.

    It sounds to me like you want to take all of the user account objects and
    group objects from an existing domain and somehow 'import' them into another
    domain. Most likely for testing purposes. In other words, you want to
    recreate your existing production environment into a testing environment
    without having to manually create each group object and user account objects
    et al.

    I would very much look at ldifde for this. It will do a very nice job.
    Have used it several times in production environments.

    All you would do would make sure that you specify the attributes that you
    want included in the .ldf file ( by using the -l switch ....and that is a
    lower case letter 'L' and not the number "1" ). Then, in your test domain
    simply recreate the OU structure ( assuming that you have created such a
    structure ) and then import that .ldf file. That would be your user account
    objects. I would then do the same for the groups objects.

    Now, the one caveat that you might need to consider ( well, there are
    several ) is if you are using different domain names. Say that your
    production environment is abc.com and your test environment is abc.local.
    Clearly there will be a problem when you try to import that .ldf file. So,
    to create this simply use the 'replace' function in Notepad and replace
    dc=abc, dc=com with dc=abc,dc=local. Then there should be no problems.

    Please notice that ldifde does not allow you to create a password.....well,
    not without a lot of trouble. So, you will be creating a bunch of user
    account objects in the test domain that do not have a password. Since you
    did not mention if this is in a WIN2000 or a WIN2003 environment you might
    have a problem with the creation of the user account objects. Simply
    disable the requirement for complex passwords - if that is indeed the
    problem - and you should be fine.

    HTH,

    --
    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:5lj3g1tupl4ucibud1fr33ht7hqhnartq3@4ax.com...
    > For various reasons, I want to recreate, not rebuild, a domain Put
    > another way, replace the domain with another one of the same name,
    > which will contain the same users, groups, and eventually mailboxes
    > and mail.
    >
    > Right now my concern is not with the workstations but AD and Exchange.
    > Will tools like csvde or ldifde allow me to import *just* users and
    > groups into the new domain - are they designed for different forests
    > like that?
    >
    > Playing around with this on virtual machines I am not getting very
    > far, but would like to know if I am working in the right direction.
    >
    > Thanks,
    >
    > Peter
    >
  3. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Paul,

    Thanks a lot. Can you rename a domain? How - dcpromo choosing that it
    is the last DC, demote the DC, then promote it again?

    Will Exchange survive that or do I do it before installing Exchange? I
    was thinking that I could just install Exchange in DR mode and then
    restore a store backup after AD was installed.

    Peter

    On Tue, 16 Aug 2005 06:59:54 -0500, "Paul Bergson"
    <pbergson@allete.com> wrote:

    >There is ADMT. Google it you will find that you can copy Exchange and AD
    >info across but it not going to allow the same domain name since dns will be
    >needed. You could use a different name with the destination domain being
    >w2k3 and once done rename the domain.
  4. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Hi Cary,

    I am trying that now. The system is W2K SP4+rollup and you do
    understand the situation correctly.

    My problem at the moment is figuring out what attributes to export in
    order to get just users and groups. I've tried using the -m switch as
    well as various filters on ldifde but can't get it.

    Even something as simple as this, run on dc1.local.pmci.net gives an
    error "A referral was returned from the server"

    <text file starts here>
    dn: DC=local,DC=pmci,DC=net
    changetype: add
    name: local

    dn: OU=No screen lock,DC=local,DC=pmci,DC=net
    changetype: add
    name: No screen lock

    dn: CN=(Ying) Chanram Sornsilp,OU=No screen
    lock,DC=local,DC=pmci,DC=net
    changetype: add
    name: (Ying) Chanram Sornsilp

    dn: OU=Staff,DC=local,DC=pmci,DC=net
    changetype: add
    name: Staff
    <text file ends here>

    Thanks a lot,

    Peter

    On Tue, 16 Aug 2005 14:14:53 -0400, "Cary Shultz [A.D. MVP]"
    <cwshultz@mvps.org> wrote:

    >Peter,
    >
    >I will take a different approach from the one that Paul is suggesting. And
    >here is why ---- just to make sure that I am reading your post correctly.
    >
    >It sounds to me like you want to take all of the user account objects and
    >group objects from an existing domain and somehow 'import' them into another
    >domain. Most likely for testing purposes. In other words, you want to
    >recreate your existing production environment into a testing environment
    >without having to manually create each group object and user account objects
    >et al.
    >
    >I would very much look at ldifde for this. It will do a very nice job.
    >Have used it several times in production environments.
    >
    >All you would do would make sure that you specify the attributes that you
    >want included in the .ldf file ( by using the -l switch ....and that is a
    >lower case letter 'L' and not the number "1" ). Then, in your test domain
    >simply recreate the OU structure ( assuming that you have created such a
    >structure ) and then import that .ldf file. That would be your user account
    >objects. I would then do the same for the groups objects.
    >
    >Now, the one caveat that you might need to consider ( well, there are
    >several ) is if you are using different domain names. Say that your
    >production environment is abc.com and your test environment is abc.local.
    >Clearly there will be a problem when you try to import that .ldf file. So,
    >to create this simply use the 'replace' function in Notepad and replace
    >dc=abc, dc=com with dc=abc,dc=local. Then there should be no problems.
    >
    >Please notice that ldifde does not allow you to create a password.....well,
    >not without a lot of trouble. So, you will be creating a bunch of user
    >account objects in the test domain that do not have a password. Since you
    >did not mention if this is in a WIN2000 or a WIN2003 environment you might
    >have a problem with the creation of the user account objects. Simply
    >disable the requirement for complex passwords - if that is indeed the
    >problem - and you should be fine.
    >
    >HTH,
    >
    >--
    >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:5lj3g1tupl4ucibud1fr33ht7hqhnartq3@4ax.com...
    >> For various reasons, I want to recreate, not rebuild, a domain Put
    >> another way, replace the domain with another one of the same name,
    >> which will contain the same users, groups, and eventually mailboxes
    >> and mail.
    >>
    >> Right now my concern is not with the workstations but AD and Exchange.
    >> Will tools like csvde or ldifde allow me to import *just* users and
    >> groups into the new domain - are they designed for different forests
    >> like that?
    >>
    >> Playing around with this on virtual machines I am not getting very
    >> far, but would like to know if I am working in the right direction.
    >>
    >> Thanks,
    >>
    >> Peter
    >>
    >
  5. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    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 this: -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


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

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


    "Peter K" <pmkdatabase_at_yahoo_dot_ca> wrote in message
    news:n1a8g1t9r2n1u47boopgtmsulkf2ar6ff5@4ax.com...
    > Hi Cary,
    >
    > I am trying that now. The system is W2K SP4+rollup and you do
    > understand the situation correctly.
    >
    > My problem at the moment is figuring out what attributes to export in
    > order to get just users and groups. I've tried using the -m switch as
    > well as various filters on ldifde but can't get it.
    >
    > Even something as simple as this, run on dc1.local.pmci.net gives an
    > error "A referral was returned from the server"
    >
    > <text file starts here>
    > dn: DC=local,DC=pmci,DC=net
    > changetype: add
    > name: local
    >
    > dn: OU=No screen lock,DC=local,DC=pmci,DC=net
    > changetype: add
    > name: No screen lock
    >
    > dn: CN=(Ying) Chanram Sornsilp,OU=No screen
    > lock,DC=local,DC=pmci,DC=net
    > changetype: add
    > name: (Ying) Chanram Sornsilp
    >
    > dn: OU=Staff,DC=local,DC=pmci,DC=net
    > changetype: add
    > name: Staff
    > <text file ends here>
    >
    > Thanks a lot,
    >
    > Peter
    >
    > On Tue, 16 Aug 2005 14:14:53 -0400, "Cary Shultz [A.D. MVP]"
    > <cwshultz@mvps.org> wrote:
    >
    >>Peter,
    >>
    >>I will take a different approach from the one that Paul is suggesting.
    >>And
    >>here is why ---- just to make sure that I am reading your post correctly.
    >>
    >>It sounds to me like you want to take all of the user account objects and
    >>group objects from an existing domain and somehow 'import' them into
    >>another
    >>domain. Most likely for testing purposes. In other words, you want to
    >>recreate your existing production environment into a testing environment
    >>without having to manually create each group object and user account
    >>objects
    >>et al.
    >>
    >>I would very much look at ldifde for this. It will do a very nice job.
    >>Have used it several times in production environments.
    >>
    >>All you would do would make sure that you specify the attributes that you
    >>want included in the .ldf file ( by using the -l switch ....and that is a
    >>lower case letter 'L' and not the number "1" ). Then, in your test domain
    >>simply recreate the OU structure ( assuming that you have created such a
    >>structure ) and then import that .ldf file. That would be your user
    >>account
    >>objects. I would then do the same for the groups objects.
    >>
    >>Now, the one caveat that you might need to consider ( well, there are
    >>several ) is if you are using different domain names. Say that your
    >>production environment is abc.com and your test environment is abc.local.
    >>Clearly there will be a problem when you try to import that .ldf file.
    >>So,
    >>to create this simply use the 'replace' function in Notepad and replace
    >>dc=abc, dc=com with dc=abc,dc=local. Then there should be no problems.
    >>
    >>Please notice that ldifde does not allow you to create a
    >>password.....well,
    >>not without a lot of trouble. So, you will be creating a bunch of user
    >>account objects in the test domain that do not have a password. Since you
    >>did not mention if this is in a WIN2000 or a WIN2003 environment you might
    >>have a problem with the creation of the user account objects. Simply
    >>disable the requirement for complex passwords - if that is indeed the
    >>problem - and you should be fine.
    >>
    >>HTH,
    >>
    >>--
    >>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:5lj3g1tupl4ucibud1fr33ht7hqhnartq3@4ax.com...
    >>> For various reasons, I want to recreate, not rebuild, a domain Put
    >>> another way, replace the domain with another one of the same name,
    >>> which will contain the same users, groups, and eventually mailboxes
    >>> and mail.
    >>>
    >>> Right now my concern is not with the workstations but AD and Exchange.
    >>> Will tools like csvde or ldifde allow me to import *just* users and
    >>> groups into the new domain - are they designed for different forests
    >>> like that?
    >>>
    >>> Playing around with this on virtual machines I am not getting very
    >>> far, but would like to know if I am working in the right direction.
    >>>
    >>> Thanks,
    >>>
    >>> Peter
    >>>
    >>
    >
  6. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Cary,

    Does it clear it up? I don't think I can answer that for a while yet,
    but it is a great start for sure. The main thing I need is to find is
    a detailed description of the AD attributes, but I will check your
    previous posts as suggested.

    Thanks very much. I appreciate your time and effort in responding.

    Peter

    On Fri, 19 Aug 2005 06:37:11 -0400, "Cary Shultz [A.D. MVP]"
    <cwshultz@mvps.org> 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 this: -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
  7. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    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@mvps.org> 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 this: -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
  8. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    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@4ax.com...
    > 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@mvps.org> 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
    >
  9. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Okay,

    If I could just now write English correctly! Sometimes I think that my
    brain is not in gear ( well, that is not true! 'Park' is a gear,
    technically speaking, correct? ).

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

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


    "Cary Shultz [A.D. MVP]" <cwshultz@mvps.org> wrote in message
    news:%23FY832epFHA.3256@TK2MSFTNGP12.phx.gbl...
    > 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@4ax.com...
    >> 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@mvps.org> 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
    >>>is: -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
    >>
    >
    >
  10. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Hi Cary,

    I hope you understand I did not mean to be critical, only to get the
    corrections into the thread. I really appreciate you and all the MVPs
    - I think that program is the smartest thing MS ever did!

    I also discovered that the group and OUs have to be imported first, or
    there will be errors importing any users in any custom groups or OUs.

    Thanks to your advice, a simple export/import worked, and I can see
    the possibilities of more sophisticated manipulations.

    Thanks again,

    Peter

    On Sat, 20 Aug 2005 21:14:31 -0400, "Cary Shultz [A.D. MVP]"
    <cwshultz@mvps.org> wrote:

    >Reply-To: "Cary Shultz [A.D. MVP]" <cwshultz@mvps.org>
    >From: "Cary Shultz [A.D. MVP]" <cwshultz@mvps.org>
    >References: <5lj3g1tupl4ucibud1fr33ht7hqhnartq3@4ax.com> <#gOWp5ooFHA.3256@TK2MSFTNGP12.phx.gbl> <n1a8g1t9r2n1u47boopgtmsulkf2ar6ff5@4ax.com> <uX#$7nKpFHA.3316@TK2MSFTNGP14.phx.gbl> <f69eg1l33sqb00323s9rmrptihlmt4tm5r@4ax.com>
    >Subject: Re: Export/import AD
    >Date: Sat, 20 Aug 2005 21:14:31 -0400
    >Lines: 119
    >Organization: NKD Solutions, Inc.
    >X-Priority: 3
    >X-MSMail-Priority: Normal
    >X-Newsreader: Microsoft Outlook Express 6.00.2900.2527
    >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
    >X-RFC2646: Format=Flowed; Original
    >Message-ID: <#FY832epFHA.3256@TK2MSFTNGP12.phx.gbl>
    >Newsgroups: microsoft.public.win2000.active_directory
    >NNTP-Posting-Host: 0-1pool120-42.nas98.washington1.dc.us.da.qwest.net 65.135.120.42
    >Path: TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
    >Xref: TK2MSFTNGP08.phx.gbl microsoft.public.win2000.active_directory:163316
    >
    >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@4ax.com...
    >> 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@mvps.org> 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
    >>
    >
  11. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Peter,

    No problem on the corrections. Those two errors ( well, one was a dumb
    error and the other was a typo ) need to be corrected and corrected quickly.

    You are correct: the groups and the OUs do need to first be created before
    you can do the import [ maybe using the "-i" switch? ;-) ]. The reason is
    that when you do the export there is something called the DN ( or
    distinguished name ). So, the user account object would have a DN of
    CN=Cary Shultz,OU=IT,OU=Offices,DC=mydomain,DC=com. This implies that there
    is a domain called mydomain.com and that there is a specific OU
    organizational structure ( namely, an OU called 'Offices' with sub-OUs, one
    of which is called 'IT' ). If this DN path does not exist ( or is spelled
    incorrectly! ) then there will be failure.

    You mentioned more sophisticated manipulations: try messing around with the
    Exchange stuff!

    There are simply tons of things that you can do with this tool. it is all
    really quite cool. It will also help you if you ever decide to get into
    scripting ( or that stuff will help you with ldifde if you are already into
    that ).

    --
    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:t4mgg11s3rlujjauj81t24s881m3ovf3vh@4ax.com...
    > Hi Cary,
    >
    > I hope you understand I did not mean to be critical, only to get the
    > corrections into the thread. I really appreciate you and all the MVPs
    > - I think that program is the smartest thing MS ever did!
    >
    > I also discovered that the group and OUs have to be imported first, or
    > there will be errors importing any users in any custom groups or OUs.
    >
    > Thanks to your advice, a simple export/import worked, and I can see
    > the possibilities of more sophisticated manipulations.
    >
    > Thanks again,
    >
    > Peter
    >
    > On Sat, 20 Aug 2005 21:14:31 -0400, "Cary Shultz [A.D. MVP]"
    > <cwshultz@mvps.org> wrote:
    >
    >>Reply-To: "Cary Shultz [A.D. MVP]" <cwshultz@mvps.org>
    >>From: "Cary Shultz [A.D. MVP]" <cwshultz@mvps.org>
    >>References: <5lj3g1tupl4ucibud1fr33ht7hqhnartq3@4ax.com>
    >><#gOWp5ooFHA.3256@TK2MSFTNGP12.phx.gbl>
    >><n1a8g1t9r2n1u47boopgtmsulkf2ar6ff5@4ax.com>
    >><uX#$7nKpFHA.3316@TK2MSFTNGP14.phx.gbl>
    >><f69eg1l33sqb00323s9rmrptihlmt4tm5r@4ax.com>
    >>Subject: Re: Export/import AD
    >>Date: Sat, 20 Aug 2005 21:14:31 -0400
    >>Lines: 119
    >>Organization: NKD Solutions, Inc.
    >>X-Priority: 3
    >>X-MSMail-Priority: Normal
    >>X-Newsreader: Microsoft Outlook Express 6.00.2900.2527
    >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
    >>X-RFC2646: Format=Flowed; Original
    >>Message-ID: <#FY832epFHA.3256@TK2MSFTNGP12.phx.gbl>
    >>Newsgroups: microsoft.public.win2000.active_directory
    >>NNTP-Posting-Host: 0-1pool120-42.nas98.washington1.dc.us.da.qwest.net
    >>65.135.120.42
    >>Path: TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
    >>Xref: TK2MSFTNGP08.phx.gbl
    >>microsoft.public.win2000.active_directory:163316
    >>
    >>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@4ax.com...
    >>> 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@mvps.org> 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
    >>>
    >>
    >
  12. Archived from groups: microsoft.public.win2000.active_directory (More info?)

    Gary,

    I wish I could retain 10% of the amount of knowledge you hold in your
    brain!

    I don't know if anyone is still monitoring this thread but way back
    when I came across a list of those samaccounttypes but can't find it
    anymore. Anyone know of the existence of one?

    Thanks,

    Peter

    On Sun, 21 Aug 2005 05:28:13 -0400, "Cary Shultz [A.D. MVP]"
    <cwshultz@mvps.org> wrote:

    >Okay,
    >
    >If I could just now write English correctly! Sometimes I think that my
    >brain is not in gear ( well, that is not true! 'Park' is a gear,
    >technically speaking, correct? ).
Ask a new question

Read More

Domain Active Directory Windows