Read Only Domain Controller for standalone/off-site testing location

Solution 1:

Active Directory functions by default in a multimaster replication mode, where each domain controller is independently authoritative for the domain(s) it manages. Thus, the test DCs will still be able to handle logins and receive updates (password changes and the like) even while disconnected. The two sets of DCs (the live ones and the ones in the test site) will slowly diverge over time, but that's only a problem if you intend to converge them afterwards.

Here is my suggestion for handling this scenario:

1. Take a full system state backup of each testing domain controller before relocating them.
2. Relocate the test DCs and get them settled in (join the workstations to the domain, create users, etc.).
3. Run your tests.
4. When you're ready to restore the DCs to production service, do a non-authoritative restore of the system state backups you took earlier. This will reset the DCs to their previous system state (of course).
5. Return the test DCs to their original network and power them back on. They'll recognize that their copies of the Active Directory data are woefully out of date (due to the ancient USNs), and start sending replication requests to the production DCs that have been there the whole time.

Solution 2:

As this is for testing only have you considered running a VM on one of the machines and setting that up as a DC? Something like Virtualbox, despite not being a good choice for production use, would do fine in this case.

Solution 3:

1) When a standard DC is isolated from other DCs in the domain, it will continue to perform all of its functions, because every AD DC is able to work on its own; you'll only run into problems if you need access to one of the FSMO roles (such as performing a schema extension or running out of RIDs for new users), but this only happens in some very specific situations you're not likely to run into in a test environment. Of course, if you perform any modification to AD on one of the two segments (such as creating a user account or even changing a password), this will not be replicated to the other one... and if you ever plan about reconnecting them, you'll very likely run into replication conflicts.

This doesn't apply to RODCs: if one of them is isolated from the rest of the network and you don't have any writable DC available (even through a WAN link), most AD functions will be unavailable; you will not be able to create/modify anything, and this of course includes joining computers to the domain, managing user accounts ang groups, etc.

2) AD cares about IP addresses for two things: replicating data and locating the "nearest" available domain controller to avoid unnecessary WAN traffic; both functions rely on the definition of sites, subnets and site links. If you want to setup a WAN link to a location with a different IP addressing than your main LAN and put a DC there, you will need to define a site and a subnet in the Active Directory Sites and Services console; this will allow AD to manage replication between the DCs in the main location and the off-site one, and also will tell servers and clients in that location to talk to the local DC.

Solution 4:

Here's what I would propose:

Set up an isolated network on the current ESXi host. Clone the existing servers needed for the test and bring them up on the isolated network. If need be, you can sieze the FSMO roles on the isolated DC, as it's isolated from the production network this won't have any ramifications for the production network. Join a test client to the isolated domain and perform your testing.

This seems like the easiest solution to me.

Solution 5:

One issue you absolutely must consider when moving a DC to offline (as far as the production network is concerned) is that if it is off the production network longer than the tombstone time, it may contain objects that have been removed from the production network (known as lingering objects) and there can be consistency problems when it is reconnected to the production network. I've experienced such problems and it wasn't pretty.

It doesn't have to be problematic if you just take care of a couple issues in the process. If the domain was originally Windows 2000 and upgraded to 2003, the tombstone age is 60 days where if it started out as a Windows 2003 domain, tombstone age is 180 days. You can change the tombstone age, but this requires going in with ADSIedit or other tool to directly modify the Directory Service partition of Active Directory and I don't know if you would be comfortable with that or not. (the path is: CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=yourdomainsuffix) This will make Active Directory take up more space on your DCs since they will hold on to all removed objects longer before actually completely deleting them.

Before disconnecting the off site DC you should be sure to do a time sync to minimize any time drift while it is off site. The important part is when reconnecting, you should first configure strict replication consistency on the production network DCs prior to reintroducing the off site DC (using the Repadm tool with the /regkey switch) and be sure to set the off site DC up for a nonauthoritative restore, also prior to the reconnection, so it will get the new SYSVOL replicated to it as soon as possible.