NTDS Replication event 2023 error 8589

Text from event log entry is:
The local domain controller was unable to replicate changes to the following
remote domain controller for the following directory partition.

Remote domain controller:
881ebe49-647f-46f2-8017-b0a14f94b25a._msdcs.xports.nhs.uk
Directory partition:
DC=ForestDnsZones,DC=xports,DC=nhs,DC=uk

The local domain controller cannot complete demotion.

User Action
Investigate why replication between these two domain controllers cannot be
performed. Then, try to demote this domain controller again.

Additonal Data
Error value:
8589 The DS cannot derive a service principal name (SPN) with which to
mutually authenticate the target server because the corresponding server
object in the local DS database has no serverReference attribute.

It mentions demotion but the source and target servers have never been
demoted.
The problem is with all the servers in this sub-domain.

My question is:
Which server object is it talking about that deos not have a serverreference
attribute?

Any help you can give me with move me onto a solution and the next problem.

Type:

nslookup -type=cname
881ebe49-647f-46f2-8017-b0a14f94b25a._msdcs.xports.nhs.uk


At a command prompt to resolve the GUID CNAME to an A record.

If it doesn't resolve, that is your problem.

--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net

Paul, it resolved to the server name ie

881ebe49-647f-46f2-8017-b0a14f94b25a._msdcs.xports.nhs.uk canonical
name =
sjhdc01.xports.nhs.uk

Regards, Major.

"Paul Williams [MVP]" wrote:

> Type:
>
> nslookup -type=cname
> 881ebe49-647f-46f2-8017-b0a14f94b25a._msdcs.xports.nhs.uk
>
>
> At a command prompt to resolve the GUID CNAME to an A record.
>
> If it doesn't resolve, that is your problem.
>
> --
> Paul Williams
> Microsoft MVP - Windows Server - Directory Services
> http://www.msresource.net | http://forums.msresource.net
>
>
>

> Which server object is it talking about that deos not have a
> serverreference attribute?

Sorry, misread your question. The corresponding server object is the object
that you see in DSSITE.MSC for the DC.

--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net

OK. If I open sites and services and locate the DC that is getting these
events is it that object that does not have a serverreference attribute or
one of its connected servers?

Is it possible to fix this by using for example adsiedit?

Regards, Major.


"Paul Williams [MVP]" wrote:

> > Which server object is it talking about that deos not have a
> > serverreference attribute?
>
> Sorry, misread your question. The corresponding server object is the object
> that you see in DSSITE.MSC for the DC.
>
> --
> Paul Williams
> Microsoft MVP - Windows Server - Directory Services
> http://www.msresource.net | http://forums.msresource.net
>
>
>

> Is it possible to fix this by using for example adsiedit?

Yes, it sure is:
-- http://support.microsoft.com/?id=312862

--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net

Paul, you are a star.
Thank you very much for your help.
From you guidance and following the KB article helped me fix the problem.
Regards, Major.

"Paul Williams [MVP]" wrote:

> > Is it possible to fix this by using for example adsiedit?
>
> Yes, it sure is:
> -- http://support.microsoft.com/?id=312862
>
> --
> Paul Williams
> Microsoft MVP - Windows Server - Directory Services
> http://www.msresource.net | http://forums.msresource.net
>
>
>

Paul, sorry spoke too soon. Too eager to get this fixed I guess.
The event error came back.
I did use adsiedit to clean up the SYSVOL replication partners.
There were some old DC entries in there.

How do I use adsiedit to select the specific dc that the event error is
talking about ie SJHDC01.
It is not a sysvol replica partner of the DC where the event error is
occuring as it is in the parent domain.

Regards, Major.


"Paul Williams [MVP]" wrote:

> > Is it possible to fix this by using for example adsiedit?
>
> Yes, it sure is:
> -- http://support.microsoft.com/?id=312862
>
> --
> Paul Williams
> Microsoft MVP - Windows Server - Directory Services
> http://www.msresource.net | http://forums.msresource.net
>
>
>

SYSVOL doesn't replicate forest wide. It is a [special] domain-based DFS
root. Can you please clarify what changes have you made, and what errors
are you now getting? Sorry if you've stated some of this, I just want to be
sure where we're at.

--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net

The changes I made were in system, file replication. That was waht the KB
article was about.
The error I am getting is the same as before event 2003 error 8589.

The local domain controller was unable to replicate changes to the following
remote domain controller for the following directory partition.

Remote domain controller:
881ebe49-647f-46f2-8017-b0a14f94b25a._msdcs.xports.nhs.uk
Directory partition:
DC=ForestDnsZones,DC=xports,DC=nhs,DC=uk

The local domain controller cannot complete demotion.

