Quantcast
Channel: Directory Services forum
Viewing all articles
Browse latest Browse all 31638

Event ID 1863 and 1864 after in-place DC refresh from 2008 R2 to 2012

$
0
0

Our environment is quite simple, we have 3 DCs and one site.

DC1 (FSMO holder)

DC2

DC3

They were all 2008 R2 servers with the DFL and FFL both on 2008 R2. Recently I have been upgrading one at a time to server 2012. When I say upgrade, I am building a brand new server as 2012 then cutting the old server over to it and renaming/re-IPing the new server to match the old server. I am following similar steps as provided here: http://msmvps.com/blogs/acefekay/archive/2010/10/09/remove-an-old-dc-and-introduce-a-new-dc-with-the-same-name-and-ip-address.aspx

Immediately after moving DC3 to 2012, I started receiving 3 errors per day under the Directory Service event log. They were all event ID 1864 (replication) and say

"This directory server has not received replication information from a number of directory servers within the configured latency interval. "

There is one event for each of the following:

Directory partition:

CN=Schema,CN=Configuration,DC=intra,DC=cas,DC=org

CN=Configuration,DC=intra,DC=cas,DC=org

DC=intra,DC=cas,DC=org

Interesting enough, after 60 days the event went away (I believe our tombstone life is set to 60 days). This past weekend I did DC2 and now I have the exact same error 3 times a day. This time it is labeled as event ID 1863 but has the exact same wording. I suspect after 60 days it too will disappear. But I am curious as to why I am getting it. Can I make it go away now and did I do something wrong? Our DCs replicate every 5 minutes and there was at least 10-15 minutes in-between demoting the old server (and removing it from the domain) and promoting the new one.

When running repadmin /showrepl  - all of the replications are successful.

When running

repadmin /showvector /latency <partition-dn>   (as suggested in the error details)

I get:

C:\Users\OURUSER>repadmin /showvector /latency <OUR PARTITION-DN INFO>
Caching GUIDs.
..
e11c3ac2-18e7-4eb8-834c-c6670d1f4f8d @ USN     81230 @ Time (unknown)
ba407c28-b8ce-449a-89fe-f27b1521ec98 @ USN   1628347 @ Time (unknown)
5856b6d1-cd55-43c9-a00e-e3a9ffdf6fe8 @ USN      7799 @ Time (unknown)
54457437-3ad4-448a-900d-cdee9386828e @ USN     21734 @ Time (unknown)
e8b40225-5392-4a7e-9473-69f6007f0e30 @ USN  25005091 @ Time (unknown)
65a00f16-4842-46b1-a4fc-7c63eb53c3d8 @ USN  30991256 @ Time 2005-10-27 17:33:58
8e4f8edc-2df5-4d3f-a83e-7fe303dd5bb8 @ USN   3141255 @ Time 2007-09-14 16:40:24
378eb54f-bbd1-4f31-8ee0-bb363e3baa54 @ USN   2332345 @ Time 2008-12-13 03:09:10
12dafb44-873d-472a-af81-1dcbce83d691 @ USN   3410119 @ Time 2011-02-19 12:04:20
e4cdc57d-87a9-44a6-9462-59258377e449 @ USN 134210124 @ Time 2011-09-17 20:46:50
6fa89ebc-26d2-439c-b481-4db8c8a1ead0 @ USN 117915771 @ Time 2011-09-17 22:09:06
b9f30932-31f3-496d-baa7-e6dba9436373 @ USN  77103549 @ Time 2014-02-15 18:32:20
OURSITE\DC2 (deleted DSA)     @ USN  94389169 @ Time 2014-04-19 18:05:39
OURSITE\DC3                   @ USN   6690499 @ Time 2014-04-22 11:46:45
OURSITE\DC1                   @ USN 127299088 @ Time 2014-04-22 11:46:55
OURSITE\DC2                   @ USN    398281 @ Time 2014-04-22 11:46:58

From what I've read, this information provided is static and cannot be changed/deleted/cleaned up. Once OURSITE\DC2 (deleted DSA) runs the course of being tombstoned and becomes just a GUID listed, I think our errors will go away.

Doesn't the demotion take care of any metadata that I would have to worry about? I have the suspicion that I am having these issues due to keeping the same name and IP, I am just not sure where I went wrong.

 


Viewing all articles
Browse latest Browse all 31638

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>