Jak sprawić, by z terminala korzystało się wygodniej?

Ładny PowerShell w Windowsie i ładny zsh w Linuksie. O tak!

Wbrew pozorom nie trzeba wiele, by zacząć lubić korzystanie z shella. Kilka prostych czynności może sprawić, że możemy wykonywać zadania szybciej, bo często zamiast wyklikać parę okienek możemy wykonać 1 polecenie, które za wszystko załatwia sprawę, lecz decydujemy się na te okienka, bo w końcu już kiedyś to klikaliśmy, to może w trakcie się jakoś przypomni jak to się robiło…nie?

Zmiany, o których będę pisał niżej sprawią, że to, co widzimy w terminalu będzie też przyjaźniejsze dla oka. Niestety, czasami niektóre czynności czy dobór kolorów w tych oknach jest kiepski i to może sprawiać taki odpychający efekt od terminali. Niezależnie czy to jest Windows czy Linux.

Windows + PowerShell + oh-my-posh + PSReadLine = ❤

Tak, Windows też potrafi zaskoczyć obsługą terminala przez PowerShell. W sumie to piszę tego posta, bo właśnie zaskoczył mnie. Od lat korzystam z dobroci zsh i nie miałem okazji mieć takich pozytywnych wrażeń w Windowsie, aż do teraz.

Zacznijmy od Chocolatey – to jest darmowe otwarto-źródłowe narzędzie, które jest menedżerem pakietów dla Windowsa. Działa ono tak samo jak menedżery pakietów w Linuksie, a ich założenie jest proste, na przykład menedżer apt (występuje w Ubuntu, Debianie i pochodnych) instaluje pakiet poprzez polecenie apt install gparted (instaluje program GParted). W Chocolatey instaluje się programy tak samo, na przykład Notepad++ instaluje się poleceniem choco install notepadplusplus.

Instalacja jest prosta – wykonaj te polecenie w Windows PowerShell z uprawnieniami administratora:

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

I voilà – mamy zainstalowane Chocolatey. Zainstalujmy więc tego Notepada++ w ten sposób, co opisałem powyżej:

choco install notepadplusplus

Na dobrą sprawę to musiałem tylko kilka razy zatwierdzić i gotowe:

Sprawmy, by ten shell wyglądał trochę lepiej. Zainstalujemy do tego conemu i oh-my-posh, który jest odpowiednikiem oh-my-zsh z Linuksa wraz z najnowszą wersją Powershella:

choco install conemu oh-my-posh pwsh

Teraz możesz wykonać polecenie Set-Prompt i masz możliwość korzystania z oh-my-posh. Jeśli polecenie się nie wykonało, najprawdopodobniej nie masz zdefiniowanej polityki względem wykonywania skryptów powershellowych (Get-ExecutionPolicy daje wynik Undefined). Zmień tą politykę na Unrestricted poleceniem Set-ExecutionPolicy Unrestricted. Dzięki temu polityka zmieni się jedynie dla komputera z którego jest wykonywane te polecenie:

Get-ExecutionPolicy -List

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser       Undefined
 LocalMachine    Unrestricted

Moduł posh-git wymaga zainstalowanego gita, warto go zainstalować poleceniem choco install git:

C:\Users\Administrator> choco install git
Chocolatey v0.10.15
Installing the following packages:
git
By installing you accept licenses for the packages.
Progress: Downloading git.install 2.25.1... 100%
Progress: Downloading git 2.25.1... 100%

git.install v2.25.1 [Approved]
git.install package files install completed. Performing other installation steps.
The package git.install wants to run 'chocolateyInstall.ps1'.
Note: If you don't run this script, the installation will fail.
Note: To confirm automatically next time, use '-y' or consider:
choco feature enable -n allowGlobalConfirmation
Do you want to run the script?([Y]es/[A]ll - yes to all/[N]o/[P]rint): a

Using Git LFS
Installing 64-bit git.install...
git.install has been installed.
git.install installed to 'C:\Program Files\Git'
  git.install can be automatically uninstalled.
Environment Vars (like PATH) have changed. Close/reopen your shell to
 see the changes (or in powershell/cmd.exe just type `refreshenv`).
 The install of git.install was successful.
  Software installed to 'C:\Program Files\Git\'

git v2.25.1 [Approved]
git package files install completed. Performing other installation steps.
 The install of git was successful.
  Software install location not explicitly set, could be in package or
  default install location if installer.

Chocolatey installed 2/2 packages.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Teraz zaimportujmy sobie polecenia z tych modułów, które zainstalowaliśmy i odpalmy w końcu nasz nowy shell:

oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\agnosterplus.omp.json" | Invoke-Expression

W efekcie dostajemy to:

Trochę to odbiega od tego, co widać na moim początkowym zrzucie ekranu, więc popracujemy nad tym, by wyglądem się to nie różniło. Na początku musimy zainstalować czcionki Nerd Font. Znajdziemy je w tym ogromnym repozytorium czcionek. Czcionki Nerd Font różnią się od swoich oryginalnych odpowiedników tym, że mają dodanych kilka znaków, które sprawiają, że ten schemat (nazywający się Agnoster) wygląda lepiej. Ja osobiście bardzo lubię czcionkę Ubuntu Mono w terminalu i z niej też skorzystam. Jeśli podoba Ci się wygląd terminala jak w screenshocie nagłówkowym, zrób to samo co ja (opisałem poniżej):

Wejdź na tą podstronę repozytorium, otwórz folder Regular, następnie complete, i pobierz czcionkę Ubuntu Mono Nerd Font Complete Windows Compatible.ttf. Powtórz to dla folderów Regular-Italic, Bold i Bold-Italic. Jak pobierzesz wszystkie, zaznacz czcionki, kliknij na jedną PPM i wybierz Zainstaluj dla wszystkich użytkowników.

