Best Practices - DC in Hyper-V Environment.
-
Hyper-V has matured into a robust and reliable HyperVisor and I have been using it reliably since the first iteration. With 2012 R2 the feature set makes it a no brainier when compared to ESX on purely cost basis.
Back to the original question regarding having a DC on the same box as the Hyper-V Hyper-visor and having it attached to the domain.
Two ways I can say I would set this up.
First way if I had access to only one Bare Metal box would be to leave the Hyper-V server off the domain and run it stand alone. This would remove the requirement of having the DC online before you login to the Hyper-V server and control functions.
Second way if I DID have access to another physical box would be to add a second domain controller as a second VM on a Second Hyper-V box. This way you almost always have a DC online to run creds against so you can attached the Hyper-V server to the domain.
Third way I have seen this setup is to have a completely separate domain for just the Hyper-V servers. I have only seen this in very large datacenter deployments so I don't really think this applies.
-
@GregoryHall My thought was the 2nd way as well - thank you!
edit: we do have two hyper-v servers, just not enough guts in them to think about HA
-
@GregoryHall said:
First way if I had access to only one Bare Metal box would be to leave the Hyper-V server off the domain and run it stand alone. This would remove the requirement of having the DC online before you login to the Hyper-V server and control functions.
You do have do a decent amount of messing with permissions and firewall rules to get RSAT to work with a non-domain hyper-v server. This is the one major component missing is remote tools for standalone hyper-v servers.
-
@MattSpeller said:
@GregoryHall My thought was the 2nd way as well - thank you!
edit: we do have two hyper-v servers, just not enough guts in them to think about HA
AD DCs do HA on their own, nothing related to HyperV level HA. If you do HyperV HA, you have to make sure that you keep the DCs separate from that as that will potentially break their application level failover.
-
NTG is in the process of moving all workloads off of VMware. Not for specific reasons, but it works out that way. Our own platforms will be HyperV and XenServer only.
Our lab will still have some VMware, but only because of CloudatCost being on it.
-
@scottalanmiller said:
@MattSpeller said:
@GregoryHall My thought was the 2nd way as well - thank you!
edit: we do have two hyper-v servers, just not enough guts in them to think about HA
AD DCs do HA on their own, nothing related to HyperV level HA. If you do HyperV HA, you have to make sure that you keep the DCs separate from that as that will potentially break their application level failover.
Yeah just put a DC on each host and you should be good assuming the storage is separate it's as redundant as a physical server.
-
@thecreativeone91 said:
@scottalanmiller said:
@MattSpeller said:
@GregoryHall My thought was the 2nd way as well - thank you!
edit: we do have two hyper-v servers, just not enough guts in them to think about HA
AD DCs do HA on their own, nothing related to HyperV level HA. If you do HyperV HA, you have to make sure that you keep the DCs separate from that as that will potentially break their application level failover.
Yeah just put a DC on each host and you should be good assuming the storage is separate it's as redundant as a physical server.
With the added benefits of virtualization too. So even better than the second host being physical.
-
@thecreativeone91 said:
@thanksajdotcom said:
@scottalanmiller said:
@thecreativeone91 said:
ESXi isn't free with all feature. ESXi does have a free version but the essentials license are $560/year if you want updates which is for three servers (with a max of 2 cpu's per server).
HyperV isn't free with all the features either. But with more than ESXi. I think blocking the backup API was SO foolish on VMware's part. It made their free version never make sense. Either XenServer or HyperV is always a better choice.
I get what you mean but you can back up the machines, just not at the block level. While this is a limiter, for someone who uses it in a very small business or even at home, this isn't really an issue. I use my UEB to back up at the file level. It's not as efficient and recovery times are slower, but it works.
Traditional Backups don't understand Virtulization They also may not be hardware/platform independent. You also can't do snapshots inside of the OS.
Exactly. That's what I said.
-
@thecreativeone91 said:
I do the DC's (including the one with the PDC emulator) as VM's. I don't usually put the VM host in the domain but, with hyper-v you pretty much have to. If you have more than one host and DC's and each host it's not a big deal. if you only have one host you really need to look into putting a second DC somewhere even if it's physical.
This makes absolutely zero sense.
Hyper-V Server is designed to be joined to the domain and as has been pointed out a pain in the ass to manage if it is not.
It does not matter if your only DC (or both) is on the host and fails to come up,
You can ALWAYS log in locally with the domain account and cached Kerberos credentials or if those are expired, you can STILL log in with the local account setup when the Hyper-V server was initially installed.
Basically, there is never a reason NOT to join the Hyper-V servers to the domain.
-
@JaredBusch said:
This makes absolutely zero sense.
Maybe to you. But most people don't domain join the VM host (espcially if it's not Hyper-v) as both me @scottalanmiller and @GregoryHall said you really want to make sure Domain is redundant if you join the vm host.
If you are running the full server with hyper-v role you can RDP into it to manage no problem without a domain, If you have the hyper-v only server there are just a few powershell commands needed to enable management without a domain via RTAS. There's also free third party tools that can be run remotely or directly on the server.
Best option is still to put a second DC on @MattSpeller 's second VM host.
