Demoting a DC in W2003

  • Thread starter Thread starter Craig Matchan
  • Start date Start date
C

Craig Matchan

Hi all,

I have a bit of a problem with a server that was promoted to act as a DC.
This is not the root DC. I am getting a lot of errors in the event logs all
popinting to some AD error with this server. There are

- multiple UserEnv 1030 errors relating to query's failing of GPOs
- multiple UserEnv 1058 errors relating to access issues to the gpt.ini for
various GPOs
- multiple kerberos 4 errors reporting that the service ticket is different
on the other DC.
- multiple Replication 1988 errors when this server tries to resolve the
other DC objects
- multiple NTFRS warnings 13508 relating to FRS not being able to resolve
the other DC names.

Additionally, the DNS server on this DC cannot connect to the DNS servers on
the other DC, it just says ACCESS DENIED, yet the other DC DNS can connect
to this one.

So, I thought given there are all these errors it might be simply easier to
demote this server from a DC back to a normal member server, however the
demote is not working. Basically I get as far as

- specifying the new admin password the server will use once it has been
demoted

When it actually tries to initiate the demote I get the following error
message

The operation failed because:
Managing the network session with <servername> failed
:Logon Failure: The target account name is incorrect."

I'm by no means an AD guru. Does anyone have any suggestions on how I can
safely remove the server from being a DC?

ta

Craig


-
 
Just noticed another things occuring on the suspect DC I can run

AD Sites and Services
AD Domains and Trusts

utilities, however, when I try and run the

Domain Controller Security Policy
Domain Security Policy

utilities they produce the following error

Failed to open the Group Policy Object. You may not have appropriate rughts.
Details: Logon Failure: The target account name is incorrect.

I've also notices that if it try and refer to the other DC using either it
FQDN or NETBIOS name it will return a "Access Denied Error: You do not have
permission to access this network resource.", howerver, if I use it's IP
address it works.

Craig
 
I saw you are experiencing event ID 1988.
That ID say a lingering object has been detected. Read the following for
more information.
http://www.microsoft.com/technet/pr...ons/4a1f420d-25d6-417c-9d8b-6e22f472ef3c.mspx

Most common reason for lingering objects is the time a DC has been
disconnected from the network (other DCs)

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
MVP Windows Server - Directory Services
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
 
Hi Jorge,

I've had a read of the kb article. Not sure if it's really the problem I'm
having. I think the 1988 errors are caused more by something else that is
broken. Yes they are a problem but I'm not sure ifd there the underlying
cause.

I'll add another thing I've noticed. The "Access Denied" errors I am getting
ONLY occur when trying to resolve other DCs within the forrest. It has no
problems access any of the other member servers.

At this point I am seriously considering trying a forceremoval and then
manually clean up the metadata in AD, however to be honest this path scares
the life out of me as it is someting I've never done before and this is our
production AD network. I can't afford to make things worse. I might have to
bring in a contractor who knows AD alot better than me.

I would still like to hear anyones elses take on this though.

regards

Craig
"Jorge de Almeida Pinto [MVP]"
 
In
Craig Matchan said:
Hi Jorge,

I've had a read of the kb article. Not sure if it's really the
problem I'm having. I think the 1988 errors are caused more by
something else that is broken. Yes they are a problem but I'm not
sure ifd there the underlying cause.

I'll add another thing I've noticed. The "Access Denied" errors I am
getting ONLY occur when trying to resolve other DCs within the
forrest. It has no problems access any of the other member servers.

At this point I am seriously considering trying a forceremoval and
then manually clean up the metadata in AD, however to be honest this
path scares the life out of me as it is someting I've never done
before and this is our production AD network. I can't afford to make
things worse. I might have to bring in a contractor who knows AD alot
better than me.
I would still like to hear anyones elses take on this though.

regards

Craig
Click to expand...

See if this helps:
http://www.eventid.net/display.asp?eventid=13508&eventno=6585&source=FRS&phase=1

Basically as Jorge said, the data being caused by the removed DC that
didn't work right (due to DNS misconfigurations or whatever reason), and
it's been offline longer than the default AD tombstone TTL of 60 days, you
have to simply remove that data from AD because it still thinks it's there.
It's not like NT4, whch you can just delete from Server Manager. With AD
either do a clean demotion, or if forced off, it must be manually cleaned.