Update 2024: te czcionki można zainstalować za pomocą:

choco install nerd-fonts-Ubuntu nerd-fonts-UbuntuMono

Następnie w oknie Windows PowerShell klikamy na pole tytułowe PPM i Właściwości. W zakładce Czcionka wybieramy naszą nową czcionkę i rozmiar. W moim przypadku to jest UbuntuMono NF z rozmiarem 16.

W ten sposób shell już wygląda lepiej:

Nadal, on może wyglądać lepiej. Zmienimy nieco kolorystykę tego okna, bo jednak ten niebieski trochę razi w oczy. Jeden z najpopularniejszych tematów znalazłem tutaj, w tym repozytorium. My skorzystamy z tematu Solarized-Dark. Instalacja jest prosta: na samym początku klonujemy repozytorium (przed pójściem dalej zrestartowałem terminal, bo nie miał świadomości tego, że ja już zainstalowałem gita):

git clone https://github.com/neilpa/cmd-colors-solarized
cd cmd-colors-solarized
reg.exe import .\solarized-dark.reg
.\Update-Link.cmd "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Windows PowerShell\Windows PowerShell.lnk"
.\Update-Link.cmd "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Windows PowerShell\Windows PowerShell (x86).lnk"

Okej, teraz otwórz PowerShella jeszcze raz. Voilà, kolory zmienione! Ale nie ma tego nowego wyglądu shella, dlaczego? Dlatego, bo nie zdefiniowaliśmy go w profilu shella. Profil shella to nic innego jak prosty skrypt, który wykonuje się, gdy otwieramy terminal. Zanim zapiszemy sobie do niego to, co potrzebujemy to chciałem pokazać jeszcze jedną rzecz, która moim zdaniem jest niezbędna.

W terminalu niesamowicie istotną rzeczą jest autouzupełnianie składni polecenia. Robi się to naciskając tabulator (przycisk Tab). Naciśnięcie powoduje autouzupełnienie polecenia jeśli, następne naciśnięcia zmienią nasze polecenie na następną opcję, np. jeśli jest polecenie Restart- i my wciśniemy tabulator to za pierwszym razem otrzymamy pierwszą propozycję uzupełnionego polecenia, za drugiem drugą opcję (jeśli istnieje) i tak dalej. Problem w tym, że w jednym czasie widzisz tylko 1 polecenie, bo to jest domyślne ustawienie w PowerShella. Wygodniej by było widzieć opcje i nawet sterować strzałkami, by wybrać interesujące dla nas rozwiązanie. Mało tego, jeszcze lepiej będzie jeśli od razu przy tym wszystkim będziemy mieli drobną podpowiedź jakie np. parametry są dostępne w danym poleceniu czy też jakie wartości oczekują dane parametry. Naszym remedium jest te polecenie:

Set-PSReadlineKeyHandler -Key Tab -Function MenuComplete

Dzięki niemu propozycje autouzupełnienia polecenia widzimy tak:

Okej, jak już mamy takie fajne ustawienia to zapiszmy sobie je tak, by wyświetlały się na stałe, co?

Okej, by otworzyć edycję profilu, z którego korzystamy w PowerShellu wykonaj polecenie:

if (!(Test-Path -Path $PROFILE )) { New-Item -Type File -Path $PROFILE -Force } .$env:SystemRoot/System32/notepad.exe $PROFILE

Wklejmy do niego to, co nas interesuje:

Dzięki temu teraz już od razu uruchamia się nam ten nowy wygląd shella:

Zmienialiśmy czcionki w oknie PowerShella, ale powinniśmy je też zmienić w Wierszu polecenia. Klikamy prawym na tytuł okna, następnie Właściwości.

Następnie podobnie jak poprzednio w zakładce Czcionka zmieniamy czcionkę na tą, którą wybraliśmy z serii Nerd Font (w moim przypadku to UbuntuMono NF) i dajemy okej. W ten sposób możemy się cieszyć ładnym wyglądem terminala w Windowsie. Te zmiany dotyczą głównie wyglądu, ale myślę, że najważniejszym przy nauce jakiegokolwiek terminala jest nauka obsługi skrótów klawiaturowych. To one sprawiają, że piszemy w nim coraz szybciej dzięki czemu nasza efektywność rośnie.

Na koniec zostawię Wam w postaci zajawki ciekawy wykład na temat szybkiej obsługi PowerShella z użyciem PSReadLine, naprawdę mi się bardzo podobał:

Linux + zsh + oh-my-zsh = ❤

Co prawda mowa tutaj o Linuksie, ale nie każdego Linuksa obsługuje się z poziomu Linuksa – w końcu serwery często nie mają zainstalowanego interfejsu graficznego i obsługuje się je poprzez SSH (secure shell). Tam też warto sprawić, by pracowało nam się z nim wygodnie.

