Wednesday, January 28th, 2009...11:10 pm

I trzymał sie będę lokacji swojej

Jump to Comments

Jakiś czas temu na wss.pl prowadzony był wątek dotyczący mechanizmów lokalizacji kontrolera domeny, przypisania stacji roboczej do lokacji itp. W szczególności w kontekście usług Exchange. Jako że temat powraca czasami to może czas na małe podsumowanie tematu. Jak to jest więc z przynależnościa stacji roboczej do lokacji (site).

(cc) prefers salt marsh’s

Masło maślane czyli lokalizacja lokacji …

Stacja robocza w trakcie procesu logowania i lokalizacji kontrolera domeny jako jedną z pierwszych rzeczy określa (a właściwie wykonuje to kontroler domeny na podstawi informacji o adresie IP stacji) jej przynależność do odpowiedniej lokacji usługi katalogowej. Proces ten został dobrze opisany przez Jorge na jego blogu (część 1, 2 i 3). W ramach tego procesu stacja robocza otrzymuje informacje o tym do jakiej lokacji należy i zapisuje ją lokalnie w rejestrze w kluczu DynamicSiteName. Opcjonalnie możliwe jest statyczne ustawienie lokacji poprzez wartość klucza SiteName jednak mówiąc szczerze nie widzę powodu dla którego w dobrze skonfigurowanym środowisku wartość ta miałaby być używana. I tak wygląda początek.

Jeżeli chodzi o lokalizację kontrolera domeny to w zasadzie jest to koniec i stacja robocza będzie korzystała z kontrolera ustalonego przy starcie, chyba że jest to system Vista lub późniejszy lub zainstalowano poprawkę z artykułu KB 939252.

Jeżeli chodzi zaś o przynależność stacji roboczej do lokacji sprawa wygląda trochę inaczej. Usługa Netlogon określa przynależność stacji roboczej do lokacji w regularnych odstępach czasu, określonych wartością klucza rejestru SiteNameTimeout (domyślnie 5 minut). Otrzymany wnik zapisywany jest w wspomnianym już kluczu DynamicSiteName. Powstaje więc małe pytanie … czy wiąże się to automatycznie ze zmianą informacji o kontrolerze domeny używanym przez stację? Wydawałoby się to logiczne … i faktycznie tak jest.

Zgodnie z opisem funkcji DsrGetSiteName, w przypadku gdy upłynie czas wskazany w wartości SiteNameTimeout stacja robocza musi wykonać zapytanie odnośnie lokacji a w przypadku gdy się zmieni zlokalizować odpowiedni kontroler domeny.

If the timer is expired, the server MUST locate a domain controller in the domain.

Czyli zmiana przypisania stacji roboczej do lokacji powinna skutkować odświeżeniem danych o kontrolerze domeny.

Zmiana kontrolera domeny…

Tyle teoria, a jak wygląda praktyka. Przetestujmy to w prostej konfiugracji z dwoma lokacjami:

  • Default-First-Site (IP subnet: 192.168.1.0/24), DC –> LHFDC01
  • DMZ (IP subnet: 192.168.2.0/24), DC –> LHFDC02

Nasza testowa stacja robocza ma przypisany adres 192.168.2.10 należy więc do lokacij DMZ. Teraz wykonajmy małą zmianę w katalogu i przypiszmy podsieć w której znajduje się stacja do lokacji HQ. Wyniku tej zmiany obie podsieci przypisane są do lokacji HQ. Po replikacji danych (dla przyspieszenia zmian włączyłem mechanizm powiadomień pomiędzy lokacjami) mamy następującą sytuację:

Czyli lokacja do której należy stacja uległa już zmianie, ale informacja ta jeszcze nie została odświeżona przez stację roboczą. Po upływie określonego w rejestrze czasu stacja robocza odświeża tą informację, co znajduje odzwierciedlenie w informacjach pokazywanych przez NLTEST:

Czyli odświeżona została została informacja o lokacji ale nie został zlokalizowany jeszcze poprawny dla tej lokacji DC. A po jakimś czasie:

Czyli wszystko jest tak jak zakładaliśmy że powinno to zadziałać. Przynajmniej w laboratorium więc działa :).

Wracając do podstawowego problemu …

Problem jakiego dotyczył wątek, który zapoczątkował ten wpisto fakt, że serwer Exchange stwierdzał, że nie jest w stanie określić swojej przynależności do lokacji usługi katalogowej i przełączał się pomiędzy lokacjami i kontrolerami domeny. Zachowanie takie wynikało z konfiguracji usługi katlaogowej, w której do poszczególnych lokacji przypisane zostały nakładające się zakresy podsieci, w związku z czym serwer Exchange nie był w stanie określić własnej lokacji. Na sieci można znaleźć informację o tym, że taka konfiugracja nie jest wspierana:

The only impact according to it would be “A site can be associated with one or more
IP subnets. Make sure that no overlapping subnets are configured.
If subnets overlap, an Exchange 2007 server will be unable to correctly determine
its site membership and routing errors may occur.

Powstaje w zasadzie pytanie po co taka konfiguracja? Konfiguracja, w której podsieci przypisane do lokacji się pokrywają z punktu widzenia usługi katalogowej nie ma sensu. Jeżeli chcemy zapanować nad procesem lokalizacji kontrolera domeny, również dla stacji roboczych które nie zostaną przypisane do żadnej podsieci możemy to kontrolować za pomocą rekordów SRV rejestrowanych w ramach DNS …

… ale to już temat na inny wpis :).

4 Comments

  • ” Jeżeli chcemy zapanować nad procesem lokalizacji kontrolera domeny, również dla stacji roboczych które nie zostaną przypisane do żadnej podsieci możemy to kontrolować za pomocą rekordów SRV rejestrowanych w ramach DNS …

    … ale to już temat na inny wpis :).”

    czekamy cierpliwie. 🙂

  • “Powstaje w zasadzie pytanie po co taka konfiguracja? Konfiguracja, w której podsieci przypisane do lokacji się pokrywają z punktu widzenia usługi katalogowej nie ma sensu. Jeżeli chcemy zapanować nad procesem lokalizacji kontrolera domeny, również dla stacji roboczych które nie zostaną przypisane do żadnej podsieci możemy to kontrolować za pomocą rekordów SRV rejestrowanych w ramach DNS …”

    …Wydaje mi się że za pomocą rekordów SRV w DNSie możemy rozwiązywać sytuacje gdy w danym AD Site nie ma żadnego DC. Nie rozwiąże to ma jednak problemu gdy dana maszyna nie należy do żadnego AD Site bo jej adres IP nie zawiera się w żadnej zdefiniowanej w AD podsieci.

  • […] uwagę że nie odpowiedziałem jeszcze na głos ludu wyrażony w komentarzach pod postem dotyczącym ustalania lokacji. Się wzięło na barki obowiązek blogowania … trzeba cierpieć. Dzisiaj więc kilka uwag w […]

  • […] prościej lub inaczej? W zasadzie można – pisałem o tym w jednym z moich postów “I trzymał sie będę lokacji swojej”. W skrócie – poprzez odpowiednią konfigurację rejestrowanych rekordów DNS możemy […]

Leave a Reply