we want to take the active directory data from the current active directory domain and import it in our test environment

we have an active directory directory implementation organized into an OU hierarchy. for testing of some applications we want to just export all users, groups and ou hierarchy and then import it into a new domain that will also be on the producation network. this new domain will only be used for testing and will ultimately me removed after testing. so i need if possible a complete procedure of exporting the current users, groups and OU hierarchy. install a new active directry domain and then import it in the new domain without effecting the existing active directory infrastructure.

i have an idea of what needs to be done, i will mention it here, need some docs to do it and also if i am missing out on someting.
 install a new active directory domain and install dns also on the domain new domain controller.
use csvde to export the current active directory to a file.
modify the file to reflect the new domain name
imort the modified csvde file.

appreciate if i can get hold of a document of doing it and anything more i need to do

Who is Participating?
martin_babarikConnect With a Mentor Commented:

actually you don't need to do anything more, you described this procedure verey well.

Now just the question is, if you want to "migrate" or "make a copy" of your existing domain structure. I mean - if you use the procedure you described, the newly imported object will be identic with the originals just "visually", they will not have anything common with the original objects regarding security (different SIDs).

So you can use csvde dc=mydomain,dc=com -scope subtree -f outputfile.csv to export the objects and then you can maybe delete some unneccessary columns in the csv file (and of course change the domain name).
But there might be a problem that you can import only to existing OUs. I don't think CSVDE will take care of the correct order (first export OU structure, then users in it, then import the OU structure, then users in it). So maybe it will be better to do it step by step. Export top level OUs, import them, etc etc...
Mal OsborneConnect With a Mentor Alpha GeekCommented:
You could either:
1. Backup the current DC, then restore it to another box.  Keep the two on differant networks. Possibly for development & testing purposes it would be best to virualise it. Some virtualisation software includes tools to move the HDD contents into a virtual image.

2. Add new machine to the network as a DC & GC.  Disconnect it then, on the old network run a Metadata cleanup to get rid of any traces, and seize all roles on the new one. http://technet.microsoft.com/en-us/library/cc736378.aspx
mgmohiuddinAuthor Commented:
Thanks for your reply. i was just going through some docs and i want the users to be organized exactly as they are in the original domain. there are too many ou's and multiple levels. so according to what you suggested i should export the OU's first, import them then import users. i will really appreciate if you could help me with a doc or command so that i could test it. i know computers cannot be migrated. creating trunt is not an option for using ADMT. we dont want to tough the production domain, all we could do is run the csvde or ldifde to export info. so i should export ou first, then inport ou's. export users, import users, export groups, import groups. some help needed. to be sure. i will do it in my VM's first and then try. so i have to export  AD once and import it in parts or export multiple times and import them accordingly.
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Actually the comments from the other guys here are very senseful. I'd say this is the easiest way to achieve your goal.

Just install some VM machine, give it access to the network, promote that machine to a DC and then wait for the AD to be completely replicated to your VM. Also make sure you install DNS server on this VM and in the TCPIP properties define the IP address of the DNS server to point to some of your real DNS servers.
Make sure the VM is Global Catalog (AD Sites and Services console, sites / site name / servers / servername / open properties of NTDS Settings object).

Then cut off the connection (just to isolate it from your real production network), change the IP address of the DNS server to point to itself and seize all roles to this VM.
Here's the procedure for seizure:

After this you should have an exact copy od your real AD domain. Just to get rid of some possible errors you could remove the real DC object from your virtual domain by using ntdsutil, see here:

I just emphasize that everything after enabling Global catalog is supposed to be done in the virtual environment - thus isolated from the production network having no possibility to do any harm.
Maybe one exception:
In your real network you can also delete the DC object (the one which has been moved to virtual network) using the procedure described by the second link (ntsutil metadata cleanup).

Is this ok for you? It's much less work to do than playing with exports/imports.

mgmohiuddinAuthor Commented:
well i dont want a new dc account to be added and the delete it from the domain. i have to go through a lot of approvals before i could modify the AD. its a big environment and i cant modify anything and i am sure i wont get this approved.
I understand. But in this scenario you can use the procedure described above - just make a backup of some DC and resore it to your virtual machine - absolutelly no modification of anything in AD.
What do you think about it?
mgmohiuddinAuthor Commented:
two domains with the same netbios name on the same network is going to have name conflicts right. one production and then the test domain exactly with the same domain name is definitely an issue. we need to have a different domain name as the test domain will also be in the same network for a while
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.