Domyślnym interpreterem poleceń w Linuksie w dzisiejszych czasach jest Bash (/bin/bash), a w tych starszych lub w okrojonych dystrybucjach sh (/bin/sh). Mają one pewne możliwości, ale też ograniczenia konfiguracyjne, przez co na codzień korzystam z zsh (/bin/zsh). Nie jest on w standardzie w systemach (przynajmniej nie spotkałem się z dystrybucją mającą ją jako domyślny shell, choć jest on dostępny w MacOS (na ten moment korzystałem tylko z 10.15 i tam był). Pokażę tutaj jak zainstalować zsh oraz w jaki sposób można z niego zrobić fajny użytek.

UWAGA: instrukcje poniżej są ogólne dla wszystkich dystrybucji Linuksa, ale są polecenia, które są specyficzne dla dystrybucji (np. w Debianie/Ubuntu menedżerem pakietów jest apt/apt-get, w Arch Linuksie jest pacman, w Red Hat/CentOS/Fedora yum/dnf, a w Gentoo…w sumie to, co chcesz, ale przeważnie Portage (polecenie emerge). Weź pod uwagę też to, że nazwy pakietów w repozytoriach mogą się różnić.

Zaczynamy od instalacji gita, zsh i podkreślania składni zsh

sudo apt install git zsh zsh-syntax-highlighting -y

Okej, teraz odpalmy one-liner, którym zainstalujemy zsh:

sh -c "$(wget -O- https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Następnie musimy zatwierdzić zmianę shella na zsh i jesteśmy w domu.

--2020-03-15 11:47:42--  https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh
Translacja raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.0.133, 151.101.192.133, 151.101.128.133, ...
Łączenie się z raw.githubusercontent.com (raw.githubusercontent.com)|151.101.0.133|:443... połączono.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 200 OK
Długość: 8445 (8,2K) [text/plain]
Zapis do: `STDOUT'

-                   100%[===================>]   8,25K  --.-KB/s    w 0s       

2020-03-15 11:47:42 (215 MB/s) - zapisano na standardowe wyjście [8445/8445]

Cloning Oh My Zsh...
Cloning into '/home/supra/.oh-my-zsh'...
remote: Enumerating objects: 1137, done.
remote: Counting objects: 100% (1137/1137), done.
remote: Compressing objects: 100% (1102/1102), done.
remote: Total 1137 (delta 22), reused 926 (delta 17), pack-reused 0
Receiving objects: 100% (1137/1137), 750.06 KiB | 2.13 MiB/s, done.
Resolving deltas: 100% (22/22), done.

Looking for an existing zsh config...
Using the Oh My Zsh template file and adding it to ~/.zshrc.

Time to change your default shell to zsh:
Do you want to change your default shell to zsh? [Y/n] y
Changing the shell...
Hasło: 
Shell successfully changed to '/usr/bin/zsh'.

         __                                     __
  ____  / /_     ____ ___  __  __   ____  _____/ /_
 / __ \/ __ \   / __ `__ \/ / / /  /_  / / ___/ __ \
/ /_/ / / / /  / / / / / / /_/ /    / /_(__  ) / / /
\____/_/ /_/  /_/ /_/ /_/\__, /    /___/____/_/ /_/
                        /____/                       ....is now installed!


Please look over the ~/.zshrc file to select plugins, themes, and options.

p.s. Follow us on https://twitter.com/ohmyzsh

p.p.s. Get stickers, shirts, and coffee mugs at https://shop.planetargon.com/collections/oh-my-zsh

➜  ~ 

Tak czy siak ten shell jeszcze wymaga drobnych poprawek (przynajmniej w moim przekonaniu). Dodałbym lub zmieniłbym następujące linijki:

export TERM=xterm-256color

Dzięki temu możemy wykorzystywać więcej kolorów (256 zamiast 8), gdy korzystamy z SSH. Naprawdę bardzo przydatne, przynajmniej ja dzięki temu mam ładnego Vima, a o tym później. Tej linijki nie ma, musimy ją dodać.

ZSH_THEME="agnoster"

W tym polu definiujemy styl terminala, czyli jak on wygląda. Możemy korzystać z motywów, które są w oh-my-zsh, możemy ściągać niestandardowe, a możemy też tworzyć własne.

Niżej mamy też sekcję pluginów, w której możemy po prostu wzbogacić nasz shell o dodatkowe polecenia (ja dodałem polecenia do systemd, ufw i dockera, bo od pewnego czasu z niego korzystam):

plugins={
   git
   systemd
   ufw
   docker-compose
   docker-machine
   docker
)

Następnie dodajmy syntax highlighting do naszego shella, które zainstalowałem wcześniej:

source /usr/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

Dzięki temu shell zmienia kolor poleceń na czerwono, gdy są nieprawidłowe i usuwa podkreślenia ze ścieżek, gdy są nieprawidłowe:

Ponadto dodałbym to:

blk=$'\x1b[90m' # Sets text to black
red=$'\x1b[31m' # Sets text to red
grn=$'\x1b[92m' # Sets text to green
ylw=$'\x1b[93m' # Sets text to yellow
blu=$'\x1b[94m' # Sets text to blue
pur=$'\x1b[95m' # Sets text to purple
cyn=$'\x1b[96m' # Sets text to cyan
wht=$'\x1b[97m' # Sets text to white
rst=$'\x1b[0m'  # resets to default terminal color
bindkey "\033[1~" beginning-of-line
bindkey "\033[4~" end-of-line
export EDITOR="/usr/bin/vim"

Te polecenia ustawiają kolor shella w terminalu graficznym (czyli pracując w trybie bez interfejsu graficznego bezpośrednio na maszynie), poza tym te polecenia bindkey są fixem na niedziałające przyciski Home/End w niektórych środowiskach. Na koniec dodałem zmienną EDITOR i wartością jest ścieżka do Vima, bo to jest edytor tekstu, z którego korzystam najczęściej. Poza tym możemy też ustawić na koncie root wykorzystywanie zsh wykonując polecenia:

sudo chsh -s /bin/zsh root
sudo cp ~/.zshrc /etc/zsh/zshrc

Poprawa wyglądu terminala w interfejsie graficznym Linuksa

W efekcie końcowym nasz shell wygląda tak:

Niezbyt fajnie. By to poprawić musimy tak samo jak w Windowsie zainstalować odpowiednie czcionki. Możemy posłużyć się czcionkami, które też tam wykorzystaliśmy, czyli z repozytorium Nerd Font. Tak samo jak poprzednio posłużę się czcionkami dla Ubuntu Mono:

#!/bin/bash
mkdir -p ~/.local/share/fonts
wget https://github.com/ryanoasis/nerd-fonts/raw/master/patched-fonts/UbuntuMono/Regular/complete/Ubuntu%20Mono%20Nerd%20Font%20Complete.ttf -P ~/.local/share/fonts/
wget https://github.com/ryanoasis/nerd-fonts/raw/master/patched-fonts/UbuntuMono/Regular-Italic/complete/Ubuntu%20Mono%20Italic%20Nerd%20Font%20Complete.ttf -P ~/.local/share/fonts/
wget https://github.com/ryanoasis/nerd-fonts/raw/master/patched-fonts/UbuntuMono/Bold/complete/Ubuntu%20Mono%20Bold%20Nerd%20Font%20Complete.ttf -P ~/.local/share/fonts/
wget https://github.com/ryanoasis/nerd-fonts/raw/master/patched-fonts/UbuntuMono/Bold-Italic/complete/Ubuntu%20Mono%20Bold%20Italic%20Nerd%20Font%20Complete.ttf -P ~/.local/share/fonts/
fc-cache -f -v

Sprawdźmy, czy czcionki się pojawiły w naszym systemie dzięki poleceniu fc-list | grep "Nerd":

/home/supra/.local/share/fonts/Ubuntu Mono Bold Italic Nerd Font Complete.ttf: UbuntuMono Nerd Font:style=Bold Italic
/home/supra/.local/share/fonts/Ubuntu Mono Bold Nerd Font Complete.ttf: UbuntuMono Nerd Font:style=Bold
/home/supra/.local/share/fonts/Ubuntu Mono Nerd Font Complete.ttf: UbuntuMono Nerd Font:style=Regular
/home/supra/.local/share/fonts/Ubuntu Mono Italic Nerd Font Complete.ttf.1: UbuntuMono Nerd Font:style=Italic
/home/supra/.local/share/fonts/Ubuntu Mono Bold Italic Nerd Font Complete.ttf.1: UbuntuMono Nerd Font:style=Bold Italic
/home/supra/.local/share/fonts/Ubuntu Mono Italic Nerd Font Complete.ttf: UbuntuMono Nerd Font:style=Italic
/home/supra/.local/share/fonts/Ubuntu Mono Nerd Font Complete.ttf.1: UbuntuMono Nerd Font:style=Regular

Jak widać jest wszystko okej, dlatego zmieńmy sobie czcionkę na nową w taki sposób, jak przedstawiłem na animacji:

Pozostają jedynie te kiepskie kolory. Te możemy zmienić za pomocą gotowych plików, które możemy znaleźć na tym blogu. Z faktu, że w różnych środowiskach graficznych są różne programy pełniące rolę emulatora terminala (w moim ulubionym Xfce4 jest to xfce4-terminal), metoda na zmianę jest inna i pokażę jak to się robi w Xfce. Skorzystamy z tematu Solarized Dark, jak w przykładzie z PowerShellem.

#!/bin/bash
git clone https://github.com/sgerrand/xfce4-terminal-colors-solarized.git
mkdir ~/.config/Terminal
cp xfce4-terminal-colors-solarized/dark/terminalrc ~/.config/Terminal/

Następnie musimy w ustawieniach wybrać ten motyw i to tyle. Ja dodatkowo zmieniam sobie kolor zielonego na trochę bardziej przypominający zielony, bo tak po prostu lubię.

Poprawa wyglądu terminala w konsoli tekstowej Linuksa

Zsh działa per konto użytkownika, co oznacza, że będzie nam działać niezależnie czy połączymy się przez emulator terminala, fizyczny terminal czy SSH, lecz z drugiej strony my w motywie wykorzystujemy czcionki z niestandardowymi znakami, dlatego też pokażę Wam jak skorzystać z tych czcionek w terminalu i jak sprawić, by działały one z automatu.

Na początku musimy pobrać czcionki, które nas interesują. Ja korzystam z pogrubionych czcionek Terminus, bo po prostu takie mi się podobają. Możemy je też znaleźć w repozytorium Powerline. Warto zaznaczyć, że te czcionki muszą być w formacie .psf, a nie .ttf. Możemy pobrać i umieścić wszystkie czcionki za pomocą jednego prostego skryptu:

#!/bin/bash
sudo wget https://github.com/powerline/fonts/raw/master/Terminus/PSF/ter-powerline-v{12n,14b,14n,14v,16b,16n,16v,18b,18n,20b,20n,22b,22n,24b,24n,28b,28n,32b,32n}.psf.gz -P /usr/share/consolefonts/

Teraz musimy wybrać czcionkę, która nam się podoba bardziej. Nic bardziej prostego, robimy to poleceniem setfont /usr/share/consolefonts/<nazwa-pliku>, na przykład:

setfont /usr/share/consolefonts/ter-powerlinev16b.psf.gz

W ten sposób pojawi nam się nowa czcionka (przy okazji tutaj pokazuję jak można łatwo uzupełniać opcję tabulatorem w terminalu, gdy ma się zsh):

Na samym końcu sprawimy, że taka czcionka będzie na każdym terminalu w naszym komputerze i to będzie się działo automatycznie po restartach. Musimy edytować plik /etc/default/console-setup, zmieniamy tutaj wartości pól CODESET, FONTFACE i FONTSIZE. Ogólnie pliki czcionek są wczytywane w składni pliku <CODESET>-<FONTFACE><FONTSIZE>.psf.gz, dlatego też w <FONTFACE> na końcu lub w <FONTSIZE> na początku trzeba dopisać myślnik. Poniżej uzupełniłem plik względem pliku czcionki, który wykorzystywałem powyżej.

# CONFIGURATION FILE FOR SETUPCON

# Consult the console-setup(5) manual page.

ACTIVE_CONSOLES="/dev/tty[1-6]"

CHARMAP="UTF-8"

CODESET="ter"
FONTFACE="powerline-"
FONTSIZE="v16b"

VIDEOMODE=

# The following is an example how to use a braille font
# FONT='lat9w-08.psf.gz brl-8x8.psf'

Po zmienieniu tego pliku można sprawdzić efekt wykonując polecenie setupcon. Jeśli czcionka się zmieniła poprawnie to po restarcie też się zmieni. Tutaj też chciałbym podziękować Tenebreosowi za znalezienie ominięcia problemu w poleceniu setupcon w nazwach plików, naprawdę to się przydało!

Poprawa wyglądu terminala w SSH

Na koniec część dla tych, którzy administrują serwerami Linuksa zdalnie, przez SSH. Pewnie większość z Was korzysta z PuTTY. Ja akurat korzystam z trochę bardziej wypasionej wersji, która nazywa się KiTTY i można ją pobrać tutaj.

Zaczniemy od zmiany kolorów terminala. Docelowo ma wyglądać jak te wszystkie poprzednie oraz będzie korzystał z tej samej czcionki (Ubuntu Font NF), co w sekcji z ustawianiem czcionek dla PowerShella. Zamiast wyklikiwać w opcjach wszystkie kolory, możemy zastosować ten jeden pliczek, który za nas zrobi całą robotę, poniżej zawartość:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\9bis.com\KiTTY\Sessions\Default%20Settings]
"Colour0"="131,148,150"
"Colour1"="147,148,161"
"Colour2"="0,43,54"
"Colour3"="7,54,66"
"Colour4"="0,43,54"
"Colour5"="238,232,213"
"Colour6"="7,54,66"
"Colour7"="0,43,56"
"Colour8"="220,50,47"
"Colour9"="203,75,22"
"Colour10"="0,187,0"
"Colour11"="88,255,117"
"Colour12"="181,137,0"
"Colour13"="101,123,131"
"Colour14"="38,139,210"
"Colour15"="131,148,150"
"Colour16"="211,54,130"
"Colour17"="108,113,196"
"Colour18"="42,161,152"
"Colour19"="147,161,161"
"Colour20"="238,232,213"
"Colour21"="253,246,227"
"Colour22"="187,187,187"
"Colour23"="0,0,0"
"Colour24"="0,0,0"
"Colour25"="187,0,0"
"Colour26"="0,187,0"
"Colour27"="187,187,0"
"Colour28"="0,0,187"
"Colour29"="187,0,187"
"Colour30"="0,187,187"
"Colour31"="187,187,187"
"Colour32"="0,0,0"
"Colour33"="187,187,187"

Poza tym warto zmienić w profilu domyślnym czcionkę, więc otwierając ustawienia w sekcji Window > Appearance, w sekcji Font settings klikamy przycisk Change… i wybieramy czcionkę, którą chcemy ustawić. Na zrzucie poniżej macie jak to wygląda u mnie:

Następnie musimy taką zmianę zapisać, najlepiej to zrobić w domyślny profilu (Sekcja Session), klikamy nazwę sesji i przycisk Save:

Gotowe. W ten sposób mamy shell przygotowany do pracy:

Podstawowa organizacja drzewa Active Directory i instalowanie oprogramowania z użyciem polityk GPO

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:

Przypisanie obiektu zasad grupy do konkretnego OU

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.

Udostępnianie folderu jako zasób sieciowy, w tym przypadku UNC to \\ad-2019.domena.local\gpo

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.

Tutaj widzimy wspomniane zielone obramowanie.

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.

Wyłączanie konfiguracji „zwiększonych zabezpieczeń” programu Internet Explorer

Odpalasz Windowsa Server i skorzystać z najlepszej przeglądarki internetowej w historii informatyki (Internet Explorer) w jedynym słusznym celu (pobranie instalatora do innej, ludzkiej przeglądarki), wpisujesz w Google „firefox„, wchodzisz w pierwszy link. Klikasz jakiś przycisk do pobrania I WIDZISZ TO. Też jesteś wściekły, jak ja? Teoretycznie możesz dodać każdą stronę do zaufanych, ale jest na to lepsze rozwiązanie.

Tym rozwiązaniem jest wyłączenie „zwiększonych zabezpieczeń” programu Internet Explorer. Mówisz, jak? To jest proste, pokażę niżej jak to zrobić w różnych Windowsach Server, począwszy od najnowszych do najstarszych:

Wyłączanie konfiguracji zwiększonych zabezpieczeń programu Internet Explorer w Windows Server 2019/2016

Windows Server 2019/2016/2012 (R2)

Tutaj trzeba się posłużyć Mendżerem serwera (Server Manager). Otwierasz go, przechodzisz w zakładkę Serwer lokalny, następnie po prawej jest ustawienie o nazwie Konfiguracja zwiększonych zabezpieczeń programu Internet Explorer i przy nim stan Włączone. To jest źródło Twojego problemu. Klikasz na ten stan, następnie zaznaczasz przy sekcji Administratorzy opcję Wyłącz. Gotowe.

Identycznie to wygląda w Windows Server 2012 R2:

Wyłączanie konfiguracji zwiększonych zabezpieczeń programu Internet Explorer w Windows Server 2012 (R2)

Windows Server 2008 (R2)

Tutaj też korzystamy z Menedżera serwera, lecz w starszej wersji, więc interfejs wygląda nieco inaczej. Klikamy główny element drzewka (w moim przypadku Menedżer serwera (AD-2008-R2)), następnie po prawej stronie znajdujemy Konfiguruj zwiększone zabezpieczenia programu Internet Explorer. Wyłączamy w taki sam sposób.

Wyłączanie konfiguracji zwiększonych zabezpieczeń programu Internet Explorer w Windows Server 2008 (R2)

Windows Server 2003 (R2)

Zostały nam jeszcze te staruszki. W tym Windowsie te okno do zarządzania nazywa się Zarządzanie tym serwerem. Otwieramy je, następnie szukamy pola Konfiguracja zwiększonych zabezpieczeń programu Interne…żartowałem. Ta opcja nie zadziała.

Wyłączanie konfiguracji zwiększonych zabezpieczeń programu Internet Explorer w Windows Server 2003 (R2)…nie, to nie tu.

Jeśli chcesz to naprawdę wyłączyć, musisz otworzyć panel Dodaj lub usuń programy. Serio.

Następnie wybierz po lewej Dodaj/Usuń składniki systemu Windows, wybierz z listy konfiguracja zwiększonych zabezpieczeń programu Internet Explorer, klikasz Dalej i gotowe. Więc tak wyłączasz te „zabezpieczenia” – usuwając je.

Niezłe usuwanie „zabezpieczeń” Internet Explorer.

Migracja domeny Active Directory z Windows Server 2003 na 2019 w obrębie jednej domeny

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:

Bez adprep /forestprep nie zajdziemy za daleko…

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

To się dzieje jeśli wcześniej nie podniesiemy poziomu funkcjonalności lasu i domeny do Windowsa Server 2003.
  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).
