Nie wiem jak dużo ludzi słyszało o tym narzędziu, jedno jest pewne. Jakoś działa. Kiedy musimy z niego korzystać? Na pewno wtedy, jeśli dwie firmy czy dwa oddziały łączą się w jeden. To ogólnie może być spory problem – co jeśli na przykład jeden oddział pracuje na staruszku Windows Server 2003, a drugi śmiga na nowości, czyli Windowsie Server 2016 czy 2019? Sytuacja się komplikuje, a pomysłów może brakować. Często ludzie wtedy zastanawiają się na postawienie domeny od zera, lecz czy to ma sens? Trzeba podłączyć wszystkie systemy od zera. Tam, gdzie mamy skonfigurowane usługi powiązane z domeną – do piachu i od nowa.

Rozwiązaniem jest ADMT (Active Directory Migration Tool). Stare narzędzie od Microsoftu, które pozwala na migrację obiektów pomiędzy domenami. Pozwala nam na przenoszenie:

• kont użytkowników (z profilami użytkowników i hasłami do kont),
• grup użytkowników,
• kont komputerów (z uprawnieniami),
• kont wykorzystywanych do usług, np. konto serwisowe dla UTMa, które ma na celu sprawdzanie dziennika zdarzeń w poszukiwaniu informacji logowaniach użytkowników na konkretnych komputerach w domenie,
• raportowania.

Ja akurat w tym poście przerobię przykład na nowszych kontrolerach domeny, to znaczy będę przenosił obiekty z Windowsa Server 2008 R2 na 2019. Jeśli macie starsze systemy (np. Windows Server 2003 czy 2003 R2), warto sobie w takiej sytuacji postawić taki Windows Server 2008 R2 tymczasowo. I tak będziemy go potrzebowali, bo nie zrobimy bezpośredniej migracji z Windowsa Server 2003 (brak obsługi DFSR, SMBv1)/2003 R2 (SMBv1). To akurat opisałem już tutaj – może się przydać.

Przygotowanie do pracy

Zanim zaczniemy, przedstawię środowisko, które mamy do dyspozycji:

• Stara domena:
  • Nazwa domeny: nowadomena.local (tak, wiem, że nazwa jest myląca w tym poradniku)
  • Nazwa hosta: ad-2008-r2
  • Adres IP: 192.168.162.11
  • Maska podsieci: 255.255.255.0
  • Brama domyślna: 192.168.162.2
  • Preferowany serwer DNS: 192.168.162.12 (ad-2019.supratest.local)
  • Alternatywny serwer DNS: 127.0.0.1
  • W tej domenie jest podłączony klient z nazwą hosta ENDPOINT-1, który zostanie przeniesiony do nowej domeny
• Nowa domena:
  • Nazwa domeny: supratest.local
  • Nazwa hosta: ad-2019
  • Adres IP: 192.168.162.12
  • Maska podsieci: 255.255.255.0
  • Brama domyślna 192.168.162.2
  • Preferowany serwer DNS: 192.168.162.11 (ad-2008-r2.nowadomena.local)
  • Alternatywny serwer DNS: 127.0.0.1

W powyższym przykładzie zastosowałem pewne uproszczenia, mianowicie zwykle będzie tak, że oba serwery będą w dwóch różnych podsieciach. Do migracji elementów w domenie kontrolery (przynajmniej jeden po obu stronach) muszą mieć między sobą łączność, czyli np. muszą mieć umożliwiony routing i odblokowany ruch na firewallu. Aby nawiązać relację zaufania między kontrolerami domeny one muszą między sobą być w stanie rozwiązywać nazwy DNS, czyli kontroler ad-2008-r2 będący kontrolerem domeny nowadomena.local musi być w stanie rozwiązać nazwy z domeny supratest.local, a serwer ad-2019 będący kontrolerem domeny supratest.local musi być w stanie rozwiązywać nazwy w domenie nowadomena.local, stąd należy ustawić na tych hostach preferowane serwery DNS tak, by serwery wskazywały na siebie na wzajem. Z faktu, że są kontrolerami domeny, drugorzędnym serwerem DNS są one same, dzięki czemu rozwiązują nazwy we własnych domenach.

Instalacja narzędzi do migracji

Swoją drogą, nie wiem jak na Windowsie Server 2003 R2, ale na Windowsie Server 2003 nie byłem w stanie używać ADMT, więc w takich przypadkach trzeba instalować ADMT na Windowsie Server 2008 (R2). Na samym początku warto zacząć od instalacji Microsoft SQL Server 2008 (NIE R2), a po tym trzeba zainstalować Service Pack 1 do tej wersji SQLa. W instrukcji skorzystamy z darmowej wersji Express. Przejdźmy przez etap instalacji. Po odpaleniu instalatora wybieramy tylko funkcję Database Engine Services:

Następnie pozostawiamy nazwę instancji jako SQLEXPRESS (właściwie wszystkie te pola można zostawić bez zmiany i iść dalej).

Teraz musimy wskazać konto, które będziemy wykorzystywać jako konto obsługujące usługi serwera SQL. Ja wybrałem konto ZARZĄDZANIE NT\SYSTEM (w angielskim Windowsie NT AUTHORITY\SYSTEM).

Następnie wybieramy tryb uwierzytelniania Mixed Mode i definiujemy domyślne hasło do bazy danych. Dodałem też konto Administrator jako konto administracyjne dla SQLa.

Potem wystarczy jedynie klikać dalej i w ten sposób przejdziemy przez proces instalacji. Po tym musimy też zainstalować SQL Server 2008 Service Pack 1 (od niedawna odnośnik do niego na stronie Microsoftu jest niedostępny, więc jeśli tego potrzebujesz, spróbuj znaleźć plik o nazwie SQLServer2008SP1-KB968369-x64-ENU.exe (wersja 64-bitowa) lub SQLServer2008SP1-KB968369-x86-ENU.exe (wersja 32-bitowa) w Internecie):

Gdy mamy to za sobą, możemy przejść do instalacji ADMT. Pobierzemy je tutaj. Na samym początku musimy wskazać instancję bazy danych, z której chcemy korzystać. Wskazuję .\SQLEXPRESS. Ta kropka na początku oznacza, że to jest ta sama maszyna, na której pracujemy (po prostu maszyna lokalna).

Następnie wybieramy, że nic nie importujemy.

I to tyle, po tym powinien się ten program zainstalować. Poza tym musimy jeszcze zainstalować ADMT Password Export Server, ale do tego dojdziemy później.

Tworzenie relacji zaufania między domenami

Następnym krokiem jest stworzenie dwustronnej relacji zaufania między domenami. By to zrobić, należy w konfiguracji DNS obu domen stworzyć conditional forwarder na wzajem, czyli w DNSie nowadomena.local musi być conditional forwarder do supratest.local i w DNSie supratest.local musi być conditional forwarder do nowadomena.local. Ponadto musimy w obu domenach utworzyć strefy do wyszukiwania wstecz (rDNS). Warto zrestartować serwery po wykonaniu tych czynności – w moim przypadku dalszy etap nie dział dojść do skutku pomimo tego, że zrobiłem wszystko poprawnie, a po restarcie magicznie zaczęło działać.

By to zrobić, klikamy na drzewku serwera DNS w gałąź Strefy wyszukiwania wstecznego PPM i wybieramy Nowa strefa…

Na początku wybieramy strefę, którą chcemy utworzyć. Nas interesuje strefa podstawowa.