See if that article helps to further understand what's happening. You can
run a metadata cleanup to remove that data as well. Check the FRS staging
area (based on Jorge's post) to delete that data.

216498 - HOW TO Remove Data in Active Directory After an Unsuccessful Domain
Controller Demotion (2000 or 2003):
http://support.microsoft.com/?id=216498

216364 - Domain Controller Server Object Not Removed After Demotion:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q216364

If the errors turn into 13568 errors (journal wrapping, which I doubt), then
we'll need to reset the NTFRS service. Let's clean up that data first which
is causing the 13508's.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

If you are having difficulty in reading or finding responses to your post,
instead of the website you are using, if I may suggest to use OEx (Outlook
Express or any other newsreader of your choosing), and configure a newsgroup
account, pointing to news.microsoft.com. This is a direct link into the
Microsoft Public Newsgroups, and it is FREE and DOES NOT require a Usenet
account with your ISP. With OEx, you can easily find your post, track
threads, cross-post, and sort by date, poster's name, watched threads or
subject.

Not sure how? It's easy:
How to Configure OEx for Internet News
http://support.microsoft.com/?id=171164

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Windows Server Directory Services
Microsoft Certified Trainer
Assimilation Imminent. Resistance is Futile.
Infinite Diversities in Infinite Combinations.
=================================
 
In
Craig Matchan said:
Hi Jorge,

I've had a read of the kb article. Not sure if it's really the
problem I'm having. I think the 1988 errors are caused more by
something else that is broken. Yes they are a problem but I'm not
sure ifd there the underlying cause.
Click to expand...

<snipped)

Craig, if you can provide a little more info too, that will help to see what
is causing some of the other issues, which may or may not be related to the
13508s. Can you post an ipconfig /all of one of the DCs and of one of your
clients please for starters? That will help to give us a better idea of your
infrastructure's basic configuration and see if there is any
mis-configuration at the basic level.

Thanks

Ace
 
Hi Ace,

Ok, I'll have a look at that URL and see if anything it suggests help.

As per your other posts request, I'll post a complete description of our
setup and a list of changes that have been done since the initial install.
It's not as much as it sounds it could be, we are a small site with a single
forest setup. I'll post this soon.

As it stands, most things are working, I'm just having issues with GPOs
being applied whilst trying to get WSUS going. Existing GPOs seem ok, but
anything new is not being pushed out and I think it's because it can't
replicate out to this troublesome DC.

Craig

"Ace Fekay [MVP]"
 
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
 
In
Craig Matchan said:
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
Click to expand...

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
 
Hi Ace,

Actually it's DC3 that seems to be isolated. DC1 and DC2 seem to be talking
to each other fine and replicating as far as I can tell.

Running dcdiag on DC1 and DC2 report no issues, however dcdiag on DC3 does.
I'm begining to think it's a DNS resolution issue, at least dcdiag is
convinced it is. Here is the output of the dcdiag on DC3

Domain Controller Diagnosis

Performing initial setup:
Done gathering initial info.

Doing initial required tests

Testing server: Default-First-Site-Name\DC3
Starting test: Connectivity
The host 296fe8bd-569e-425a-951a-678ab37c4fd0._msdcs.<domain> could
not be resolved to an
IP address. Check the DNS server, DHCP, server name, etc
Although the Guid DNS name

(296fe8bd-569e-425a-951a-678ab37c4fd0._msdcs.open.edu.au) couldn't
be

resolved, the server name (dc3.<domain>) resolved to the IP

address (192.168.0.2) and was pingable. Check that the IP address
is

registered correctly with the DNS server.
......................... DC3 failed test Connectivity

Doing primary tests

Testing server: Default-First-Site-Name\DC3
Skipping all tests, because server DC3 is
not responding to directory service requests

Running partition tests on : ForestDnsZones
Starting test: CrossRefValidation
......................... ForestDnsZones passed test
CrossRefValidation
Starting test: CheckSDRefDom
......................... ForestDnsZones passed test CheckSDRefDom

Running partition tests on : DomainDnsZones
Starting test: CrossRefValidation
......................... DomainDnsZones passed test
CrossRefValidation
Starting test: CheckSDRefDom
......................... DomainDnsZones passed test CheckSDRefDom

Running partition tests on : Schema
Starting test: CrossRefValidation
......................... Schema passed test CrossRefValidation
Starting test: CheckSDRefDom
......................... Schema passed test CheckSDRefDom