Zaś jeśli nam pyknie przygotowanie domeny to taki mniej więcej dostaniemy wynik.

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).

Tutaj wykonałem polecenie adprep32.exe /domainprep /gpprep, a potem adprep.exe /rodcprep i ten /domainprep było tutaj totalnie niepotrzebne.

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).

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.

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).

Podnoszenie poziomu funkcjonalności domeny do Windowsa Server 2008 R2
Podnoszenie poziomu funkcjonalności lasu do Windowsa Server 2008 R2

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.

Zmiana wzorca schematu z Windows Server 2008 R2 (ad-2008-r2) do 2019 (ad-2019).
To ta zmiana kontrolera, którą musimy wykonać za każdym razem przed wykonaniem operacji zmiany wzorca. Zabrakło tutaj zrzutu ekranu ze zmianą wzorca nazw domen. Realizujemy ją właśnie tutaj.
Tutaj akurat zmieniany jest wzorzec menedżera puli RID.
A tutaj rola podstawowego kontrolera domeny.
Tutaj jest zmieniany wzorzec infrastruktury.

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


Move Operation Master Role
Do you want to move role 'SchemaMaster' to server 'ad-2019.supra.local' ?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

Move Operation Master Role
Do you want to move role 'DomainNamingMaster' to server 'ad-2019.supra.local' ?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

