Thursday, February 18th, 2010...1:04 am

Niedzielne zobowiązanie …

Jump to Comments

… człowiek coś chlapnie w niedziele wieczorem w komentarzach do bloga I cóż, chlapnęło się … trzeba pisać. O lokalizacji SYSVOL będzie. Kto był na ostatniej mojej prezentacji na ICL to już trochę słyszał … kto nie był, niech czyta.

SYSVOL jaki jest każdy widzi, wystarczy że zajrzy do udziałów udostępnianych przez kontroler domeny. Rolą SYSVOL jest udostępnianie plików klientom usługi katlaogowej – w szczególności plików szablonów polityk GPO (duży skrót: GPO składa się z GP container (GPC) w katalogu I GP Template (GPT) na SYSVOL), skrytpów startu \ logowania itp. Przed zreplikowaniem I udostępnieniem SYSVOL kontroler domeny nie udostępnia swoich usług, bez SYSVOL klienci nie będą też przetwarzali GPO. To tak w telegraficznym skrócie.

(cc) swingnut

Z czysto technologicznego punktu widzenia SYSVOL to nic innego jak rozproszony system plików (DFS) udostępniany jako domenowa przestrzeń nazw (odwołania do SYSVOL odbywają się poprzez \\<FQDN domeny>\SYSVOL). Jego zawartość jest replikowana przy pomocy FRS w systemach starszych niż Windows 2008 I przy użyciu DFS-R w środowiskach opartych o Windows Server 2008 I wyższych, o ile administrator dokonał migracji tego mechanizmu. Szczerze mówiąc, to w zasadzie zawartość SYSVOL może być replikowana dowolnie, tak długo jak utrzymana jest jej spójność na wszystkich kontrolerach domeny.

Mówiąc o wszystkich kontrolerach domeny – skąd wiemy, z której repliki SYSVOL w skorzysta nasz klient, czyli jak lokalizowana jest ta replika przez klienta? I tutaj dochodzimy do problemu …

Teoria …

Jak już kilka razy pisałem, I co jest jedną z podstawowych informacji o konfiguracji I działaniu usługi katalogowej, kontroler domeny lokalizowany jest przez klienta w oparciu o konfiguracje lokacji i podsieci. Domyśłnie SYSVOL niestety nie korzysta z tego mechanizmu, co może powodować problemy (których sądząc z komentarzy niektórzy doświadczyli).

Klient w odpowiedzi na zapytanie o listę hostów utrzymujących replike SYSVOL otrzymuje domyślnie listę podzieloną na dwie grupy:

  • repliki SYSVOL w ramach jego lokacji
  • repliki SYSVOL poza jego lokacją.

Domyślnie, w ramach każdej z grup lista replik ułożona jest *losowo*, klient wybiera jeden z nich, próbując najpierw zlokalizować replikę w ramach tych, które istnieją w jego lokacji, następnie sięgając po te spoza swojej lokacji. Nawet w ramach jednej lokalizacji, nie zapewnia to, że klient używa tego samego DC do uwierzytelnienia I do  dostępu do SYSVOL (kluczem tutaj jest słowo losowo użyte wcześniej).

Po to, aby być pewnym że DC, który został użyty w procesie logowania będzie równiez tym, użytym do dostępu do SYSVOL można posłużyć sie poprawką opisaną w KB831201, dzięki której, po wykonaniu odpowiedniego wpisu w rejestrze, DC który uwierzytelni użytkownika umieszcza swoją nazwę na początku listy replik SYSVOL.

W przypadku jednak, gdy klient nie korzysta z DC we własnej lokacji wybór jest całkowicie losowy ponieważ lista replik jest tworzona w tan sposób. Problem polega na tym, że lista replik dostarczana klientowi, nie uwzględnia w żaden sposób konfiguracji sieci środowiska (tak jak ma to miejsce w przypadku lokacji I podsieci w procesie lokalizacji DC), w związku z tym na początku listy może znaleźć się DC, który znajduje się w odległej sieci I to jeszcze połączonej kiepskim łączem z 3 hopkami pomiędzy lokalizacją klienta I tym DC.

