想象一下这样的配置：
|--------------|
| example.com |
| |
| dedicated IM |
|--------------|
|
|
|
|-------------------|
| child.example.com |
| |
| IM on a GC |
|-------------------|
子项具有两个同时具有全局编录的DC,这意味着基础结构主机角色位于GC上.并且,示例在不是GC的DC上有三个具有基础结构主机角色的DC.
我知道通常最好只让一切都成为GC而不必担心这类事情,但假设情况并非如此 – 从这样的设置可以预期的确切错误行为是什么,以及哪个域( s)这种行为会表现出来吗？孩子还是父母？
域中的Infrastructure Master负责更新域中其他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未正确复制的域.
同样地,这就是为什么微软通常建议只生成所有DC的GC,因为如果IM工作正常与否则无关紧要,因为所有DC都因为GC而拥有所有更新的信息.
编辑：我还想回到这篇文章,并提到当启用AD回收站时,基础设施FSMO绝对没有做任何事情：
