Skip to Content

IT nieuczesane.

Migracja domeny windows 2000 do windows 2003

Od 14 maja 2003 roku możemy oficjalnie nabyć produkty serwerowe z rodziny Windows 2003, początkowo nieco myląco promowanego jako .NET server. Ponieważ ‚nowe’ nie zawsze znaczy ‚lepsze’ wiele osób na pewno rozważa upgrade domeny do windows 2003, zastanawiając się czy to co kolwiek da. Niniejszy artykuł przeznaczony jest głównie dla osób zajmujących się domeną windows 2000. Dla czego? Ponieważ ogólnych zalet zastosowania Active Directory w stosunku do domeny NT4.0 jest niepoliczalnie wiele, są oczywiste, i mowi się o nich już od ponad 3 lat (od czasu pojawienia się w2k). Niniejszy artykuł traktuje o nowościach w stosunku do AD w windows 2000, i mam nadzieję pomoże zdecydować czy warto przejść na nową platformę. Dla kogo zatem domena windows 2003?

co nowego w AD 2003?

(2003Anno Domini? (; )

Windows Server 2003 był dość długo oczekiwanym następcą w2k – biorąc pod uwagę, iż windows XP miał swoją premierę ponad półtora roku temu. Nie dziwi więc fakt, że po raz pierwszy w historii systemów Microsoftu numer wersji kernela jest różny dla workstacji (5.1 w Windows XP) i różny dla serwera (5.2 dla Windows Server 2003). Pomimo, iż rodzina Serverów 2003 nie jest rewolucyjna w stosunku do swojego poprzednika – 2k, wprowadzone jest sporo zmian ułatwiających życie administratora, zarówno od strony wielu nowych automatów-wizardów (buehk! prawdziwi męszczyźni nie korzystają z wizardów :P ) jak i kilku nowych mechanizmów. Nie trudno się domyślać, że sporo zmian dotyczy usługi katalogowej Active Directory – jako serca (i mózgu) całej domeny. Zmiany są na tyle radykalne, że wymagają uprzedniego przygotowania domeny w2k przed rozpoczęciem instalacji nowego serwera – co jest szczegółowo opisane w rozdziale poniżej (proces migracji AD 2000 do 2003). W niniejszym rodziale postaram się opisać podstawowe zmiany w AD w stosunku do w2k.

Największe zmiany dotyczą usługi Global Catalog’u. GC jest kontrolerem domeny przetrzymującym częściową kopię wszystkich obiektów AD w obrębie lasu oraz najczęściej sprawdzane atrybuty tych obiektów. Konkretniej – przechowuje pełną kopię obiektów z tej samej domeny, w której się znajduje, oraz częściową (niepełną) kopię obiektów każdej domeny w obrębie lasu. Dzieki usłudze GC optymalizowane są wszelkie zapytania do obiektów, bez konieczności zbędnych odwołań pomiędzy kontrolerami domen, przyspieszając w ten sposób działanie całej operacji oraz zmniejszając ruch w sieci. Klejnym ważnym zadaniem GC jest przechowywanie informacji o członkach grup uniwersalnych (tylko w trybie w2k native mode). W przeciwieństwie do grup globalnych, które są przechowywane na każdym z kontrlolerów, informacja o przynależności do grup uniwersalnych przechowywana jest jedynie w GC. Co zmieniło się w Global Catalog’u:

nowa cecha opis

Zwiększona wydajność replikacji GC

Wydajność replikacji atrybutów/obiektów w GC została uzyskana poprzez wprowadzenie replikacji przyrostowej. Dzięki mechanizmowi Partial Attribute Set (PAS) [Częściowy Zestaw Atrybutów] ograniczony jest zarówno ruch w sieci jak i obciążenie serwera GC podczas aktualizacji.
Wydajnieszy sposób przechowywania informacji o przynależności do grup Dotychczas informacje o członkach grupy replikowane były jako pojedyńczy atrybut (single multi-value replication), co miało swoje następstwa w postaci ograniczenia ilości członków grupy do 5000 ze względu na wydajność tranzakcji. W efekcie jaka kolwiek zmiana w przynależności do grupy – np. dodanie nowego użytkownika – powodowała replikację wszystkich rekordów. Teraz replikowana jest pojedyńcza wartość atrybutu.
Brak wymogu połączenia z GC Do tej pory podczas każdego logowania do kontrolera domeny, wymagane było połączenie z GC celem ustalenia przynależności użytkownika do grup uniwersalnych. Teraz kontrolery domeny cache’ują te informacje, i jeśli połączenie z GC nie jest możliwe, pobierane są ostatnie aktualne wartości. Takie rozwiązanie zdaje egzamin zwłaszcza w przypadku site’ów podłączonych słabym łączem [slow link]. Ponadto nie ma konieczności ustawiania GC w każdej lokalizacji, co eliminuje w dużej mierze ilość replikowanych danych.

Z innych większych zmian we wnętrzu Active Directory oraz nowych możliwości GPO, o których warto wspomnieć:

nowa cecha opis
Partycja Katalogu Aplikacji (Application Directory Partition) AD pozwalają na utworzenie nowego typu kontekstu nazewniczego lub partycji – Partycję Katalogu Aplikacji. Taka partycja może zawierać dowolną hierarchię wszystkich typów obiektów poza obiektami głównymi (użytkownicy, grupy i komputery) i można skonfigurować replikację tego katalogu na dowolne kontrolery domeny na przestrzeni lasu. Wykorzystane to zostało np. do przechowywania informacji o strefach DNSowych. Zaletą takiego rozwiązania jest optymalizacja replikacji poprzez usunięcie zbędnych atrybutów z GC oraz poprzez fakt, iż informacje o DNSie są replikowane wyłącznie pomiędzy konkretnymi serwerami – a nie jak dotychczas między wszystkimi.

Zmiana nazwy domeny

Co prawda były narzędzia umożliwiające zmianę nazwy domeny w2k, ale było to rodzajem łatki czy też dodatku. Generalnie nie przewidziano takiej opcji. Obecnie, nie bez pewnych ograniczeń, da się to zrobić niejako oficjalnie. Możliwa jest zmiana nazwy DNS’owej i NetBIOS’owej domeny, zachowując GUID i SID domeny. Nie jest również konieczne ponowne dodawanie komputerów do domeny – wymagany jest jednak dwukrotny restart każdej maszyny.
Nowa funkcjonalność nie daje nadal możliwości zmiany głównej domeny lasu (forest root domain).

Filtracja WMI

To bardzo ciekawa nowa właściwość dająca możliwość wykonywania akcji w zależności od ustawień filtra WMI (Windows Management Instrumentation). I tak na przykład można ustalić polisę, która instaluje użytkownikowi aplikację, ale tylko w przypadku jeśli na danym komputerze jest 500Mb wolnego miejsca na dysku.
Ze względu na szeroki zakres właściwości do których można się odwołać za pomocą WMI (SNMP, rejestry, sterowniki, aplikacje, AD i wiele więcej) daje to olbrzymie możliwości. Do tej pory WMI przydawało się głównie zaawansowanym administratorom do tworzenia własnych skryptów. W końcu znalazło praktyczne zastosowanie w codziennej pracy.
Ustawienie standardowego kontenera, w którym tworzą się obiekty typu ‚objectCategory=user’ i ‚objectCategory=computer’ Do tej pory wielu początkujących użytkowników była rozżalonych faktem, iż po założeniu użytkownika za pomocą jakiejś standardowej aplikacji (np. net user) zakłada się on w kontenerze ‚Users’. Analogiczna sytuacja jest z obiektami ‚komputer’. Do polis dodana zostala nowa opcja – możliwość przekierowania standardowych kontenerów, w których będą się tworzyć ww. obiekty.
Nowe ustawienia polis Polisy zostały poszeżone o ponad 150 nowych funkcji, dość poważnie rozszeżając dotychczasową, już i tak nie małą, funkcjonalność GPO.
Trusty miedzy lasami Dodano możliwość tworzenia trustów pomiędzy różnymi lasami. Dzięki takiemu rozwiązaniu firmy prowadzące współpracę, które pozostają od siebie niezależne, będą mogły umożliwić logowanie się użytkowników do swoich lasów, bez konieczności restrukturyzacji całej domeny i łączenie w jedną strukturę lasu. W domenie windows 2000 las wyznacza granicę możliwości autentykacji użytkownika. W windows 2003 nie ma już takiego ograniczenia.

Wszystkie zmiany dotyczące Active Directory 2003, w stosunku do windows 2000 znajdują się w oficjalnym dokumencie „Active Directory Technical Overview„.

Upgrade’ować czy nie?

Czy warto dla takich zmian migrować do windows 2003? Jak już wspominałem, dylematu nie powinny mieć osoby pracujące cały czas na NT4.0 [podziwiam i współczuję]. Sprawa jest mniej oczywista w przypadku domeny windows 2000, w stosunku do której co prawda dodanych zostało sporo nowych możliwości, ale nie są to możliwości przełomowe – jakim np. byłaby możliwość ustalania polityki haseł na poziomie OU. Kto zatem poważnie powinien pomyśleć o migracji do windows 2003?

Ze wzgledu na bardzo poważne zmiany w sposobie replikacji danych między kontrolerami optymalizujące cały proces, zmiany w GC, możliwość tworzenia trustów między domenami (cross-forest authentication i cross-forest authorization) i kilka innych cech, wyraźnie widać, że są to zmiany mające znaczenie przedewszystkim dla dużych, rozległych sieci. Na pewno więc zmiana będzie bardzo opłacalna w domenie o dużej, złożonej strukturze, podzielonej na oddziały rozsiane po całym kraju [czy wręcz świecie].
Należy również pamiętać o fakcie, że znacząca większość wszystkich tych dobrodziejstw będzie dostępna dopiero po przejściu domeny w tryb natywny windows 2003 – analogicznie do trybów mixed/native w windows 2000, a więc należy wziąc pod uwagę upgrade wszystkich kontrolerów domeny, a nie tylko poszczególnych.
Dla administratorów małych sieci kuszące mogą być nowe możliwości GPO. Wprowadzone zostało nowe narzędzie do obsługi polis – Group Policy Manager (można z niego korzystać również na serwerze 2000), które pozwala na dużo łatwiejszy, bardziej przejrzysty sposób zarządzania polisami.

Zmiany w Active Directory, pomimo że kluczowe, nie są oczywiście jedynymi zmianami w systemie. Równie ważne zmiany zostały dokonane w kernelu systemu, funkcjonalności interface’u (np. możliwość wyliczania uprawnień efektywnych), nowy IIS6.0 korzystający z parsera HTTP na poziomie kernela, obsługa 64bit procesorów etc. – i pomimo, że tematy te odbiegają od tematu niniejszej pracy i niedotyczą bezpośrednio mechanizmów pracy domeny, powinny być wzięte pod uwagę podczas podejmowaniu decyzji o migracji.

PS. z podstawowych wad windows 2003 przemawiających za powstrzymaniem się z migracją jest skandalicznie mała ilość obsługiwanych użądzeń, co najprawdopodobniej potrwa jeszcze przez jakiś czas, oraz brak możliwości instalacji wielu aplikacji. W2k3 nie współpracuje np. z exchange’em oraz ISA – które swoje premiery w wersjach 2003 mają mieć pod koniec tego [2003] roku. Jako kontrolery domeny funkcjonują znakomicie, natomiast na resztę funkcjonalności trzeba będzie poczekać. Nie warto się spieszyć.

Proces migracji Active Directory 2000 do 2003

   Proces migracji domeny składa się z trzech kroków – sprawdzeniu czy sprzęt spełnia wymagania servera 2003, przygotowania lasu i domeny oraz samego procesu instalacji.

  1. Wstępne przygotowanie
    Jak przed każdą poważniejszą zmianą, przed przystąpieniem do właściwej instalacji należy wykonać kilka rutynowych czynności. Do takich czynności zaliczają się przedewszytkim: backup danych oraz kontrola wymagań sprzętowych.
    Aby po zainstalowaniu systemu nie okazało się, że np. nie działa modem który znajduje się w komputerze, warto najpierw sprawdzić czy posiadany sprzęt odpowiada wymogom systemu. Server 2003 ma również swoje wymagania co do pamięci i procesora.

    Aby pomóc nieprzeoczyć żadnego z ważnych kroków podczas wstępnego procesu, polecam zapoznać się z checklist’ą dostępną na stronach technetu.

  2. Przygotowanie lasu i domeny
    • Aby przystąpić do upgrade’u należy upewnić się, że na wszystkich kontrolerach domeny jest zainstalowany co najmniej ServicePack 2.
    • Kolejnym krokiem jest zlokalizowanie kontrolerów pełniących rolę „schema master” oraz „infrastructure master”. Przy standardowej instalacji jest to ten sam kontroler – pierwszy jaki został postawiony w obrębie lasu (forest root domain).
    • Ze względu na duże zmiany w samej strukturze AD, przed przystąpieniem do upgrade’u należy najpierw przygotować las oraz domenę. Proces polega na wprowadzeniu zmian w schemacie AD. Dla tego też warto w pierwszym rzędzie zrobić kopię zapasową serwera pełniącego rolę „schema master”. Po zrobieniu backup’u należy odłączyć kontroler od sieci.
    • Do dokonania niezbędnych modyfikacji przygotowane zostało narzędzie – adprep. Po odłączeniu od sieci, w konsoli należy przejść do katalogu ‚i386‚ na płycie instalacyjnej windows 2003, i wykonać polecenie ‚adprep /forestprep‚.

      Aby móc wykonać tę czynność należy być zalogowanym jako użytkownik należący do grupy „Schema Admins” oraz „Enterprise Admins”.

    • Jeśli polecenie zakończyło się sukcesem można przejść do dalszej części – czyli przygotowania domeny. Aby upewnić się czy na pewno wszystko przebiegło tak jak powinno, warto przejrzeć logi (EventViewer) oraz skorzystać z jakiegoś narzędzia daignostycznego dla kontrolerów domeny (np. dcdiag). Należy pamiętać o tym, że zapewne w logach znajdzie się kilka błędów wynikających z braku połącznia z siecią.
      Logi z przebiegu operacji adprep’em zakładane są w katalgu %windir%system32debugadprep, aczkolwiek nie znajdzie się w nich wiele więcej, niż komunikaty wyświetlane na ekranie podczas działania programu.
    • Jeśli program zatrzymał się z jakimś krytycznym błedem zalecane jest odtworzenie serwera z kopii zapasowej, wykrycia problemu i jego usunięcia przed ponownym przystąpieniem do operacji adprep’em.
      W razie drobnych błedów – np. braku zainstalowanego wymaganego hotfixa – adprep poinformuje o czynnościach niezbędnych do wykonania. Należy pamiętać, że jeśli podłączymy „schema master” do sieci, i zmiany zreplikują się, nie będzie możliwe przywrócenie domeny do pierwotnego stanu.
      Jeśli procedura przebiegła pomyślnie, należy podłaczyć kontroler do sieci i przejść do kolejnego kroku procedury instalacji.
    • Jeśli „schema master” i „infrastructure master” nie są tym samym kontrolerem należy poczekać, aż zmiany zreplikują się. Czas zależy od rozmieszczenia serwerów – może to zając od kilku minut [sieć lokalna] do kilku godzin [replikacja między site’ami].
    • Od tego momentu mamy pełną dowolność kiedy wykonać kolejny krok. Domena będzie funkcjonować bez żadnych widocznych zmian. Następną czynnością jest update domeny, po którym również nie trzeba się spieszyć z instalacją serwerów – można to zrobić kiedykolwiek. Aby tego dokonać wykonuje się polecenie ‚adprep /domainprep‚. Tak jak w poprzednim przypadku należy zweryfikować poprawność przebiegu procedury i dokonać ewentualnych poprawek.

      Aby móc wykonać tę czynność, użytkownik musi należeć do grupy „Domain Admins” lub „Enterprise Admins”.

    • Poczekać na zreplikowanie zmian na wszystkie kontrolery w danej domenie.

    To jest jedna z bardziej niebezpiecznych cześci instalacji – ze względu na skalę wprowadzanych zmian. Po poprawnym przebiegu powyżej przedstawionych czynności można odetchnąc z ulgą. Pozostało już tylko zainstalowanie oprogramowania – czyli windows server 2003 – na kontrolerach domeny.
    Dokument w wersji anglojęzycznej, dotyczący powyżej przedstawionych czynności, można znaleść na płycie CD z oprogramowaniem w katalogu ‚docs’ [docs/EntSrv1.TXT]. Dla ułatwienia w ktalogu głównym znajduje się plik ‚readme.htm’ zawierającym linki do poszczególnych plików. Podobny dokument można również znaleść na stronach technetu.

  3. Instalcja systemu operacyjnego.
    Instalacja została uproszczona w stosunku do poprzednich wersji systemu. W zasadzie sprowadza się do kilku kliknięć i wpisaniu numeru seryjnego. Jeśli na kontrolerze domeny znajdują się aplikacje bądź serwisy nie zgodne z nową wersją systemu, zostaną one wylistowane z ewentualnymi uwagami. Jeśli któraś z aplikacji/serwisów jest krytyczna, zostanie wyświetlona informacja o konieczności dokonania zmian i program instalacyjny zostanie wstrzymany.

    Po wpisaniu numeru seryjnego instalacja przebiega bezdotykowo i po 15-30 minutach mamy już kontroler w wersji server 2003.

Zagrożenia i spostrzeżenia

   W większości przypadków instalacja nie jest skomplikowana i powinna przebiec bezproblemowo. Są jednak osoby, dla których prawa Murphy’iego sprawdzają się częściej niż w stosunku do innych. Mam dziwne wrażenie, iż należę do takich właśnie osób, o czym może świadczyć dość nietypowy problem jaki zaistaniał podczas migracji, którą robiłem. Podczas wykonywania upgrade’u lasu [adprep /forestprep] dostałem taką informację:

Murphy działa nadal i tak okazało się, iż nie trudno odnaleść stronę opisującą niniejszą przypadłość, problem polega na tym, że nie ma tam linka do hotfix’a o którym mowa. Po tygodniu wymiany poczty dostałem niezbędny plik od polskiego supportu. Hotfixa nie dało się jednak zainstalować, ponieważ przeznaczony był dla systemu z SP2, podczas gdy ja miałem wszędzie SP3. Jedynym wyjściem pozostała instalcja SFU3.0, tylko po to, żeby za chwilę je odinstalować. Po tym instalcja ruszyła bez problemu.

Bardzo ważna informacja pojawia się również podczas fazy instalacji systemu, dotycząca problemów z autoryzacją klientów starszych niż w2k na serwerze windows 2003 („Windows 95 and Windows NT 4.0 interoperability issues„). Wynika to z defaultowych polis zwiększających bezpieczeństwo komunikacji z kontrlolerem. Dokument dokładnie opisuje które polisy i w jaki sposób wpłyną na komunikajcę – jeśli w sieci znajdują się końcówki starsze niż w2k lub klienty linuxowe z sambą [nawet 3.x], warto go sobie wydrukować i zaraz po instalacji pierwszego kontrolera dokonać odpowiednich zmian.

Kolejną rzeczą na którą warto zwrócić uwagę to kontroler pełniący rolę PDC. Podczas całego procesu instalcji należy pamiętać o przenoszeniu roli PDC na serwer, z którym nic się obecnie nie dzieje, aby zachować ciągłość pracy. W innym przypadku część klientów może mieć problemy z logowaniem.


Życzę miłej instalcji, nExoR