Sign in with
Sign up | Sign in
Your question

Export/import AD

Last response: in Windows 2000/NT
Share
Anonymous
August 16, 2005 10:44:18 PM

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

More about : export import

Anonymous
August 16, 2005 10:44:19 PM

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
>
Anonymous
August 16, 2005 10:44:19 PM

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
>
Related resources
Anonymous
August 16, 2005 11:46:23 PM

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.
Anonymous
August 18, 2005 5:31:10 PM

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
>>
>
Anonymous
August 19, 2005 10:37:11 AM

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
>>>
>>
>
Anonymous
August 20, 2005 5:49:48 PM

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
Anonymous
August 20, 2005 11:46:34 PM

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
Anonymous
August 21, 2005 1:14:31 AM

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
>
Anonymous
August 21, 2005 9:28:13 AM

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
>>
>
>
Anonymous
August 21, 2005 10:01:07 PM

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
>>
>
Anonymous
August 21, 2005 10:06:16 PM

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
>>>
>>
>
Anonymous
August 30, 2005 10:37:56 PM

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? ).
!