Save to My DOJO
With the responses to our article series on virtualized domain controllers, it seemed natural to tackle another related topic. Unfortunately, it’s a little too common for administrators to try to solve the physical vs. virtual dilemma by installing the domain controller role and the Hyper-V role in the same physical instance of Windows Server. This is not good practice for a number of reasons.
I try to avoid using “never” or “always” when it comes to the technology world, but this is one situation where I think it’s appropriate. There’s probably never a great reason to have your Hyper-V hosts also be domain controllers. If you must have a physical domain controller, use some other computer. If you’re concerned about virtual domain controllers, read our series (linked in the intro paragraph). Now, let’s explore why such dual-purpose machines are a bad idea:
1. Domain Security
There’s always a concern that someone might compromise your hypervisor. If that happens, the attacker gains control over your virtual machines. That’s bad. If your hypervisor is also your domain controller, that means the attacker now controls your entire domain as well. That’s really bad.
Next, you might be asking, “If the attacker has compromised the hypervisor, then does it make a difference whether the domain controller co-resides on the parent partition versus being a guest on that system?” The answer is, yes, it does matter. Compromising the hypervisor is bad, there’s no question. But it’s also a bit limited. Hypervisors are built around the idea of partition isolation and many of those rules apply to the hypervisor as well. So, compromising upward from the guest to the hypervisor does not immediately mean easy access into other guests. Could it be done? Of course. Has it been done? Not that anyone knows of. To go around speculating on it is to wander into FUD territory. If you’re concerned, put your domain controller on a separate, physical unit. What I would do is keep externally facing (think public web servers) on separate Hyper-V hosts from critical guests, such as domain controllers.
A simpler way to phrase this concern is that it increases the attack surface for both of these roles. If an attacker knows the name of your system and can target Hyper-V or domain services, s/he gets the other in the deal.
2. No Support from Microsoft — or Almost Anyone Else
Microsoft only supports a handful of roles alongside Hyper-V, and domain services isn’t one of them. Some people think, “Well, so what? I never call Microsoft PSS anyway.” That doesn’t matter. The people that you’re likely to ask help of probably do. If they don’t, the people they look to probably do. The point is, the real experts out there don’t do this. Because they don’t do this, they don’t know the answers to questions about it. If you run into a problem, the only people you’re going to be able to talk to on the subject are also people who went against the grain. The community at large will largely shrug at your questions and go on to something else. Who ya gonna call?
3. Performance Impacts
When domain services are installed, one of the first things they do at boot up is disable all disk write caches. ALL disk write caches. If your domain controller is also your hypervisor, that means that all your VMs will lose write cache capabilities. Hello, needlessly long I/O queues.
The other side is that the hypervisor is prone to sacrificing itself for the needs of its guests whenever there is contention. If your system isn’t heavily laden, that might not be a big deal. Otherwise, your domain services may not be as responsive as you’d like. One thing that the hypervisor is not always great about is cutting up memory. If another process is able to get its hands on some, it can reserve it indefinitely in a way that keeps Hyper-V from assigning it to guests. Processes of that kind typically take a chunk of whatever available memory is on the system. Since we’re talking about a system running a hypervisor, that’s probably quite a lot. Conversely, putting it in a virtual machine gives you direct control over the maximum amount of memory it can possibly consume. The largest domain I ever managed had about 400 users, and I was able to DM virtualized 2008 R2 domain controllers below 768 MB RAM during normal daily operations. Would it have done the same had I installed domain services directly in the management operating system of machines with 128 GB of RAM? I don’t know (see #2).
4. Zero Licensing Benefit
One reason I’ve heard is that people don’t want to buy another license to cover domain services running in the guest. Well, if you run any service in a Windows hypervisor that provides services beyond virtual machine operation and maintenance, the management operating system must be fully licensed, meaning that you forfeit one of your Windows Server guest virtualization rights just by enabling domain services. So whether you run domain services in the hypervisor or as a guest, the licensing requirement is identical.
5. System Hardening Becomes Questionable
When you make a computer into a domain controller, computer-level security ceases to exist. This has some far-reaching consequences that a lot of people don’t think about.
First, there is no longer a local security accounts manager (SAM) or related database. So, there’s no such thing as a local account. In the series on virtualizing domain controllers, I pointed out that if your domain is damaged, you could still log on locally. Well, if your hypervisor is also a domain controller, that’s no longer an option. The “Hyper-V Administrators” group is created on machines with the Hyper-V role installed, but what happens when you do this on a domain controller (I don’t know, see #2). What I do know is that if it is created, it’s not local. It can’t be, because there’s no SAM.
One thing that systems administrators have done since time immemorial for local security is to add regular domain accounts to the local administrators group. This way, you can allow someone to destroy their computer without wrecking the domain. If you’re in a somewhat higher security context, you can do the same thing with your own accounts. For example, I have my own personal domain account that is an admin on my desktop. I have another domain account with high privileges and permissions. I use secondary logon (AKA Run As) for domain management. Guess what? You can’t really make that distinction on a domain controller, because there is no SAM (am I repeating myself?)
Group Policy is also a big concern. All domain controllers must exist in the default Domain Controllers OU or your domain will have problems. That means that if you want to apply any policies to your DC/Hyper-V system, you must apply them on that OU.
6. Backup and Recovery Becomes Messy
Active Directory backups can be done by protecting the System State on a domain controller. This is pretty basic information. But, when you start installing other invasive, critical services, the face of System State changes. Importantly, you don’t have many options for backing up the System State in a granular manner. You cannot restore one without affecting everything else that participates in System State. What happens if you need to perform an authoritative restore of domain services to two weeks ago? How does that affect Hyper-V when it’s installed with domain services? I don’t know (see #2). Maybe you think you can avoid this problem by just restoring the specific Active Directory database files and skipping the larger System State. This might be true, but it’s certainly not the supported way. It’s also not worth the risk.
The other thing I dislike about this is that it now forces you to back up the management operating system (because backups are not optional). Normally, I only worry about backing up virtual machines, because I can reinstall Hyper-V from scratch and have virtual machines operational in no more time than it would take to run a bare metal restore. Since I’m the PowerShell type, I can save the initial configuration of a Hyper-V host in a quick little .PS1 file instead of a big backup file, and go from new install to ready-to-run in very short order. But, if I’ve got domain services on there, now I need to come up with a backup. If I were to create a backup of a Hyper-V host, I’d be looking for the schedule option named “Every now and again”, because hardly anything ever changes at that level that I really worry about. In practice, I just care about backing up the virtual machines and their related files. But, if I throw domain services on there, now I have to care about backing up the management operating system.
7. DC Portability is Gone
Hey, it’s time to retire this physical host. Let’s just use Shared Nothing Live Migration to flip the domain controller over to the new host!
Oh, wait. The host is the domain controller. Darn. Add a couple more hours to the migration for configuration and testing of domain services.
Summary
It may be tempting to answer the virtual vs. physical domain controller question by just making your Hyper-V host a domain controller. Please, don’t do it.
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!
More in this category
About the Author
Eric Siron
106 thoughts on "7 Reasons not to Make Hyper-V a Domain Controller"
Putting security aside I planned to run a secondary DC with the Hyper-V role as a DR site. I wouldn’t be expecting massive performance due to the circumstances and could be realistic with the number of VM’s running.
So then maybe you can explain this mentality, since I obviously don’t understand it. You could just as easily put your DC into a tiny VM and avoid all this. And yet, you’re actively choosing to expose yourself to all these problems and risks, with full knowledge that you won’t be able to get help if something goes wrong. Why would you do that? What is the secret good reason that eludes me as to why people take such unnecessary risks?
— It has been brought to my attention that this response comes across as being mean-spirited. I assure you it was not written with that intent. I genuinely do not understand this position. If anyone can make a case for it, it would be a benefit to the community. If you can convince me, you can probably convince anyone.
I agree with you on this. However, to clarify point number two, installing AD on a Hyper-V host is supported (but, specifically not recommended) on 2008 and 2008 R2 platforms. It is not supported on 2012 and 2012 R2 platforms.
Don’t forget that with 2012, you can have 2 VMs running on top of the host that are included as part of the license, so in effect there isnt even a cost saving by putting the DC role on the host! Just run up a VM and put it there as part of the process.
Great article by the way.
That’s what I was getting after in #4, but your clarification is helpful. Also, the guest licensing picked up at least as early as 2008 R2.
good article, could you provide more information about this hyper-v configuration backup script you mentioned ?
I’m sorry, I’m not sure which script you’re referencing. Can you tell me which mention you saw so I can point you in the right direction?
I think the script he was referring to (cause I am also wondering myself) is how you backed up your initial Hyper-V configuration to ps1 file instead of backuping up the operating system.
“ince I’m the PowerShell type, I can save the initial configuration of a Hyper-V host in a quick little .PS1 file instead of a big backup file, and go from new install to ready-to-run in very short order.”
How do you accomplish what you are describing here?
Ah, that’s a good question. I haven’t published that because I think the practice has fallen out of favor now that Desired State Configuration is with us.
Basically, I take all the steps that I took to build the host and I keep those in storage. If I ever rebuild that host, I just run the script again. So, something like:
$HostName = ‘svhv1’
$DomainName = ‘siron.int’
$OU = ‘whatever OU’
$MgmtIP = ‘192.168.25.10’
$MgmtGateway = ‘192.168.25.1’
$MgmtDNS = @(‘192.168.25.5’, ‘192.168.25.6’)
$ClusterIP = ‘192.168.10.10’
# etc.
$DomainCredential = { a stored script I have that retrieves an encrypted copy of my domain credentials }
Add-Computer -Credential $DomainCredential -DomainName $DomainName -OUPath $OU -NewName $HostName
Rename-NetAdapter -Name { I detect names } -NewName { what I want the new adapter name to be }
# run through all the adapters
New-NetIPAddress -IPAddress $MgmtIP -InterfaceAlias ‘Mgmt’ -DefaultGateway $MgmtGateway -PrefixLength 24
Set-DnsClientServerAddress -InterfaceAlias ‘Mgmt’ -ServerAddresses $MgmtDNS
New-VMSwitch …
Add-VMNetAdapter …
# set IPs for non-mgmt adapters
# clear DNS registration for non-mgmt adapters
So on and so forth. I know some people there have really done theirs up, but mine is not a complete script and it’s not 100% automated and I tinker with it all the time. And of course, DSC is probably more ideal but I didn’t see a good reason to throw out a system that works for me.
“When domain services are installed, one of the first things they do at boot up is disable all disk write caches. ALL disk write caches.”
That is quite incorrect.
1. Not all caches – only disk write cache and only on volumes hosting ad db/log files (system volume in a default setup).
2. Most server class HBA’s (all I know from HP and IBM for sure) do not allow to enable the write cache for any volume at all in the first place – so the whole problem is purely theoretical as there is nothing do disable any more these days.
“DC Portability is Gone”
Thats not a big problem – as AD DC role is relatively (!) easy to migrate to another host. (in short: promote, move fsmo roles, demote, readdress, rename)
To make it clear: I do not recommend to put DC on HV but I do advise to make design decisions based on pros and cons of both solutions. For example in single host/server scenario, one can:
– put DC on the bare metal (with HV)
– put DC in a VM, and leave the VM host in the workgroup (do not join domain)
None of the above is the ideal solution….
Regards,
Pawel Mazurkiewicz
1a) I did say that it was only writes 🙂
1b) I’ll need to check on it disabling only specific volumes, as it wasn’t the impression that I got. But remember that most people aren’t using a lot of fancy hardware, especially the people that are likely to do something like combine AD and Hyper-V. If the database and logs are on the same physical or array logical disk but have just been partitioned, then the write cache disable will still impact them. Also, if a DC and Hyper-V are installed with defaults on the same system, then the AD DB and logs are on the same volume as the Hyper-V guests.
2) Not to split hairs, but are you looking in the right place? In the systems I use, the HBA isn’t what determines caching capabilities — it’s not where I go to set it, anyway. The EMC systems I work with do support write caching, as do a great many commodity RAID controllers, such as the Dell PERC series.
We know that it’s not just a theoretical problem because of all the domain controllers that were damaged when Hyper-V wasn’t properly processing the write cache disable request. If write caching hadn’t been functioning on the back end, people wouldn’t have seen that sort of data loss.
I understand what you mean about domain services being fairly easy to move, but the point was that the domain controller itself has no portability. In terms of domain services portability, compare the process you describe against Live Migrating a DC from one system to another. I’m sure you also know that the process of domain services migration always goes more smoothly on paper than it does on the system. I realize that it’s not a deal-breaker situation, but I don’t understand what anyone gains by willingly accepting this burden when a superior alternative exists.
I also understand what you mean about making design decisions using pros and cons. The purpose of this article was one-sided, and I tried to be clear about that. There aren’t many cases where I think one side’s cumulative arguments more or less shut out any opposition, but this is one of those times. None of these 7 items is a perfect argument on its own, but I have yet to see any reasoning that properly counters all 7. What I’ve always wanted someone to explain to me is: What do you actually get out of making the same system a DC and run Hyper-V?
“When domain services are installed, one of the first things they do at boot up is disable all disk write caches. ALL disk write caches.”
That is quite incorrect.
1. Not all caches – only disk write cache and only on volumes hosting ad db/log files (system volume in a default setup).
2. Most server class HBA’s (all I know from HP and IBM for sure) do not allow to enable the write cache for any volume at all in the first place – so the whole problem is purely theoretical as there is nothing do disable any more these days.
“DC Portability is Gone”
Thats not a big problem – as AD DC role is relatively (!) easy to migrate to another host. (in short: promote, move fsmo roles, demote, readdress, rename)
To make it clear: I do not recommend to put DC on HV but I do advise to make design decisions based on pros and cons of both solutions. For example in single host/server scenario, one can:
– put DC on the bare metal (with HV)
– put DC in a VM, and leave the VM host in the workgroup (do not join domain)
None of the above is the ideal solution….
Regards,
Pawel Mazurkiewicz
I want to install Hyper-v an run DC on VM is this recommended?
What would be the best practice?
1. To add the Hyper-V host to domain and log in as DC administrator or as local admin?
2. Should I leave Hyper v host in workgroup?
3. if DC is installed would be best to run put the VHD on DataPartition which is RAID 10?
Thanks in advance
Running a DC inside a VM is allowable. There is no general recommendation except that you not install the DC role on the management operating system. Whether or not it’s recommended depends on your overall environment.
The best practice is to add the Hyper-V host to the domain, add a domain account that is not a domain admin to its local administrators, and use that. You should not ever be logging in anywhere as a domain admin unless you need to do domain administration.
Put the VHD anywhere you want. Just make sure it’s secured and backed up.
This comment pretty much answers all my concerns. I was questioning how right it was not to have my hyper-v host on the domain but it seemed silly to add it to the domain with it hosting the domain controller in a VM.
I want to install Hyper-v an run DC on VM is this recommended?
What would be the best practice?
1. To add the Hyper-V host to domain and log in as DC administrator or as local admin?
2. Should I leave Hyper v host in workgroup?
3. if DC is installed would be best to run put the VHD on DataPartition which is RAID 10?
Thanks in advance
Running a DC inside a VM is allowable. There is no general recommendation except that you not install the DC role on the management operating system. Whether or not it’s recommended depends on your overall environment.
The best practice is to add the Hyper-V host to the domain, add a domain account that is not a domain admin to its local administrators, and use that. You should not ever be logging in anywhere as a domain admin unless you need to do domain administration.
Put the VHD anywhere you want. Just make sure it’s secured and backed up.
Hi Eric,
thanks for the Article! Very well explained.
I’ve a question about a Virtualized DC: I had a debate with a consultant about an installation of Hyper V with Win Srv 2012 R2 Std.
The consultant said that you could put the DC in a VM, and put the Hyper V host in Active Directory as Server Member (not DC), but this could cause a strange situation, when the Hyper V server start and it does not find his DC (because the VM is not started yet).
Do you think this can create some trouble?
I am absolutely certain that everything will be fine. http://www.altaro.com/hyper-v/demystifying-virtualized-domain-controllers-part-1-myths/
Any domain-joined computer can start without a domain controller being present. Just like any other computer, the only time you’d encounter a problem is if you’re trying to access a resource on a different machine that requires active security arbitration. An SMB 3 share would be a good example. Hyper-V is not domain-dependent in any fashion because it is a Type 1 hypervisor. Anything in the management operating system that works with local resources using domain accounts will operate just fine using cached credentials. Local credentials (like the LocalSystem account, which VMMS runs as) are always available. This is based on facts that have been true since Active Directory was introduced with Windows 2000 Server and are based on things that were true in Windows NT. Your consultant is wrong, and I would not rely on him or her in any situation where the topic is Windows authentication.
That is however not allways correct – unfortunately.
SOFS – won’t start without a DC – trust me – been there.
So if you Hyper-V uses SOFS or SMB3 for storage on a domain joined machine – you have no storage – and cannot start the DC if it is living on the same storage.
In what way is what I said not always correct? I specifically pointed out that SMB shares would have a problem. That’s not an excuse to make the Hyper-V host a domain controller. At most, it’s why you should have at least one domain controller that isn’t on SMB storage. If your DC is on internal storage or an iSCSI/fibre LUN and set to auto start, then the Hyper-V host will automatically start up all the guests living on SMB as soon as it is able to authenticate.
Sorry. didn’t mean to imply what you said was incorrect – I merely wanted to warn others about missing DC when using SMB storage. You are really fucked, sitting there with your large setup – and it just won’t start nothing.
Most people have secondary DC’s – but – in case even your routing is virtual – that wont start either…
DC’s are important for SMB3 – don’t go there with DCs virtualized on SMB3. Have a spare one somewhere else – anywhere else than on SMB3.
Just a friendly warning… Two whom it may be apropriate.
If you allready wrote that, I might have read it too fast, sorry, then let me repeat it… I agree totally that DC’s don’t belong anywhere else than in a VM – just not all on SMB DON’T.
Ah, fair enough.
On a SOFS, you might be completely out of luck, but I tend to be of the opinion that there’s always a way. I haven’t got the spare hardware to really try it thoroughly, though. For a standalone SMB system, you can log in locally using cached credentials and salvage the VM that way. If nothing else, you make it a Hyper-V host and have it load the DC VM from local storage.
But yes, you’re absolutely right, all DCs on SMB 3 storage will eventually result in a painful catastrophe.
Hi Eric,
thanks for the Article! Very well explained.
I’ve a question about a Virtualized DC: I had a debate with a consultant about an installation of Hyper V with Win Srv 2012 R2 Std.
The consultant said that you could put the DC in a VM, and put the Hyper V host in Active Directory as Server Member (not DC), but this could cause a strange situation, when the Hyper V server start and it does not find his DC (because the VM is not started yet).
Do you think this can create some trouble?
I am absolutely certain that everything will be fine. https://www.altaro.com/hyper-v/demystifying-virtualized-domain-controllers-part-1-myths/
Any domain-joined computer can start without a domain controller being present. Just like any other computer, the only time you’d encounter a problem is if you’re trying to access a resource on a different machine that requires active security arbitration. An SMB 3 share would be a good example. Hyper-V is not domain-dependent in any fashion because it is a Type 1 hypervisor. Anything in the management operating system that works with local resources using domain accounts will operate just fine using cached credentials. Local credentials (like the LocalSystem account, which VMMS runs as) are always available. This is based on facts that have been true since Active Directory was introduced with Windows 2000 Server and are based on things that were true in Windows NT. Your consultant is wrong, and I would not rely on him or her in any situation where the topic is Windows authentication.
That is however not allways correct – unfortunately.
SOFS – won’t start without a DC – trust me – been there.
So if you Hyper-V uses SOFS or SMB3 for storage on a domain joined machine – you have no storage – and cannot start the DC if it is living on the same storage.
Hello. I know this article is a bit old but I notice that there is a recent reply. Now I fully understand the whole article and the response as to why this is not recommended. What I would like to ask is this.
I have one physical computer, lets say with the following specs (16GB mem/8TB HD/3.0 Ghz x2/Dual Gigabit NIC). I would like to use this 1 physical server to make 3 servers (the physical and 2 virtual) running your standard network applications (AD, DNS, DHCP, File Share, Print Server, Web Server, E-mail Server). I would then like to have say 20 workstations interact with these 3 servers. How would I get such a configuration going if I cannot install the DC function on the physical computer? How will I create a domain that all 3 servers and that the workstations would be a part of?
I hope I have explained the scenario clearly enough to get a proper reply.
Thanks.
You make a virtual machine specifically to host domain services. 1 ADDS/DHCP/DNS, 1 file/print, 1 web, 1 e-mail. Two WS2012R2STD licenses covers the whole thing.
Hello. I know this article is a bit old but I notice that there is a recent reply. Now I fully understand the whole article and the response as to why this is not recommended. What I would like to ask is this.
I have one physical computer, lets say with the following specs (16GB mem/8TB HD/3.0 Ghz x2/Dual Gigabit NIC). I would like to use this 1 physical server to make 3 servers (the physical and 2 virtual) running your standard network applications (AD, DNS, DHCP, File Share, Print Server, Web Server, E-mail Server). I would then like to have say 20 workstations interact with these 3 servers. How would I get such a configuration going if I cannot install the DC function on the physical computer? How will I create a domain that all 3 servers and that the workstations would be a part of?
I hope I have explained the scenario clearly enough to get a proper reply.
Thanks.
Thanks for the quick reply Eric, but maybe I don’t understand your reply but I don’t think I got my answer. How would you use one machine to create the network. Would you install an OS on the physical that would serve no other purpose but to run the VM and which would not be part of the domain? Or it would be part of the domain but not performing as a DC and create a VM that would be the DC. Thank, just trying to clarify how the physical computer gets used and included in the domain
I would install Hyper-V. I would create a VM and install domain services, DNS, DHCP, etc. I would join the Hyper-V system to the domain. I would then create all the other VMs.
Much appreciated. Just wanted to be sure my thinking was along the lines of the experts.
Is there any point in joining the Hyper-V host to the domain if it is only going to be running Hyper-V? If your domain controller is virtual. After you join the domain and reboot the physical hyper V host, the DC won’t be online and you won’t be able to login?
I’m was planning to set it up like this.
1 Hyper V Physical host
1 virtual ADDS, DHCP, DNS and File share
1 virtual RDP services
Then I was planning to get a second Hyper V host to do the failover replication if the budget permits and so I don’t need a secondary DC.
Sound like it isn’t a great idea hosting the file share on the domain controller? What would your advice be in this case? The storage are just local disks attach to the physical host. Should I just offline them and mount them into Hyper V instance?
The point of joining the domain is the same as for any other system: superior security and greatly eased management. You’ll be able to login just fine. Local credentials will always work if all else fails.
It’s not a wonderful solution to put file services on the domain controller but you definitely don’t want to create a share on the virtualization host directly. If you do that, you need another Windows license so you might as well just stand up a dedicated file server VM.
If you set up a second host for replication, you still have to license all the replica VMs. Might as well just put a second DC on it and only replicate the RDS system.
If it were me, I’d spring for the additional Windows Server license and have a dedicated file/print server VM.
How about using the hyper-v host as a BACKUP domain controller? Will this work and are there any benefits to have a second DC while the virtual primary DC has still not started?
There is no such thing as a backup domain controller. There are only domain controllers. There are certainly benefits to multiple DCs but not enough to justify the damage to a Hyper-V management operating system. If having another DC would make you feel better, find another physical unit.
I saw your article after creating my domain.
Actually I’m using a server 2012 as a domain controller on the host directly. I don’t use hyper-v yet.
I have a second server that I still need to setup that I would use as a backup if main server fails.
If I wanted to make it right on the main server and set this up as hyper-v host and have the domain controller in a VM. What would be the steps to take.
I also use the server as a file server, should i make this a separate vm or it is ok to leave it with the DC.
I’m not new to servers but new to virtualization.
Fortunately, your path is actually quite clear.
I saw your article after creating my domain.
Actually I’m using a server 2012 as a domain controller on the host directly. I don’t use hyper-v yet.
I have a second server that I still need to setup that I would use as a backup if main server fails.
If I wanted to make it right on the main server and set this up as hyper-v host and have the domain controller in a VM. What would be the steps to take.
I also use the server as a file server, should i make this a separate vm or it is ok to leave it with the DC.
I’m not new to servers but new to virtualization.
1. It is really encouraging to see how responsive you are with your commenters; thank you.
I have seen you mention a number of times that DCs should never be moved out of the Domain Controllers OU. Point taken, I am sufficiently frightened, and will never ever do that. However, I am wondering about applying different policies to certain DCs, and if it is okay to have nested OUs _within_ the Domain Controllers OU? Or is it pretty much leave-it-as-one-single-OU-w/-all-the-DCs and leave-them-alone-or-else? 😉
That is a great question, and one that I do not know the answer to. I moved a DC out of the root “Domain Controllers” OU once and brought down the Exchange environment and that was the end of my experimentation. Because of the way that LDAP heirarchy works, my suspicion is that moving a domain controller into a sub-OU would mostly have the same effect as moving it to another root folder. I would not do it.
If you’re looking to selectively apply group policies, I think a better solution would be WMI filtering: https://technet.microsoft.com/en-us/library/cc779036(v=ws.10).aspx.
I haven’t tested this, but I think that something like this will do the trick: rootcimv2;select * from win32_computersystem where name=”EXPECTED-DCs-SHORT-NAME”
Test your query first with PowerShell: gwmi -computername ‘EXPECTED-DCs-SHORT-NAME’ -query ‘select * from win32_computersystem where name=”EXPECTED-DCs-SHORT-NAME”‘
If it doesn’t return anything, then the computer that the query was run against will not apply the GPO. If it does return something, the computer that the query was run against will apply the GPO.
Plan B would be to modify apply permissions on the GPO. I prefer the WMI route but permissions are better than tinkering with OUs.
1. It is really encouraging to see how responsive you are with your commenters; thank you.
I have seen you mention a number of times that DCs should never be moved out of the Domain Controllers OU. Point taken, I am sufficiently frightened, and will never ever do that. However, I am wondering about applying different policies to certain DCs, and if it is okay to have nested OUs _within_ the Domain Controllers OU? Or is it pretty much leave-it-as-one-single-OU-w/-all-the-DCs and leave-them-alone-or-else? 😉
That is a great question, and one that I do not know the answer to. I moved a DC out of the root “Domain Controllers” OU once and brought down the Exchange environment and that was the end of my experimentation. Because of the way that LDAP heirarchy works, my suspicion is that moving a domain controller into a sub-OU would mostly have the same effect as moving it to another root folder. I would not do it.
If you’re looking to selectively apply group policies, I think a better solution would be WMI filtering: https://technet.microsoft.com/en-us/library/cc779036(v=ws.10).aspx.
I haven’t tested this, but I think that something like this will do the trick: rootcimv2;select * from win32_computersystem where name=”EXPECTED-DCs-SHORT-NAME”
Test your query first with PowerShell: gwmi -computername ‘EXPECTED-DCs-SHORT-NAME’ -query ‘select * from win32_computersystem where name=”EXPECTED-DCs-SHORT-NAME”‘
If it doesn’t return anything, then the computer that the query was run against will not apply the GPO. If it does return something, the computer that the query was run against will apply the GPO.
Plan B would be to modify apply permissions on the GPO. I prefer the WMI route but permissions are better than tinkering with OUs.
Hello Eric.
I found really usefull your article and all the help that you give to the people here.
We have an old physical W2003 server that do ad/dns/dc and something else (that run only on W2003).
We bought a new server that I want to configure as HyperV host, with W2012R2.
I need to virtualize W2003 server because it runs a program that won’t work on recent Windows Server versions.
I will join the new server W2012R2 to the actual domain as first thing, than I will configure something (account, hyperv…) and then I will try to virtualize W2003 and put on it.
In that way I will have DC ( AD, DNS) as a VM on the new HyperV W2012R2 host.
What do you think about all that things? Do you have any suggestions for me?
Thank you very much
(sorry for bad english)
I think about another solution.
Make a new W2012 VM on the new server W2012R2, create a DC and do all the necessary things to do a new DC connected with the old one on W2003 physical server.
Virtualize the W2003 server and put on the new server.
Remove DC from the W2003 vm and leave the only one on the VM W2012.
So I will have 1 new physical server with W2012R2 as hyper-v host.
1 VM with W2003 and that app that runs only on W2003.
1 VM with W2012R2 that do DC, AD, DNS….
Is that a better solution?
I like that because we will have a new W2012 as DC and because the machine with DC/dns etc… will be separated from the one that have other apps.
Thanks!
I don’t know that I’m following everything that you say. But if the 2003 is a DC then yes, the best process is to make another DC and not p2v any existing ones.
Sounds like it’s your best chance. Just expect some problems with the w2k3 p2v.
Hello Eric.
I found really usefull your article and all the help that you give to the people here.
We have an old physical W2003 server that do ad/dns/dc and something else (that run only on W2003).
We bought a new server that I want to configure as HyperV host, with W2012R2.
I need to virtualize W2003 server because it runs a program that won’t work on recent Windows Server versions.
I will join the new server W2012R2 to the actual domain as first thing, than I will configure something (account, hyperv…) and then I will try to virtualize W2003 and put on it.
In that way I will have DC ( AD, DNS) as a VM on the new HyperV W2012R2 host.
What do you think about all that things? Do you have any suggestions for me?
Thank you very much
(sorry for bad english)
I think about another solution.
Make a new W2012 VM on the new server W2012R2, create a DC and do all the necessary things to do a new DC connected with the old one on W2003 physical server.
Virtualize the W2003 server and put on the new server.
Remove DC from the W2003 vm and leave the only one on the VM W2012.
So I will have 1 new physical server with W2012R2 as hyper-v host.
1 VM with W2003 and that app that runs only on W2003.
1 VM with W2012R2 that do DC, AD, DNS….
Is that a better solution?
I like that because we will have a new W2012 as DC and because the machine with DC/dns etc… will be separated from the one that have other apps.
Thanks!
Thanks Eric.
I think I will implement the second idea.
ciao!
Thanks Eric.
I think I will implement the second idea.
ciao!
Eric,
I was getting ready to promote a 2012 Hyper V Host to a DC to deal with an issue I am having, but after reading your article I am questioning myself. I am wondering if you have seen the following issue in a single server environment before.
Single server running 4 VM’s. My issue is that because the domain controller doesn’t come up fast enough the Network Location Awareness Service doesn’t recognize that the servers are talking to the domain network and therefor sets the network type as “Public” which causes firewall rules blocking File and Print access, etc. I have set the NLA service to delay start, delayed the other VM at startup etc, but it doesn’t seem to help. If I restart the NLA service on each of the VM’s after everything has finished loading it will then see that it is on the domain and switch to the appropriate profile. I was beginning to think this might be a common issue for single server environments, and my solution was going to be to promote the physical server to a DC, but now I am not so sure.
I’ve heard of the issue, yes. I don’t know how widespread it is. My network has multiple servers, but I do perform a full power cycle on the entire environment from time to time, so I should be equally susceptible to it. It’s never happened to me.
It’s surprising that a combination of delaying the start of the other guests and setting NLA to delayed start isn’t doing the trick. Domain services, especially in a small network, should not require that much time to start. I would check to see if the DC is having some troubles. I would also verify that there isn’t some routing issue that’s confusing the guests into thinking that they have multiple pathways to the domain controller or that the domain controller is not available even when it is. For one thing, do not allow the guests to refer to anything other than your internal DNS server. If you set the secondary on a non-DNS server to a public DNS server’s IP, it will introduce a substantial delay before that computer can realize that the domain is available.
Another thing that you can do is force NLA to default to private mode rather than public. I don’t love the idea and it won’t be as wide-open as domain, but it won’t be nearly as restrictive as public and it also won’t have as negative of an impact as making your Hyper-V host into a DC. Here’s an article that explains how: http://evansblog.thebarrs.info/2013/02/windows-server-force-your-network.html.
Eric,
I was getting ready to promote a 2012 Hyper V Host to a DC to deal with an issue I am having, but after reading your article I am questioning myself. I am wondering if you have seen the following issue in a single server environment before.
Single server running 4 VM’s. My issue is that because the domain controller doesn’t come up fast enough the Network Location Awareness Service doesn’t recognize that the servers are talking to the domain network and therefor sets the network type as “Public” which causes firewall rules blocking File and Print access, etc. I have set the NLA service to delay start, delayed the other VM at startup etc, but it doesn’t seem to help. If I restart the NLA service on each of the VM’s after everything has finished loading it will then see that it is on the domain and switch to the appropriate profile. I was beginning to think this might be a common issue for single server environments, and my solution was going to be to promote the physical server to a DC, but now I am not so sure.
If you are such a small setup, that you do not have hardware for a separate DC, why join the Hyper-V server to a domain in the first place, if you do that you have to back it up etc etc. The domain only reall becomes useful if you want to replicate or run cluster protection of the VM’s
If you want to cluster your Hyper-V’s then you have access to, at least entry level SAN/NAS hardware and should then have access to at least a cheap entry level (HP Micro) server for your AD…
Splitting hair is what will convince you that your MD is right when he denies you budget for X…
You join it to the domain because you are a responsible employee that cares about security and not wasting your employer-paid time on pointless micromanagement tasks. If you already have a domain controller, then the fiscal cost to join your Hyper-V host to the domain is precisely $0, so I don’t follow the logic behind your money argument. If your environment is such that maintaining a gaggle of workgroup hosts is less effort than managing them in a domain, then there are at least a few things that have gone very, very wrong in your environment. Not sure why you tied domain membership to a backup requirement. That is not where the line is drawn.
If you are such a small setup, that you do not have hardware for a separate DC, why join the Hyper-V server to a domain in the first place, if you do that you have to back it up etc etc. The domain only reall becomes useful if you want to replicate or run cluster protection of the VM’s
If you want to cluster your Hyper-V’s then you have access to, at least entry level SAN/NAS hardware and should then have access to at least a cheap entry level (HP Micro) server for your AD…
Splitting hair is what will convince you that your MD is right when he denies you budget for X…
One reason that begins the kill chain for this entire article was ostensibly left out.
Cost. It’s the number one reason thousands of savvy people are doing this. There are even complete command driven walk through articles all over the interwebs.
Being in IT since the 90’s I can tell you one thing. Want to motivate people? Tell them they can’t do something.
HyperV Core edition costs zero dollars. Therefore, the remaining arguments must commit to killing themselves.
Inserting rhetoric in 3, 2, 1…
It’s not possible to turn “HyperV Core edition”[sic] into a domain controller regardless of your motivation levels. It’s also not possible to save a penny on licensing costs by turning a Windows Server with Hyper-V system into a domain controller, as everyone who read the article picked up on. I’ve never met a legitimate business owner willing to accept the risk of a multi-thousand dollar fine over a few dollars on a Windows Server license. And if you don’t have the confidence in your argument to use your real name, you should probably be aware that Steve Case was in the business before the 90s. Just something that you might want to be aware of if you expect this juvenile trolling to work somewhere else.
you need to review shielded VM and encryption feature in Windows. When you host in Azure it will be a virtual machine, therefore. MS moving towards virtualized DC.
This articles holds true for DC before 2012 R2 but not anymore
I think you misread the title and did not read the article at all. Virtualized DCs are fine. Making a physical Hyper-V host into a domain controller is always wrong in all circumstances.
I have a sense of humor. Hahaha! Making your Hyper-V host a domain controller is a bad idea!
What if I made my Hyper-V host a domain controller just to be funny?
Making your Hyper-V host a domain controller is worse than installing IIS on a domain controller.
It’s not recommended to install any additional software or server roles on a domain controller, and Exchange Server is no exception.