Creating an active directory test lab environment from your production AD forest

Creating an active directory test lab environment from your production AD forest

From:http://www.msresource.net/paulw/creating_an_active_directory_test_lab_environment_from_your_production_ad_forest.html

The question of how can one create a copy of the existing production active directory environment for testing purposes is a frequent one in the forums and groups. There are several ways of doing this: backup/restore, cloning, attribute import/ export, etc. but the easiest and probably one of the cleanest ways of doing this is to introduce a new server into the production environment, shut it down and move it to the test lab and clean up the production environment and the test environment. In this post I’ll explain a nice approach to doing this. OK, so you’ve got a working, live active directory environment and you don’t have an adequate test lab. You wish to create a test lab that mimics the production environment, particularly in the area of OU, users, computers, groups and group policy. How does one go about implementing the test lab? Summarised, the steps are as follows:

Build a virtual server and promote this server to a domain controller in the production environment. This is your development DC.

On the development DC, install DNS and configure the DC as a GC, disable init-sync then shutdown the DC and transfer the virtual disk file(s) to your test lab environment.

Perform a “metadata cleanup” in the production environment to remove the development DC that has been powered off.

Cleanup DNS in the production environment to remove the development DC that has been powered off.

Boot the development DC in the lab environment and seize all operations master (OM), a.k.a. FSMO, roles.

On the development DC perform a “metadata cleanup” for all DCs other than this DC.

Cleanup DNS (basically delete _msdcs sub-domain and recreate) on the development DC.

The following sections discuss each bullet in a little more detail. I’m intentionally skipping the promotion and server build steps, assuming the reader is comfortable enough with this as if you’re not, you shouldn’t be performing this task. Where appropriate URLs or script examples are provided.

Pre-requisites

Before removing the newly promoted machine, ensure that the DNS service is installed and that the DC is pointing to itself for DNS (configured in the advanced TCP/IP properties, an IP address of 127.0.0.1 will avoid any issues with IP address changes). Also ensure that the DC is a Global Catalog (GC) server.

Note. In a single domain forest it isn’t essential to make the DC a GC. In a multi-domain forest it is essential this be done before the machine is removed. Failure to do so will result in the DC not holding enough forest-wide information.

This step assumes that you’re using AD-Integrated DNS. If this isn’t the case, the DNS service will need to be setup as a secondary server. Once the zone has replicated and loaded it is safe to move to the next section. The DNS setup will need to be tweaked once the machine has been brought online in the development environment. The DNS server will need to be made primary and the zone transfer properties un-configured. It makes sense to configure the zone as an AD-integrated zone even if the production isn’t using this setup.

Disable init-sync, a.k.a. Initial Synchronisation (Synchronization)

Once the server has become a domain controller (it’s rebooted and you’ve logged on and checked the event logs and replication status using REPLMON) you can power it off and transfer the virtual disk, and virtual machine settings file if you wish, to the lab environment. To speed up the boot process it is best to disable initial synchronisation (init-sync performs a replication of each of the objects that maintain the OM roles upon startup to ensure that there are no duplicate role holders). You disable init-sync via a registry value.

Key: 	HKLM\ System\ CurrentControlSet\ Services\ NTDS\ Parameters
Value: 	Repl Perform Initial Synchronizations
Type: 	REG_DWORD
Data:	0x0 (zero)

Once you’ve made this change shutdown the server and move the files to your lab environment.

Production Metadata, AD object and DNS cleanup

The development machine that has been shutdown still exists in the production active directory domain. We must perform the process known as metadata cleanup to remove the necessary NTDS and NTFRS objects in a supported manner. Once these objects have been removed the server object (child of the site container) and the computer object (child of OU=Domain Controllers, DC=domain-name, DC=com) need to be deleted and all DNS records pertaining to this server removed. This process is documented in some detail here as well as in the Microsoft KB. At this point your production environment is back to where it was before we started and we can now continue to setup the lab environment.

The links above cover the removal of the objects outside of the scope of the NTDSUTIL METADATA CLEANUP command, namely the computer and server objects and the DNS SRV, A, PTR and CNAME RRs.

Seize Operations Master, a.k.a. FSMO, Roles

In the development environment seize the two enterprise and three domain operations master roles to the development DC. You seize the roles using NTDSUTIL. The following is a CMD script that does this for you.

::
:: AD-Man-xferAllOMs.CMD
::  Paul Williams, msresource.net, February 2007
::
:: Version: 		 V01.00.00cmd
:: Written: 		 22/11/2006
:: Last updated: 	 22/11/2006
:: Last updated by:	 Paul Williams
::
:: Last update: Renamed to align with other scripts.
::

@echo off

SET APPNAME=xferAllOMs
SET APPVERSION=V01.00.00cmd
SET APPAUTHOR=Paul Williams (
paul@msresource.netThis e-mail address is being protected from spam bots, you need JavaScript enabled to view it
)
SET APPWRITTEN=Nov. 2006

echo/
echo %APPNAME% %APPVERSION% %APPAUTHOR% %APPWRITTEN%
echo/

if [%1]==[] (
goto :usage
) else (
if [%1]==[/?] (
goto :usage
)
ntdsutil "popups off" roles connections "connect to server %1" quit
"seize pdc" "seize rid master" "seize infrastructure master"
"seize schema master" "seize domain naming master" quit quit
echo/
echo/
netdom query fsmo
goto :Exit
)

:Usage
echo/
echo Usage:
echo/
echo   %APPNAME% ^

Note. The three lines starting with ntdsutil "popups off" are a single line with no line breaks. Line breaks have been added for layout and readability purposes.

Development Metadata, AD object and DNS cleanup

All domain controllers in the forest still exist in the active directory domain in your development environment and have to be removed. The process is exactly the same as that detailed in the previous section “Production Metadata, AD object and DNS cleanup” but will have to be performed multiple times –once for each DC that no longer exists in this development environment.

The DNS in the development forest doesn’t need to be removed in the same was as in the production forest. Because the bulk of the DCs have been removed it is quicker and easier to simply delete the _msdcs zone and recreate it. After recreating the zone recreate the delegation and, assuming that the DC points to self for DNS, restart NETLOGON. NETLOGON will re-register all appropriate SRV records in DNS. If there’s more than one DC in the development environment, restart NETLOGON on those machines too.

In addition to this, the Name Server (NS) records will also need to be removed from each hosted zone. Reverse lookup zones can be left the same or deleted and recreated. They’re not essential so aren’t an issue.

Other considerations

If you have a multiple domain forest and you wish to reproduce all domains in your development environment you’ll need to perform the above steps once per domain, i.e. promote, move and cleanup a new DC in each domain. If you do this, ensure you do not perform the metadata cleanup for the domain controllers that you are subsequently moving, e.g. don’t metadata cleanup all DCs except the one you’re working on if you plan on also introducing at least one other from each domain.

Furthermore do not remove the DCs from the production domain until all temporary DCs have been promoted, otherwise the temporary DCs will not exist in your development forest. In performing this task for multiple domains it makes sense to introduce the domains in hierarchical order, e.g. root, child, and grandchild. The order of promotion of the temporary DC is irrelevant. It’s the order in which you move from production and then “build” your development environment that is important.

If you do not wish to reproduce the full forest structure, e.g. you only require a subset of the domains in the development environment then you’ll also need to clean up the stale domains in the development environment. The aforementioned document also covers all necessary steps for performing these steps.

Note. The removal of domains, not domain controllers, only needs to be performed in the development forest and only needs to be performed if you chose to implement a forest with a subset of domains.