Real world root DC Demote/Promote question
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Hi folks,
Let me preface this with saying that I'm just finishing up my MCSA (about halfway through 291) and have started a new job as a network engineer/admin. I have a good working knowledge of AD but not so much from a multi-domain standpoint. In the network I inherited there are multiple child domains from one root in a single forest. The root domain is used for nothing more than it's parent abilities to our site/child domains. No file serving, user processing, DHCP or other services bar being a 2ndary DNS server for the site in which it is located. Since this was my first week I started off by going through the event logs and fixing things up, I noticed there were some replication issues between the Child domain DC and the parent at my site (mainly DNS replication). Further investigation showed that while DNS is setup as an AD integrated Zone on the primary DC (Child) the option is greyed out on the Parent DC....which I know usually means it is not hosted on a DC at all. I ran repadmin and got successful replication reports from the Child DC to the other Child domains at our different sites. The Parent DC only shows replication to the Child DC at our (the same) site. DCDIAG on the Parent DC is successfuly with one exception, the Machine account, stating that (as was show in the DNS properties) that the server does not have a DC account....even though it is the ONLY DC for the parent domain, and under server roles it is shown as being one. As I just said though it is the only DC in the parent domain.
My current thinking is to install a second server and promote it to DC in the parent domain temporarily, give it time to replicate (and of course backup the problematic DC), then demote the old and promote it again to hopefully resolve it's identity crisis. The only thing I am worried about in this scanario is that the issue itself affects replication.
What I realy would like to know is just how tolerant a domain tree is of issues with the root/parent domain? Would it be enough to restore the system state after demotion/promotion in the event the initial AD data is lost. And what kind of impact it's downtime would have on the rest of the domain....Not much huh?...;)
Any help would be GREATLY appreciated.
Cheers
Let me preface this with saying that I'm just finishing up my MCSA (about halfway through 291) and have started a new job as a network engineer/admin. I have a good working knowledge of AD but not so much from a multi-domain standpoint. In the network I inherited there are multiple child domains from one root in a single forest. The root domain is used for nothing more than it's parent abilities to our site/child domains. No file serving, user processing, DHCP or other services bar being a 2ndary DNS server for the site in which it is located. Since this was my first week I started off by going through the event logs and fixing things up, I noticed there were some replication issues between the Child domain DC and the parent at my site (mainly DNS replication). Further investigation showed that while DNS is setup as an AD integrated Zone on the primary DC (Child) the option is greyed out on the Parent DC....which I know usually means it is not hosted on a DC at all. I ran repadmin and got successful replication reports from the Child DC to the other Child domains at our different sites. The Parent DC only shows replication to the Child DC at our (the same) site. DCDIAG on the Parent DC is successfuly with one exception, the Machine account, stating that (as was show in the DNS properties) that the server does not have a DC account....even though it is the ONLY DC for the parent domain, and under server roles it is shown as being one. As I just said though it is the only DC in the parent domain.
My current thinking is to install a second server and promote it to DC in the parent domain temporarily, give it time to replicate (and of course backup the problematic DC), then demote the old and promote it again to hopefully resolve it's identity crisis. The only thing I am worried about in this scanario is that the issue itself affects replication.
What I realy would like to know is just how tolerant a domain tree is of issues with the root/parent domain? Would it be enough to restore the system state after demotion/promotion in the event the initial AD data is lost. And what kind of impact it's downtime would have on the rest of the domain....Not much huh?...;)
Any help would be GREATLY appreciated.
Cheers
We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
Comments
-
Danman32 Member Posts: 1,243It might help to know what version OS the DCs are. 2003 has quite a bit of flexibility on how you replicate DNS information within AD whereas in 2000, it can only replicate the zone along with the domain replication, which means it can only replicate the zone with other DCs in the same domain.
But when you have DNS problems, what I usually do with a client is have them set up a DNS zone for the domain (in your case that would be the root zone) and not use AD integrated, so you don't get into the chicken/egg situation where AD replication relies on DNS, but DNS relies on AD replication, so you get into a deadlock.
Once you have the DNS zone not relying on AD replication to be correct, have all DCs in the domain use that one DNS server for resolution. Then run Netdiag /fix on all DCs using that DNS server.
How are you addressing child domain resolution for the root domain hosts? It has to be able to resolve records for the child domains in order to be able to find and reach the child domain DCs and their services. Also the reverse is true: the child domains have to be able to resolve resource records for the root domain. -
Ahriakin Member Posts: 1,799 ■■■■■■■■□□Hi and thanks for replying. Should have been specific about the OS, apologies. Both are Win2k3 but the Forest and subdomains are all in Win2k native mode. I'm not at the office at the mo. and can't get specifics but the Root domain DC is resolving the child domains correctly from what I can see, it has the Child domain DC at the same site as it's primary DNS....Odd I know, the guy I replaced was an NT head and kinda built the company domains in that vein, DNS and an efficient AD setup didn't figure into things, at least that what it seems like. We're having fun reconsolidating our domains to work more efficiently with AD. Ah well it's a learning experience and that can't be bad.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
-
Danman32 Member Posts: 1,243It seems like you may not grasp the concepts of DNS zones, replication and resolution, or else not presenting the whole picture we need. Each DC is a host that have DNS client services in the TCP stack, as do other machines such as member servers and workstations. All the DCs have to be able to resolve all domains in the forest, either directly or indirectly. DNS clients will not go polling various DNS servers. They will query the primary DNS server ONLY, unless that server is offline or busy and doesn't respond at all.
So, if a DC of the child domain had DNS services, and only had the zone for its own domain, and there were no other mechanism configured in the DNS server service to resolve other domains, and the DC DNS client service had the primary DNS being itself, it would have no way of resolving other domains. Now it seems that you may have DNS resolution working upstream from the child domains to the root, but what about the other way around? Can the root domain DCs resolve the child domains?
Have you run Netdiag on your DCs and observe the DNS test? If that test fails, all bets are off for other aspects of AD. -
Ahriakin Member Posts: 1,799 ■■■■■■■■□□Apologies for the delay in replying, it's one of my own pet hates to have someone ask a question and then disappear, was just travelling a lot for work and didn't get any time to get back to this. Many thanks for all the advice Danman I appreciate the time you spent on it. I had installed a 2ndary server and was a few days away from trying the demote/promote when we had a visit from one of our software vendors, who also happens to be an AD god (And I do not use the term lightly). Took him all of 30 seconds to fix. Just in case anyone else has anything similar happen here was the solution.
On the newly installed 2ndary server:
Open ADSIEDIT and go to DOMAIN / DC=(Domain)..../OU=Domain Controllers/CN=(ServerName), right click to get the properties and scroll down to userAccountControl, double click it and copy the numeric value.
On the problematic server do the same but paste the numeric value from the working server.
Dcdiag reports all is fine and we're replicating fully (it was affecting the forest level GPO propagation).We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
rossonieri#1 Member Posts: 799 ■■■□□□□□□□hello,
how about promote the new DC first - then demote the other one.
specify - this is not the last DC in domain.
cheers; )the More I know, that is more and More I dont know.