Re: Demoting a DC in W2003
- From: "Ace Fekay [MVP]" <PleaseSubstituteMyActualFirstName&LastNameHere@xxxxxxxxxxx>
- Date: Fri, 20 Jan 2006 00:18:31 -0500
In news:%238l8HoLHGHA.4076@xxxxxxxxxxxxxxxxxxxx,
Craig Matchan <cwigster@xxxxxxxxxxxxxxx> stated, which I commented on below:
> Hi Ace (and all you lurkers out there)
>
> We have a fairly simple setup. It's a single forrest / single domain
> with three DCs. I'll explain why there are three in a moment. To keep
> things simple, I'll refer to the DCs as DC1, DC2 and DC3 with the
> following IP addresses 192.168.0.1, 192.168.0.2 and 192.168.0.31
> respectively.
>
> DC1 was the master DC and held the FSMO roles. It currently runs on a
> low end single CPU server. It's only role is being a DC and our
> primary internal DNS server. Nothing else runs on it. DNS is AD
> integrated.
>
> DC2 and DC3 were added later when we had the budget to purchase some
> IBM servers, in this case IBM X346 servers. Initially DC2 and DC3
> were just promoted to DCs once the base OS was installed. This
> appeared to be fine.
>
> When I was happy that all three seemed to be ok I transfered (not
> siezed) the FSMO roles from DC1 to DC2 using the MS KB article
> 324801. As far as I can tell this seems to have worked. I just
> haven't gotton round to demoting DC1 yet. I realise that if you seize
> the FSMO roles then the DC that originally held them should be
> demoted asap, but from what I have read this doesn't apply if you
> sucessfully transfer them.
>
> So now DC1 is a DC, DC2 is the master (after transfering the FMSO
> roles) and DC3 is a plain DC.
>
> All the DCs are running Win2003 without SP1. I was planning on
> installing SP1 after I demoted DC1, but given the current problems I
> am having I don't want to risk making things worse by applying SP1.
>
> All the DCs act as internal DNS servers as well. Initially each DC
> was configured to use itself as it's primary DNS server, however I
> started to get some DNS errors (can't recall the exact error now) but
> when I researched it the article seemed to imply that I should not be
> doing this, so I changed the DNS settings on the DCs to point to each
> other so
>
> DC1 used DC2 as it's primary and DC3 as it's secondary
> DC2 used DC3 as it's primary and DC1 as it's secondary
> DC3 used DC1 as it's primary and DC2 as it's secondary
>
> I will use <domain> to replace our real domain name.
>
> At an IP level things seem ok, I can ping/traceroute/nslookup the
> thee DCs and they all seem to see each other. It's at some AD level
> things aren't quite right.
>
> DC1 and DC2 can see DC3 using IP , FQDN and Netbios names. Within the
> DNS application on DC1 and DC2 I can add DC3 as another DNS server to
> monitor. I can access DC3 filesystem using UNC style pathnames from
> DC1 and DC2. The exact oppisite ocurrs on DC3, but only relative to
> DC1 and DC2. That is I cannot access DC1 or DC2 via UNC style
> pathnames, FQDNs or Netbios names, however IP addressed names work.
> At the IP level there doesn't appear to be any connectivity issues.
>
> DC3 is the one that is reporting the following event log errors
>
> Application -> Userenv 1030->User:<domain>Administrator->Computer DC3
> Windows cannot query the list of Group Policy objects.
>
> Application -> Userenv 1058->User:<domain>Administrator->Computer DC3
> Windows cannot access the file gpt.ini for GPO CN=<blah blah blah>
> Group policy processing aborted.
>
> System -> Kerberos Event Id 4 ->User N/A -> Computer DC3
> The kerberos client received a KRB_AP_ERR_MODIFIED error from the
> server host/tofu.open.edu.au. The target name used was <domain>\DC2$.
> This indicates that the password used to encrypt the kerberos service
> ticket is different than that on the target server. Commonly, this is
> due to identically named machine accounts in the target realm
> (<DOMAIN>), and the client realm. Please contact your system
> administrator.
>
> Directory Service -> NTDS Replication->Replication->1988->User:NT
> Authority\ANONYMOUS LOGON->Computer DC3
> The local domain controller has attempted to replicate the following
> object from the following source domain controller. This object is
> not present on the local domain controller because it may have been
> deleted and already garbage collected.
> Source domain controller:
> c11fb976-869f-47c4-b91c-8f467e52aa55._msdcs.<domain>
> Object:
> DC=..SerialNo-DC1.<domain>\0ADEL:d9fa6938-1bcf-4c04-98d9-0d4f0ab6def7,CN=Deleted
> Objects,DC=ForestDnsZones,DC=<domain>,DC=edu
> Object GUID: d9fa6938-1bcf-4c04-98d9-0d4f0ab6def7
>
> Replication will not continue with the source domain controller until
> the situation has been resolved.
>
> One thing I have noticed on the DNS servers for each DC, on DC3 in
> the _msdcs tree threre are NS entries for each of the DCs and if I i
> do a porties on one of the NS entries then if brings up a properties
> page with the FQDN of each DNS server and their IP address. If I do
> the same on either DC1 or DC2 the IP address field is "Unknown" and
> there are only entries for DC1 and DC2. Not mention of DC3.
>
> I think I'll stop at this point as this posting is already long
> enough. If you want any more info ask away.
>
> Craig
Interesting. My thoughts are that DC1 has been out of touch with DC2 and DC3
due to replication problems that have been happening longer than 60 days
ago.
Let's see, I have a few thoughts on this. Apparently from what you're
saying, replication seems to be working between DC2 and DC3, but they don't
think DC1 is any longer part of the domain. If that is truly the case, you
can possibly:
1. Follow the previous tech articles.
2. Force demote DC1 out the domain. Metadata cleanup DC1's data out of the
domain. Instead of formatting and starting from scratch, I have these steps
to clean up the machine of all the components and reg entries that make it a
DC and then promote it back into the domain as a fresh DC.
3. Create this reg entry below on DC1, DC2 and DC3 to force each other to
recognize themsleces as viable replication partners and disregard the old
data (I've never tested it but someone recently in another thread said
they've used it to do the same thing at it worked for them).
Quoted (forget who the poster was):
_______________________________________
HKLM\System\CurrentControlSet\Services\NTDS\Parameters
Create a value called "Allow Replication With Divergent and Corrupt Partner"
as REG_DWORD type with data of 1.
I do it on both of my VMs and after waiting a little bit (not sure how long)
and trying to force replication in AD Sites and Services. I no longer get
errors.
_______________________________________
Let me know what you think.
Ace
.
- Follow-Ups:
- Re: Demoting a DC in W2003
- From: Jorge de Almeida Pinto [MVP]
- Re: Demoting a DC in W2003
- From: Craig Matchan
- Re: Demoting a DC in W2003
- References:
- Demoting a DC in W2003
- From: Craig Matchan
- Re: Demoting a DC in W2003
- From: Jorge de Almeida Pinto [MVP]
- Re: Demoting a DC in W2003
- From: Craig Matchan
- Re: Demoting a DC in W2003
- From: Ace Fekay [MVP]
- Re: Demoting a DC in W2003
- From: Craig Matchan
- Demoting a DC in W2003
- Prev by Date: Re: attribute size limit
- Next by Date: Re: Demoting a DC in W2003
- Previous by thread: Re: Demoting a DC in W2003
- Next by thread: Re: Demoting a DC in W2003
- Index(es):
Relevant Pages
|