Po pierwsze nie jest to optymalne, I dostęp do zasobów SYSVOL będzie odbywał sie wolniej. Po drugie, w przypadku sieci, gdzie dostęp do zasobów poszczególnych lokalizacji jest ograniczony na poziomie urzadzeń sieciowych (a z taką konfiguracją spotykam sie w kraju z literkami PL nader często) prowadzić to może do sytuacji w której w przypadku braku lokalnego DC, pomimo że klient uzyska połączenie z DC w lokalizacji centralnej to nie uda mu się zlokalizowć SYSVOL.

Jak sobie poradzić z tym fantem? Z pomocą przychodzi mechanizm generowania listy replik SYSVOL z uwzględnieniem wartości kosztu pomiędzy nimi (koszt pomiędzy lokacjami jednak ma sens). Mechanizm ten, dostępny jest w systemie od Windows 2003 (dla Windows 2000 dostępna jest poprawka w KB823362) I nosi nazwę SiteCostedRefferals, od nazwy klucza rejestru który go uruchamia:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters
Value Name: SiteCostedReferrals
Data Type: REG_DWORD
Value: 1

Wpis ten musi być wykonany na wszystkich DC. Po jego wykonaniu lista kontrolerów domeny, dostarczających repliki SYSVOL uszeregowana będzie z uwzględnieniem kosztu pomiędzy poszczególnymi lokacjami.

Aby ten mechanizm jednak zadziałał, musimy dostarczyć dodatkowych informacji, a mianowicie informacji o tym, pomiedzy którymi lokacjami możliwe jest przejście klienta, czyli do których replik SYSVOL ma zostać wyliczony koszt. Możliwe jest to przez włączenie opcji Bridge all site links (BASL). Wadą tego podejścia może być to, że niekoniecznie możemy chcieć aby wszystkie wszystkie lokacje były oznaczone jako połączone z użyciem BASL, ponieważ może to być niepożądane z punktu widzenia mechanizmów replikacji. Aby jednak nadal możliwe było skorzystanie z mechanizmu wyliczania kosztu dla listy replik DFS w oparciu o koszt połączeń między lokacjami, bez negatywnego wpływu włączenia BASL możliwe jest włączenie dla lokacji opcji ingnorowania BASL na potrzeby KCC, pozostawiając ją aktywną dla mechanizmów wyliczenia kosztu DFS.

W teorii alternatywą dla BASL jest manualne utworzenie site link bridges, pomiędzy wybranymi lokacjami. Nigdy w praktyce jednak takiego podejścia nie stosowałem. Pierwsze co przychodzi mi do głowy jako problem to kwestia planowania I utrzymania ręcznie tworzonych mostów pomiędzy lokacjami w większej ilości.

I tak jakby życie z SYSVOL (I NETLOGON o którym nie wspomniałem) stało się prostsze …

Trochę narzędzi …

Na zakończenie krótkie informacje o narzędziach. Aby uzyskać informacje o liście replik z punktu widzenia klienta należy posłużyć się narzędziem dfsutil. Dwa przełączniki do zapamiętania to:

DFSUTIL /SPCINFO
DFSUTIL /PKTINFO

W wersji DFSUTIL z Windows Server 2008 (dostępna po zainstalowaniu narzędzi do zarządzania DFS) odpowiednikami są:

DFSUTIL CACHE DOMAIN

DFSUTIL CACHE REFERRAL

Dzięki tym poleceniom, po stornie klienta możemy sprawdzić z której repliki SYSVOL w danej chwili korzysta klient, oraz listę wszystkich znanych klientowi replik SYSVOL uzyskanych w procesie lokalizacji SYSVOL.

Leave a Reply