Następnie w pierwszym oknie kreatora wybieramy opcję Do wszystkich serwerów DNS uruchomionych na kontrolerach domeny w tym lesie: nowadomena.local:

Potem musimy wskazać, czy strefa będzie dotyczyć IPv4 czy IPv6. Wybieramy IPv4.

Następnie wskazujemy identyfikator sieci dla strefy rDNS, czyli w moim przypadku to 192.168.162.x:

Pod koniec, w ustawieniach aktualizacji dynamicznych wybieramy opcję Zezwalaj tylko na zabezpieczone aktualizacje dynamiczne (zalecane dla Active Directory).

W ten sposób mamy utworzoną strefę wyszukiwania wstecz i musimy to samo zrobić na drugim kontrolerze domeny. Następnie by utworzyć usługę warunkowego przesyłania dalej klikamy na gałąź Usługi warunkowego przesyłania dalej PPM i wybieramy Nowa usługa warunkowego przesyłania dalej….

Teraz w polu Domena DNS definiujemy nazwą domeny, do której przesyłamy zapytania DNS dalej, czyli na kontrolerze domeny supratest.local wskazujemy domenę nowadomena.local i poniżej w sekcji Adresy IP serwerów głównych wskazujemy adres serwera DNS tej domeny, czyli 192.168.162.11. Jeśli w waszej organizacji jest więcej niż jeden serwer DNS w domenie, należy wtedy zaznaczyć opcję Przechowaj tę usługę warunkowego przesyłania dalej w usłudze Active Directory i replikuj ją w następujące serwery: i wybieramy z listy Wszystkie serwery DNS w tym lesie.

Analogicznie robimy to samo dla domeny supratest.local na kontrolerze domeny nowadomena.local:

Mając to gotowe możemy w końcu nawiązać relację zaufania w przystawce Domeny i relacje zaufania usługi Active Directory klikając prawym na nazwę naszej domeny i Właściwości.

Następnie wybieramy zakładkę Zaufania i klikamy przycisk Nowe zaufanie….

Jeśli widzisz takie opcje w pierwszym oknie wyboru – to oznacza, że prawdopodobnie nie wykonałeś któregoś z poprzednich kroków. Ja tak miałem i zorientowanie się w czym popełniłem błąd zajęło mi tak z dobre 20 minut.

Jeśli wszystko jest okej, powinieneś zobaczyć takie opcje wyboru (wybieramy typ zaufania Zaufanie lasu):

Następnie wybieramy kierunek zaufania jako dwukierunkowy:

Teraz wskazujemy utworzenie zaufania dla tej domeny i określonej domeny.

Następnie musimy podać poświadczenia do konta administracyjnego w tej drugiej domenie. Zwróćcie uwagę, że ja tą czynność wykonuję z kontrolera domeny supratest.local!

Jako zakres uwierzytelniania dla użytkowników lasu nowadomena.local wybierzemy Uwierzytelnienie dla całego lasu.

Na końcu powinniśmy potwierdzić przychodzące i wychodzące zaufanie, więc tak też zaznaczamy.

Ostatnie machnięcia pędzlem przed rozpoczęciem migracji

I cyk, gotowe. Mamy relację zaufania pomiędzy dwoma domenami. Teraz przydadzą nam się jeszcze 3 rzeczy przed rozpoczęciem migracji:

• dodane uprawnień do grup administracyjnych w domenach nawzajem,
• zainstalowanie Password Export Server,
• wyłączenie firewalla na stacjach końcowych.

W grupie Administratorzy członkami są:

• użytkownik Administrator,
• grupa Administratorzy domeny (Domain Admins),
• grupa Administratorzy przedsiębiorstwa (Enterprise Admins).

W momencie pisania tego posta znalazłem posta, który dobrze opisuje do czego te grupy są, polecam zerknąć tutaj, by zaczerpnąć dobrej lekturki!
Tak czy siak, musimy tych członków grupy dodać nawzajem z obu domen, dzięki czemu w moim przykładzie w obu grupach Builtin\Administratorzy (Builtin\Administrators) lista członków będzie wyglądała następująco:

Teraz warto zainstalować ADMT Password Export Server. Na początku musimy utworzyć plik klucza szyfrującego, bo będzie nam potrzebny w instalacji. Zrobimy to za pomocą następującego polecenia (oczywiście możemy zmienić ścieżkę pliku i hasło):

cd C:\Windows\ADMT
admt.exe Key /Option:Create /SourceDomain:NOWADOMENA.LOCAL /KeyFile:C:\FileMigPass.pes /KeyPassword:Pass@123

Po pobraniu instalatora i uruchomieniu go zostaniemy poproszeni o ten plik klucza, co zrobiliśmy wyżej i o podanie hasła do niego:

Następnie musimy wskazać konto, na którego prawach będzie pracowała usługa serwera haseł. Ja wskazałem tutaj konto administrator@supratest.local (jak sam zrzut ekranu sugeruje te konto musi móc pracować w trybie usługi):

Po instalacji serwera haseł musimy zrestartować serwer, na którym wykonaliśmy instalację, a następnie włączyć jego usługę w przystawce Usługi (services.msc), usługa nazywa się Password Export Server Service:

