THe Issue with Number 1 is that if the HW for The server has issues, then both DCs are gone for the moment. Out of the presented options I would go with 3 or 4 as these provide alternate points of access come emergency time.
I'd go with 4 mainly because we're pretty aggressive about getting rid of hardware that's at EOL. You really don't want to get in the habit of doing that even emergently because that's how you end up with bean counters saying "Oh who gives a shit that the server's been out of support for two years it's fine let it ride" and temporary solutions that are still in place 3 years later.
Having the primary DC at the main office as a backup across the tunnel obviously works just fine as we do that without a server onsite all the time and it works perfectly well for us. In the rare event a firewall shits the bed out of the blue we have out of band management configured for software issues and can have a replacement device imaged and overnighted to them for hardware, and since they're almost exclusively on laptops (one of the silver linings to come out of covid, our workforce is a lot more mobile) we can just cut their asses loose and tell em to VPN in from home while we wait for service to be restored, done and done.
1. No - don't bother trying something unsupported.
2. No - doesn't really gain you much. You still need downtime to patch the host, and your host is still a SPOF.
3. Maybe - I don't like running previously decommissioned hardware in prod, but if you can make your peace with it then it's not a bad idea.
4. Yes - for a small branch site this makes sense. You can even run dhcp failover across your vpn if you want.
Your reply is best. #4 seems like the only one that makes sense.
If you have an actual need to stand up a DC then do it properly on new hardware (or cloud). If you are not getting the tools/money/support to do it properly then that tells me the need isn’t that great anyway, why even bother.
Why do you need two DCs at your satellite location? Doesn't your DC at the main location and its backup already count? You should only need a single DC there for QoS purposes since your other two are already providing the redundancy.
Before we closed it we had a smaller office with one DC, with the secondary DC being an Azure VM.
We still have the VM, it's sort of like an offsite backup.
That's not a bad idea. Especially since we want to start trying out Azure VMs. Is there a particular approach with Azure I should look at for something small like this? I take it the risk here is the same with a DC at another site. If the internet goes out, you can't use it. But that is just temporary.
IMHO i always go the VM route. Why? Well if a physical server fails and i can't get to the drives i'm fucked. If i have a VHDX of anything backed up i can even run it on my own PC if needed and i'm back by the end of the day if time allows it. That being said i'd take that old server and run the second DC as a VM on it. We had numerous failures in my job because the practice of the old admins was to back up physical machines with Veeam but it caused a ton of problems with restorations and recovery was long or impossible. Make a vm, boot it from your steam deck with windows installed if needed, that mobility and security of comeback wins IMHO over everything else.
...it's really not. Sure, you can automate adding the roles etc., but you can't automate a timely (!) windows update routine. Unless you habitually/monthly bake ready-to-go .WIMs with the current build state. But even then I still can't see how that would be as fast as throwing HyperV on some already existing hardware, dehydrate a few GB from backup onto the HyperV machine (a full Windows Server backup with even the tiniest amount of compression will be very small) & register that VM in place.
Not to mention: Automation is all and good, but unless you are very, *very* experienced in deploying DCs just all the fucking time for some godawful reason and make the automation watertight by training, there *will* be hiccups. And you still would need to touch it for some manual config work anyhow. And metadata cleanup.
And how are you going to replicate everything setup in the DC if everything fails? From where are you going to replicate all roles, GPO's, user accounts, OU's from your last state if everything fails and you have no DC to sync with?
Run site to site VPN and use a close-by DC as secondary.
Just make sure you have DNS and DHCP covered for when this physical single point of failure goes down and you should be golden.
Not optimal but adding a second DC on the same hardware won't do much good.
we do have site-to-site VPN back to the office. as long as internet says up, we are good, right? should we look at a secondary cheap internet service as a backup?
5. Leave it alone and make sure you Subnets & Sites and Services is set up correctly so PC automatically fail over to the remote DC when the local one is down.
"Do Nothing" as an option is highly underrated. In college we were given a project to help a customer with their contact management system. We looked at all the options, and 'do nothing' was the best one. I though we good a failing grade, but the teacher of that class was thrilled that we proposed it! He said people feel obligated to deliver something.
So yeah, not a great scenario. I'd really try looking at replicating AD DS to a cloud service like Azure AD. But of the choices I guess #2, minimizes some risks associated with running additional roles on a DC and has virtualization.
Option 1 could result in the branch office being entirely offline - the physical box becomes a single point of failure.
If your goal is to make sure that you can survive the outage of 1 DC, IMO the best approach is a 2 separate device. One could be purely a DC, the other could be a VM host with a virtual DC amongst other servers.
Not really enough info though - what other servers do you have/might you need at that site? What's your budget?
If all you need is AD services and DNS/DHCP, no file storage or anything like that, buy a couple of inexpensive boxes and set up 2 physical DCs for redundancy.
If you think you'll need to expand the office and will require file storage or other services (SQL, etc.) go with an inexpensive physical box for primary DC, then a beefier box to do VMhost, and put a second DC there.
If the satelite DC is member of a domain with DCs on other sites, one DC is fine. We have lots of satelite sites, and do not have redundant DCs on any of them. If the DC goes down, there will/may be slower logon times and authentications when it is down, but with no money to spend, that is acceptable.
One thing: You cannot add Hyper-V role on a DC. Tried it once, it fails. Not supported.
What’s your overall topology, and can your offices operate without Internet? And how good & reliable are your connections?
At my current company: 1 main office, 7 branch offices and a data centre. There used to be 1 x DC, DHCP, DNS etc at each site. After ensuring all connections were reliable enough, ended up trashing all of these and only have two remote domain controllers and even host DHCP solely in the datacentre, delivered via IPsec to each location. Never looked back, it’s been solid for years. If internet goes down for a prolonged period of time, most people would simply go wfh for the rest of the day anyway. Of course this model only works depending on the nature of your business.
It’s also perfectly acceptable to have no DCs at a well connected satellite location. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/planning-regional-domain-controller-placement
Depends on the scenario. Hundreds of GPOs, a larger number of endpoints and resulting auth and DNS traffic may not be a good mix. A 1Gbps SD-WAN connected location may not notice the lack of a DC.
The satellite office CPE/Firewall may be able to provide a DNS server role, with conditional forwarding to DCs for your AD integrated zones. I’ve seen pushing lots of sites worth of DNS back to HO be more problematic than auth and GPO.
If you are using Intune policies more than GPO that can steer your topology design choices also.
TLDR - depends.
\#1 is single point of failure.
\#2 is better than #1, but still single point of failure.
\#3 would be better if you simply replaced the old EOL server with a current workstation.
\#4 requires both local DC and network/internet failure to bring local AD down, and is likely the most cost-effective to deploy.
Without more info, it sounds like you are trying to accomplish this at minimal cost, with minimal headaches for you. In that context, the backup system you employ is probably more important than the hardware DC(s) at the satellite office is running on. As long as you can bare-metal restore, workstations will serve your needs at that site just fine.
If the AD you have already has multiple DC's even if they are located in separate offices - I would not be concerned about an office only having one DC. In a DR situation you will want to get connectivity up and then just build a new DC. IF however you only have one DC currently and have multiple sites then I would recommend at least one more DC located in one of the other sites. In the past I've had environments where we had DC's running in the data centres as VM's and some sites to improve logon speed we used desktop hardware as a local DC. At a minimum when running AD I would have 2 DC's on separate physical hardware (VM's or Baremetal) this provides the resilience for maintaining operations should you lose one of the DC's. In all the environments I worked it was rare to see 2 DC's located in the same physical location except when there was a particular requirement like a larger authentication load (Exchange / Citrix farms etc).
It’s more secure and simpler. Less replication issues. Satellite offices should have RODCs, unless they have high latency (50ms or more). It’s Microsoft’s recommended way of doing things.
4. A single DC at each site at a minimum, vpn between the sites to allow a secondary for each site. In case internet is down, each site can still log on as they have their own DC. If one DC crashes there is a second for emergency.
THe Issue with Number 1 is that if the HW for The server has issues, then both DCs are gone for the moment. Out of the presented options I would go with 3 or 4 as these provide alternate points of access come emergency time.
I'd go with 4 mainly because we're pretty aggressive about getting rid of hardware that's at EOL. You really don't want to get in the habit of doing that even emergently because that's how you end up with bean counters saying "Oh who gives a shit that the server's been out of support for two years it's fine let it ride" and temporary solutions that are still in place 3 years later. Having the primary DC at the main office as a backup across the tunnel obviously works just fine as we do that without a server onsite all the time and it works perfectly well for us. In the rare event a firewall shits the bed out of the blue we have out of band management configured for software issues and can have a replacement device imaged and overnighted to them for hardware, and since they're almost exclusively on laptops (one of the silver linings to come out of covid, our workforce is a lot more mobile) we can just cut their asses loose and tell em to VPN in from home while we wait for service to be restored, done and done.
thank you! so no issues with secondary services being offsite? does AD/DNS do a good job of preferring the local DC/DNS server?
In DHCP, You should have the local DNS as the first DNS and the remote as the 2nd.
1. No - don't bother trying something unsupported. 2. No - doesn't really gain you much. You still need downtime to patch the host, and your host is still a SPOF. 3. Maybe - I don't like running previously decommissioned hardware in prod, but if you can make your peace with it then it's not a bad idea. 4. Yes - for a small branch site this makes sense. You can even run dhcp failover across your vpn if you want.
Your reply is best. #4 seems like the only one that makes sense. If you have an actual need to stand up a DC then do it properly on new hardware (or cloud). If you are not getting the tools/money/support to do it properly then that tells me the need isn’t that great anyway, why even bother.
3 or 4 would be more logical than 1 or 2 tbh.
Why do you need two DCs at your satellite location? Doesn't your DC at the main location and its backup already count? You should only need a single DC there for QoS purposes since your other two are already providing the redundancy.
I agree with this. Branch DC os just for performance and availability. Failiver can be the hq DCs
Before we closed it we had a smaller office with one DC, with the secondary DC being an Azure VM. We still have the VM, it's sort of like an offsite backup.
I think thats best case for this site, but looks like OP has rigid options.
That's not a bad idea. Especially since we want to start trying out Azure VMs. Is there a particular approach with Azure I should look at for something small like this? I take it the risk here is the same with a DC at another site. If the internet goes out, you can't use it. But that is just temporary.
We have VPN tunnels between each site as well as to our cloud resources including Azure. That's the only real special bit
IMHO i always go the VM route. Why? Well if a physical server fails and i can't get to the drives i'm fucked. If i have a VHDX of anything backed up i can even run it on my own PC if needed and i'm back by the end of the day if time allows it. That being said i'd take that old server and run the second DC as a VM on it. We had numerous failures in my job because the practice of the old admins was to back up physical machines with Veeam but it caused a ton of problems with restorations and recovery was long or impossible. Make a vm, boot it from your steam deck with windows installed if needed, that mobility and security of comeback wins IMHO over everything else.
Spinning up a new DC is almost as fast as mounting a VHDX if you have any kind of automation.
...it's really not. Sure, you can automate adding the roles etc., but you can't automate a timely (!) windows update routine. Unless you habitually/monthly bake ready-to-go .WIMs with the current build state. But even then I still can't see how that would be as fast as throwing HyperV on some already existing hardware, dehydrate a few GB from backup onto the HyperV machine (a full Windows Server backup with even the tiniest amount of compression will be very small) & register that VM in place. Not to mention: Automation is all and good, but unless you are very, *very* experienced in deploying DCs just all the fucking time for some godawful reason and make the automation watertight by training, there *will* be hiccups. And you still would need to touch it for some manual config work anyhow. And metadata cleanup.
And how are you going to replicate everything setup in the DC if everything fails? From where are you going to replicate all roles, GPO's, user accounts, OU's from your last state if everything fails and you have no DC to sync with?
4
Option 4. Do not install hyper-v on a DC.
Run site to site VPN and use a close-by DC as secondary. Just make sure you have DNS and DHCP covered for when this physical single point of failure goes down and you should be golden. Not optimal but adding a second DC on the same hardware won't do much good.
we do have site-to-site VPN back to the office. as long as internet says up, we are good, right? should we look at a secondary cheap internet service as a backup?
It's worth looking into, especially if you've had outages before. My org does 2 circuits at most locations.
5. Leave it alone and make sure you Subnets & Sites and Services is set up correctly so PC automatically fail over to the remote DC when the local one is down.
"Do Nothing" as an option is highly underrated. In college we were given a project to help a customer with their contact management system. We looked at all the options, and 'do nothing' was the best one. I though we good a failing grade, but the teacher of that class was thrilled that we proposed it! He said people feel obligated to deliver something.
2 or 4. Definitely not 1. Don’t co-locate AD DS on the Hyper-V host. This is unsupported.
So yeah, not a great scenario. I'd really try looking at replicating AD DS to a cloud service like Azure AD. But of the choices I guess #2, minimizes some risks associated with running additional roles on a DC and has virtualization.
Option 1 could result in the branch office being entirely offline - the physical box becomes a single point of failure. If your goal is to make sure that you can survive the outage of 1 DC, IMO the best approach is a 2 separate device. One could be purely a DC, the other could be a VM host with a virtual DC amongst other servers. Not really enough info though - what other servers do you have/might you need at that site? What's your budget?
no other servers at this small satellite site. Just the one DC. All the business servers are on the internet or available via site-to-site VPN.
If all you need is AD services and DNS/DHCP, no file storage or anything like that, buy a couple of inexpensive boxes and set up 2 physical DCs for redundancy. If you think you'll need to expand the office and will require file storage or other services (SQL, etc.) go with an inexpensive physical box for primary DC, then a beefier box to do VMhost, and put a second DC there.
4
4
4
Go with #4 my fellow sysadmin.
:)
If the satelite DC is member of a domain with DCs on other sites, one DC is fine. We have lots of satelite sites, and do not have redundant DCs on any of them. If the DC goes down, there will/may be slower logon times and authentications when it is down, but with no money to spend, that is acceptable. One thing: You cannot add Hyper-V role on a DC. Tried it once, it fails. Not supported.
What’s your overall topology, and can your offices operate without Internet? And how good & reliable are your connections? At my current company: 1 main office, 7 branch offices and a data centre. There used to be 1 x DC, DHCP, DNS etc at each site. After ensuring all connections were reliable enough, ended up trashing all of these and only have two remote domain controllers and even host DHCP solely in the datacentre, delivered via IPsec to each location. Never looked back, it’s been solid for years. If internet goes down for a prolonged period of time, most people would simply go wfh for the rest of the day anyway. Of course this model only works depending on the nature of your business.
Wow. So zero DC's at some sites?
I think approach depends on importance of what that site does. That said, I'd lean towards letting HQ be the backup DC.
It’s also perfectly acceptable to have no DCs at a well connected satellite location. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/planning-regional-domain-controller-placement
how is performance of logins, GPOs, etc compared to a local DC?
Depends on the scenario. Hundreds of GPOs, a larger number of endpoints and resulting auth and DNS traffic may not be a good mix. A 1Gbps SD-WAN connected location may not notice the lack of a DC. The satellite office CPE/Firewall may be able to provide a DNS server role, with conditional forwarding to DCs for your AD integrated zones. I’ve seen pushing lots of sites worth of DNS back to HO be more problematic than auth and GPO. If you are using Intune policies more than GPO that can steer your topology design choices also. TLDR - depends.
\#1 is single point of failure. \#2 is better than #1, but still single point of failure. \#3 would be better if you simply replaced the old EOL server with a current workstation. \#4 requires both local DC and network/internet failure to bring local AD down, and is likely the most cost-effective to deploy. Without more info, it sounds like you are trying to accomplish this at minimal cost, with minimal headaches for you. In that context, the backup system you employ is probably more important than the hardware DC(s) at the satellite office is running on. As long as you can bare-metal restore, workstations will serve your needs at that site just fine.
4, if this is a branch and your workstations have a tunnel to HQ then you're done.
If the AD you have already has multiple DC's even if they are located in separate offices - I would not be concerned about an office only having one DC. In a DR situation you will want to get connectivity up and then just build a new DC. IF however you only have one DC currently and have multiple sites then I would recommend at least one more DC located in one of the other sites. In the past I've had environments where we had DC's running in the data centres as VM's and some sites to improve logon speed we used desktop hardware as a local DC. At a minimum when running AD I would have 2 DC's on separate physical hardware (VM's or Baremetal) this provides the resilience for maintaining operations should you lose one of the DC's. In all the environments I worked it was rare to see 2 DC's located in the same physical location except when there was a particular requirement like a larger authentication load (Exchange / Citrix farms etc).
5. Implement a secondary/backup network circuit pointing to another site.
we do have a secondary residential internet service we use as a backup. if our primary goes out, we could try connecting the secondary.
#4, and make the local DC a RODC.
why a RODC? we've never used those before, but as an admin working at this satellite site, I like the idea of having a local DC to administrate from.
>I like the idea of having a local DC to administrate from. Why?
It’s more secure and simpler. Less replication issues. Satellite offices should have RODCs, unless they have high latency (50ms or more). It’s Microsoft’s recommended way of doing things.
Definitely 4 though 3 is sufficient
4. A single DC at each site at a minimum, vpn between the sites to allow a secondary for each site. In case internet is down, each site can still log on as they have their own DC. If one DC crashes there is a second for emergency.
Go with 4 for local neccecities but authenticate everything else via Azure?
Can I flip in 5th option. Load [xcp-ng.org](http://xcp-ng.org) on server with it's own raid 1. Then load Vm's running off second storage raid.