Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I originally asked this question on stack overflow and was referred here.

Using Hyper-V I built a private windows domain which is fenced off from our main network. Ultimately I want to provision this domain for others to use for dev and test, so they can be domain admin.

My problem is this: the domain controller has the DHCP service running. If someone deploys the domain to their Hyper-V host and mistakenly connects it to the main network, the DHCP service will start assigning bad IP configurations.

I would like to prevent this situation. I considered writing a service to wrap dhcploc, this service would then stop the local DHCP service if a remote DHCP server can be found. This is really damage limitation, since the rogue DHCP server would still have a small window of opportunity.

Is there is a better/simpler alternative that would acheive the objective? Are there any caveats I should be aware of?


share|improve this question
Why do you have DHCP enabled? – Izzy Jul 9 '09 at 15:51
We have a client/server product, and want to be able to test for and repro any bugs that may stem from clients with dynamically assigned addresses. At the moment, our DHCP tests are quite isolated. I expect that if the whole team uses DHCP we will flush out more bugs. Furthermore, DHCP can be configured to statically assign addresses to certain MACs. My server components have known MACS, so when you deploy the images (DC, Exchange, SQL etc) everything works with zero user configuration. – Alex Peck Jul 9 '09 at 16:31
up vote 1 down vote accepted

Given that your test DHCP config uses MAC addresses to assign regular IPs you can limit the scope to include only the known MAC addresses. This way, even if someone puts it on the main network accidentally, it won't hand out any IPs because none of the requests match any of the MACs in its scope. As far as potential problems of putting a test DC on your main network it depends on a couple of things:

1) Hopefully you are using a separate subnet for the test network than the main network. Ex. test net = and main net = This will limit the test DCs access to stuff on the main network as long as it can't get to a router that is aware of both subnets and is set to route between them. 2) How was the test DC created? If it was attached to the main network first to grab AD data via replication and then removed and put in the test environment, it would still know about the other DCs on the main network and try to replicate to/from them once it came up. This is very bad for obvious reasons...If it was created within the test environment and has a unique domain name separate from the main domain name, then you are good to go.

What I meant by "larger problems" is that if people are putting DCs on the main network accidentally then someone should be giving them some training on using Hyper-V rather than trying to limit the damage in case they do! I'd be very nervous if I had DEV people playing with DCs (test or not) around my production network...Could you have their Hyper-V workstations separated even more on a different subnet altogether from the main network?

share|improve this answer
That's excellent, thanks. The MAC address restriction sounds like the way to go. The DC was created seperately and uses a distinct domain name and subnet, so I think we are pretty safe. All the users are proficient engineers, but I wanted to safeguard against accidents wherever possible. – Alex Peck Jul 9 '09 at 17:38
We do something similar: the (Microsoft) DHCP server has a configured scope; there's an exclusion that covers the entire scope; then we have reservations so that specific MAC addresses get specific IP addresses. – Roger Lipscombe Sep 16 '09 at 14:34

When you say "fenced off", what exactly do you mean?

If you have two DHCP servers on the same subnet, then you'll have some requests going to one DHCP server and some going to the other and, of course, conflicts if both servers are giving IPs from the same pool.

For the situation you described, I would create a routed subnet for your "fenced off" server and use a VLAN to isolate the subnet or you could use another cheap switch for a more physical separation.

Your Windows DHCP server can be multi-homed (connected to two or more networks). With two network cards, you cable one card into your production network and cable the other card into a separate network switch or separate VLAN allowing one server to act as a DHCP server for both networks. Or, per your original question, you would not need to do this if you want to continue to operate two DHCP servers.

Then on the fenced off switch or VLAN, you create a subnet that is different than your production network. For example:

Production Switch/VLAN: Development Switch/VLAN:

Production DHCP Server may use a scope of - Development DHCP Server may use a scope of -

In the Production DHCP scope, you could hand out a static route to Development and on the Development DHCP scope, you could hand out a static route to Production....

You may need some routing between the two if, for example, your Development area needs Internet access and the Internet is accessible only via Production network.

share|improve this answer
Thanks for the input. By fenced off, I mean that in Hyper-V the domain is connected to a virtual network with either a private or internal binding. By connecting to the main network, I mean changing the binding to the host's physical NIC. I expect that we will deploy 10-30+ test domains running on Hyper-V workstations. Neither I, nor the eventual users, are able to alter the configuration of the production network. From your description, it sounds as though if the private domain uses a subnet that is definately not used in production, then there can be no conflict. Is that correct? – Alex Peck Jul 9 '09 at 16:15
+1. a separate VLAN id running through the network is perfect for that. Totally logically isolates the traffic, so it does not easily interfere with each other. Then if needed install a router to route between them. – TomTom Jan 10 '13 at 15:50

Easiest thing to do is not have DHCP at all. Is the private virtual domain so large that you can't manage the IP addresses using static IPs? Secondly, you have larger problems if people are connecting DCs to your main network that are supposed to be for testing only. I haven't used Hyper-V yet, but in VMWare at least you can assign pretty granular permissions that would prevent a user from attaching the VM to a different network or changing it's network config.

share|improve this answer
Unfortunately we have a dependency on DHCP. Devs/testers will deploy the domain to their own workstations with the Hyper-V role, so they can pretty much connect anything to anything. At the risk of highjacking my own question, what might happen if the DCs are connected to the main network? – Alex Peck Jul 9 '09 at 16:22

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.