Co w lesie wielodomenowym DOKŁADNIE dzieje się, gdy niektórzy, ale nie wszyscy, wzorcowi infrastruktury znajdują się w katalogach globalnych?

Istnieje wiele artykułów TechNet, takich jak ten, które mówią, że obiekt fantomowy nie jest aktualizowany, jeśli wzorzec infrastruktury jest również katalogiem globalnym, ale poza tym nie ma wielu szczegółowych informacji na temat tego, co faktycznie dzieje się w tym konfiguracja.

Wyobraź sobie taką konfigurację:

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

Gdzie childma dwa kontrolery domeny, które są zarówno katalogami globalnymi, co oznacza, że ​​rola wzorca infrastruktury jest na GC. I examplema trzy kontrolery domeny z rolą wzorca infrastruktury na kontrolerze, który nie jest GC.

Rozumiem, że zwykle najlepiej jest po prostu uczynić wszystko GC i nie trzeba się martwić o takie rzeczy, ale zakładając, że tak nie jest - jakiego dokładnie błędu można się spodziewać po takiej konfiguracji i jakiej domeny ( s) czy przejawiłoby się to zachowanie? Dziecko czy rodzic?

Kontroler domeny, który nie jest wykazem globalnym, nie ma kopii (częściowego zestawu atrybutów lub nie) każdego obiektu w lesie. Dlatego taki kontroler domeny musi utworzyć obiekty „fantomowe”, aby odwoływać się do rzeczywistych obiektów z innej domeny.

Wzorzec infrastruktury w domenie jest odpowiedzialny za aktualizację tych referencji fantomowych na innych kontrolerach domeny w domenie. Aby to zrobić, najpierw odwołuje się do serwera wykazu globalnego w swojej domenie, ponieważ zakładamy, że katalogi globalne mają najbardziej kompletną i aktualną wiedzę na temat wszystkich obiektów w lesie.

Problem jest taki. Jeśli wzorzec infrastruktury jest tym samym serwerem, co katalog globalny, gdy komunikator internetowy idzie do wykonania zadania aktualizacji (co 2 dni), sprawdza GC, który również jest nim sam. „Cóż, nie widzę tu żadnej różnicy!” Mówi, ponieważ jest już na GC, więc nie ma różnicy między tym, co jest na GC, a tym, co jest na IM ... więc wygląda na to, że jest całkowicie aktualny. Problem polega na tym, że teraz wraca spać, zadowolony, że nie ma nic do roboty. Oznacza to, że inne kontrolery domeny w domenie, które nie są GC, nie są aktualizowane o te informacje między domenami.

Edytować:

Jeśli utworzyłeś obiekt w example.com, replikowałby się on do GC w child.example.com, ale ponieważ child.example.com ma IM na GC, a także inne DC, które nie są GC, ten nowy obiekt nigdy nie należy tworzyć fantomu na innych kontrolerach domeny w child.example.com. Dlatego nie będzie można dodawać tego nowego obiektu do list ACL ani umieszczać go w grupach zabezpieczeń itp. Z tych innych kontrolerów domeny, ponieważ nie pozwalają one dodawać podmiotów, do których nie mają odniesienia. I słusznie, ponieważ wtedy mielibyście różnego rodzaju dziwne problemy z integralnością referencyjną.

Idąc w drugą stronę, jeśli utworzyłeś nowy obiekt w child.example.com, zreplikowałby się on do example.com i byłoby dobrze użyć tego nowego obiektu w example.com, ponieważ nie masz żadnych kontrolerów domeny w obiekcie nadrzędnym domena, która nie jest poprawnie replikowana przez komunikator internetowy.

I podobnie, dlatego Microsoft zwykle zaleca po prostu tworzenie wszystkich GC DC, ponieważ wtedy nie ma znaczenia, czy IM działa poprawnie, czy nie, ponieważ wszystkie DC mają wszystkie zaktualizowane informacje z racji tego, że są GC.

Edycja: Chciałem też wrócić do tego postu i wspomnieć, że gdy włączony jest Kosz AD, Infrastruktura FSMO absolutnie nic nie robi:

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