Re: Demoting a DC in W2003

all three steps as mentioned by Ace are OK. However before performing step 3
MAKE SURE you have cleaned the lingering objects!

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
MVP Windows Server - Directory Services
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
"Ace Fekay [MVP]"
<PleaseSubstituteMyActualFirstName&LastNameHere@xxxxxxxxxxx> wrote in
message news:e5F31DYHGHA.524@xxxxxxxxxxxxxxxxxxxxxxx
> 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
>
>
>


.

Relevant Pages

  • Re: SBS 2003 and Replication Errors with Remote DC
    ... either fixup the alpha site dns or point it to use the SBS dns server ... and allow replication to complete (including the DNS forest and domain ... Domain Controller Diagnosis ... Performing upstream analysis. ...
    (microsoft.public.windows.server.sbs)
  • Re: SBS 2003 and Replication Errors with Remote DC
    ... that can replicate the directory partition over this ... either fixup the alpha site dns or point it to use the SBS dns server and allow replication to complete before pointing it back to using itself for DNS. ... Domain Controller Diagnosis ...
    (microsoft.public.windows.server.sbs)
  • Re: Demoting a DC in W2003
    ... > were just promoted to DCs once the base OS was installed. ... > roles) and DC3 is a plain DC. ... > was configured to use itself as it's primary DNS server, ... due to replication problems that have been happening longer than 60 days ...
    (microsoft.public.win2000.active_directory)
  • Re: DNS/AD/RPC issues
    ... subnet - although replication is not functioning. ... domain controller has consistently failed. ... The DNS log is where the real action is: ... (The DNS server could not bind a Transmission Control ...
    (microsoft.public.windows.server.dns)
  • Re: Replication issues
    ... "If this is a Windows 2000 AD domain controller, ... you will want to ensure that the first DNS server in the ... What if it is Windows Server 2003, ... >> The File Replication Service is in an error state. ...
    (microsoft.public.windows.server.active_directory)