Problems replicating after long time disconnection.

Hi All,

After having had a DC disconnected for a couple of months, i'm having
trouble replicating with it.

I have 2 domain controllers. One of them (DC1) was shipped to a remote
site, so I followed the instructions in:
Preparing an Existing Domain Controller for Shipping and Long-Term
Disconnection:
http://www.microsoft.com/technet/pro...c0fc9cd77.mspx

And:
Reconnecting a Domain Controller After a Long-Term Disconnection:
http://www.microsoft.com/technet/pro...009fc66d1.mspx

When the shipped server was powered back on, it was running for a week
or so, before being able to reach the local domain controller.

Now the two domain controllers are finally able to see each other over
a VPN tunnel, but there seems to be some problems replicating.

When trying to replicate manually, i'm getting an error that "The
target principal name is incorrect".
Trying to manage the local DC (DC2) *from* the remote DC (DC1) gives an
"Access Denied" error.

It actually seems as if the replication works from DC1 to DC2, but not
the other way around.

The event log on DC1 gives quite a lot of KRB_AP_ERR_MODIFIED kerberos
errors, so i'm assuming that one of the DCs have had some sort of
machine account change, without the other DC being aware of it.

I think that i have to look into netdom, as stated in several KB
articles.
(disable kerberos, netdom reset, restart, start kerberos)
Any other ideas?

Was just wondering if anyone has any other input to the issue.
As i understand the above articles, i shouldn't have had any problems
reconnecting. What i do think could have been a problem, is that DC1
was allowed to start without being able to talk to the other. Comments
on that?

DC2 is holding all FSMO roles and can actually access DC1 quite fine.
DC1 cannot access anything on DC2

Thanks

--
/Sune
..

Hi Sune,
Do both DC's cleanly resolve each other correctly? Make sure there aren't
any old records in DNS pointing to the previous IP of the relocated DC. Also
... is time correctly syncronised? If you could post the actual eventlog
message you are getting that would help.
Thanks,
Mark

"Sune T. Tougaard" wrote:

> Hi All,
>
> After having had a DC disconnected for a couple of months, i'm having
> trouble replicating with it.
>
> I have 2 domain controllers. One of them (DC1) was shipped to a remote
> site, so I followed the instructions in:
> Preparing an Existing Domain Controller for Shipping and Long-Term
> Disconnection:
> http://www.microsoft.com/technet/pro...c0fc9cd77.mspx
>
> And:
> Reconnecting a Domain Controller After a Long-Term Disconnection:
> http://www.microsoft.com/technet/pro...009fc66d1.mspx
>
> When the shipped server was powered back on, it was running for a week
> or so, before being able to reach the local domain controller.
>
> Now the two domain controllers are finally able to see each other over
> a VPN tunnel, but there seems to be some problems replicating.
>
> When trying to replicate manually, i'm getting an error that "The
> target principal name is incorrect".
> Trying to manage the local DC (DC2) *from* the remote DC (DC1) gives an
> "Access Denied" error.
>
> It actually seems as if the replication works from DC1 to DC2, but not
> the other way around.
>
> The event log on DC1 gives quite a lot of KRB_AP_ERR_MODIFIED kerberos
> errors, so i'm assuming that one of the DCs have had some sort of
> machine account change, without the other DC being aware of it.
>
> I think that i have to look into netdom, as stated in several KB
> articles.
> (disable kerberos, netdom reset, restart, start kerberos)
> Any other ideas?
>
> Was just wondering if anyone has any other input to the issue.
> As i understand the above articles, i shouldn't have had any problems
> reconnecting. What i do think could have been a problem, is that DC1
> was allowed to start without being able to talk to the other. Comments
> on that?
>
> DC2 is holding all FSMO roles and can actually access DC1 quite fine.
> DC1 cannot access anything on DC2
>
> Thanks
>
> --
> /Sune
> ..
>
>

Hi Mark,

No problems resolving. Actually no IPs has been changed.

Time seems correct and in sync.

The full event log goes like:
Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 31/03/2006
Time: 00:30:48
User: N/A
Computer: DC1
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the
server host/dc2.dom01.tld. The target name used was DOM01\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 (DOM01.TLD),
and the client realm. Please contact your system administrator.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

And as above, error messages like "Access Denied" and "The target
principal name is incorrect" shows when trying to manage/manually
replicate from DC1 to DC2.

I'll go deeper with netdiag and dcdiag later, but right now everything
seems to point at the netdom procedure, i think.

Thanks.

--
/Sune

You cannot leave DCs disconnected from each other over 60 days. If you do,
then there are things you have to do to get them going again. Unfortunately
I cannot remember any specifics on this. But you might find details on MS's
site if you do a search.


--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com