Move Operation Master Role
Do you want to move role 'PDCEmulator' to server 'ad-2019.supra.local' ?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

Move Operation Master Role
Do you want to move role 'RIDMaster' to server 'ad-2019.supra.local ?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

Move Operation Master Role
Do you want to move role 'InfrastructureMaster' to server 'ad-2019.supra.local' ?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

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

PS C:\Users\Administrator> netdom query fsmo
Schema master               ad-2019.supra.local
Domain naming master        ad-2019.supra.local
PDC                         ad-2019.supra.local
RID pool manager            ad-2019.supra.local
Infrastructure master       ad-2019.supra.local
The command completed successfully.

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.

Migracja DHCP z Windows Server 2008 R2 na Windows Server 2019

Spotkałem się z firmami, w którymi niestety (moim zdaniem niestety) jest wdrożone DHCP na Windowsie Server? Czemu niestety? Może jeszcze nie jestem takim kozakiem w kwestii security, ale jakoś tak czuję, że DHCP to jest coś, czym powinien zajmować router w mniejszych firmach lub UTM jeśli firmę na takiego stać.

Tak czy siak, jeśli firma nie decyduje się na przeniesienie serwera DHCP na UTMa, a mają system bez wsparcia lub po prostu chcą się przenieść na nowy system, muszą się spotkać z tym niesamowicie trudnym wyzwaniem. Pewnie nawet nie zdajecie sobie z tego sprawy jak to jest bardzo trudne.

