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/
