Wycieczka do nowego lasu cz.2

Zgodnie z obietnicą prezentuję drugą część wpisu o migracji do nowej domeny. Przypominam, że w poprzedniej części omówiłem teoretyczną część zagadnienia, tym razem będzie o praktyce, czyli miejscu, w którym założenia ulegają regulacji przez rzeczywistość.

Samo nadanie uprawnień już na samym początku zaczęło sprawiać problemy. Okazało się, że o ile w mieście A, gdzie - przypominam - stanął od razu kontroler domeny NEW wszystko działało jak trzeba (to znaczy forwardowanie dnsowych stref lokalnych dla domen OLD i NEW działało bez zarzutów), o tyle w mieście B nie było już tak dobrze. Tamtejszy serwer DNS wskazywał kontroler w mieście A z domeny NEW dla strefy new.local, ale z jakiś powodów nie działało to zawsze. Być może winne były timeouty. Uporaliśmy się z tym dopiero stawiając kontroler nowej domeny w mieście B. Ale tutaj dopiero zaczyna się historia.

Po kilkukrotnym upewnieniu się, że w mieście A wszystko jest ok i testowym przeniesieniu kilku osób do domeny NEW (o procesie przenoszenia już za chwilę, dość szczegółowo) zapakowaliśmy się w samochód i wyruszyliśmy w prawie 300 kilometrową podróż do miasta B. Plan był następujący - na czas reinstalowania systemu przenosimy serwer DNS oraz DHCP na router (sjakiś debian), task scheduler do przenoszenia faxów z miasta A do miasta B zostaje zamieniony, pracownicy z miasta B korzystają z zasoby w mieście A i stamtąd odczytują faxy (trochę lagów, ale da się zaakceptować). Do samego serwera dopinamy kolejny kontroler RAID, stawiamy na nowych dyskach mirror, oba RAIDy działają równolegle (gdyby co...), po postawieniu samego serwera przenosimy pracowników do nowej domeny. Tymczasem...

Tymczasem okazało się, że nasz serwer nie wpuści kolejnego tego typu kontrolera do siebie. Po prostu brak wolnego slota PCI‑E. No i... no i trudno. Płyta nam na szczęście udostępniała dwa sloty SATA, które działać mogą jako raid. Jeden problem z głowy (wspominałem o wycieczce po mieście w poszukiwaniu przejściówki molex->sata?). Kolega się uparł na backup struktury zasobów przez robocopy. Jeszcze tylko kilkukrotne sprawdzenie, że dane są ok i serwer wyłączamy. Stawiamy system, wszystko działa po 6 godzinach od wyłączenia serwera. Mamy nową domenę.

Wyłączamy serwer DNS i DHCP z routera, przenosimy strefy DNS ze starego. I tutaj należy się kilka słów. Strefy dns w systemach windows server 2003 i 2008 (nie lokalne) serwer dns trzyma w plikach z rozszerzeniem dns (nie da się uniknąć tych powtórzeń ;) w katalogu x:\windows\system32\dns. Można je więc dość łatwo przenosić miedzy instancjami. Wystarczy na nowym serwerze dns utworzyć odpowiednia strefę, potem wyłączyć serwer dns, nadpisać plik i na nowo uruchomić serwer. Po kłopocie.

Po wszystkim rozpoczynamy nadawanie uprawnień dla użytkowników z domeny NEW. I tutaj kolejne zaskoczenie. Z przyczyn do tej pory dla nas znanych słabo, klienci serwera dns błędnie widzą strefę OLD. To znaczy adres old.local zostaje przez dns błędnie rozczytany jako adres ip kontrolera domeny w mieście B (który przecież został zaorany i postawiony jako kontroler domeny NEW). Po krótki dochodzeniu odnajdujemy pierwsze symptomy zamieszania. O to kontroler domeny w mieście B posiada FQDN (full quality domain name) b‑dc.old.local. Jak do cholery? Skąd do cholery? Do końca nie jesteśmy pewni. Wszystko wskazuje na to, że serwer DHCP na routerze podawał klientom właśnie taki suffix domeny. A serwer sobie zapisał i utrwalił. Dość łatwo to pozamieniać w kluczu:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System\DNSClient

Jednak odszukanie tego klucza i eliminację tego problemu zajęła nam dwa dni. Wcześniej próbowaliśmy zdziałać coś z samym serwerem DNS, ale wpisy w NS ciągle wracały do błędnego stanu.

Po wszystkim gotowy byłem do przenoszenia komputerów do nowej domeny. Cały proces nie jest skomplikowany. Z konta użytkownika eksportuje klucz HKEY_CURRENT_USER i zapisuje gdzieś na pulpicie. Potem loguję się na lokalne konto z uprawnieniami administracyjnymi, przenoszę z domeny OLD do grupy roboczej. Restart. Loguję się kolejny raz na lokalnego usera (w tym momencie i tak nie mogę zalogować się na konto domenowe), wprowadzam użytkownika do domeny NEW. Restart. Loguję się na konto użytkownika w nowej domenie, w tym momencie tworzy się nowy profil (zgodnie z tym, co pisałem w poprzednim wpisie). Wylogowuję się, loguję na użytkownika z uprawnieniami administracyjnymi i zmieniam wpis w rejestrze (także pisałem o tym w poprzednim blogu). I znów loguję się na użytkownika. Tym razem mam już dane z pulpitu itd. Nie mam jednak żadnych ustawień. Na szczęście na pulpicie jest pliki z wyeksportowanym CurrentUser, teraz go integruje i odpalam gpupdate /force. Na koniec restart, uzupełniam dane z Protected User Storage, ustawiam na użytkowniku żądanie zmiany hasła po następnym zalogowaniu i po wszystkim.

Całość w porywach może zająć 10 minut.

I na koniec pewna obserwacja... którą uważam za dość duży błąd... W każdym razie sytuacja wygląda tak: użytkownicy, będący programistami i pracownikami działu IT posiadają uprawnienia administracyjne na swoich komputerach. Po prostu są dodani do lokalnej grupy administratorzy. Po przeniesieniu do domeny NEW w niejasnych dla mnie okolicznościach użytkownik z domeny OLD zamieniony zostaje na odpowiedniego użytkownika z domeny NEW. Jeśli ktoś wie, dlaczego tak się dzieję chętnie przeczytam o tym!

Na koniec pewne zapowiedzi. Po pierwsze coś z działki administratora, czyli czym są domeny i czym różnią się od grup roboczych, co to jest DNS i DHCP oraz dlaczego to warto łączyć z AD. Po drugie coś dla początkujących programistów, czyli co to są frameworki w PHP, czym są wzorce i po jednym przykładzie z każdego. Wszystko już w miarę wkrótce :)