User Action
Investigate why replication between these two domain controllers cannot be
performed. Then, try to demote this domain controller again.

Additonal Data
Error value:
8589 The DS cannot derive a service principal name (SPN) with which to
mutually authenticate the target server because the corresponding server
object in the local DS database has no serverReference attribute.

Regards, Major.

"Paul Williams [MVP]" wrote:

> SYSVOL doesn't replicate forest wide. It is a [special] domain-based DFS
> root. Can you please clarify what changes have you made, and what errors
> are you now getting? Sorry if you've stated some of this, I just want to be
> sure where we're at.
>
> --
> Paul Williams
> Microsoft MVP - Windows Server - Directory Services
> http://www.msresource.net | http://forums.msresource.net
>
>
>

Anyone any other thoughts on this?
I realise you are all very busy looking after your own systems and helping
other users but if you could give me a hint on where to look I will go and
look there.
Any help you can give will help me loads.
Thanks.
Regards, Major.

"Mr Major Thorburn" wrote:

> Text from event log entry is:
> The local domain controller was unable to replicate changes to the following
> remote domain controller for the following directory partition.
>
> Remote domain controller:
> 881ebe49-647f-46f2-8017-b0a14f94b25a._msdcs.xports.nhs.uk
> Directory partition:
> DC=ForestDnsZones,DC=xports,DC=nhs,DC=uk
>
> The local domain controller cannot complete demotion.
>
> User Action
> Investigate why replication between these two domain controllers cannot be
> performed. Then, try to demote this domain controller again.
>
> Additonal Data
> Error value:
> 8589 The DS cannot derive a service principal name (SPN) with which to
> mutually authenticate the target server because the corresponding server
> object in the local DS database has no serverReference attribute.
>
> It mentions demotion but the source and target servers have never been
> demoted.
> The problem is with all the servers in this sub-domain.
>
> My question is:
> Which server object is it talking about that deos not have a serverreference
> attribute?
>
> Any help you can give me with move me onto a solution and the next problem.
>
>

Sorry for the delay - I wanted to verify this in one of my customer
environments - they have several domains in a forest. I haven't been able
to yet, as I've been out of the office.

Try adding the necessary NTDS Settings object DN into the serverReference
attribute, regardless of domain. This is like so:

CN=NTDS Settings, CN=<Computer name>, CN=Servers, CN=<Site name>, CN=Sites,
CN=Configuration, DC=<forest root>,DC=com


e.g.

CN=NTDS Settings, CN=LON-MIIS, CN=Servers, CN=Default-First-Site-Name,
CN=Sites, CN=Configuration, DC=fabrikam,DC=com


Note. There appears to be a typo in the DN listed in the KB. The above is
correct - pasted from a VM.

--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net

Paul, thanks for getting back to me. ok about delays. I understand how busy
you must be. One of you and lots of us with questions.

The KB article talks about FRS SYSVOL share. The DC referenced in the event
is in a parent domain. I thought that the SYSVOL share was domain specific.
Should there be a CN entry for the server in the event on this DC in
ADSIEDIT under System, File Replication Service, Domain System Volume (SYSVOL
share)?
If not which CN would contain the ServerReference?
Regards, Major.

"Paul Williams [MVP]" wrote:

> Sorry for the delay - I wanted to verify this in one of my customer
> environments - they have several domains in a forest. I haven't been able
> to yet, as I've been out of the office.
>
> Try adding the necessary NTDS Settings object DN into the serverReference
> attribute, regardless of domain. This is like so:
>
> CN=NTDS Settings, CN=<Computer name>, CN=Servers, CN=<Site name>, CN=Sites,
> CN=Configuration, DC=<forest root>,DC=com
>
>
> e.g.
>
> CN=NTDS Settings, CN=LON-MIIS, CN=Servers, CN=Default-First-Site-Name,
> CN=Sites, CN=Configuration, DC=fabrikam,DC=com
>
>
> Note. There appears to be a typo in the DN listed in the KB. The above is
> correct - pasted from a VM.
>
> --
> Paul Williams
> Microsoft MVP - Windows Server - Directory Services
> http://www.msresource.net | http://forums.msresource.net
>
>
>

> The KB article talks about FRS SYSVOL share. The DC referenced in the
> event is in a parent domain. I thought that the SYSVOL share was domain
> specific.

It is. That's why the KB threw me. Although I've had a re-think and I
think I know what's going on... (famous last words before hiding away in
shame)


> Should there be a CN entry for the server in the event on this DC in
> ADSIEDIT under System, File Replication Service, Domain System Volume
> (SYSVOL share)?

No.


> If not which CN would contain the ServerReference?