"Sune T. Tougaard" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> Hi Mark,
>
> No problems resolving. Actually no IPs has been changed.
>
> Time seems correct and in sync.
>
> The full event log goes like:
> Event Type: Error
> Event Source: Kerberos
> Event Category: None
> Event ID: 4
> Date: 31/03/2006
> Time: 00:30:48
> User: N/A
> Computer: DC1
> Description:
> The kerberos client received a KRB_AP_ERR_MODIFIED error from the
> server host/dc2.dom01.tld. The target name used was DOM01\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 (DOM01.TLD),
> and the client realm. Please contact your system administrator.
>
> For more information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp.
>
> And as above, error messages like "Access Denied" and "The target
> principal name is incorrect" shows when trying to manage/manually
> replicate from DC1 to DC2.
>
> I'll go deeper with netdiag and dcdiag later, but right now everything
> seems to point at the netdom procedure, i think.
>
> Thanks.
>
> --
> /Sune
>

Before the disconnection, the tombstone lifetime was increased to 360
days.
If i recall correctly, the standard for a Win2k3 server is 60 days. A
Win2k3 server with SP1 applied is 180 days. We increased to 360 (better
safe than sorry).
As far as i can tell from the article above, if the tombstone lifetime
(plus replication delay) isn't exceeded, then there shouldn't be any
problems reconnecting.

Was that the thing you were thinking about?
If so, then i think that i'm on the safe side.

Thanks.

--
/Sune

"Sune T. Tougaard" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> Was that the thing you were thinking about?
> If so, then i think that i'm on the safe side.

Yes, I think that was it. I never heard the term "tombstone" used when the
guy spoke, but I suspect that it was the same thing. It was at one of the
TechNet meetings.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

I'd also make sure that no client machine has recieved the same IP as a DC in
the past and registered itself. If that record is still lingering you might
see problems. Thought I'd mention it because I had weird "Access Denied"
errors for a while that had me stumped until I delved into our dns records.
And back to your machine password possibility which seems likely looking
through technet ... have a look at the pwdLastSet attribute for both DC
machine accounts on both DC's. If the attribute is different depending on
which dc you are querying then that is probably it.
Hope this helps,
Mark

"Phillip Windell" wrote:

> "Sune T. Tougaard" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ups.com...
> > Was that the thing you were thinking about?
> > If so, then i think that i'm on the safe side.
>
> Yes, I think that was it. I never heard the term "tombstone" used when the
> guy spoke, but I suspect that it was the same thing. It was at one of the
> TechNet meetings.
>
> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>
>

I would ask in the active directory newsgroup. I think it is an AD
problem. Something to do with the secure channel between the DCs.

Mark wrote:
> I'd also make sure that no client machine has recieved the same IP as
> a DC in the past and registered itself. If that record is still
> lingering you might see problems. Thought I'd mention it because I
> had weird "Access Denied" errors for a while that had me stumped
> until I delved into our dns records. And back to your machine
> password possibility which seems likely looking through technet ...
> have a look at the pwdLastSet attribute for both DC machine accounts
> on both DC's. If the attribute is different depending on which dc you
> are querying then that is probably it.
> Hope this helps,
> Mark
>
> "Phillip Windell" wrote:
>
>> "Sune T. Tougaard" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed) ups.com...
>>> Was that the thing you were thinking about?
>>> If so, then i think that i'm on the safe side.
>>
>> Yes, I think that was it. I never heard the term "tombstone" used
>> when the guy spoke, but I suspect that it was the same thing. It was
>> at one of the TechNet meetings.
>>
>> --
>> Phillip Windell [MCP, MVP, CCNA]
>> www.wandtv.com

I'll take a closer look at the DNS.

The pwdLastSet attribute does indeed look different.

Looking at DC2 from DC2:
w32tm /ntte 127855893652491059
147981 08:36:05.2491059 - 28-02-2006 10:36:05 (local time)

Looking at DC1 from DC2:
w32tm /ntte 127881312151718423
148010 18:40:15.1718423 - 29-03-2006 20:40:15 (local time)

Looking at DC1 from DC1:
w32tm /ntte 127776735450161753
147889 17:45:45.0161753 - 28-11-2005 19:45:45 (local time)

Looking at DC2 from DC1:
w32tm /ntte 127777376059440469
147890 11:33:25.9440469 - 29-11-2005 13:33:25 (local time)

So i guess that first of all, the records aren't replicating back to
the DC1 server.
Second, the DC1 server must somehow have been able to change it's
machine account (29-03-2006), without being able to see that change in
its own records afterwards.

If the inital machine account change (on 29-03-2006) from DC1 is the
reason why it won't replicate, then why on earth did it do that ? ;-)
If the reason why it won't replicate is, that the DC2 server has
changed its own machine account a couple of times without the DC1
knowing, then i guess that there are other issues to take care of, than
just the tombstone lifetime, for the "Long-Term Disconnection"
procedure to work.

Comments?

Thanks.

--
/Sune

I think it's an AD issue too.
I'll get my self over there.

Thanks to all for their inputs.

--
/Sune