W moim przykładzie serwer DHCP jest na Windowsie Server 2008 R2, Windows Server 2019 będzie jego nowym domem. Na przykładzie stary host to dhcp.domena-sbs.local, a docelowa maszyna to ad-2019.domena-sbs.local.

DHCP na Windowsie Server 2008 R2

Poniżej lista kroków, którą należy wykonać, by mieć ten proces za sobą:

  1. Zainstaluj usługę serwera DHCP na Windowsie Server 2019.
  2. Podłącz ten nowy serwer do domeny Active Directory.
  3. Stwórz folder export i export-backup w głównym katalogu partycji C:.
  4. Otwórz na WS 2019 konsolę Windows PowerShell z uprawnieniami administratora i wykonaj polecenia:
Export-DhcpServer -File C:\export\DHCPdata.xml -Leases -Force -ComputerName dhcp –Verbose
Import-DhcpServer -File C:\export\DHCPdata.xml -BackupPath C:\export-backup\ -Leases -ScopeOverwrite -Force -ComputerName ad-2019 –Verbose

I to tyle. Dla wyjaśnienia – pierwsze polecenie eksportuje konfigurację do pliku XML ze starego serwera DHCP, a drugie polecenie importuje je do nowego serwera.

Przeniesiona konfiguracja na Windowsie Server 2019

Było trudne, nie?

Migracja domeny Active Directory z Windows SBS 2008 na Windows Server 2019

Zrobiłem wirtualkę z 40 GB przestrzeni dyskowej. Jak bardzo byłem w błędzie myśląc, że to wystarczy…

Domyślam się, że część z Was z takim problemem do czynienia miała lub mieć może do czynienia. Kiepska sprawa, bo SBSy w prawdzie działają wolniej niż zwykłe Windowsy Server 2008 dlatego, bo mają na sobie WSUSa, Exchange’a i wiele innych usług, o których administratorzy nie mają pojęcia, że w ogóle istnieją.

Tak czy siak najczęściej o istnieniu AD wiedzą i dzisiaj pokażę jak krok po kroku przenieść domenę z takiego kontrolera na zwykłego Windowsa Server. Aktualnie najnowszym jest Windows Server 2019, więc na taki przeniesiemy domenę.