Running partition tests on : Configuration
Starting test: CrossRefValidation
......................... Configuration passed test
CrossRefValidation
Starting test: CheckSDRefDom
......................... Configuration passed test CheckSDRefDom

Running partition tests on : <domain>
Starting test: CrossRefValidation
......................... <domain> passed test CrossRefValidation
Starting test: CheckSDRefDom
......................... <domain> passed test CheckSDRefDom

Running enterprise tests on : <domain>
Starting test: Intersite
......................... <domain> passed test Intersite
Starting test: FsmoCheck
[DC1] LDAP bind failed with error 8341,
Win32 Error 8341.
......................... open.edu.au passed test FsmoCheck

Now there is no cname record on any of the DNS servers that matches
296fe8bd-569e-425a-951a-678ab37c4fd0 and I'm sure this is the SID of DC3.
I'm guessing that somehow this record was deleted and that's when all the
problems started. I'm tempted just to recreate this entry but I'm not 100%
sure if it's the right thing to do.

Craig
 
please post for EACH DC the output of (in separate attachments):
DCDIAG /D /C /V

for each DC post the event ID errors

it is a bit confusing which DC is not healthy if I read the posts

--

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!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
Craig Matchan said:
Hi Ace,

Actually it's DC3 that seems to be isolated. DC1 and DC2 seem to be
talking to each other fine and replicating as far as I can tell.

Running dcdiag on DC1 and DC2 report no issues, however dcdiag on DC3
does. I'm begining to think it's a DNS resolution issue, at least dcdiag
is convinced it is. Here is the output of the dcdiag on DC3

Domain Controller Diagnosis

Performing initial setup:
Done gathering initial info.

Doing initial required tests

Testing server: Default-First-Site-Name\DC3
Starting test: Connectivity
The host 296fe8bd-569e-425a-951a-678ab37c4fd0._msdcs.<domain>
could not be resolved to an
IP address. Check the DNS server, DHCP, server name, etc
Although the Guid DNS name

(296fe8bd-569e-425a-951a-678ab37c4fd0._msdcs.open.edu.au) couldn't
be

resolved, the server name (dc3.<domain>) resolved to the IP

address (192.168.0.2) and was pingable. Check that the IP address
is

registered correctly with the DNS server.
......................... DC3 failed test Connectivity

Doing primary tests

Testing server: Default-First-Site-Name\DC3
Skipping all tests, because server DC3 is
not responding to directory service requests

Running partition tests on : ForestDnsZones
Starting test: CrossRefValidation
......................... ForestDnsZones passed test
CrossRefValidation
Starting test: CheckSDRefDom
......................... ForestDnsZones passed test CheckSDRefDom

Running partition tests on : DomainDnsZones
Starting test: CrossRefValidation
......................... DomainDnsZones passed test
CrossRefValidation
Starting test: CheckSDRefDom
......................... DomainDnsZones passed test CheckSDRefDom

Running partition tests on : Schema
Starting test: CrossRefValidation
......................... Schema passed test CrossRefValidation
Starting test: CheckSDRefDom
......................... Schema passed test CheckSDRefDom

Running partition tests on : Configuration
Starting test: CrossRefValidation
......................... Configuration passed test
CrossRefValidation
Starting test: CheckSDRefDom
......................... Configuration passed test CheckSDRefDom

Running partition tests on : <domain>
Starting test: CrossRefValidation
......................... <domain> passed test CrossRefValidation
Starting test: CheckSDRefDom
......................... <domain> passed test CheckSDRefDom

Running enterprise tests on : <domain>
Starting test: Intersite
......................... <domain> passed test Intersite
Starting test: FsmoCheck
[DC1] LDAP bind failed with error 8341,
Win32 Error 8341.
......................... open.edu.au passed test FsmoCheck

Now there is no cname record on any of the DNS servers that matches
296fe8bd-569e-425a-951a-678ab37c4fd0 and I'm sure this is the SID of DC3.
I'm guessing that somehow this record was deleted and that's when all the
problems started. I'm tempted just to recreate this entry but I'm not 100%
sure if it's the right thing to do.

Craig
Click to expand...
 
In Jorge de Almeida Pinto [MVP]
all three steps as mentioned by Ace are OK. However before performing
step 3 MAKE SURE you have cleaned the lingering objects!
Click to expand...

Good point.

:-)
 
In
Craig Matchan said:
Hi Ace,

