Upgrade Active Directory (Unsupported, but better…)

23 lutego 2015 at 14:33

Weźmy na tapetę temat wykonania upgrade’u Active Directory. Z jednej strony temat bardzo zawiły ze względu na możliwe powikłania, komplikacje i zależności. Z drugiej strony sprowadza się zasadniczo do wykonania dwóch poleceń. Jednakże te dwa polecenia w skrajnym wypadku mogą rozłożyć cały BackOffice Twojej organizacji, atesty na środowiskach testowych i akceptacyjnych i tak najczęściej nie dają jasnych odpowiedzi na wszystkie pytania. Czy jest więc jakiś bezpieczniejszy sposób wykonania upgrade’u Active Directory?

Oczywiście jest, ale o tym za chwilę :)

Przypomnijmy sobie po krótce jak teoretycznie wygląda proces upgrade’u Active Directory jeśli chcemy podnieść poziom funkcjonalności domeny powiedzmy z 2008 R2 do 2012 R2:

1. Rozszerzenie schematu Active Directory

2. Przygotowanie domen Active Directory

3. Upgrade’y/zastąpienie kontrolerów domen nowszymi systemami operacyjnymi

4. Podniesienie poziomów funkcjonalności domen

5. Podniesienie poziomów funkcjonalności lasów.

* Zakładamy, że mamy cale AD pod kontrolą Windows Server 2008R2 i przechodzimy na Windows Server 2012 R2

 

OK – wyodrębniliśmy kilka zasadniczych kroków – zastanówmy się teraz, która faza jest krytyczna i niesie ze sobą nieodwracalne (albo trudne do odwrócenia) skutki? Zasadniczo najbardziej krytyczne są punktu 1-2. Dlaczego? Ano dlatego, że rozpropagowanego w Active Directory schematu nie da się (w prosty sposób) przywrócić… Procedura przywrócenia sprowadza zasadniczo do odtworzenia całego lasu Active Directory – a to będzie bolało…

Każda kolejna faza jest dużo prostsza i szybsza w odtworzeniu i wycofaniu. Przykładowo punkt 3 – sprowadza się do otworzenia kontrolera domeny z backupu, bądź postawieniu go od nowa (a z racji redundancji inny kontroler domeny może w tym czasie obsługiwać zadania przywracanego kontrolera). Natomiast punkty 4 i 5 w wycofywaniu sprowadzają się zasadniczo do wykonania pojedynczych komend w Powershell’u – nic prostszego :)

Co więc możemy zrobić żeby zminimalizować ryzyko punktów 1-2? Od razu należy wspomnieć, że przedstawiana przeze mnie metoda (testowana w dużych środowiskach i działająca) nie jest oficjalnie wspierana przez Microsoft i wykonujesz ją na swoją odpowiedzialność!

Zaczynamy oczywiście od wykonania backupu kontrolera domeny (najlepiej kontrolera utrzymującego rolę wzorca schematu). Następnie staramy się wyizolować na tym wybranym kontrolerze wzorce ról potrzebne do wykonania rozszerzenia schematu i przygotowania domeny (zakładamy w uproszczeniu, że jest to las jedno-domenowy.), czyli wzorzec schematu oraz wzorzec infrastruktury:

 

Rys.1. Przeniesienie ról wzorca schematu i wzorca infrastruktury na inny kontroler domeny.

FSMO

Rys.2. Weryfikacja kontrolerów domeny pełniących role FSMO.

Po reorganizacji ról FSMO należy tenże kontroler „wyizolować” jednakże w sposób, który pozwoli aplikacjom na swobodne korzystanie z tego kontrolera domeny, więc wycięcie ruchu na firewallu bądź wyłączenie karty sieciowej odpada. Trzeba to zrobić sprytniej np tak:

Disable_replication

Rys.3. Wyłączenie replikacji dla izolowanego kontrolera domeny.

Na tym etapie nasz kontroler domeny jest wyizolowany w kontekście replikacji danych Active Directory ( a więc również zmian schematu ) natomiast jest w stanie przyjmować i obsługiwać standardowy ruch taki jak LDAP, Kerberos czy DNS. Przedstawienie czas zacząć :)

Wykonujemy rozszerzenie schematu Active Directory:

Extend_Forest_SchemaRys.4. Rozszerzenie schematu lasu Active Directory.

Przygotowujemy domenę:

Revision_Domain_UpdatePNG

Rys.5. Przygotowanie domeny Active Directory.

Testujemy, testujemy, testujemy… – Im więcej czasu poświecimy na testy, które mogą wykryć jakieś błędy aplikacji bądź ich niepoprawne funkcjonowanie – tym lepiej, bo trzeba mieć w pamięci, co się stanie, gdy błędy będą wykryte zbyt późno…

Żeby nie było, że procedura jest wykonywana „na niby” poniżej potwierdzenie różnych wersji schematu na kontrolerach domeny:

Different_Schema

Rys.6. Różne wersje schematu Active Directory na kontrolerach domen.

Jeśli rzetelnie wykonane testy potwierdziły poprawność działania aplikacji możemy rozpropagować zmiany na całe środowisko. Sprowadza się to zasadniczo do włączenia replikacji na wyizolowanym kontrolerze domeny ( w poleceniach „+” zastępujemy „-” ) oraz wymuszeniu replikacji ( repadmin /syncall ), która przez jakiś czas będzie kończyć się błędem wynikającym z różnicy w wersjach schematu na kontrolerach domeny – ten błąd ustąpi po kilkunastu/kilkudziesięciu minutach.

Teraz pozostaje już tylko wykonać upgrade’y systemów operacyjnych i podnieść poziomy funkcjonalności domeny i lasu Active Directory.

* w przypadku wielu domen procedurę należy rozbić na 2 cześć. W pierwszej obsługiwane jest rozszerzenie schematu Active Directory, natomiast w drugiej należy wyizolować kontroler domeny w każdej z domen i przeprowadzić procedurę przygotowania domeny.

DODATEK:

1.  Wersje schematów Active Directory:

Wersja schematu objectVersion
Windows Server 2000 13
Windows Server 2003 30
Windows Server 2003 R2 31
Windows Server 2008 44
Windows Server 2008 R2 47
Windows Server 2012 56
Windows Server 2012 R2 69

2. „Poprawki” domen:

„Poprawki” AD Revision
Windows Server 2008 3
Windows Server 2008 R2 5
Windows Server 2003 R2 8
Windows Server 2012 9
Windows Server 2012 R2 10