有很多 TechNet 文章，例如这个表示如果基础结构主机也是全局目录，则幻像对象不会得到更新，但除此之外，没有太多关于什么的深入信息实际上在这种配置下会发生。
想象一下这样的配置：
|--------------|
| example.com |
| |
| dedicated IM |
|--------------|
|
|
|
|-------------------|
| child.example.com |
| |
| IM on a GC |
|-------------------|
其中child，有两个 DC 都是全局目录，这意味着基础结构主机角色在 GC 上。并且，example有三个 DC，其中基础结构主机角色在不是一个 GC。
我知道最好把所有东西都变成 GC，这样就不用担心这种事情了，但假设情况并非如此——精确的此类设置中可能出现哪些错误行为？该行为会在哪些域中出现？子域还是父域？
答案1
非全局目录的域控制器不具有林中每个对象的副本（无论是否设置部分属性）。因此，此类 DC 必须创建“幻像”对象来引用来自另一个域的真实对象。
域中的基础结构主机负责更新域中其他 DC 上的幻像引用。为此，它首先引用其域中的全局编录服务器，因为我们假设全局编录具有有关林中所有对象的最完整、最新的知识。
问题是这样的。如果基础结构主机与全局目录是同一台服务器，当 IM 开始执行更新工作时（每 2 天），他会检查 GC，而 GC 恰好也是他自己。“好吧，我在这里看不到任何区别！”他说，因为他已经在 GC 上，所以 GC 和 IM 上的内容没有区别……所以当然看起来他完全是最新的。问题是现在他又回去睡觉了，因为没有什么可做的了。这意味着域中不是 GC 的其他域控制器不会使用该域间信息进行更新。
编辑：
如果您在 example.com 中创建了一个对象，它将复制到 child.example.com 中的 GC，但由于 child.example.com 在 GC 上有一个 IM，并且还有其他非 GC 的 DC，因此该新对象永远不会在 child.example.com 中的其他 DC 上为其创建幻像。因此，您无法将该新对象添加到 ACL 中或将其放入其他 DC 的安全组等中，因为它们不允许您添加它们没有引用的主体。这是理所当然的，因为那样您就会遇到各种奇怪的引用完整性问题。
反过来说，如果您在 child.example.com 中创建了一个新对象，它将复制到 example.com，并且可以在 example.com 中使用该新对象，因为您在父域中没有任何未被 IM 正确复制的 DC。
同样，这就是为什么微软通常建议全部您的 DCs GC，因为 IM 是否正常工作并不重要，因为所有 DC 凭借 GC 都拥有所有更新的信息。
编辑：我也只是想回到这篇文章并提到，当启用 AD 回收站时，基础设施 FSMO 什么也不做：