Actually it's DC3 that seems to be isolated. DC1 and DC2 seem to be
talking to each other fine and replicating as far as I can tell.
Click to expand...

Let's see the tests that Jorge requested. Keep in mind, once we get
replication working, netlogon should properly register it's GUID into DNS
under the _msdcs zone so there won't be any need to manually create it.

Ace
 
DC 3 has detected that other DCs contain lingering objects. (event ID 1988)

Besides that DC1 and DC2 are having trouble replicating (event ID 1925)

see:
event ID 1988
this event will also specify which DC contains the lingering objects.
look at something that looks like:

Source DC (Transport-specific network address):
"4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.contoso.com"

it will will also say in which partition the lingering objects reside as it
states the DC of the lingering object


start NSLOOKUP
paste the address between quotes in the nslookup window and you will see
which DC contains the lingering objects

on the DC that contains the lingering objects RUN:
REPADMIN /REMOVELINGERINGOBJECTS <FQDN DC with lingering objects>
<objectGUID> <partition>

<objectGUID> can be found through REPADMIN /SHOWREPL <FQDN DC that reports
the lingering objects>
<partition> is the DN for the partition that contains the lingering objects.

http://www.microsoft.com/technet/pr...ons/4a1f420d-25d6-417c-9d8b-6e22f472ef3c.mspx



event ID 1925
http://www.microsoft.com/technet/pr...ons/43e6f617-fb49-4bb4-8561-53310219f997.mspx
http://www.microsoft.com/technet/pr...ons/7fcaa311-bc19-479d-9a4e-179704dfe08f.mspx
both links provide steps to troubleshoot replication issues


to be clear:
the destination DC is the receiving DC
the source DC is the sending DC




--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
MVP Windows Server - Directory Services
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
 
Hi Guys,

well we are making headway. We ended up bringing in a AD expert someone
recomended. You'll be happy to know his diagnosis pretty much correlates to
what you have all come up with. It does look as if DC3 was blocked because
of tombstones entities, but is looks as if some of the SIDs are missing as
well. Apparently I did one thing which is a bit of a no no, and that I
re-used a hostname without deleting it first from AD. It was a silly thing
to do but it was a a very busy and hectic time and I just rushed it through.

What we have decided to do is to basically do a force removal. I've
successfully promoted another server to be a DC and the promotion went fine
and it is replicating ok, so the whole replication process seems ok. I'm
just going to apply SP1 to the DCs and then use the new tools that come with
SP1 to for a force removal of DC3.

I would just like to thank you all for the amount of time and effort you
have all put into this and I also thought you would like to know that your
diagnosis was pretty well spot on. If any of you were in Melb, Australia
I'ld buy you all a slab of beer! Of course I'm only saying that because none
of your are in Melb, Australia :)

One good thing to come out of this is that it looks like my work as agreed
to send me on some MS AD training courses. So with any luck they will put me
through the Administrator and Engineer courses for accreditation. Woot.

Once again many thanks to you all.

Regards

Craig



"Jorge de Almeida Pinto [MVP]"
 
In
Craig Matchan said:
Hi Guys,

well we are making headway. We ended up bringing in a AD expert
someone recomended. You'll be happy to know his diagnosis pretty much
correlates to what you have all come up with. It does look as if DC3
was blocked because of tombstones entities, but is looks as if some
of the SIDs are missing as well. Apparently I did one thing which is
a bit of a no no, and that I re-used a hostname without deleting it
first from AD. It was a silly thing to do but it was a a very busy
and hectic time and I just rushed it through.
What we have decided to do is to basically do a force removal. I've
successfully promoted another server to be a DC and the promotion
went fine and it is replicating ok, so the whole replication process
seems ok. I'm just going to apply SP1 to the DCs and then use the new
tools that come with SP1 to for a force removal of DC3.

I would just like to thank you all for the amount of time and effort
you have all put into this and I also thought you would like to know
that your diagnosis was pretty well spot on. If any of you were in
Melb, Australia I'ld buy you all a slab of beer! Of course I'm only
saying that because none of your are in Melb, Australia :)

One good thing to come out of this is that it looks like my work as
agreed to send me on some MS AD training courses. So with any luck
they will put me through the Administrator and Engineer courses for
accreditation. Woot.
Once again many thanks to you all.

Regards

Craig
Click to expand...

You know, just for saying that, I'm going to get a ticket right now and fly
down there just to get that beer!

Cheers!

:-)

Ace
 
Back
Top