Additional domain controller in remote site
-
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.
-
@IRJ said:
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.
Recovery and full restoration are different processes. For Recovery, enough VM hosts to cover the basics and a some switches would cover it. It doesn't need to be pretty or perfect. You wouldn't need a whole datacenter.
-
Additionally, with the remote (sorta secondary) DC users would have an authentication point available ASAP for any data that was still online.
-
i know that the best practice is to have one additional DC in the branch office, but unfortunately i still not have the skills to get that done, this project was not successful and i risked to damage the main DC because it seem that there was some kind of conflict between the 2 DC, now i'm thinking about having child DC in the branch office, this is my next plan, hoping that will be successful
best regard
