Additional domain controller in remote site
-
We use a 5 DCs at our main office and branches have no DCs. Since I use PDQ for package deployment and I use a separate Group Policy for each branch. I have never had an issue with our T1 Connections. You can use AD Sites and Services to create a new site for the branch and just build the second DC at your main office. I really don't see why you need a second DC at the branch, user authentication and group policy don't use much bandwidth at all. I bet your branch users are still accessing their shares and applications over the WAN. Which uses much more resources than AD would ever use.
-
We use central AD only as well.
-
@scottalanmiller said:
@alexntg said:
@IT-ADMIN said:
@Dashrender said:
@Dashrender said:
what server is providing DHCP for the branch PCs?
Again, what server is providing DHCP to the branch PCs? Is the scope set correctly to give the PC's the DNS of the branch DNS server.
yes, the DHCP is providing the correct DNS setting which is the ip of my ADC as primary DNS and the internet gateway as secondary DNS
For the branch site, the DC should be primary DNS, and the DC at your main location should be secondary. Non-AD DNS sources should not be used.
I use them but only for tertiary and quaternary DNS options and only when I have only two DCs.
Using non-AD DNS in an AD enviornment can lead to kerberos errors and other fun, erratic behavior.
-
Yes. Using non-AD DNS is a more expert option. Just going to make things harder. Stick with integrated AD / DNS.
-
@scottalanmiller said:
Yes. Using non-AD DNS is a more expert option. Just going to make things harder. Stick with integrated AD / DNS.
yes of course i set my ADC to be DNS server, i think that this issue have no solution because i think i have everything set correctly whether it be physical and logial,
i will bring that ADC from the branch office and content myself with only one DC in the main office. -
Two in the main office is good.
-
Have you tried forcing a lookup against the branch DC via nslookup yet?
-
can you imagine what happen to me yesterday night??
i was trying to solve the problem, i added one reverse lookup zone for the remote network 192.168.5 because there was only one reverse lookup zone for the main network, after doing so the main DC get crazy, a message appears "THE DNS SERVER NOT OPERATING", fortunately i do that at night and no employee was there, everything stack, no logon server available, the network drive is not working....
i had very difficult time, i realize the importance of the DNS, so i delete the reverse lookup zone, then the DNS came to life, i restarted the main DC, the same issue again DNS NOT OPERATING, i doubt the remote DC have some affect on the main DC so i disable the VPN, restarted the main DC, DNS came to life, i enable the VPN, the DNS stack, that time i realize that the remote DC who is responsible of all of this, so i remove this shit from the Domain and from the Site and services console, everything is working now ,lol -
Wow. Glad that you found that.
-
so you only have one DNS server running now?
-
@Dashrender said:
so you only have one DNS server running now?
yes, i content myself with only one DC - DNS server which is the old one in the main office, and users in the branch office login from the main DC, hopefully the remote login will not consume much bandwidth since i have only 512 Kbps speed, i wanted to have a remote DC from my branch computers but unfortunately this project was not successful and may corrupt the all domain because the DNS service is everything in the domain, if corrupted or damaged, it will be a total lost, fortunately i test that at night otherwise i will be in trouble with the management
-
You might want to consider a second DC at the main site.
-
@scottalanmiller said:
You might want to consider a second DC at the main site.
Or just fixing the one at the remote site.
-
@scottalanmiller said:
You might want to consider a second DC at the main site.
I recommended that a week ago. Its alot easier to manage.
-
@IRJ said:
@scottalanmiller said:
You might want to consider a second DC at the main site.
I recommended that a week ago. Its alot easier to manage.
Having a second DC at a main site without one at a remote site doesn't really offer any advantages. If the site fails, you're out both DCs. If they're spit one at each site and the clients are pointed properly, the setup could suffer a WAN link failure without losing authentication, and one of the DCs could fail without any major issue. The only time there would be an issue is that if the WAN's down and one DC's out, but one of the sites would still continue to work properly.
-
@alexntg said:
@IRJ said:
@scottalanmiller said:
You might want to consider a second DC at the main site.
I recommended that a week ago. Its alot easier to manage.
Having a second DC at a main site without one at a remote site doesn't really offer any advantages. If the site fails, you're out both DCs. If they're spit one at each site and the clients are pointed properly, the setup could suffer a WAN link failure without losing authentication, and one of the DCs could fail without any major issue. The only time there would be an issue is that if the WAN's down and one DC's out, but one of the sites would still continue to work properly.
From my understanding, All the resources are at the main site anyway. So what good is authentication, if there are no resources that need to be authenticated?
-
@IRJ said:
@alexntg said:
@IRJ said:
@scottalanmiller said:
You might want to consider a second DC at the main site.
I recommended that a week ago. Its alot easier to manage.
Having a second DC at a main site without one at a remote site doesn't really offer any advantages. If the site fails, you're out both DCs. If they're spit one at each site and the clients are pointed properly, the setup could suffer a WAN link failure without losing authentication, and one of the DCs could fail without any major issue. The only time there would be an issue is that if the WAN's down and one DC's out, but one of the sites would still continue to work properly.
From my understanding, All the resources are at the main site anyway. So what good is authentication, if there are no resources that need to be authenticated?
Disaster Recovery's a good start. If the main site's unavailable, you can use the offsite DC as a start for recovery. Also, if considering WPA Enterprise, having a local DC/RADIUS would be useful. Otherwise, a loss of WAN could result in loss of WiFi.
-
@alexntg said:
@IRJ said:
@alexntg said:
@IRJ said:
@scottalanmiller said:
You might want to consider a second DC at the main site.
I recommended that a week ago. Its alot easier to manage.
Having a second DC at a main site without one at a remote site doesn't really offer any advantages. If the site fails, you're out both DCs. If they're spit one at each site and the clients are pointed properly, the setup could suffer a WAN link failure without losing authentication, and one of the DCs could fail without any major issue. The only time there would be an issue is that if the WAN's down and one DC's out, but one of the sites would still continue to work properly.
From my understanding, All the resources are at the main site anyway. So what good is authentication, if there are no resources that need to be authenticated?
Disaster Recovery's a good start. If the main site's unavailable, you can use the offsite DC as a start for recovery. Also, if considering WPA Enterprise, having a local DC/RADIUS would be useful. Otherwise, a loss of WAN could result in loss of WiFi.
I dont understand what you mean by using the offsite DC for recovery. What are you going to recover from a DC? He will probably continue to make changes from the Main site DC and replicate them to the offsite DC.
-
@IRJ said:
@alexntg said:
@IRJ said:
@alexntg said:
@IRJ said:
@scottalanmiller said:
You might want to consider a second DC at the main site.
I recommended that a week ago. Its alot easier to manage.
Having a second DC at a main site without one at a remote site doesn't really offer any advantages. If the site fails, you're out both DCs. If they're spit one at each site and the clients are pointed properly, the setup could suffer a WAN link failure without losing authentication, and one of the DCs could fail without any major issue. The only time there would be an issue is that if the WAN's down and one DC's out, but one of the sites would still continue to work properly.
From my understanding, All the resources are at the main site anyway. So what good is authentication, if there are no resources that need to be authenticated?
Disaster Recovery's a good start. If the main site's unavailable, you can use the offsite DC as a start for recovery. Also, if considering WPA Enterprise, having a local DC/RADIUS would be useful. Otherwise, a loss of WAN could result in loss of WiFi.
I dont understand what you mean by using the offsite DC for recovery. What are you going to recover from a DC? He will probably continue to make changes from the Main site DC and replicate them to the offsite DC.
For DR, there's no more main site to make changes at. The secondary site then becomes the primary site. There'll be a need to hook up some more computers to handle the overflow staff (assuming any staff survive the event). Having a DC available would be most useful, and it would serve for authentication to any servers you stand up at the second site during recovery. If the infrastructure's in place at the second site, there's no reason to not have a DC there. For the amount of computers, there's no workload need for 2 DCs at any one site.
-
I see where what you are saying, but the chances of that scenario are slim to none. If there was a cataclysmic event that took down the main branch completely, the likelihood of them building the infrastructure at the second branch from the ground up is highly unlikely.
If they are backing up offsite, they would be more likely to restore everything to the original site or the cloud. The likelihood of them buying equipment in a small branch office and rehosting everything there is almost non-existent. I doubt they have the space to build a datacenter.
