Additional domain controller in remote site
-
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
-
also just recently i have a problem, i cannot manage computers in the branch office (in the console Active Directory users and computers), this problem appear only after i add that shit (additional DC in branch office) , before that i was able to manage them, now i cannot (network path not found)
-
@IT-ADMIN said:
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
Do you mean a child domain? There's very little reason to use a child domain unless there's a legal separation requirement between two business entities or you have so many computers that a single domain wouldn't be practical.
-
@alexntg said:
@IT-ADMIN said:
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
Do you mean a child domain? There's very little reason to use a child domain unless there's a legal separation requirement between two business entities or you have so many computers that a single domain wouldn't be practical.
so, i meant child domain, i plan to do that in order to have a backup login server in the branch, i know that additional DC is the best solution for that but this project was not successful. so sad .....
-
@IT-ADMIN said:
@alexntg said:
@IT-ADMIN said:
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
Do you mean a child domain? There's very little reason to use a child domain unless there's a legal separation requirement between two business entities or you have so many computers that a single domain wouldn't be practical.
so, i meant child domain, i plan to do that in order to have a backup login server in the branch, i know that additional DC is the best solution for that but this project was not successful. so sad .....
If you go with a child domain, you'd just have 2 domains with single domain controllers. You'd still have the single-DC point of failure (times two), as well as having to deal with domain trusts, group permissions from multiple domains, etc. You really don't want to do that. If it were me, I'd focus on getting the second DC working properly.
-
i appreciate your kind advise, but unfortunately i think that i have all setting correct but still not able to get an additional DC installed in the branch office, and what is worst is that ADC was creating conflict with the main DC (DNS issues) and i risked the stability the whole domain, for this reason i refrain from having it in the branch,
