I may be slow but I finally saw this. Piss off Dean. ;o)


Anyway, there are a few people I won't argue with about certain things

1. Dean and Phantoms/IM functionality.  
2. ~Eric and debugging / dump diving. He also knows a good burger when he
sees it.
3. Brett and anything ESE related or AD backup/Restore
4. Guido and disaster recovery. 
5. Tony Murray and wine




-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
Sent: Tuesday, August 16, 2005 1:37 PM
To: Send - AD mailing list
Subject: RE: [ActiveDir] Question on Replication Topology

I managed to locate a detailed explanation of the IM's behavior I wrote some
time back, I've pasted it below in the hopes that it will clear up some of
the confusion.

---
The IM locates phantom records within the local DIT.  Phantoms are injected
database rows, they are structural entities primarily used to maintain
database level cross-references between a local object and a
foreign-domain/same-forest object.  They also serve a couple of other
low-level purposes.  Note we refer to phantoms as records as opposed to
objects since phantoms are effectively outside the scope of the directory
itself.

Phantoms maintain only 3 attributes: dn, objectGUID and objectSID (where
applicable). Since phantoms represent objects in foreign domains,
administrative updates to that foreign object's dn or SID cause the phantom
to become stale (i.e. the phantom's dn or objectSID no longer reflect that
of the object it was created to locally represent -- somewhat like the
result when renaming the target file that a Windows Explorer shortcut points
to).

The IM scans the local DIT/DIB and collates a pre-defined number of
phantoms, the phantom's objectGUID is used to locate the (partial copy of
the) real object that exists in a GC (the GC is assumed to have an ~up to
date copy).  The dn and objectSID of the phantom are then compared against
the corresponding attributes on the object maintained by the GC.  If
everything is equal, the IM continues to the next phantom, if the dn or the
objectSID do not match, the local phantom is improved with the GC's more
up-to-date values.  If the object cannot be located, it is deemed to have
been deleted and the corresponding local phantom is also deleted.  Note that
additional measures are taken by the IM in order to ensure that the changes
or deletions introduced are replicated to all other DCs within the same
domain, I haven't described those actions here since it's somewhat overkill
but they're referenced below by the steps I provided to locate the changes
made.

To determine what the IM did, 2 approaches (outside of attaching a
debugger) spring to mind.  The first is to crank up DS logging but that
would carry an awful lot of event-baggage with it; the second is query for
the replicable entries created by the IM.  For once in my life I'm going to
recommend the use of one of Joe Richards' tools :o) -- specifically
ADFIND.EXE (it's not that I don't like his tools, I just don't like him ...
I'm teasing ... I prefer, where possible, to use tools supplied with the
base media but there simply aren't any capable of doing the job this well).
Download and run the following command within a command shell (obviously,
the dn needs substituting) -

C:\>adfind -b "cn=Deleted Objects,dc=child,dc=test,dc=com" -showdel -f
"objectclass=infrastructureUpdate" dnReferenceUpdate whenChanged -extname
-rsort whenChanged -nodn -s onelevel

The resulting output displays the objectGUID, objectSID and dn of any
phantoms that were locally improved (most recent improvements ordered to the
top).  By default, the result set will contain any phantom-alterations that
have occurred within the last 2 months (unless the forest was constructed
using 2K3 SP1).  Note that you may need to increase query timeouts depending
on the size of the DIT and/or the number of infrastructureUpdate instances.

The IM itself can be triggered manually using a variety of tools, here's a
technique using another of Joe's -

C:\>admod -h im_roleholder -b "" checkPhantoms::1

--
Dean Wells
MSEtechnology
* Email: [EMAIL PROTECTED]
http://msetechnology.com


List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to