reasons to have a local DC in a remote office?
-
I have a remote office with a local DC that I would like to decommission. There is a site to site VPN to HQ. If the VPN goes down, they really wouldn't be doing much of anything because their primary business application depends on a SQL server at HQ.
-
@Mike-Davis said in reasons to have a local DC in a remote office?:
I have a remote office with a local DC that I would like to decommission. There is a site to site VPN to HQ. If that was the case though, they really wouldn't be doing much of anything because their primary business application depends on a SQL server at HQ.
No reason at all in that situation.
Without SQL being local, there is no reason to keep something.
I would not remove it since it is there already, but once it dies, I would not replace it.
-
@JaredBusch The last time it died no one noticed until they tried to print to one of the print shares on it. As soon as we push those printers out as local printers I don't think anyone will notice.
-
Agree in that situation there is no reason to have a local DC.
I use local DC's in remote sites mostly when the connections are very slow ie.. i have one that has 400+ms latency to the HQ.
-
Yeah, the only reason I can see to keep it would be local (faster) network shares. But if you aren't doing that, I'm with JB, when it does, make it go away.
One thing though, what is providing DHCP/DNS at that branch?
-
We have an EdgeRouter there that does DHCP and DNS comes from HQ with google tertiary. If the VPN is down they can still get email that way.
-
@Mike-Davis said in reasons to have a local DC in a remote office?:
We have an EdgeRouter there that does DHCP and DNS comes from HQ with google tertiary. If the VPN is down they can still get email that way.
Personally I'd get rid of that tertiary entry. If a PC ever has a DNS issue and ends up using the tertiary, their DNS queries will be broken until either they have a DNS failure with Google and bound back to DNS primary, or until reboot.
This has caused me more heartache than I care to admit. yes it sucks when the VPN goes down, the site is effectively down, but the other problems wheren't worth the rare times this would have been helpful.
-
Local DC does not seem to have any purpose. I agree, decom it when it makes sense.
-
@Dashrender I forgot about that. I guess if the DC did go down, I could talk someone in to changing the DNS settings on their computer so that screen connect would work, log in to the ER and change DNS if we thought the VPN was going to be down for any length of time. (or just enable SSH on the ER from the outside interface.)
-
@Mike-Davis said in reasons to have a local DC in a remote office?:
@Dashrender I forgot about that. I guess if the DC did go down, I could talk someone in to changing the DNS settings on their computer so that screen connect would work, log in to the ER and change DNS if we thought the VPN was going to be down for any length of time. (or just enable SSH on the ER from the outside interface.)
Why not have local DNS point to the DC, but the secondary point across the VPN? No need to change anything.
-
@scottalanmiller said in reasons to have a local DC in a remote office?:
@Mike-Davis said in reasons to have a local DC in a remote office?:
@Dashrender I forgot about that. I guess if the DC did go down, I could talk someone in to changing the DNS settings on their computer so that screen connect would work, log in to the ER and change DNS if we thought the VPN was going to be down for any length of time. (or just enable SSH on the ER from the outside interface.)
Why not have local DNS point to the DC, but the secondary point across the VPN? No need to change anything.
He mentioned that Google was his tertiary DNS entry is Google. blips causing DNS flipping to your other entries seem to be common (Not like every day common, but common enough to be a problem). My not stated suggestion is that google should be removed from the line up.
-
@Dashrender said in reasons to have a local DC in a remote office?:
@scottalanmiller said in reasons to have a local DC in a remote office?:
@Mike-Davis said in reasons to have a local DC in a remote office?:
@Dashrender I forgot about that. I guess if the DC did go down, I could talk someone in to changing the DNS settings on their computer so that screen connect would work, log in to the ER and change DNS if we thought the VPN was going to be down for any length of time. (or just enable SSH on the ER from the outside interface.)
Why not have local DNS point to the DC, but the secondary point across the VPN? No need to change anything.
He mentioned that Google was his tertiary DNS entry is Google. blips causing DNS flipping to your other entries seem to be common (Not like every day common, but common enough to be a problem). My not stated suggestion is that google should be removed from the line up.
I have dhcp hand out primary DNS as the main office DC. Secondary is the local ERL.
In the ERL I again set dns1 as the main DC but secondary as Google.
I also set static host mapping in the ERL for the local domain just in case.
-
@JaredBusch said in reasons to have a local DC in a remote office?:
@Dashrender said in reasons to have a local DC in a remote office?:
@scottalanmiller said in reasons to have a local DC in a remote office?:
@Mike-Davis said in reasons to have a local DC in a remote office?:
@Dashrender I forgot about that. I guess if the DC did go down, I could talk someone in to changing the DNS settings on their computer so that screen connect would work, log in to the ER and change DNS if we thought the VPN was going to be down for any length of time. (or just enable SSH on the ER from the outside interface.)
Why not have local DNS point to the DC, but the secondary point across the VPN? No need to change anything.
He mentioned that Google was his tertiary DNS entry is Google. blips causing DNS flipping to your other entries seem to be common (Not like every day common, but common enough to be a problem). My not stated suggestion is that google should be removed from the line up.
I have dhcp hand out primary DNS as the main office DC. Secondary is the local ERL.
In the ERL I again set dns1 as the main DC but secondary as Google.
I also set static host mapping in the ERL for the local domain just in case.
Interesting, manual, but definitely a solution. And even if the ERL is going to Google for DNS, the internal mappings solves the local problem, I assume.
-
@Dashrender said in reasons to have a local DC in a remote office?:
@JaredBusch said in reasons to have a local DC in a remote office?:
@Dashrender said in reasons to have a local DC in a remote office?:
@scottalanmiller said in reasons to have a local DC in a remote office?:
@Mike-Davis said in reasons to have a local DC in a remote office?:
@Dashrender I forgot about that. I guess if the DC did go down, I could talk someone in to changing the DNS settings on their computer so that screen connect would work, log in to the ER and change DNS if we thought the VPN was going to be down for any length of time. (or just enable SSH on the ER from the outside interface.)
Why not have local DNS point to the DC, but the secondary point across the VPN? No need to change anything.
He mentioned that Google was his tertiary DNS entry is Google. blips causing DNS flipping to your other entries seem to be common (Not like every day common, but common enough to be a problem). My not stated suggestion is that google should be removed from the line up.
I have dhcp hand out primary DNS as the main office DC. Secondary is the local ERL.
In the ERL I again set dns1 as the main DC but secondary as Google.
I also set static host mapping in the ERL for the local domain just in case.
Interesting, manual, but definitely a solution. And even if the ERL is going to Google for DNS, the internal mappings solves the local problem, I assume.
It was the least amount of work I could come up with and still have users with internet access when the VPN was down.