Na koniec polityką GPO wyłączymy firewall we wszystkich systemach w firmie (zakładając, że wykorzystują jedynie Zaporę systemu Windows. W przystawce Zarządzanie zasadami grupy tworzymy nowy obiekt GPO klikając PPM na Obiekty zasad grupy i wybieramy Nowe, następnie wpisujemy nazwę polityki i zatwierdzamy.

Możemy ją od razu przeciągnąć i upuścić pod OU Komputery zakładając, że tam są wszystkie komputery, które chcemy przenosić (tam jest nasz host ENDPOINT-1 do przeniesienia). Następnie klikamy na obiekt PPM i wybieramy Edytuj….

Następnie przechodzimy do Konfiguracja komputera > Zasady > Szablony administracyjne > Sieć > Połączenia sieciowe > Zapora systemu Windows > Profil domeny i wyłączamy opcję Zapora systemu Windows: chroń wszystkie połączenia sieciowe. To samo wykonujemy na kontrolerze domeny w drugiej domenie.

Domyślnie po 90 + od 0 do 30 minut polityka wejdzie w życie na stanowiskach końcowych. Możemy przyspieszyć ten proces wykonując na tych maszynach polecenie gpupdate /force. Jeśli masz innego firewalla w systemie (np. jeśli korzystasz z ESET Endpoint Security) – powinieneś do wyłączenia antywirusa wykorzystać dedykowane narzędzia do tego, czyli w przypadku ESETa jest to konsola ESMC (ESET Security Management Center).
Dla ciekawskich, tutaj opisano z jakich portów korzysta ogólnie Active Directory.

W ten sposób firewall jest wyłączony i możemy zacząć prawdziwą migrację.

Migracja kont użytkowników, grup, komputerów, zabezpieczeń i haseł

Zaczynamy od uruchomienia ADMT (Active Directory Migration Tool). W nim, klikamy prawym na górę drzewka i wybieramy opcję, która nas interesuje. Z faktu, że musimy zrobić migrację komputera, musimy wykonać migracje (we wskazanej kolejności):

• użytkowników,
• grup użytkowników,
• translację zabezpieczeń,
• migrację haseł (to się robi już na etapie migracji użytkowników),
• komputerów.

Zaczniemy więc od migracji użytkowników kreatorem User Account Migration Wizard. Musimy na początku wskazać źródłową i docelową domenę względem których wykonujemy migrację. Wskazałem w Source domenę nowadomena.local i w Target supratest.local.

Następnie wybieramy Select users from domain, ponieważ chcemy wybierać użytkowników do migracji z drzewa AD, a nie z pliku.

Następnie wskazujemy użytkowników dodając ich z drzewka. Ja już dodałem dwóch:

Potem wskazujemy OU do którego przenosimy użytkowników w docelowej domenie. Nie stworzysz OU w nowej domenie z tego kreatora, więc jeśli planujesz jakiś konkretny schemat drzewa to przygotuj sobie go przed migracją. Wystarczy kliknąć w odpowiedni element drzewka po kliknięciu Browse… w domenie i to spowoduje, że adres się sam uzupełni.

W następnej części kreatora zostaniemy spytani, czy chcemy też migrować hasła użytkowników. Z faktu, że mamy już wdrożony ADMT Password Export Server, skorzystamy z tego. Wybieramy opcję Migrate passwords. Wskazujemy też kontroler domeny z którego migrujemy takie hasła, w moim przypadku to jest ad-2008-r2.nowadomena.local.

Następnie musimy określić w jaki sposób ma być realizowana migracja kont użytkowników. Aby uniknąć problemów wybieram opcję Target same as source. To powoduje, że jeśli konto jest włączone to docelowo też będzie na drugiej domenie i odwrotnie. Wybieram też na dole Migrate user SIDs to target domain. To jest istotne przy migracji komputerów z tego względu, że profile użytkownika i uprawnienia plików (np. na udziałach sieciowych) są do takiego SIDa przypisane i z tego powodu chcielibyśmy, by ten SID użytkownika się nie zmieniał. Poza tym musimy dać Tak w obu monitach, bo bez tego migracja SIDów się nie wykona:

Potem, musimy zdecydować czy chcemy dokonać translacji profili mobilnych, zaaktualizować uprawnienia użytkownika i przenieść grupy, w których jest użytkownik. Opcji jest więcej, w skrócie zaznaczamy wszystkie:

Kolejna rzeczy to wybór właściwości obiektów, które przenosimy. W skrócie nie wykluczamy żadnych, więc przechodzimy dalej bez zmieniania czegokolwiek.

Ostatnią rzecz, którą wybieramy jest decyzja co ma zrobić kreator, gdy pojawią się problemy w postaci konflików (np. przenosimy obiekt, który już istnieje w domenie docelowej). Najlepszym rozwiązaniem jest przeniesienie bez migracji obiektów z konfliktami i przejrzenie ich ręcznie by zobaczyć co właściwie jest nie tak, czy obiekty dotyczą takiej samej osoby i potem można uruchomić ten sam kreator ponownie, gdy się rozwiąże problem (np. przez usunięcie starego obiektu w docelowej domenie).

W ten sposób dotarliśmy do końca kreatora. Po kliknięciu Zakończ rozpocznie się proces migracji (okienko po prawej). Kliknąłem też View Log, by pokazać Wam jak wyglądają logi z takiej migracji.

Okej, teraz przejdźmy do migracji zabezpieczeń, którą trzeba wykonać przed migracją komputerów. Na tym etapie musimy mieć przygotowane komputery, które przenosimy w taki sposób, że:

• mają możliwość rozwiązywania nazw DNS w nowej domenie,
• mamy możliwość korzystania z uprawnień administracyjnych z obu domen,
• maszyny NIE mogą być uśpione/we wstanie wstrzymania,
• tak jak wcześniej to zmienialiśmy komputery najlepiej gdyby miały wyłączony firewall na czas migracji tak, aby agenty ADMT mogły się szybko zainstalować i wykonać ich robotę,
• taką translację powinniśmy robić na komputerach bez zalogowanych użytkowników. Dzięki temu nie mamy żadnych błędów przy translacji.

Jeśli jesteśmy pewni, że to jest zrobione i możemy odpalić kreator Security Translation Wizard:

Wybieramy opcję Previously migrated objects.

Tutaj zostawiamy tak samo jak poprzednio, bo przenosimy nadal z domeny nowadomena.local do supratest.local.

Wskazujemy komputery dla których translacja ma być wykonana poprzez drzewko z domeny wskazując opcję Select computers from domain, następnie wybieramy komputery, które nas interesują.

Poza wybraniem komputerów wskazujemy dodatkowo w polu Additional trusting domain domenę nowadomena.local.

Następnie zaznaczamy wszystkie pola. Po prostu.

W następnym polu zaznaczamy opcję Add, bo jeśli coś pójdzie nie tak to w żaden sposób nie zmodyfikujemy obiektów w naszej domenie.

Następnie po tym otworzy nam się okno Active Directory Migration Tool Agent Dialog, w którym taki proces migracji się odbywa. Jest on nieco bardziej rozbudowany, bo migracja nie odbywa się natychmiast, dzięki mamy czas po zakończeniu kreatora, by upewnić się, że komputery są gotowe do migracji. Na początku wybieramy Run pre-check dzięki czemu sprawdzimy, czy agent się poprawnie zainstaluje na maszynie końcowej. Dopiero po tym możemy wykonać translację.

Jeśli otrzymujesz po pre-checku następujący błąd:

ERR2:7666 Unable to access server service on the machine 'computer.domain.com'.  Make sure netlogon and workstation services are running and you can authenticate yourself to the machine.  hr=0x800706ba. The RPC server is unavailable

To oznacza, że firewall blokuje połączenie, ogólnie te błędy się sprawdza w View Migration Log. Po prostu wyłącz firewall i wtedy zadziała. Jeśli stan Pre-check jest Passed, możemy wybrać Run pre-check and start agent operation. Oczywiście wtedy Agent Dialog pominie test i zajmie się tym, czym właściwie ma. Jeśli mieliście zalogowanych użytkowników na danej stacji, to translacja zakończy się z ostrzeżeniami.

W innym wypadku nie powinno być problemu jak tutaj (po prostu uruchomiłem dla tego samego komputera kreator ponownie):

Okej, w takim razie w tym momencie doszliśmy do etapu przewodniego tego posta – migracji komputerów. Odpalamy kreator Computer Migration Wizard. Na samym początku wskazujemy domeny tak samo jak poprzednio:

Potem wskazujemy komputer(y) tak samo jak w kreatorze translacji zabezpieczeń (opcją Select computers from domain i wybierając je z drzewka):

Następnie wskazujemy DN dla docelowego OU, w którym ma się znajdować komputer po przeniesieniu do domeny (tak samo jak w migracji użytkowników/grup wskazujemy miejsce w drzewku, a adres się sam uzupełni):

Tak jak poprzednio, zaznaczamy wszystkie elementy do translacji.

Podobnie jak w poprzednim kreatorze, zaznaczamy opcję translacji zabezpieczeń Add (choć ja zaznaczyłem Replace na zrzucie).

Potem określamy czas, po jakim migracja się rozpocznie. Jeśli pracownicy pracują przy komputerach i są tego świadomi, że będzie wykonywana taka migracja lub ich po prostu nie ma, warto zaznaczyć 0 – po prostu migracja rozpocznie się natychmiast.

Podobnie jak w przypadku migracji użytkowników nie wykluczamy żadnych atrybutów obiektów ani nie migrujemy obiektów, jeśli pojawi się jakiś konflikt pomiędzy domenami (lecz teraz nie między obiektami użytkowników/grup, a obiektami komputerów).

Na koniec obiekt zostanie skopiowany i na maszynie powinien odpalić się ten sam proces przygotowania instalacji agenta ADMT jak w przypadku translacji zabezpieczeń.

Tutaj po zakończeniu migracji możemy zobaczyć, że komputer się restartuje…

i kończymy sukcesem, bo podłączył się do nowej domeny.

Co prawda nie mam screenshota z przeniesionego hosta, ale po zalogowaniu się do użytkownika, z którego korzystałem na tej przeniesionej maszynie mogłem się zalogować do tego samego profilu, lecz przy pierwszym logowaniu musiałem zmienić hasło (starym hasłem było hasło dotychczasowe ze starej domeny). I tyle, w ten sposób można zrobić migrację komputerów dzięki ADMT!

Sporo informatyków w różnych organizacjach ma jeden duży problem – jego organizacja nie ma lub nie chce przeznaczać środków na IT. Nie ma kasy na nowy serwer, nie ma kasy na Windowsa Server 2019 (Essentials lub Standard) i nie ma kasy na licencje CAL (w przypadku wersji Standard). W takiej sytuacji pojawia się pomysł: „hej, w końcu na QNAPie i Synology jest funkcja kontrolera domeny, postawmy domenę na tym”. Moja sugestia:

Nie rób tego.

Dlaczego? To, że ta funkcja w tych systemach tak się nazywa nie znaczy, że oferuje dokładnie to samo, co kontroler domeny w Windowsie z prawdziwego zdarzenia. By oszczędzić Ci włosów, które byś sobie wyrwał(a) z głowy w trakcie pracy na tym, postanowiłem samemu przekonać się na własnej skórze jak to działa w praktyce.

Przygotowanie do testów

Mam w domu QNAPa TS-453A z 8 GB RAMu z 4 dyskami 2 TB marki WD. klientami są maszyny wirtualne, które stawiałem w środowisku VMware Workstation Pro 15.x. Założenie jest proste – podłączyć do niego maszyny i próbować sprawdzić jak zachowuje się domena oraz jaka jest jej charakterystyka. Prędzej czy później w firmach znajdują się środki, więc pewnie kiedyś taka domena po jakimś czasie zostałaby przeniesiona na nowy kontroler domeny.

Praktyka

Na początek podłączyłem sobie Windowsa Server 2016 do tej domeny, bo chciałem przenieść domenę na drugi kontroler (zainstalowałem na tym Windowsie rolę Usługi domenowe Active Directory). Chciałem to zrobić w sposób, który opisałem tutaj. Nie wyszło, dlaczego? Przed startem podniesienia drugiego kontrolera domeny otrzymuję komunikat, że serwer RPC nie jest dostępny, ani, że serwer nie jest w stanie skontaktować się z aktualnym kontrolerem poprzez WMI.

Na tym etapie zrezygnowałem. Może inny Windows Server da radę? Sprawdziłem na 2019, to samo.

Powyżej zrzut ekranu z 2012 – też to samo, 2012 R2 – te same efekty. Sprawdziłem sobie poziom funkcjonalności lasu i domeny – Windows Server 2008 R2. To oznacza, że te hosty powinny się bez problemu podłączać.

Jak spróbowałem podłączyć system Windows Server 2008 R2 (ze starszymi nie próbuję, ten i tak już nie jest wspierany) do domeny to otrzymałem taki komunikat:

W dużym skrócie – nie podepniesz go do domeny. W takiej sytuacji myślę sobie – ale przecież możemy zrobić relację zaufania pomiędzy domenami i tak przenieść wszystkie obiekty w AD wraz ze wzorcami na nowy serwer. Z tym pomysłem też się przejechałem, bo jak otworzyłem DNSa na koncie Administratora to dostałem to:

W QNAPie jest zakładka do zarządzania DNSem, wygląda ona tak:

Opcje związane z zarządzaniem usługami do warunkowego przekierowania tu nie istnieją, a bez tego nie zrobimy dwustronnej relacji zaufania. Nie wiem jak, ale potem byłem już w stanie dostać się do ustawień DNSa z poziomu przystawki MMC, ale nadal przy wspomnianych ustawieniach dostaję to:

Dzięki temu możemy zapomnieć o przeniesieniu obiektów z tej domeny. Zobaczmy jeszcze jak wygląda zarządzanie politykami GPO:

Widzicie różnicę? Bo ja tak, nie ma wielu ustawień. Miałem też problem ze stworzeniem nowej polityki, właściwie tego nie byłem w stanie zrobić, ale nie zrobiłem z tego zrzutu ekranu. Trochę poszperałem w Internecie i znalazłem instrukcje do konfiguracji DNSa w Sambie:
https://lists.samba.org/archive/samba/2018-December/219978.html
Ponadto tutaj jest więcej informacji na temat konfiguracji DNS w Sambie:
https://wiki.samba.org/index.php/DNS_Administration

Konkluzja

Nie jestem magikiem od AD póki co, ale to mi śmierdzi – sporo rzeczy, które działa normalnie w Windowsowym AD DS albo wymaga kombinacji jak niczym Justyna Kowalczyk w biathlonie, lecz przed komputerem i niektóre rzeczy po prostu nie działają tak, jak powinny. Czy pocenie się przed kolejnym wyzwaniem stawianym przez to, że Samba nie jest standardowym serwerem AD jest warte świeczki i pieniędzy, które można przeznaczyć na Windowsa Server? Moim zdaniem nie.

Jeśli administrujecie domeną Active Directory w waszych organizacjach, pewnie wiecie, że czasami trzeba instalować różne programy pracownikom. Z faktu, że informatyk to leniwy zawód to by utrzymać swój stan warto spróbować instalować programy zdalnie. Dzięki temu nie musimy biegać po komputerach, by zainstalować jeden program. Jeden program, a co jeśli komputerów trzeba ogarnąć sporo?

W sumie to warto się zastanowić co się najczęściej instaluje na komputerze:

• Przeglądarka internetowa (Chrome/Firefox),
• Pakiet Office (MS Office/LibreOffice),
• W niektórych firmach Adobe Reader/Foxit Reader,
• 7-Zip,
• Program antywirusowy (w moim przypadku ESET Security),
• Klient VPN (jeśli firma daje możliwość np. home-office),
• Program do robienia kopii zapasowych komputera (w moim przypadku StorageCraft ShadowProtect),
• Java Runtime Kit (niektóre aplikacje tego wymagają),
• Z przydatnych, lecz niekoniecznie niezbędnych:
  • Everything (szybkie wyszukiwanie plików),
  • Klient chmurowy (w moim przypadku Nextcloud i OneDrive),
  • Narzędzie do robienia screenshotów (w moim przypadku Greenshot),
  • Menedżer haseł (w moim przypadku KeepassXC),
• Programy potrzebne do konkretnego rodzaju pracy, np. księgowość będzie korzystała z programów pokroju Płatnika czy jakiegoś programu ERP typu Comarch Optima, Macrologic itd., administratorzy będą raczej mieli VirtualBoxa, VMware Workstation, Visual Studio Code/Notepad++, programiści mieliby np. Visual Studio, IntelliJ i tak mógłbym wymieniać be z końca.

Jak widać, robi się z tego dosyć pokaźna lista i pewnie gdyby trzeba było to zainstalować na komputerze pracownika ręcznie – możesz zapomnieć o godzinie w pracy co najmniej, a pracowników do obsłużenia czasami może być kilkadziesiąt czy kilkaset, więc prostszym rozwiązaniem jest skorzystanie z GPO (Group Policy Object).

Myślę, że warto to podzielić na dwa etapy – szybka organizacja użytkowników i komputerów w AD i stworzenie polityk GPO. GPM (Group Policy Management) pozwala nam ustawić dowolne ustawienie dotyczące działania systemu Windows jak i niektórych programów względem konkretnych komputerów czy użytkowników poprzez zarządzanie obiektami (tzw. GPO).

Inaczej mówiąc, dzięki temu możemy ustawić dla użytkownika, że na przykład ma mieć z góry ustawioną tapetę z logiem naszej firmy i nie może jej zmieniać czy np. to, że nie może korzystać ze sklepu Microsoft Store w celu instalowania dodatkowych aplikacji.

Dla komputera możemy zaś ustawić np. to, że nie wymagamy modułu TPM do szyfrowania komputerów BitLockerem, polityki firewalla w Windows Defender. Są rzeczy, które pojawiają się zarówno w części dla komputera jak i użytkownika jak na przykład instalowanie programów, ale tutaj raczej się skupię nad samym wykorzystaniem funkcjonalności w praktyce niż opisaniem co to jest.

Organizacja użytkowników i komputerów w AD

To jest prostsze, niż nam się wydaje, bo bardziej chodzi tutaj o poukładanie komputerów i użytkowników w odpowiednim schemacie drzewka. Tworzy się je w przystawce Użytkownicy i komputery usługi Active Directory. Myślę, że najsensowniejsze jest to rozwiązanie poniżej (jeśli są propozycje na lepsze to zachęcam do zostawienia komentarzy). Podzieliłem je tak dlatego, bo wdrażałbym osobno polityki dla użytkowników (np. ustawienia dotyczące montowania zasobów sieciowych automatycznie) byłyby per danych dział lub były wspólne (podpinam je do drzewka poziom wyżej, np. ustawienie wspólnego udziału sieciowego dla całej firmy byłoby podpięte do obiektu Użytkownicy, bo dotyczy wszystkich użytkowników w firmie).

Z drugiej strony chcę móc wybierać jak mają być skonfigurowane osobno komputery i osobno laptopy (np. chcę szyfrować wszystkie laptopy i nie szyfruję stacjonarek). Poza tym chcę, by konkretne programy były zainstalowane w konkretnych działach (np. ERP Optima w księgowości, VMware Workstation w IT), ale na przykład Chrome i Firefox powinny być zainstalowane u wszystkich bez względu na to, czy pracują na laptopach czy stacjonarkach.

Po co to wszystko? Po to, by móc konkretnie ustawić daną grupę komputerów, dzięki czemu czynności, które musimy wykonać po to, by ustawić wszystkie komputer są automatyzowane, czyli zamiast robić coś 10 razy zrobimy to raz by przetestować czy dobrze działa, a potem wskażemy daną grupę (np. dział IT) i niech się ten VMware Workstation instaluje na wszystkich komputerach od IT.

Następnie miejsce, gdzie ustawiamy polityki GPO jest tutaj, w przystawce Zarządzanie zasadami grupy.

Tworzenie polityk GPO i przypisywanie ich do grup

W tworzeniu konfiguracji założenie jest następujące:

• tworzymy obiekty, które są szablonami konfiguracji komputerów lub/i użytkowników (przy czym warto im dać jakąś nazwę, która będzie mówiła nam jasno co ten szablon robi bez głębszego zerkania w szczegóły, np. browser install),
• definiujemy jakie ustawienia chcemy mieć w konkretnym szablonie, na przykład instalację pakietu oprogramowania Google Chrome i Mozilla Firefox (by użytkownicy mieli jakiś wybór) czy automatycznie dodanie udziału sieciowego //fileserver/share,
• przypisujemy taki obiekt do konkretnej jednostki organizacyjnej (OU – organisational unit), dzięki czemu definiujemy, że szablon instalacji Google Chrome i Mozilla Firefox ma być wdrożony na wszystkich komputerach w organizacji (przypinając obiekt do OU Firma/Komputery).

tworzymy obiekty, które są szablonami konfiguracji komputerów i użytkowników.

W przypadku zwykłych ustawień to jest kwestia wyklikania w szablonie tego, co chcemy, a potem przeciągnięcia szablonu do OU w ten sposób:

Z faktu, że tutaj jest mowa o pakietach instalacyjnych, najpierw musimy te pakiety umieścić w miejscu, gdzie te komputery, na których wdrażamy programy będą mogły je wdrożyć. Po prostu trzeba zrobić udział sieciowy. Stwórz folder na przykład w C:\, ja akurat go nazwałem gpo. Następnie udostępnij ten folder poprzez przejście do zakładki Udostępnianie, wybierz poniżej Udostępnianie zaawansowane…, kliknij na górze okna Udostępnij ten folder, kliknij w Uprawnienia i upewnij się, że grupa Wszyscy ma dostęp tylko do odczytu. Dzięki temu nikt nam nic nie zmieni w tym katalogu.

Poza tym przydaloby się dać dostęp komputerom do tych plików. Wybieramy zakładkę Zabezpieczenia i dodajemy dostęp do odczytu i wykonanie (domyślne ustawienie) grupie Użytkownicy uwierzytelnieni.

Okej, jak już mamy ten udział to umieśćmy pliki instalacyjne w nim. W moim przypadku będziemy instalować 7-Zipa i StorageCraft ShadowProtect SPX. Instalatory muszą być pakietami MSI, by dało się je zainstalować. Stworzymy dla nich 3 osobne polityki GPO. Aby stworzyć jedną, trzeba kliknąć Obiekty zasad grupy > Nowe, następnie podaj nazwę nowego obiektu i OK. W moim przykładzie nazwałem obiekt 7zip.

Następnie klikamy prawym na nowoutworzony obiekt i wybieramy Edytuj…, następnie otworzy nam się okno, w którym definiujemy szablon. W nim przechodzimy do Konfiguracja komputera > Zasady > Ustawienia oprogramowania > Instalacja oprogramowania i po prawej stronie klikamy PPM, następnie wybieramy Nowy > Pakiet….

Wybieramy z listy instalator 7-Zipa (mamy 2, więc proces musimy wykonać 2 razy dla systemów 32 i 64-bitowych), następnie musimy wybrać metodę rozmieszczenia oprogramowania. Przypisany – po prostu z domyślnymi ustawieniami ma się zainstalować. Założenie jest takie, że pakiet, który przypisujesz powinien się zgadzać językiem z systemem, na którym ma być zainstalowany i czasami po zostawieniu pakietu w taki sposób instalacja się w ogóle nie wykonuje, dlatego wybieram opcję Zaawansowane.

Otworzy nam się okienko z właściwościami tego instalatora. Dzięki niemu możemy zobaczyć na jaką platformę jest przygotowany program, jaki język jest domyślnym językiem programu i to mamy w zakładce Ogólne. To, co na ten moment nas interesuje to zakładka Rozmieszczanie.

Klikamy tutaj Zaawansowane…

Następnie zaznaczamy opcje Ignoruj język w czasie rozmieszczania tego pakietu i Udostępnij tę 32-bitową aplikację X86 komputerom Win64. Dzięki temu ta aplikacja zainstaluje się tylko na komputerach z systemem 32-bitowym bez względu na język systemu operacyjnego. Po tym można dać OK 2 razy i w ten sposób dodaliśmy pakiet instalacyjny dla 32-bitowej wersji 7-Zipa, teraz musimy to samo zrobić dla 64-bitowej wersji. Jedyna różnica tutaj będzie taka, że nie ma w Zaawansowane opcje rozmieszczania opcji Udostępnij tę 32-bitową aplikację X86 komputerom Win64, bo w końcu da się ją zainstalować tylko na 64-bitowych procesorach.

Po wszystkim szablon powinien wyglądać tak:

Jeśli klikniemy w oknie Zarządzanie zasadami grupy na nasz nowy obiekt i przejdziemy u góry do zakładki Ustawienia, będziemy mogli zobaczyć jak wyglądają wszystkie ustawienia zdefiniowane w tym szablonie. Po tym możemy przeciągnąć szablon do OU, tak jak na animacji wyżej i to tyle. W ten sposób mamy wdrożoną politykę GPO.

Drobna uwaga – warto mieć maszyny wirtualne na których możemy sobie testować takie polityki przed wdrożeniem ich produkcyjnie, na przykład jeśli mamy w organizacji pracowników pracujących na Windowsie 10 i Windowsie 8.1 to dobrze jest mieć wirtualki z takimi systemami – dzięki temu jesteśmy w stanie zobaczyć jak przejdzie proces instalacji na takich maszynach dzięki czemu unikniemy potencjalnych nieprzyjemnych niespodzianek na produkcyjnym sprzęcie.

Pakiety transformacji i wykorzystywanie Orca

Czasami niektóre pakiety MSI wymagają dodatkowych parametrów, by zadziałały. Skorzystam z przykładu programu StorageCraft ShadowProtect SPX. We wdrożeniach GPO wymaga on, by podać parametr IACCEPT=STORAGECRAFTEULA. W tej sytuacji rozwiązaniem jest stworzenie pakietu transformacji i dodanie go to pakietu instalacyjnego w momencie dodawania go do szablonu GPO.

Takie pakiety transformacji tworzy się w programie Orca. Jest on dostarczany w postaci instalatora razem z Windows ADK (Assessment and Deploment Kit). W moim przypadku był w katalogu C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86\Orca-x86_en-us.msi. W tym instalatorze na dobrą sprawę musimy go przeklikać dalej, dalej, dalej i mamy go na zainstalowanego. Następnie otwieramy go, wybieramy u góry w lewym rogu File > Open i wybieramy instalator, który nas interesuje.

Wedle wskazania w dokumentacji powinniśmy taki parametr podać w sekcji Property (wybieramy z listy po prawej stronie), potem w górnym panelu wybieramy Transform > New Transform.

Wybieramy teraz w Tables > Add Row… i tutaj dodajemy dane klikając w pole Property i wpisując IACCEPT, następnie klikamy pole Value i wpisujemy STORAGECRAFT.EULA. Po tym klikamy OK.

Zobaczymy po tym, że nowe pole jest obramowane na zielono. W ten sposób możemy zapisać nasz plik transformacji poprzez Transform > Generate Transform… i zapisując plik.

Mając to przy dodawaniu pakietu wybieramy kartę Modyfikację, klikamy przycisk Dodaj… i wskazujemy plik transformacji, przy czym nie zapomnijmy go umieścić na wcześniej utworzonym udziale sieciowym.

Zmiany można też zamieszczać wewnątrz pakietów MSI, dzięki czemu nie trzeba korzystać z pakietów transformacji, po prostu należy zapisać zmiany jako pakiet MSI:

Wdrażanie polityk GPO w życie

Nowa polityka wchodzi w życie w ciągu 90 minut + maksymalnie 30 minut. Jest to zrobione po to, by w przypadku dużych środowisk polityki były bez problemu wysłane i zastosowane na wszystkich wskazanych stanowiskach. Możemy ten proces przyspieszyć wykonując polecenie gpupdate /force na stanowiskach, gdzie taka polityka powinna być zaaktualizowana. W przypadku pakietów instalacyjnych jest potrzebny restart systemu, więc do polecenia dodajemy parametr /boot, czyli gpupdate /force /boot. Od Windowsa Server 2012 możemy takie wymuszenia wykonywać zdalnie (z samej przystawki i poprzez Windows PowerShell).

Zanim będziemy takie aktualizacje wykonywać zdalnie powinniśmy wdrożyć jedną politykę GPO odblokowującą porty w firewallu, bo domyślnie są zablokowane i otrzymamy błędy przy wykonaniu. Do tego trzeba stworzyć politykę, która odblokowuje ruch przychodzący, gdzie na dobrą sprawę możemy skopiować polityki bezpośrednio z lokalnych ustawień Zapory Windows Defender z zabezpieczeniami zaawansowanymi, a nazwy reguł, które musimy mieć to:

• Instrumentacja zarządzania Windows (ruch przychodzący ASync),
• Instrumentacja zarządzania Windows (ruch przychodzący DCOM),
• Instrumentacja zarządzania Windows (ruch przychodzący WMI),
• Zdalne zarządzanie woluminami (RPC-EPMAP),
• Zdalne zarządzanie zaplanowanymi zadaniami (RPC-EPMAP).

Część z reguł jest domyślnie wyłączona; należy na nie kliknąć prawym i wybrać Włącz regułę. Te ustawienia znajdują się w Konfiguracja komputera > Zasady > Ustawienia systemu Windows > Ustawienia zabezpieczeń > Zapora Windows Defender z zabezpieczeniami zaawansowanymi > Zapora Windows Defender z zabezpieczeniami zaawansowanymi – LDAP://CN={UUIDBARDZODLUGI},CN=POLICIES,CN=SYSTEM,DC=DOMENA,DC=LOCAL > Reguły przychodzące.

Wymuszenie takiej aktualizacji poprzez Zarządzanie zasadami grupy wygląda tak, że klikamy PPM na OU, w którym chcemy wykonać aktualizację polityk GPO, a następnie wybieramy Aktualizacja zasad grupy….

Następnie zostaniem spytani czy na pewno chcemy to zrobić, od razu widzimy ile komputerów otrzyma aktualizację. Klikamy Tak.

W efekcie widzimy też na jakich hostach taki proces się udał, a na jakich nie. W moim przypadku wszystko się udało.

Po restarcie jednego z desktopów widzimy efekt (w międzyczasie też dodałem na komputerze Google Chrome):

Drugą metodą na aktualizację polityk są polecenia (tzw. cmdlety (command-lety)) w Windows PowerShell. Odpowiednikiem polecenia gpupdate /force w PowerShell jest Invoke-GPUpdate, lecz te polecenie da się wykonać tylko z Windowsów Server. Tutaj mamy większe możliwości, bo możemy wskazywać nawet z jakim opóźnieniem ma być wykonywana aktualizacja. Same polecenie uruchomi aktualizację polityk GPO na maszynie, z której te polecenie jest wykonywane, więc warto wskazać komputery na których chcemy taką aktualizację przeprowadzić. Dam tutaj bardziej rozbudowany przykład polecenia. Dzięki niemu:

Invoke-GPUpdate -Force -Boot -Computer endpoint-3 -RandomDelayInMinutes 0

• wymuszamy aktualizację bez potwierdzenia od strony użytkownika,
• restartuje komputer przy wdrożeniu pakietów instalacyjnych,
• wskazuje komputer endpoint-3 jako tą, na której ma być wykonana aktualizacja polityk,
• wykonanie nastąpi natychmiast, bo określony losowy czas wykonania to 0.

Rozbudujmy to trochę bardziej – wskażmy wszystkie komputery z danego OU do aktualizacji.

W moim przypadku chcę zaaktualizować wszystkie komputery będące w OU Komputery będącym w OU FIRMA. Biorąc pod uwagę, że nazwa mojej domeny to domena.local, polecenie wygląda następująco:

Get-ADComputer -Filter * -SearchBase "OU=Komputery,OU=FIRMA,DC=domena,DC=local" | foreach { Invoke-GPUpdate -Force -Boot –Computer $_.name -RandomDelayInMinutes 0}

W parametrze -SearchBase polecenia Get-ADComputer musimy określić Distinguised Name (jak bym miał to przetłumaczyć to byłoby to „wyróżniająca się nazwa”, choć słyszałem tłumaczenia nazwa dystyngowana, zbierało mi się na wymioty). To można znaleźć na dwa sposoby:

Pierwszą jest znalezienie DNa dla konkretnego OU. Możemy to zrobić włączając Opcje zaawansowane w przystawce Użytkownicy i komputery usługi Active Directory. O tutaj:

Następnie klikamy na OU, które nas interesuje PPM > Właściwości.

Wybieramy zakładkę Edytor atrybutów i szukamy pola distinguishedName. Klikamy na dole okna przycisk Wyświetl i kopiujemy zawartość.

Na dobrą sprawę druga metoda to wypisanie sobie schematów drzewka od samego dołu do góry i zapisanie ich w jednej linii oddzielając przecinkami:

• OU=Komputery
• OU=FIRMA
• DC=domena
• DC=local

W DN oddzielamy wszystkie segmenty drzewka przecinkami, poza tym wykorzystuje skróty CN (common name) dla nazw użytkownika i grup, OU (organisational unit) dla jednostek organizacyjnych i DC (domain component) dla nazwy domeny. Gdyby domena to było to.jest.testowa.domena.local to kompletna część DC byłaby: DC=to,DC=jest,DC=testowa,DC=domena,DC=local. W tym przypadku powyżej wynik jest widoczny na zrzucie ekranu.

Windows Server 2003 i 2003 R2 to relikty przeszłości, ale z jakiegoś powodu czasami niektórzy je nadal wykorzystują (pomimo braku wsparcia, aktualizacji, braku możliwości migracji systemu itd.). Czasami tak bywa i trzeba się z tym liczyć, więc warto też wiedzieć jak przenieść obiekty w AD do systemu z tego aktualnego dziesięciolecia (co prawda końcówki, ale nadal).

W tym poście postaram się przedstawić najgorszy przypadek, jaki jest do migracji i właściwie jej cały proces. Teoretycznie można robić downgrade Windowsa Server do niższej wersji jeśli się zamówi do tego nośnik, ale po co? Mamy nowy sprzęt, mamy nowy system, więc dlaczego to zmieniać? Najlepiej się moim zdaniem trzymać nowszych systemów z prostego powodu – ich wsparcie się kończy później.

Okej, w takim razie moje środowisko wygląda tak:

• Domena: supra.local
• Nazwa hosta z Windowsem Server 2003: ad-2003
• Adres IP ad-2003: 192.168.162.10/24
• Nazwa hosta z Windowsem Server 2008 R2: ad-2008-r2
• Adres IP ad-2008-r2: 192.168.162.11/24
• Nazwa hosta z Windowsem Server 2019: ad-2019
• Domena supra.local znajduje się na ad-2003 (pełni on rolę kontrolera domeny AD)

Przeniesienie domeny bezpośrednio na Windowsa Server 2019 nie jest możliwe ze względu na to, że Windows Server 2019 nie wspiera SMB 1.0. Co prawda, można ją włączyć, ale to i tak nic nie da, bo jeszcze trzeba zmienić metodę replikacji danych pomiędzy kontrolerami z FRS na DFSR, gdzie DFSR nie jest wspierany przez Windowsa Server 2003. Jest on dostępny dopiero w Windowsie Server 2003 R2. W naszym scenariuszu postawimy tymczasowo Windowsa Server 2008 R2, przeniesiemy na niego domenę, a potem przeniesiemy domenę z 2008 R2 na 2019.

W tym poście pominę zrzuty ekranu z tego, jak się stawia kontroler domeny – będąc szczerym nie robiłem ich w momencie, gdy pisałem sobie notatki w tym zakresie. Tak czy siak, tym od czego należy zacząć jest instalacja Windowsa Server 2008 R2 (najlepiej na maszynie wirtualnej, potem można jej się szybko pozbyć). Na niej zmieniamy nazwę hosta na taką, jaką chcemy (w moim przypadku jest to ad-2008-r2 dla łatwiejszego zrozumienia jaki system na jakim etapie jest wykorzystywany), następnie ustawiamy statyczne adresy IP dla nowego serwera. W moim przypadku będzie to 192.168.162.11/24, poza tym serwerem DNS będzie adres aktualnego kontrolera domeny – 192.168.162.10. Po tym podłączamy ją do domeny (w moim przypadku supra.local podając uprawnienia do konta pozwalającego na dodanie do domeny nowego komputera.

Następnie instalujemy na nim rolę Usługi domenowe w usłudze Active Directory, to też nam zainstaluje Serwer DNS. W Windows Server 2008 (R2) można uruchomić kreatora promocji serwera do kontrolera domeny za pomocą polecenia dcpromo.exe i to też zrobiłbym, ale bez żadnego przygotowania można spotkać się z takim komunikatem w trakcie dodawania drugiego kontrolera domeny:

Na tym etapie powinniśmy przygotować strukturę lasu i domeny do umożliwienia stworzenia kontrolera domeny na Windowsie Server 2008 R2. Do tego musimy:

1. Sprawdzić jaki mamy aktualnie poziom funkcjonalności domeny i lasu. Domyślnie to jest Windows Server 2000 Local, należy go zmienić na Windows Server 2003. Na dobrą sprawę wystarczy ustawić Windows Server 2000 Mixed, ale w moim przypadku nie był on dostępny w opcjach. Na ten moment wystarczy zmiana samego poziomu domeny.
2. Podłączyć do napędu ad-2003 płytę instalacyjną Windowsa Server 2008 R2 (w moim przypadku napęd jest pod literą D:).
3. Otworzyć Wiersz polecenia jako Administrator, przejść do lokalizacji <litera-dysku>:\support\adprep, a następnie wykonać polecenie adprep32.exe /forestprep (lub adprep.exe /forestprep w przypadku 64-bitowego Windowsa Server 2003).

Następnie musimy przygotować domenę tak samo jak las, więc uruchamiamy polecenie adprep32.exe /forestprep (lub adprep.exe /domainprep w przypadku 64-bitowego Windowsa Server 2003).

Po tym powinno się podać parametry /gpprep i /rodcprep, więc wykonujemy adprep32.exe /gpprep, a potem adprep32.exe /rodcprep (jak mamy wersję 64-bitową, program to adprep.exe jak w poprzednich poleceniach).

Po tym możemy ponownie odpalić Kreator instalacji usług domenowych Active Directory i tym razem nie powinno być problemu z dodaniem kontrolera domeny na Windowsie Server 2008 R2.

Okej, jak kontroler się postawi to trzeba standardowo zrobić restart systemu. Teraz trzeba się zabrać za podniesienie poziomu domeny, przeniesienie ról głównego kontrolera domeny na ad-2008-r2 i pozbycie się ad-2003. Na początku zaczniemy od podniesienia poziomu funkcjonalności lasu do Windowsa Server 2003. Można to zrobić w Domeny i relacje zaufania usługi Active Directory. Po otwarciu musimy kliknąć na główne drzewko, które się nazywa tak samo jak okno, wybrać Podnieś poziom funkcjonalności lasu…, a następnie wybrać Windows Server 2003.

Teraz możemy zająć się przenoszeniem ról głównego kontrolera domeny. Upewnij się, że jesteś zalogowany na koncie administratora (dosłownie Administrator) i uruchom polecenie regsvr32 schmmgmt.dll.

To nam doda nową przystawkę do MMC – Schemat usługi Active Directory. Uruchom konsolę MMC poprzez polecenie mmc, kliknij Plik -> Dodaj/Usuń przystawkę… i wybierz z listy wspomnianą, a następnie kliknij przycisk Dodaj.

Następnie musisz zmienić kontroler domeny, z którego wykonujesz czynność, bo założenie jest takie, że z jego poziomu możesz kliknąć Zmień…. Tak będzie ogólnie z każdym wzorcem operacji, który musimy zmienić, a jest ich 5:

• Wzorzec schematu,
• Wzorzec nazw domen,
• Podstawowy kontroler domeny,
• Menedżer puli RID,
• Wzorzec infrastruktury.

W Schemacie usługi Active Directory zmieniamy wzorzec schematu. Na początku tak jak pisałem kontroler domeny wybierając PPM na początek drzewka, który nazywa się tak samo jak podstawka i wybieramy Zmień kontrolera domeny usługi Active Directory…, a następnie wybieramy nowy kontroler domeny, w moim przypadku ad-2008-r2. Następnie ponownie klikamy PPM na początek drzewka, lecz tym razem wybieramy Wzorzec operacji… i klikamy Zmień…. Zostaniemy spytani, czy na pewno chcemy przenieść wzorzec na taki host i to musimy zatwierdzić. Niestety, z tego etapu nie mam zrzutu ekranu 🙁

Tak czy siak, teraz musimy przenieść wzorzec nazw domen i to robimy w Domeny i relacje zaufania usługi Active Directory. Zmieniamy kontroler domeny, otwieramy opcje zmiany wzorca operacji w taki sam sposób, jak poprzednio, klikamy Zmień… i w ten sposób wzorzec nazw domen mamy za sobą.

Teraz pora na pozostałe 3 komponenty. Te zmieniamy w Użytkownicy i komputery usługi Active Directory klikając na drzewko z nazwą naszej domeny (w moim przypadku supra.local) prawym przyciskiem myszy, zmieniamy kontroler domeny na ad-2008-r2 i podobnie jak poprzednio wybieramy Wzorce operacji…. Tutaj na każdej karcie musimy kliknąć Zmień… i zatwierdzić.

Tym sposobem wszystkie role głównego kontrolera domeny zostały przeniesione. Teraz pora pozbyć się hosta z WS 2003. Przed samym wyłączeniem funkcji zmieniam jeszcze wpis w _mscds.supra.local i wpisuję tutaj IP nowego kontrolera domeny. Czasami po zdjęciu funkcji kontolera domeny ten wpis nie jest zmieniany.

Okej, usunięcie roli kontrolera domeny jest dosyć proste, bo trzeba uruchomić kreator poleceniem dcpromo.exe (dokładnie tak jak byśmy promowali serwer do roli kontrolera domeny), lecz w kreatorze będziemy pytani o inne rzeczy. W tym kreatorze padnie pytanie czy to ostatni kontroler domeny – pod żadnym pozorem nie zaznaczajcie tej opcji. Z tego, co pamiętam ona spowoduje usunięcie wszystkiego w DNSie związanego z całą domeną i nie wiem szczerze co to zrobi bazą LDAP (obstawiam, że ją usunie).

Pytanie czy usuwamy dane po kontrolerze AD. Jasne, że tak!

Następne pytanie w kreatorze to to, czy usunąć wpisy w DNS dotyczące tego serwera i tutaj warto zaznaczyć. Czasami i tak ten kreator tego nie zrobi i wtedy musimy usuwać wszystkie odwołania do starego kontrolera domeny, ale jeśli to się stanie to przynajmniej mamy mniej roboty. UWAGA: to czasami się wykrzacza i trzeba pousuwać wpisy ręcznie.

W sumie to by było na tyle. Po tym możemy rozpocząć proces usuwania roli kontrolera domeny.

I tym oto sposobem możemy usunąć z domeny starego Windowsa. Następnie zmieńmy poziom funkcjonalności domeny i lasu do Windowsa Server 2008 R2 (najwyższego, jaki jesteśmy w stanie osiągnąć aktualnie). Robimy to tak samo, jak poprzednio. Robimy to dlatego, bo nowsze wersje Windowsa Server wymagają DFSR do replikacji obiektów w domenie (gdzie w starszych wersjach odbywa się to za pomocą mechanizmu FSR).

Na samym początku sprawdźmy, czy stan naszej domeny jest poprawny. Robimy to odpalając z poziomu Wiersza poleceń z uprawnieniami administratora polecenie dcdiag /e /test:sysvolcheck /test:advertising.

W moim przypadku wszystko jest okej, więc przejdę dalej. Następnie musimy przejść przez 3-etapowy proces migracji z FSR do DFSR. To nie jest nic skomplikowanego, ale czasami to trochę trwa. Na samym początku zaczynamy poleceniem dfsrmig /setglobalstate 1. To ustawia status globalny DFSR na „prepared”. Po wykonaniu polecenia możemy sprawdzać status wykonania poleceniem dfsrmig /getmigrationstate. Poniżej efekty z tego, jak to wygląda gdy etap migracji nie został zakończony i gdy mamy już go za sobą.

Następnie uruchamiamy przejście na drugi etap migracji „redirected” poleceniem dfsrmig /setglobalstate 2. Gdy to się skończy, powtarzamy operację dla trzeciego etapu „eliminated”, oczywiście za pomocą polecenia dfsrmig /setglobalstate 3. Status migracji sprawdzamy tak samo jak w poprzednich etapach – poleceniem dfsrmig /getmigrationstate.

Gdy po ostatniej zmianie mamy informację, że wszystko jest okej, możemy przejść do przeniesienia funkcji na nowego hosta z Windowsem Server 2019, czyli ad-2019. Zmieniamy wzorce dokładnie tak samo jak z 2003 na 2008 R2: zmieniamy schemat domeny. Warto nie zapomnieć o tym, by przy każdej operacji wskazać ten nowy serwer. Taką operację możemy zrobić na dobrą sprawę z dowolnego kontrolera domeny. W moim przypadku zrzuty są z hosta ad-2019.

I teraz najlepsze – ten cały proces zmiany wzorców możemy zrobić one-linerem z poziomu konsoli Windows PowerShell:

Move-ADDirectoryServerOperationMasterRole -Identity ad-2019 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Warto sobie sprawdzić na sam koniec, czy wszystkie role się przeniosły. Robimy to poleceniem netdom query fsmo:

I to tyle. W ten sposób możemy pozbyć się kontrolera domeny na Windowsie Server 2008 R2 za pomocą kreatora uruchamianego poleceniem dcpromo.exe, usunąć serwer z domeny i możemy zapomnieć o problemie.