On Tue, Aug 21, 2012 at 4:21 PM, Greg Olson <[email protected]> wrote: > Probably won't work, but since this is a test domain on vm, what happens if > you simply change all the clocks back on all of them (and the vm hosts)?
The VM hosts are also my production VM machines, so that won't work ... > -G > > > -----Original Message----- > From: Michael Leone [mailto:[email protected]] > Sent: Tuesday, August 21, 2012 1:02 PM > To: NT System Admin Issues > Subject: Re: Event ID 2042: It has been too long since this machine replicated > > On Tue, Aug 21, 2012 at 3:43 PM, Christopher Bodnar > <[email protected]> wrote: >> >> I haven't used /removelingeringobjects for the same purpose you are having, >> but I have used it in a USN rollback scenario. In my instance the event logs >> clearly indicated what container the issue was in. For me that was the >> configuration container. You should be able to find this somewhere in the >> event logs, not exactly sure where. Once you know what container to target, >> you need to establish what your source of truth will be. What DC is "clean" . > > There is only 1 DC in the parent domain. > >>Once you decide that, you should be good to go. Yes, the DC Object GUID from >>the repadmin /showrepl is what you will need to use. For example: >> >> Repadmin /removelingeringobjects ACMEDC0 >> 2ba99ac3-8a25-4711-7d84-c87c44902d0a CN=Configuration,DC=acme,DC=com >> Repadmin /removelingeringobjects ACMEDC2 >> 2ba99ac3-8a25-4711-7d84-c87c44902d0a CN=Configuration,DC=acme,DC=com >> Repadmin /removelingeringobjects ACMEDC3 >> 2ba99ac3-8a25-4711-7d84-c87c44902d0a CN=Configuration,DC=acme,DC=com >> Repadmin /removelingeringobjects ACMEDC4 >> 2ba99ac3-8a25-4711-7d84-c87c44902d0a CN=Configuration,DC=acme,DC=com >> Repadmin /removelingeringobjects ACMEDC5 >> 2ba99ac3-8a25-4711-7d84-c87c44902d0a CN=Configuration,DC=acme,DC=com > > So, in my case, I would run the command on the parent DC, referencing the > parent DC. Do I then run the same command on the 2 DCs in the child domain? I > don't run the "removelingeringobjects" on the parent DC, but referencing the > child DCs, do I ? > >> >> >> Where 2ba99ac3-8a25-4711-7d84-c87c44902d0a is the DC object GUID for your >> clean DC you obtained from the repadmin /showreply command. >> >> >> Christopher Bodnar >> Enterprise Architect I, Corporate Office of Technology:Enterprise >> Architecture and Engineering Services Tel 610-807-6459 >> 3900 Burgess Place, Bethlehem, PA 18017 [email protected] >> >> >> >> The Guardian Life Insurance Company of America >> >> www.guardianlife.com >> >> >> >> >> >> >> From: Michael Leone <[email protected]> >> To: "NT System Admin Issues" <[email protected]> >> Date: 08/21/2012 02:54 PM >> Subject: Event ID 2042: It has been too long since this machine >> replicated >> ________________________________ >> >> >> >> Hey all. Been a while since I've had time to read or post. But I'm >> back, looking for advice. :-) >> >> I have a test domain (this is a private domain running on a VMware >> server, self-contained on their own private vSwitch, completely >> separate from my production domain), consisting of a parent (1 DC) and >> child domain (2 DCs). This is my testing domain. Unfortunately, >> apparently the VMs have been turned off too long, as now I have no >> replication between the DCs, giving the error in the subject line). >> Apparently they've been turned off since 2012-06-20, and are now there >> beyond their tombstone life. (figures I couldn't have looked at this >> LAST week, when it still would have been within their tombstone >> lifetime. Oh, well ...) >> >> This is a AD 2008 domain; each DC is Win2008 R2. >> >> In reading through the options to fix this, I can't demote or re-install the >> DCs (not easily, anyway). So I want to try the second suggestion: >> >> 2. Use the "repadmin /removelingeringobjects" tool to remove inconsistent >> deleted objects and then resume replication. >> >> The documentation on the exact syntax of the "/removelingeringobjects" is a >> bit unclear to me. Obviously I have to run this on the parent DC, and one >> one (both?) of the child DCs. >> >> Some questions before running that: >> >> SourceDCGUID-Run the command repadmin /showrepl AuthDCname |more, where >> AuthDCname is the host name of the domain controller that you selected as >> authoritative. Substitute the first DSA object GUID that appears for >> <SourceDCGUID>. >> >> I find this odd ... when I run "repadmin /showrepl <parent DC>" on the >> parent DC, I don't see a "DSA object GUID:"; I see a "DC object GUID"; is >> that the same thing? (and why doesn't it say DSA? My production DC says >> "DSA". But then, production has had updates applied to it, and I couldn't >> even begin to tell you when the private domain was updated - no Internet >> access). >> >> LDAPPartition-The Lightweight Directory Access Partition (LDAP) name of the >> partition that you are targeting. For example, if the lingering objects are >> in the domain partition of the contoso.com domain, substitute >> dc=contoso,dc=com for <LDAPPartition>. >> >> How am I supposed to know where the lingering objects are, before running >> it? :-) Also, what if there are in a different partition than the domain >> partition; what's the syntax for that? >> >> >> I ran the "repadmin /removelingeringobjects" with the /advisory_mode switch, >> as recommended, and it just came back that "RemoveLingeringObjects >> successful on <parent DC FQDN>". >> >> Is it supposed to say that? Seems odd - no indication that this is >> advisory_mode, etc. >> >> Do I just go and do the same on each of the child DCs? >> >> Thanks for listening to my long-winded whine ... >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to [email protected] >> with the body: unsubscribe ntsysadmin >> >> ----------------------------------------- This message, and any attachments >> to it, may contain information that is privileged, confidential, and exempt >> from disclosure under applicable law. If the reader of this message is not >> the intended recipient, you are notified that any use, dissemination, >> distribution, copying, or communication of this message is strictly >> prohibited. If you have received this message in error, please notify the >> sender immediately by return e-mail and delete the message and any >> attachments. Thank you. >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to [email protected] >> with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
