Export/import AD

  • Thread starter Thread starter Peter Kaufman
  • Start date Start date
P

Peter Kaufman

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
 
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.
 
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
 
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
 
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
 
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
 
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
 
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
Click to expand...

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

Reply-To: "Cary Shultz [A.D. MVP]" <[email protected]>
From: "Cary Shultz [A.D. MVP]" <[email protected]>
References: <[email protected]> <#[email protected]> <[email protected]> <uX#[email protected]> <[email protected]>
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: <#[email protected]>
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 said:
For the archives, I think this is wrong (I am sure you will correct me
if *I* am!).


-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
Click to expand...
Click to expand...
 
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 said:
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

Reply-To: "Cary Shultz [A.D. MVP]" <[email protected]>
From: "Cary Shultz [A.D. MVP]" <[email protected]>
References: <[email protected]>
<#[email protected]>
<[email protected]>
<uX#[email protected]>
<[email protected]>
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: <#[email protected]>
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 said:
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]"

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
Click to expand...
Click to expand...
Click to expand...
 
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
 
Back
Top