Specyfikacja środowiska

Na początku dla jasności przedstawię środowisko i adresacje, które wykorzystałem w przykładzie:

Maszyna z WS SBS 2008:

  • Adres IP: 192.168.162.20/24
  • Brama domyślna: 192.168.162.2
  • DNS: 127.0.0.1 (w końcu kontroler domeny realizuje też funkcję DNSa)
  • Nazwa hosta: supra-ad (potem wykorzystywałem zrzuty z instalacji na której była nazwa it.supra.tf)
  • Nazwa domeny: domena-sbs.local

Maszyna docelowa z WS 2019 Standard:

  • Adres IP: 192.168.162.12/24
  • Brama domyślna: 192.168.162.2
  • DNS: 162.168.162.20 (it.supra.tf.domena-sbs.local)
  • Nazwa hosta: ad-2019

Zakładam, że obie maszyny mają statyczne skonfigurowane adresacje sieciowe.

Przygotowanie do przeniesienia

Jeśli będziecie próbowali podnieść serwer do roli kontrolera domeny bez jakichkolwiek zmian, spotkacie się z tym błędem.

Na początku garść teorii – Windows SBS 2008 posiada domyślnie poziom funkcjonalności domeny i lasu na poziomie Windowsa Server 2003. Ponadto korzysta on z systemu FRS (File Replication Services) do replikacji danych pomiędzy kontrolerami domeny. Windows Server 2016 i 2019 już nie wspierają tego systemu i jedyną opcją na postawienie kontrolera domeny na nich jest zmiana tego systemu na DFRS (Distributed File System Replication). Jest to generalnie dosyć łatwy proces, ale czasami może trochę potrwać.

A to jest drugi problem z którym można się spotkać jeśli już się podniesie poziom domeny i lasu na Windows Server 2008.

Aby podnieść poziom domeny i lasu do Windows Server 2008 należy wejść do narzędzia Użytkownicy i komputery usługi Active Directory, następnie kliknąć na początek drzewka z nazwą naszej domeny PPM i wybrać Podnieś poziom funkcjonalności domeny…, wybrać z listy Windows Server 2008 i zatwierdzić.

Następnie trzeba przejść do drugiego narzędzia Domeny i relacje zaufania usługi Active Directory, tutaj zmieniamy poziom lasu tak samo jak domeny – klikając na początek drzewka PPM i wybierając Podnieś poziom funkcjonalności domeny… i tak samo wybierając poziom na Windows Server 2008.

Następnie musimy zmienić system replikacji danych pomiędzy kontrolerami na DFSR. To jest dosyć proste. Na początku warto sprawdzić czy nasz kontroler działa poprawnie (za pomocą polecenia dcdiag /e /test:sysvolcheck /test:advertising):

Jeśli wszystko jest tak jak na moim zrzucie ekranu poprawnie, możemy włączyć pierwszy stan migracji „Prepared”: dfsrmig /setglobalstate 1

Następnie musimy poczekać. Nie ma żadnego paska postępu, jedyne co możemy zrobić to sprawdzić to, czy udało się zastosować zmianę poleceniem dfsrmig /getmigrationstate.

Jeśli macie taki wynik – to oznacza, że musicie jeszcze trochę poczekać!
Jeśli przejdzie, dostaniecie mniej więcej taki komunikat.

Gdy przejście na pierwszy stan się zakończy, musimy przejść na drugi za pomocą polecenia dfsrmig /setglobalstate 2, a po przejściu na drugi musimy przejść na trzeci stan za pomocą dfsrmig /setglobalstate 3.

Podniesienie nowego kontrolera domeny…

Gdy to mamy za sobą, możemy podłączyć nowy serwer do domeny i zająć się jego podniesieniem do kontrolera domeny. Na początku należy ustawić odpowiednią nazwę hosta, adresację i zainstalować rolę serwera Usługi domenowe Active Directory poprzez Menedżer serwera. Gdy to mamy za sobą, należy wybrać w Menedżerze serwera Promuj ten serwer do roli kontrolera domeny. Po tym pojawi się okno w którym wybieramy naszego użytkownika administracyjnego, wybieramy opcję wdrażania Dodaj kontroler domeny do istniejącej domeny i lecimy Dalej.

Następnie podajemy hasło do przywracania usług katalogowych DSRM, lecimy Dalej.


Tutaj i tak nic nie zrobimy; Dalej.

Tutaj równie dobrze możemy przejść Dalej…

I tutaj też.

Dalej też.

Tak samo…

Tutaj akurat Zakończ. Po wykonaniu czynności musimy zrestartować serwer i w ten sposób mamy nowy kontroler domeny w domenie.


…i migracja roli głównej kontrolera domeny na nowy

Na tym etapie musimy zmienić tak zwane wzorce operacji. Nawet po postawieniu nowego kontrolera domeny te znajdują się na serwerze, który był pierwotnie kontrolerem. Wzorców jest 5 i musimy przenieść wszystkie. Jeśli mamy wiele serwerów, możemy je przechowywać na różnych maszynach, ale nic nie stoi na przeszkodzie, by przenieść wszystkie na nowy kontroler domeny, bo w końcu pozbywamy się starego. Mowa tutaj o:

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

Bez wchodzenia w szczegóły co one robią, pokaże jak je przenieść na dwa sposoby:

Metoda „klikając”

Zaczniemy od wzorca schematu. Żeby grzebać w jego ustawieniach, musimy przejść na konto administratora (dosłownie administrator), które jest domyślnie w SBSie wyłączone, więc aby je włączyć wykonujemy polecenia:

net user administrator /active:yes
net user administrator 'na5zeha$lO'

Następnie przelogowujemy się na te konto, wchodzimy do sekcji Uruchom (najlepiej za pomocą Win+R) i uruchamiamy polecenie regsvr32 schmmgmt.dll. Jeśli nam się powiedzie, otrzymamy komunikat:

Jeśli się zaś nie przelogujemy na konto Administrator to dostaniemy taki komunikat:

Mając załadowaną DLLkę możemy odpalić konsolę Microsoft Management Console (MMC) tak samo jak uruchamialiśmy poprzednie polecenie: mmc. Następnie musimy dodać przystawkę Schemat usługi Active Directory. Klikamy u góry Plik -> Dodaj/Usuń przystawkę…, wybieramy ją z listy, klikamy Dodaj > i zatwierdzamy.

Domyślnie wskazany kontroler to ten pierwszorzędny, więc musimy go zmienić na nasz nowy. Należy kliknąć prawym na początek drzewka PPM i wybrać Zmień kontrolera domeny usługi Active Directory… i tam wybieramy nasz nowy kontroler.

Teraz w końcu możemy przejść do ustawień wzorca. Tak samo klikamy prawym na początek drzewka i wybieramy Wzorzec operacji…

Tutaj musimy tylko kliknąć Zmień… i zatwierdzić. Na tym etapie może się Wam pojawiać komunikat, że FSMO nie jest online. Szybkie rozwiązanie – restart systemu na obu kontrolerach.

Następnie zmienimy Menedżer puli RID, Podstawowy kontroler domeny (Kontroler PDC) oraz Wzorzec infrastruktury. Tutaj należy przejść do przystawki Użytkownicy i komputery usługi Active Directory, kliknąć na początek drzewka naszej domeny (będzie się nazywał tak samo jak nasza domena) PPM, zmienić serwer na nowy kontroler domeny tak samo jak w poprzednim przypadku i ponownie wejść w opcję Wzorzec operacji…

Następnie w zasadzie we wszystkich zakładkach trzeba kliknąć Zmień… i zatwierdzić.

Zmiana menedżera puli RID
Zmiana podstawowego kontrolera domeny (PDC)
Zmiana wzorca infrastruktury

Mając to za sobą pozostaje jedynie zmiana ostatniego wzorca operacji – nazw domen. Należy tutaj przejść do przystawki Domeny i relacje zaufania usługi Active Directory, tam kliknąć prawym przyciskiem na najwyższy element przystawki (nie drzewko z nazwą domeny), zmienić tutaj kontroler domeny jak poprzednio i otworzyć opcje zmiany wzorca poprzez Wzorzec operacji…

Tak samo jak poprzednio klikamy Zmień… i zatwierdzamy.

Metoda „na szybko”

Jest o wiele szybsza, niż mogłaby się wydawać. Uruchamiamy na koncie administratora (nazwa Administrator) konsolę Windows PowerShell i wykonujemy polecenie (po wykonaniu polecenia musimy je zatwierdzić):

Move-ADDirectoryServerOperationMasterRole -Identity <nazwa-nowego-serwera> -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

W moim przypadku to było:

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

W ten sposób powinniśmy mieć wszystkie wzorce przeniesione. By się upewnić, można na serwerze uruchomić polecenie netdom query fsmo:

Wynik polecenia netdom query fsmo

Jeśli wszystkie wyniki nie wskazują na stary serwer – jesteśmy w domu.

Sprzątanie po imprezie

Teraz, aby pozbyć się starego kontrolera domeny, musimy najpierw na nim usunąć rolę Usługi certyfikatów w usłudze Active Directory. Otwieramy Menedżer serwera, przechodzimy do sekcji Role w drzewku i po prawej stronie znajdziemy przycisk Usuń role.

Następnie w Kreatorze usuwania ról odznaczamy wspomnianą rolę i przechodzimy dalej.

Następnie zatwierdzamy naciskając Usuń.

Jak to się skończy, musimy uruchomić Kreator instalacji usług domenowych w usłudze Active Directory za pomocą polecenia dcpromo.exe.

Przywita nas kreator. Nie mamy czym się obawiać, zatwierdzamy i idziemy dalej.

Nie zaznaczamy tej opcji. To nie jest jedyny kontroler domeny, więc nie mamy do tego powodu, bo nie pozbywamy się domeny.

Jeśli pojawi Ci się taki komunikat jak ten:

W takiej sytuacji pod żadnym pozorem nie kontynuuj procesu usuwania kontrolera. Ten komunikat oznacza inaczej, że nie przeniosłeś wzorca schematu i musisz to zrobić zanim pozbędziesz się tego kontrolera. W innym wypadku kontynuacja spowoduje totalne wyczyszczenie DNSa, a to proszenie się o kłopoty. Jeśli nie ma takiego komunikatu – nie ma o co się obawiać.

Akurat to zostawiamy zaznaczone:

To też. Być może będziesz musiał te rekordy naprawdę wyczyścić ręcznie. Musiałem tutaj podać poświadczenia administratora.

Na koniec krótkie podsumowanie tego, na co się zdecydowaliśmy…i lecimy dalej.

Jeśli pojawi Ci się po wykonaniu operacji taki komunikat – to oznacza, że wpisy w DNSie musisz pousuwać ręcznie. Tak czy siak kontroler się usunie.

Zresztą, jak widać:

Na koniec otwórz ustawienia serwera DNS na nowym kontrolerze domeny i:

  • Zmień wpis w <domena>\_mscds na FQDN swojego kontrolera domeny:
  • Usuń wszystkie wpisy wskazujące na stary kontroler domeny. Zaznaczyłem wszystkie podfoldery, w którym się znajdują na zrzucie ekranu (zaznaczyłem też jak taki wpis może wyglądać, w skrócie zawiera FQDN starego kontrolera domeny):

I to byłoby na tyle. Teraz możesz usunąć starą maszynę z domeny, ewentualnie jeśli potrzebujesz to możesz przejść do przeniesienia innych usług, np. DHCP.