在多域林中，当一些（但不是全部）基础结构主机位于全局目录上时，究竟会发生什么？

Question

有很多 TechNet 文章，比如这篇文章说，如果基础架构主节点也是全局目录，则幻像对象不会得到更新，但除此之外，没有很多关于此中实际发生的情况的深入信息配置。

想象一个这样的配置：

|--------------|
| example.com  |
|              |
| dedicated IM |
|--------------|
    |
    |
    |
|-------------------|
| child.example.com |
|                   |
|  IM on a GC       |
|-------------------|

Wherechild有两个都是全局目录的 DC，这意味着 Infrastructure Master 角色在 GC 上。并且，example在非GC的 DC 上具有三个具有基础结构主机角色的 DC 。

我知道通常最好将所有内容都设置为 GC 而不必担心此类事情，但假设情况并非如此 -从这样的设置中可以预期的确切错误行为是什么，以及哪个域（ s) 这种行为会表现在吗？孩子还是家长？

Answer 1

不是全局编录的域控制器没有林中每个对象的副本（部分属性集与否）。因此，这样的 DC 必须创建“幻影”对象来引用来自另一个域的真实对象。

域中的基础结构主机负责更新域中其他 DC 上的那些幻像引用。为此，它首先引用其域中的全局编录服务器，因为我们假设全局编录具有关于林中所有对象的最完整、最新的知识。

问题是这个。如果基础架构主机与全局目录是同一台服务器，那么当 IM 执行其更新工作时（每 2 天），他会检查一个 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 中使用该新对象，因为您在父级中没有任何 DC IM 未正确复制到的域。

同样，这就是为什么 Microsoft 通常建议只将所有DC 设置为 GC，因为这样就无关紧要 IM 是否正常工作，因为所有 DC 无论如何都拥有所有更新的信息，因为它们都是 GC。

编辑：我也只是想回到这篇文章并提到启用 AD 回收站时，基础结构 FSMO 绝对不执行任何操作：

http://myotherpcisacloud.com/post/2013/04/13/AD-Recycle-Bin-and-a-Eulogy-for-the-Infrastructure-Master.aspx