10 października zostanie zakończone wsparcie techniczne dla systemów Windows Server 2012 i Windows Server 2012 R2. Systemy zostały wydane odpowiednio 4 września 2012 i 18 października 2013, czyli minęła już dekada. Brak wsparcia oznacza brak aktualizacji, co może przełożyć się na bezpieczeństwo środowisk korzystających z tych systemów.
Zalecane jest przeprowadzenie aktualizacji do nowszej wersji, przy czym w przypadku serii 2012 najnowszą dostępną wersją jest wyłącznie 2019 (dodatkowo tylko dla 2012 R2). Szczegóły przedstawiono w tabeli na stronie learn.microsoft.com.
Aktualizację można wykonać poprzez zamontowanie dysku zawierającego rozpakowany plik ISO z nową wersją. Wystarczy uruchomić plik setup.exe (z poziomu zastępowanego systemu), który przeprowadzi przez cały proces. W celu zachowania danych i ustawień (in-place upgrade), ważne jest, aby zgadzały się wersje tzn. jeśli posiadamy system Windows Server 2012 Standard, to oczywiste jest, że nie możemy zaktualizować np. do wersji Server 2019 Datacenter. Ponadto zgodność powinna dotyczyć także wersji językowych. Aktualizacja musi też przebiegać stopniowo, tzn. najpierw aktualizujemy do wersji 2016, a następnie do docelowej 2019.
Jeśli natomiast nie zamierzamy zachowywać naszych ustawień, powyższe ograniczenia nas nie dotyczą. Dane zawsze można przywrócić z kopii zapasowych, jednak ewentualne trudności zaczynają się przy odtwarzaniu konfiguracji zainstalowanych uprzednio usług.
Microsoft oferuje również opcję rozszerzonego wsparcia przez trzy lata dla klientów, którzy z wybranych powodów nie mogą uaktualnić swojego środowiska. Koszt to 100% pełnej ceny licencji za każdy kolejny rok.
Zwykle opisując zakończenie wsparcia dla desktopowej wersji systemu Windows (np. Windows 8.1), jako alternatywę dla aktualizacji czy zakupu nowego sprzętu, podawaliśmy instalację dowolnej dystrybucji systemu Linux. Ta porada nie ma jednak większego uzasadnienia w przypadku systemów serwerowych Windows — często są one stosowane do celów, których osiągnięcie na Linuxie może być skomplikowane, a nawet niemożliwe. Świetny przykład to używany powszechnie w sieciach firmowych Active Directory i dostosowywanie konfiguracji klientów z poziomu jednego miejsca. Ciężko znaleźć rozwiązanie oferujące podobną elastyczność dla Linux.
Pewną zaletą systemów Windows Server jest dość duża spójność konfiguracji. Można powiedzieć, że jeśli przez dłuższy czas pracowaliśmy z systemem Windows Server 2012, to nie spotkamy trudności przy korzystaniu z bardziej współczesnych wersji. Wszelkie ustawienia są z reguły w tych samych miejscach.
Dodatek: Migracja kontrolera domeny z Windows Server 2012 R2 na Windows Server 2022
Zamiast przeprowadzania aktualizacji istniejącego kontrolera domeny możemy w stosunkowy szybki sposób zreplikować dane na nową maszynę i przenieść na nią role FSMO, aby została głównym kontrolerem. Co więcej, przedstawię kroki pozwalające na zachowanie adresu IP zastępowanego kontrolera oraz jego nazwy domenowej. Dzięki temu unikniemy konieczności zmian ustawień DNS na klientach czy konfiguracji innych usług zintegrowanych z Active Directory.
Bardzo ważne jest wykonanie kopii obecnego kontrolera działającego w pełni poprawnym stanie. Jeśli korzystamy z wirtualizacji, dobrze sprawdzi się migawka maszyny. Będzie to zabezpieczenie przed ewentualnym szkodliwym wpływem zmian, ponieważ migracje tak kluczowych usług są często po prostu ryzykowne.
Ustawiamy tymczasowy adres IP i adres serwera DNS na docelowym kontrolerze, aby wskazywał na aktualny adres zastępowanego. Zmieniamy też nazwę na tę odpowiadającą poprzedniemu kontrolerowi (w moim przypadku to dc). System będzie informował, że w sieci już istnieje host z taką nazwą, natomiast można zignorować ten komunikat.
Z poziomu Server Manager instalujemy rolę Active Directory Domain Services, natomiast należy wstrzymać się jeszcze z dołączaniem do domeny, ponieważ na poprzednim DC musimy zmienić nazwę, zaktualizować rekordy w DNS oraz zmodyfikować pewien wpis w ADSI Edit.
Nie ma innej możliwości zmiany nazwy kontrolera domeny niż tej z użyciem polecenia netdom. Na początek wykonujemy:
netdom COMPUTERNAME dc.avlab.local /ADD:dcold.avlab.local
netdom COMPUTERNAME dc.avlab.local /MAKEPRIMARY:dcold.avlab.local
Dodaliśmy więc drugą nazwę (dcold.avlab.local), następnie ustawiliśmy ją jako główną. Aby zmiana została zastosowana, musimy ponownie uruchomić system. Poleceniem hostname możemy potwierdzić zmianę nazwy, a netdom pozwoli na usunięcie poprzedniej:
netdom COMPUTERNAME dcold.avlab.local /REMOVE:dc.avlab.local
Ponownie uruchamiamy system i wykonujemy:
ipconfig /registerdns
Należy teraz poczekać przez pewien czas, ponieważ poprzednia nazwa w tle będzie sukcesywnie zastępowana w rekordach DNS przez nowo nadaną.
Teraz koniecznym krokiem jest modyfikacja wpisu msDS-AdditionalDnsHostName w ADSI Edit, ponieważ poprzednia nazwa została zachowana, przez co próba dołączenia nowego kontrolera do domeny zakończy się błędem. Wspomniany wpis znajdziemy w Default naming context w węźle widocznym na poniższym zrzucie ekranu. Z rozwijanego menu wybieramy pozycję Properties.
Usuwamy ponadto wpis dc z DNS Manager (Forward Lookup Zones -> domena) i restartujemy oba systemy (na docelowym potrzebujemy odświeżyć wpisy możliwego cache DNS).
Dołączamy nowy kontroler do domeny (jako nowy kontroler w istniejącej domenie — Add a domain controller to an existing domain). Proces jest standardowy i nie wymaga dodatkowych wyjaśnień. Warto zwrócić uwagę na krok o Additional Options, gdzie przy wyborze kontrolera do zreplikowania powinniśmy zobaczyć nową nazwę.
Do przeniesienia wszystkich ról FSMO wykorzystamy PowerShell. Polecenie netdom query fsmo zwróci nam, że aktualnie każda z ról jest obsługiwana przez zastępowany kontroler domeny. W celu ich migracji wystarczy wykonać:
Move-ADDirectoryServerOperationMasterRole -Identity dc -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster
Jak widać, wszystkie role zostały skutecznie przeniesione:
Przed odłączeniem starego kontrolera upewniamy się, że wszelkie konfiguracje i dane zostały poprawnie zreplikowane. Do weryfikacji można użyć poleceń repladmin czy dcdiag, ale też przejrzeć powiązane z AD przystawki MMC.
Aby usunąć stary kontroler domeny, musimy w pierwszej kolejności podjąć próbę usunięcia roli Active Directory Domain Services. Nie powiedzie się, ale dzięki temu zobaczymy opcję Demote this domain controller, której musimy użyć.
W przedstawionych krokach absolutnie nie możemy zobaczyć checkboxów dotyczących usuwania strefy DNS i „application partition”. W innym wypadku oznacza to, że niewłaściwie wykonaliśmy powyższe kroki. Polecam wtedy przywrócić kopię i próbować jeszcze raz.
Będziemy proszeni o wybranie nowego hasła dla konta Administrator. Jest to związane z tym, że podczas promowania serwera do roli kontrolera domeny wbudowane w Windows Server konto Administrator jest „zastępowane” kontem Administrator, ale domeny. Nie moglibyśmy się zwyczajnie zalogować po skończeniu operacji demote.
Serwer nie jest już kontrolerem, ale wciąż pozostaje w domenie. W celu pełnego usunięcia serwera z domeny wystarczy zmienić jako grupę roboczą (np. na domyślną WORKGROUP) oraz usunąć obiekt DCOLD z Computers w przystawce dsa.msc.
Na nowym kontrolerze z kolei ustawiamy adres IP poprzedniego serwera (wcześniej go wyłączamy). Możemy też w pełni potwierdzić, że w sieci pozostał nam jeden nowy domain controller poleceniem Get-ADDomainController w PowerShell.
Możemy też podnieść functional level do Windows Server 2016. Najprościej użyć przystawki Active Directory Domains and Trusts.
