Additional domain controller in remote site
-
@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,
-
Alex is right, you don't want a child domain, it gains you nothing. If you go that route, you might as well have two completely separate domains.
I would really like to see what is happening when you have the additional DC setup at the remote office. You can take the server to the remote office, install Server on it. Promote it to Active Directory, and only have one or two machines in the branch use that machine so that you don't effect the whole remote office.... once you have those one or two computers working well, you can enable all those machines to use that server.
-
What problems are you having now with the remote branch computers and them connecting to the domain?
-
@Dashrender said:
What problems are you having now with the remote branch computers and them connecting to the domain?
ok Sir, i will tell you all the steps i have done,
1- promote windows server 2008 R2 to be a domain controller (additional), and i select during the wizard DNS server and global catalog (i did this in the main office)
2- go to Active directory site and services,--> create a new site called Branch, --> create a site link between Main and Branch,--> create new subnet 192.168.5.0, --> in the site link i set the cost and a schedule for replication,--> change ip address of my ADC from 192.168.1.250 to 192.168.5.250, and set the preferred DNS to the ip of the main DC and alternate DNS to his ip ---> i moved to branch office and plug the ADC to the switch ---> change the preferred DNS of branch computers from the PDC ip to ADC,in this stage i go to one of my branch computer, and login from it, i open cmd then type set in order to know the logon server, it show the name of the main DC, i flushed the dns, still having the main DC as logon server, i disconnect the VPN, the user cannot login,
the problem is that the branch computers cannot recognize the PDC as logon server,
then i go to reverse lookup zone, i didn't find any reverse lookup zone that correspond to my remote network 192.168.5, so i decided to add one for my remote network, in this stage a painful story start, the main DC show a message DNS NOT OPERATING, everything got crazy, so i disconnect the VPN, the DNS was restored, enable VPN the DNS not operating, that time i recognize that the ADC who is responsible for these problem,
finally i decided to remove that shit (ADC) from remote officethis is the whole story, i hope that you enjoy it, lol
-
What about Read Only DC, is it a good idea ??
-
@IT-ADMIN said:
What about Read Only DC, is it a good idea ??
Doesn't feel like it is needed here. Now that you have the DC at the main site... is it causing a problem?
-
@scottalanmiller said:
@IT-ADMIN said:
What about Read Only DC, is it a good idea ??
Doesn't feel like it is needed here. Now that you have the DC at the main site... is it causing a problem?
no problem at all, but i need a backup logon server in the branch office so that if the VPN go down, ---> users in the branch can login from the DC in the branch