The serverReference attribute should point to the NTDS Settings object for
this DC. Basically, the nTFRSMember object defines what servers are part of
a given FRS replica set. There are several important attributes of these
objects, two of which are fRSComputerReference and serverReference. The
former holds the DN of the FRS member that this object represents. The
latter holds the DN of the connection object for the FRS member that this
object represents. The reason being that SYSVOL uses the same connection
objects as DS replication.

So, you need to verify that both servers point to themselves, or rather,
their own connection object. The parent DCs member object should have its
own NTDS Settings object as its serverReference attribute, and the other DC
in question should have it's own.

As an example, you have four DCs - two per domain. We'll focus on one from
each domain. In this example there are two nTFRSMember objects that we're
concerned with (one in each domain):

CN=PDC01, CN=Domain System Volume (SYSVOL), CN=File Replication Service,
CN=System, DC=forest-root, DC=com

CN=CDC01, CN=Domain System Volume (SYSVOL), CN=File Replication Service,
CN=System, DC=child-domain, DC=forest-root, DC=com


These should have a serverReference attribute that points to something like
this:

CN=NTDS Settings, CN=PDC01, CN=Servers, CN=ParentDomainSite, CN=Sites,
CN=Configuration, DC=forest-root, DC=com

CN=NTDS Settings, CN=CDC01, CN=Servers, CN=ChildDomainSite, CN=Sites,
CN=Configuration, DC=child-domain, DC=forest-root, DC=com


Hope that makes sense.

--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net

Paul, thanks for the excellent explanation which I followed with no problem.
I checked the serverReference and the field is correct for all the DCs in
all the domains.
The confusion for me is that the event log entry is referring to a server
that is not in this domain. On this particvular DC it is for a DC from the
parent domain. If I look on the parent domain it has the same event but for
this DC.
It looks like there is a link missing.

I should have pointed out earlier that this ActiveDirectory setup has been
established via an Active Directory disaster recovery exercise, following all
the good guidelines from MS, and is all running on virtual systems.
It was established because we do not have a test facility.
I have carried out things like installation of SP1, promotions, demotions,
move of DCs, rename of DCs and raising the forest to run in native mode and
all has been successful.
What I am now trying to achieve now is a domain rename and this event error
is what is stopping me do that.

We have an opertunity here to do what we like.
if we want to experiment in something I will take a backup of all the images
and we can do anything we like as we would have a full recovery available.

Regards, Major.

"Paul Williams [MVP]" wrote:

> > The KB article talks about FRS SYSVOL share. The DC referenced in the
> > event is in a parent domain. I thought that the SYSVOL share was domain
> > specific.
>
> It is. That's why the KB threw me. Although I've had a re-think and I
> think I know what's going on... (famous last words before hiding away in
> shame)
>
>
> > Should there be a CN entry for the server in the event on this DC in
> > ADSIEDIT under System, File Replication Service, Domain System Volume
> > (SYSVOL share)?
>
> No.
>
>
> > If not which CN would contain the ServerReference?
>
> The serverReference attribute should point to the NTDS Settings object for
> this DC. Basically, the nTFRSMember object defines what servers are part of
> a given FRS replica set. There are several important attributes of these
> objects, two of which are fRSComputerReference and serverReference. The
> former holds the DN of the FRS member that this object represents. The
> latter holds the DN of the connection object for the FRS member that this
> object represents. The reason being that SYSVOL uses the same connection
> objects as DS replication.
>
> So, you need to verify that both servers point to themselves, or rather,
> their own connection object. The parent DCs member object should have its
> own NTDS Settings object as its serverReference attribute, and the other DC
> in question should have it's own.
>
> As an example, you have four DCs - two per domain. We'll focus on one from
> each domain. In this example there are two nTFRSMember objects that we're
> concerned with (one in each domain):
>
> CN=PDC01, CN=Domain System Volume (SYSVOL), CN=File Replication Service,
> CN=System, DC=forest-root, DC=com
>
> CN=CDC01, CN=Domain System Volume (SYSVOL), CN=File Replication Service,
> CN=System, DC=child-domain, DC=forest-root, DC=com
>
>
> These should have a serverReference attribute that points to something like
> this:
>
> CN=NTDS Settings, CN=PDC01, CN=Servers, CN=ParentDomainSite, CN=Sites,
> CN=Configuration, DC=forest-root, DC=com
>
> CN=NTDS Settings, CN=CDC01, CN=Servers, CN=ChildDomainSite, CN=Sites,
> CN=Configuration, DC=child-domain, DC=forest-root, DC=com
>
>
> Hope that makes sense.
>
> --
> Paul Williams
> Microsoft MVP - Windows Server - Directory Services
> http://www.msresource.net | http://forums.msresource.net
>
>
>