Windows Server 2019 Dla Profesjonalistow Wydanie II Jordan Krause Helion

Wydanie II
Windows
Server 2019
dla profesjonalistów
Tak stworzysz najnowocześniejsze centrum obliczeniowe!
Jordan Krause
Tytuł oryginału: Mastering Windows Server 2019: The complete guide for IT professionals
to install and manage Windows Server 2019 and deploy new capabilities,
2nd Edition
Tłumaczenie: Jacek Janusz
ISBN: 978-83-283-6486-8
Copyright © Packt Publishing 2019.

First published in the English language under the title ‘Mastering Windows Server 2019 - Second
Edition – (9781789804539)’
Polish edition copyright © 2020 by Helion SA

All rights reserved.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by
any means, electronic or mechanical, including photocopying, recording or by any information
storage retrieval system, without permission from the Publisher.
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu

niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą
kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym
lub innym powoduje naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi

ich właścicieli.
Autor oraz Helion SA dołożyli wszelkich starań, by zawarte w tej książce informacje były
kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie,
ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich.
Autor oraz Helion SA nie ponoszą również żadnej odpowiedzialności za ewentualne
szkody wynikłe z wykorzystania informacji zawartych w książce.
Helion SA
ul. Kościuszki 1c, 44-100 Gliwice
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (księgarnia internetowa, katalog książek)
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/ws19pr_ebook
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
• Poleć książkę na Facebook.com • Księgarnia internetowa

• Kup w wersji papierowej • Lubię to! » Nasza społeczność
• Oceń książkę
Spis treści
O autorze 11
O recenzentach 12
Przedmowa 13
Rozdział 1. Pierwsze kroki w systemie Windows Server 2019 19

Cel systemu Windows Server 20
Robi się pochmurno 22
Chmura publiczna 22
Chmura prywatna 23
Wersje systemu Windows Server i jego licencjonowanie 24
Wersje Standard i Datacenter 24
Desktop Experience, Server Core, Nano Server 25
Modele licencjonowania — SAC i LTSC 26
Przegląd nowych i zaktualizowanych funkcji 28
System Windows 10 wciąż działa 28
Infrastruktura hiperkonwergentna 28
Windows Admin Center 29
Windows Defender Advanced Threat Protection 29
Hasła zabronione 29
Miękki restart 30
Integracja z Linuksem 30
Ulepszona funkcja Shielded Virtual Machines 31
Azure Network Adapter 31
Always On VPN 32
Poruszanie się po interfejsie 32
Uaktualnione menu Start 33
Menu szybkich zadań administracyjnych 34
Spis treści
Używanie funkcji wyszukiwania 36

Przypinanie programów do paska zadań 37
Korzystanie z nowszego ekranu Settings 40
Dwie metody wykonania tej samej czynności 43
Menedżer zadań 46
Widok zadań 49
Podsumowanie 51
Pytania 52
Rozdział 2. Instalowanie systemu Windows Server 2019 i zarządzanie nim 53

Wymagania dotyczące instalacji 54
Instalowanie systemu Windows Server 2019 54
Wypalanie pliku ISO 55
Tworzenie rozruchowej pamięci USB (pendrive) 56
Uruchamianie instalatora 57
Instalowanie ról i funkcji 61
Instalowanie roli za pomocą kreatora 62
Instalowanie funkcji przy użyciu powłoki PowerShell 67
Scentralizowane zarządzanie i monitorowanie 69
Menedżer serwera 69
Narzędzia administracji zdalnej serwera (RSAT) 74
Czy to oznacza, że RDP jest martwy? 75
Windows Admin Center (WAC) 76
Instalacja Windows Admin Center 77
Uruchamianie Windows Admin Center 78
Dodawanie większej liczby serwerów do Windows Admin Center 80
Zarządzanie serwerem przy użyciu Windows Admin Center 81
Umożliwienie szybkiego wdrożenia serwera za pomocą narzędzia Sysprep 82
Instalacja systemu Windows Server 2019 na nowym serwerze 83
Konfigurowanie ustawień i aktualizacji na nowo utworzonym serwerze 83
Uruchomienie narzędzia Sysprep, aby przygotować i wyłączyć serwer główny 84
Tworzenie wzorcowego obrazu dysku 87
Wdrażanie nowych serwerów przy użyciu kopii obrazu wzorcowego 87
Podsumowanie 88
Pytania 89
Rozdział 3. Podstawowe usługi infrastrukturalne 91

Co to jest kontroler domeny? 92
Active Directory Domain Services 92
Używanie roli AD DS do zarządzania siecią 93
Active Directory Users and Computers 94
Active Directory Domains and Trusts 100
Active Directory Sites and Services 101
Active Directory Administrative Center 102
Kontrolery domeny tylko do odczytu (RODC) 104
Potęga zasad grupy 105
Domyślne zasady domeny 106
Tworzenie i podłączanie nowego obiektu zasad grupy 108
Filtrowanie obiektów zasad grupy z uwzględnieniem określonych urządzeń 111
4
Spis treści
System nazw domen (DNS) 112

Różne rodzaje rekordów DNS 114
DHCP a adresowanie statyczne 119
Zakres DHCP 120
Zastrzeżenia DHCP 122
Kopia zapasowa i jej przywracanie 124
Planowanie wykonywania regularnych kopii zapasowych 124
Przywracanie danych z systemu Windows 128
Przywracanie z płyty instalacyjnej 129
Skróty MMC i MSC 133
Podsumowanie 136
Pytania 136
Rozdział 4. Certyfikaty w systemie Windows Server 2019 137

Ogólnie używane typy certyfikatów 138
Certyfikaty użytkownika 138
Certyfikaty komputera 139
Certyfikaty SSL 139
Planowanie środowiska PKI 143
Usługi roli AD CS 143
Urząd certyfikacji przedsiębiorstwa czy autonomiczny? 144
Główny czy podrzędny urząd certyfikacji? 146
Nazwa serwera urzędu certyfikacji 147
Czy mogę zainstalować rolę CA na kontrolerze domeny? 147
Tworzenie nowego szablonu certyfikatu 148
Wydawanie nowych certyfikatów 152
Publikowanie szablonu 152
Żądanie wydania certyfikatu przy użyciu konsoli MMC 154
Żądanie wydania certyfikatu przy użyciu interfejsu WWW 156
Określanie sposobu automatycznej rejestracji certyfikatów 159
Uzyskanie certyfikatu SSL organu publicznego 164
Para kluczy publiczny-prywatny 164
Tworzenie żądania podpisania certyfikatu 165
Przesyłanie żądania certyfikatu 167
Pobieranie i instalowanie certyfikatu 168
Eksportowanie i importowanie certyfikatów 170
Eksportowanie z przystawki MMC 170
Eksportowanie z konsoli IIS 171
Importowanie w innym serwerze 172
Podsumowanie 172
Pytania 173
Rozdział 5. Obsługa sieci w Windows Server 2019 175

Wprowadzenie do protokołu IPv6 176
Jak działają adresy IP w wersji IPv6? 177
Twoje narzędzia sieciowe 181
Polecenie ping 181
Polecenie tracert 182
Polecenie pathping 184
5
Spis treści
Polecenie Test-Connection 185

Polecenie telnet 187
Polecenie Test-NetConnection 189
Śledzenie pakietów za pomocą programów Wireshark lub Message Analyzer 190
Narzędzie TCPView 191
Tworzenie tablicy routingu 192
Serwery o wielu adresach 192
Tylko jedna brama domyślna 193
Definiowanie trasy 194
Grupowanie kart sieciowych 198
Programowalna sieć komputerowa 201
Wirtualizacja sieci Hyper-V 202
Łączenie sieci lokalnej z usługą Azure 207
Azure Network Adapter 207
Podsumowanie 209
Pytania 209
Rozdział 6. Użycie opcji zdalnego dostępu 211

Always On VPN 212
Rodzaje tuneli AOVPN 213
Wymagania niezbędne do uruchomienia tunelu urządzenia 214
Wymagania klienta AOVPN 214
Wdrażanie ustawień 215
Serwerowe komponenty AOVPN 217
DirectAccess 219
Cała prawda o usłudze DirectAccess i protokole IPv6 220
Wymagania wstępne dotyczące usługi DirectAccess 222
Nie używaj kreatora Getting Started Wizard (GSW)! 230
Remote Access Management Console 231
Configuration 232
Dashboard 233
Operations Status 233
Remote Client Status 234
Reporting 235
Tasks 236
DirectAccess, VPN czy AOVPN? Jakie rozwiązanie jest najlepsze? 237
Dołączenie do domeny? 237
Uruchamianie automatyczne czy ręczne? 238
Oprogramowanie zewnętrzne czy wbudowane? 238
Problemy z hasłem i logowaniem w tradycyjnych sieciach VPN 239
Zapory z ograniczeniami portów 240
Ręczne rozłączanie 241
Natywne funkcje równoważenia obciążenia 242
Dystrybucja konfiguracji klienta 243
Web Application Proxy (WAP) 244
WAP jako serwer proxy AD FS 245
Wymagania dla WAP 245
Najnowsze ulepszenia WAP 246
Uwierzytelnienie wstępne dla autoryzacji HTTP Basic 246
Przekierowanie HTTP na HTTPS 246
6
Spis treści
Adresy IP klientów przekazywane do aplikacji 247

Dostęp do serwera Remote Desktop Gateway 247
Ulepszona konsola administracyjna 247
Podsumowanie 249
Pytania 249
Rozdział 7. Hardening i bezpieczeństwo 251

Windows Defender Advanced Threat Protection 252
Instalacja programu Windows Defender AV 253
Wykorzystanie interfejsu użytkownika 253
Wyłączanie usługi Windows Defender 254
Czym w ogóle jest ATP? 256
Windows Defender ATP Exploit Guard 257
Zapora systemu Windows Defender — bez żartów 258
Trzy konsole administracyjne zapory systemu Windows 259
Trzy różne profile zapory 262
Tworzenie w zaporze nowej reguły przychodzącej 263
Tworzenie reguły zezwalającej na wysyłanie pingów (ICMP) 266
Zarządzanie zaporą WFAS przy użyciu zasad grupy 269
Technologie szyfrowania 272
BitLocker i wirtualny układ TPM 272
Chronione maszyny wirtualne 273
Szyfrowane sieci wirtualne 274
Encrypting File System 274
Protokoły IPsec 275
Hasła zabronione 278
Zaawansowana analiza zagrożeń 279
Najważniejsze wskazówki dotyczące ogólnego bezpieczeństwa 282
Pozbycie się wiecznych administratorów 282
Korzystanie z odrębnych kont w celu uzyskania dostępu administracyjnego 283
Używanie innego komputera do wykonywania zadań administracyjnych 283
Nigdy nie przeglądaj internetu, będąc zalogowanym na serwerze 284
Kontrola dostępu oparta na rolach 284
Just Enough Administration 285
Podsumowanie 285
Pytania 286
Rozdział 8. Server Core 287

Dlaczego warto korzystać z wersji Server Core? 288
Zmiana wersji w locie jest już niemożliwa 289
Używanie systemu Server Core 290
PowerShell 291
Zdalna sesja PowerShell 296
Menedżer serwera 298
Narzędzia administracji zdalnej serwera 298
Przypadkowe zamknięcie okna z wierszem poleceń 300
Wykorzystanie aplikacji Windows Admin Center do zarządzania systemem Server Core 302
Narzędzie Sconfig 305
Role dostępne w wersji Server Core 309
7
Spis treści
Co się stało z systemem Nano Server? 309

Podsumowanie 310
Pytania 311
Rozdział 9. Redundancja w systemie Windows Server 2019 313

Równoważenie obciążenia sieciowego 314
Coś innego niż usługa DNS typu round-robin 315
Jakie role mogą korzystać z równoważenia obciążenia sieciowego? 315
Adresy IP wirtualne i dedykowane 316
Tryby pracy NLB 317
Konfigurowanie strony WWW z równoważeniem obciążenia 319
Włączanie opcji NLB 320
Konfigurowanie opcji NLB 321
Konfigurowanie usług IIS i DNS 325
Testowanie rozwiązania 327
Opróżnianie pamięci podręcznej ARP 328
Klaster pracy awaryjnej 329
Klastrowanie hostów Hyper-V 329
Klastry dla usług plikowych 330
Poziomy klastrowania 331
Klastrowanie na poziomie aplikacji 331
Klastrowanie na poziomie serwera 332
Połączenie obu poziomów klastrowania 332
Jak działa tryb pracy awaryjnej? 332
Konfigurowanie klastra pracy awaryjnej 333
Konfigurowanie serwerów 334
Instalowanie funkcji 335
Uruchamianie menedżera klastra pracy awaryjnej 335
Uruchamianie sprawdzania poprawności klastra 336
Uruchamianie kreatora tworzenia klastra 338
Najnowsze ulepszenia dotyczące klastrowania w systemie Windows Server 339
Prawdziwe dwuwęzłowe klastry ze świadkami wykorzystującymi medium USB 339
Wyższe bezpieczeństwo klastrów 340
Klastry korzystające z wielu lokalizacji 340
Klastry w wielu domenach lub grupie roboczej 340
Uaktualnienia stopniowe systemu operacyjnego klastra 341
Odporność maszyn wirtualnych 342
Storage Replica 342
Bezpośrednie miejsce do magazynowania 343
Nowości w systemie Windows Server 2019 345
Podsumowanie 345
Pytania 346
Rozdział 10. PowerShell 347

Dlaczego warto używać interfejsu PowerShell? 347
Polecenia cmdlet 348
PowerShell jest podstawą 349
Skrypty 350
Server Core 350
8
Spis treści
Praca z programem PowerShell 351

Uruchamianie środowiska PowerShell 351
Użycie klawisza Tab 356
Przydatne polecenia cmdlet używane do codziennych zadań 357
Użycie polecenia Get-Help 359
Formatowanie danych wyjściowych 360
Zintegrowane środowisko skryptowe PowerShell 363
Pliki PS1 364
Zintegrowane środowisko skryptowe PowerShell 365
Zdalne zarządzanie serwerem 368
Przygotowanie zdalnego serwera 369
Łączenie ze zdalnym serwerem 371
Konfiguracja żądanego stanu 375
Podsumowanie 377
Pytania 377
Rozdział 11. Kontenery i Nano Server 379

Co to są kontenery aplikacji? 380
Współdzielenie zasobów 380
Izolowanie 381
Skalowalność 382
Kontenery i Nano Server 383
Kontenery Windows Server a kontenery Hyper-V 384
Kontenery Windows Server 384
Kontenery Hyper-V 385
Docker i Kubernetes 385
Kontenery Linux 386
Docker Hub 386
Docker Trusted Registry 387
Kubernetes 388
Używanie kontenerów 389
Instalowanie roli i funkcji 389
Instalacja środowiska Docker for Windows 390
Pobieranie obrazu kontenera 392
Uruchamianie kontenera 393
Podsumowanie 395
Pytania 395
Rozdział 12. Wirtualizacja centrum danych za pomocą hiperwizora Hyper-V 397

Projektowanie i wdrażanie serwera Hyper-V 398
Instalowanie roli Hyper-V 399
Użycie przełączników wirtualnych 402
Zewnętrzny przełącznik wirtualny 404
Wewnętrzny przełącznik wirtualny 405
Prywatny przełącznik wirtualny 405
Tworzenie nowego przełącznika wirtualnego 405
Implementacja serwera wirtualnego 406
Uruchamianie maszyny wirtualnej i łączenie się z nią 410
Instalowanie systemu operacyjnego 411
9
Spis treści
Zarządzanie serwerem wirtualnym 412

Menedżer funkcji Hyper-V 413
Opcja Settings 415
Konsola Hyper-V, protokół pulpitu zdalnego (RDP) czy PowerShell 420
Windows Admin Center (WAC) 421
Chronione maszyny wirtualne 421
Szyfrowanie dysków VHD 424
Wymagania dotyczące infrastruktury dla chronionych maszyn wirtualnych 425
Poświadczenia hosta 426
Integracja z systemem Linux 427
Deduplikacja w systemie Resilient File System (ReFS) 428
System plików ReFS 428
Deduplikacja danych 429
Dlaczego jest to ważne dla środowiska Hyper-V? 429
Środowisko Hyper-V Server 2019 429
Podsumowanie 432
Pytania 433
Odpowiedzi na pytania 435
10
O autorze
Jordan Krause został sześciokrotnie nagrodzony tytułem MVP nadawanym przez firmę
Microsoft — najnowsza nominacja dotyczy kategorii zarządzania chmurą i centrami danych.
Autor ma wyjątkową okazję zajmować się sieciami Microsoft i technologiami zdalnego dostępu
w swojej codziennej pracy. Specjalizuje się w technologiach Microsoft DirectAccess i Always On
VPN. Ciągle poszerza swoją wiedzę i posiada następujące certyfikaty firmy Microsoft: MCP,
MCTS, MCSA i MCITP Enterprise Administrator. Regularnie publikuje artykuły o swoich
doświadczeniach z tymi technologiami. Jordan mieszka w pięknej, zachodniej części stanu Mi-
chigan (USA), jednakże codziennie współpracuje z firmami z całego świata.
Rozwijanie mikrousług w Pythonie
O recenzentach
Anderson Patricio to kanadyjski posiadacz tytułu MVP firmy Microsoft i konsultant IT pracujący
w Toronto. Specjalizuje się w systemach Microsoft Exchange, Skype for Business, Azure,
System Center i Active Directory. Anderson jest aktywnym członkiem społeczności Exchange
i uczestniczy w forach oraz tworzy blogi, artykuły, a także filmy wideo. Jego strona internetowa,
dostępna w języku portugalskim, zawiera tysiące samouczków związanych z produktami firmy
Microsoft, które pomagają lokalnej społeczności, a także wykłady prowadzone na konferencjach
TechED w Ameryce Południowej i szkolenia w akademii MVA.
Premnath Sambasivam jest analitykiem technicznym z 6-letnim doświadczeniem w admini-

strowaniu systemami Windows, VMWare i SCCM. Posiada certyfikat specjalisty MCSE
Cloud Platform and Infrastructure. Opracował i wdrożył rozwiązanie wykorzystujące Microsoft
System Center Configuration Manager, służące do zarządzania ponad 6 tysiącami zasobów
w środowisku jego klienta. Zgłębia tajniki działania platformy Azure i wciąż poszerza wiedzę
o niej. Jest entuzjastą produktów firmy Microsoft.
To było bardzo ciekawe doświadczenie. Dziękuję ci, Sunando, za wybranie mnie do tego
projektu.
12
Przedmowa
Nie jestem do końca pewien, jak i kiedy to się wydarzyło, ale mamy już prawie 2020 rok!
Faktycznie jakaś część mojej osoby naprawdę żałuje, że Microsoft nie chciał poczekać z wyda-
niem nowej wersji systemu Windows Server, abyśmy mogli je nazwać Server 2020. Niestety,
będziemy musieli się zadowolić znacznie mniej egzotycznym brzmieniem Server 2019. Jak
wspaniale jest patrzeć wstecz i zastanawiać się nad wszystkimi wielkimi zmianami, które doko-
nały się w obszarze technologii w ciągu ostatnich 20 lat. W pewnym sensie wydaje się, że
problem roku 2000 (Y2K) właśnie miał miejsce i wszyscy bardzo starali się, aby aplikacje
oparte na systemie DOS i zielonych ekranach były przygotowane do obsługi czterocyfrowych
zakresów dat. Trudno nam obecnie uwierzyć, że systemy informatyczne mogły zostać stwo-
rzone w tak krótkowzroczny sposób. Czy nie braliśmy pod uwagę tego, że świat dożyje 2000
roku? Dziś budujemy technologię opartą na zupełnie odmiennych celach i perspektywie.
Wszystko jest scentralizowane, redundantne, globalne i oparte na chmurze. Użytkownicy ocze-
kują 100% bezawaryjnego dostępu do systemów bez względu na to, gdzie się znajdują i jakie
urządzenia wykorzystują. Świat się naprawdę zmienił.
Wraz ze zmianami na świecie nastąpiły zmiany w infrastrukturze technologicznej. Obecnie wi-

tamy system Microsoft Windows Server 2019. Zanim się zorientujemy, będziemy już w 2020 roku.
Teraz żyjemy w przyszłości Doca i Marty’ego z filmu Powrót do przyszłości. Moje dzieci faktycz-
nie używały już elektrycznej deskorolki!
Z perspektywy użytkownika jako konsumenta danych wymagania obliczeniowe dotyczące zaple-

cza sprzętowego stają się prawie nieistotne. Zagadnienia takie, jak okno obsługi, planowane
przestoje, aktualizacje systemu, spowolnienie działania z powodu niewłaściwej infrastruktury,
muszą się stać niewidoczne dla pracowników. Budujemy sieci w taki sposób, aby ich współużyt-
kownicy mogli wykonywać swoje zadania bez względu na to, co wspiera ich pracę. Czego
więc używamy w celu uzyskania odpowiedniego poziomu niezawodności i odporności na awa-
rie? Nasze centra danych nie zniknęły. Częste używanie słów „chmura” i „chmura prywatna”
nie czyni ich magicznymi. Cała ta scentralizowana mentalność typu „wybierz to, czego potrze-
bujesz” działa dlatego, że wciąż używamy fizycznych serwerów w fizycznych centrach danych.
Windows Server 2019 dla profesjonalistów
Co zapewnia moc obliczeniową w centrach danych w większości firm na świecie? Windows

Server. Nawet jeśli przeniosłeś wszystkie swoje zasoby do chmury Azure, w rzeczywistości nadal
korzystasz z systemu Windows Server 2019. Jest to system operacyjny, który stanowi podstawę
całej platformy Azure! Server 2019 jest gotowy do obsługi nawet najpoważniejszych zadań
w sposób, który został zoptymalizowany dla środowiska chmury.
W ciągu ostatnich kilku lat zaczęliśmy używać programowalnej mocy obliczeniowej (ang. So-
ftware-Defined Computing) ,wykorzystując technologię wirtualizacji do przekształcenia obciąże-
nia serwera w warstwę oprogramowania. Firma Microsoft rozwija ten pomysł, wprowadzając
nowe definicje, takie jak programowalna sieć komputerowa (ang. Software-Defined Networking),
a nawet programowalne centrum danych (ang. Software-Defined Data Center). Technologie,
które umożliwiają realizację tych definicji, pozwalają wirtualizować i udostępniać zasoby na
wielką skalę.
Aby uczynić moc obliczeniową bardziej uniwersalną i przystosowaną do chmury, Microsoft

podejmuje odpowiednie kroki w celu zmniejszenia rozmiaru platformy obliczeniowej w serwe-
rach i stworzenia nowych sposobów komunikacji z nimi. Zaleca się, by w przypadku nowych
serwerów Windows uruchamiano mniejszy, wydajniejszy i bezpieczniejszy interfejs Server
Core. Także technologia kontenerów z aplikacjami bardzo rozwinęła się w ciągu ostatniego
roku. Server 2019 pozwala obecnie przenosić nasze programy do kontenerów w celu urucha-
miania ich w odizolowaniu od siebie i na masową skalę. Mamy również narzędzia do scentrali-
zowanego zarządzania serwerami i sieciami, a mianowicie zupełnie nową aplikację Windows
Admin Center, którą będziemy omawiać na dalszych stronach tej książki.
Poświęćmy trochę czasu na zapoznanie się z funkcjami najnowszej wersji serwerowego systemu
operacyjnego, który w nadchodzących latach będzie obsługiwał tak wiele infrastruktur bizneso-
wych. Serwery Windows od ponad dwóch dekad dominują w przestrzeniach naszych centrów
danych. Czy ta najnowsza wersja w postaci Windows Server 2019 będzie kontynuowała ten
trend?
Dla kogo jest przeznaczona ta książka?

Z książki tej skorzysta każdy, kto jest zainteresowany systemem Windows Server 2019 lub ogól-
nymi informacjami o centrum danych wykorzystującym produkty firmy Microsoft. Ważnym
czynnikiem podczas tworzenia tej pozycji była chęć upewnienia się, by każdy, kto ma podstawową
wiedzę o obsłudze komputerów, mógł wykorzystać zawarte w niej wiadomości we własnej
pracy. Jeśli dobrze znasz technologie infrastrukturalne firmy Microsoft i używałeś wcześniej-
szych wersji systemu Windows Server, wiedz, że istnieje kilka zagadnień dotyczących funkcjo-
nalności, które są zupełnie nowe i pojawiły się dopiero w systemie Server 2019. Z drugiej strony,
jeśli obecnie przyjmujesz zgłoszenia od użytkowników lub dopiero rozpoczynasz przygodę
z informatyką, wiedz, że w tej książce zadbano o to, abyś w pełni zrozumiał nie tylko te zagad-
nienia, które pojawiły się dopiero w wersji Server 2019, ale także podstawowe funkcje, które
zostały przeniesione z poprzednich wersji systemu operacyjnego. Są one nadal bardzo ważne
14
Przedmowa
i należy o nich pamiętać, pracując w centrum danych wykorzystującym produkty firmy

Microsoft.
Opis rozdziałów
Rozdział 1., „Pierwsze kroki w systemie Windows Server 2019”, zawiera wprowadzenie do
systemu operacyjnego oraz przegląd nowych technologii i możliwości, które może on zapewnić.
Poświęcimy również trochę czasu na przeanalizowanie unowocześnionego interfejsu — będzie
to przydatne dla tych osób, które jeszcze nie obsługują go w pełni komfortowo.
Rozdział 2., „Instalowanie i zarządzanie systemem Windows Server 2019”, omawia pierwszą
czynność, którą musimy wykonać podczas pracy z systemem Server 2019 — należy go zainsta-
lować! Choć wydaje się to prostym zadaniem, istnieje wiele parametrów dotyczących wersji
i licencji, które należy zrozumieć przed przystąpieniem do instalacji. Od tej pory zaczniesz
poznawać scentralizowaną procedurę obsługi środowisk firmy Microsoft, analizując sposoby,
dzięki którym można zarządzać serwerami i wchodzić z nimi w interakcje bez konieczności
logowania się do nich.
Rozdział 3., „Podstawowe usługi infrastrukturalne”, pozwala uzyskać podstawową wiedzę w za-
kresie technologii, która tworzy infrastrukturę dowolnej sieci zorientowanej na produkty
firmy Microsoft. Omówimy wielką trójkę — usługę katalogową Active Directory (AD), system
nazw domen (Domain Name System — DNS) i protokół dynamicznego konfigurowania ho-
stów (Dynamic Host Configuration Protocol — DHCP), a także zajmiemy się niektórymi
możliwościami tworzenia kopii zapasowych serwerów oraz zaprezentujemy skróty przydatne
podczas obsługi konsoli zarządzania (Microsoft Management Console — MMC) i konfiguracji
systemu (Microsoft Configuration — MSC).
Rozdział 4., „Certyfikaty w systemie Windows Server 2019”, analizuje jeden z elementów
systemu Windows Server, z którym większość spotykanych przeze mnie administratorów nie
jest zaznajomiona, mimo że istnieje od wielu lat. Przyjrzyjmy się bliżej certyfikatom, ponieważ
stają się one coraz częściej wymagane w nowych technologiach, które wdrażamy. Pod koniec
tego rozdziału powinieneś być w stanie stworzyć własną infrastrukturę klucza publicznego (PKI)
i zacząć wydawanie certyfikatów za darmo!
Rozdział 5., „Obsługa sieci w Windows Server 2019”, rozpoczyna się od wprowadzenia do
skomplikowanego i przerażającego protokołu IPv6, a następnie prezentuje zestaw narzędzi,
które są wbudowane w Windows Server 2019 i mogą być używane w codziennych zadaniach
związanych z zarządzaniem siecią komputerową. W tym rozdziale omówimy również sieci
programowalne.
Rozdział 6., „Użycie opcji zdalnego dostępu”, omawia różne technologie zdalnego dostępu,
które są wbudowane w Windows Server 2019. Prezentujemy w nim możliwości, które zapewnia
wirtualna sieć prywatna (VPN), DirectAccess, Web Application Proxy oraz zupełnie nowa usługa
Always On VPN.
15
Rozdział 7., „Hardening i bezpieczeństwo”, daje pewien wgląd w funkcje bezpieczeństwa i szy-
frowania, które są wbudowane w Windows Server 2019. W tym roku bezpieczeństwo jest na
całym świecie priorytetem dla osób odpowiedzialnych za zarządzanie systemami informatycz-
nymi, więc sprawdźmy, jakie mechanizmy ochrony są dostępne.
Rozdział 8., „Server Core”, wprowadza w świat serwerów bezobsługowych o coraz mniejszych
rozmiarach. Server Core przez wiele lat nie był zbyt zauważalny, jednak należy się z nim
zapoznać, ponieważ w naszej infrastrukturze wprowadzamy nowy poziom świadomego bezpie-
czeństwa. Upewnijmy się, że będziesz mieć wiadomości niezbędne do poprawy bezpieczeństwa
i wydajności w swoim środowisku przy jednoczesnym zmniejszeniu ilości miejsca i zasobów
zużywanych przez serwery.
Rozdział 9., „Redundancja w systemie Windows Server 2019”, prezentuje wybrane platformy
dostępne w systemie Server 2019, które zapewniają wydajną redundancję danych i obliczeń.
Zapoznaj się z równoważeniem obciążenia sieciowego, klastrami pracy awaryjnej oraz zaktuali-
zowaną funkcją Spaces Storage Direct.
Rozdział 10., „PowerShell”, wprowadza w nowy, niebieski interfejs wiersza poleceń, abyś mógł
z niego swobodnie korzystać, a także dowiedzieć się, dlaczego jest on o wiele potężniejszy
niż standardowy wiersz poleceń. PowerShell szybko staje się niezbędnym narzędziem słu-
żącym do administrowania serwerami, szczególnie w przypadkach, gdy stosujesz scentrali-
zowane podejście do zarządzania.
Rozdział 11., „Kontenery i Nano Server”, omawia otwarte oprogramowanie i system Linux
w książce o produkcie firmy Microsoft! Pojemniki z aplikacjami szybko stają się nowym standar-
dem dla hostingu nowoczesnych, skalowalnych rozwiązań. Dowiedz się, jak zwiększyć swoje
doświadczenie inżyniera DevOps za pomocą narzędzi takich, jak Windows Server Containers,
Hyper-V Containers, Docker i Kubernetes.
Rozdział 12., „Wirtualizacja centrum danych za pomocą hiperwizora Hyper-V”, omawia temat,
który każdy administrator serwera powinien znać. Organizacje od wielu lat migrują w dużych
ilościach swoje serwery na maszyny wirtualne. Skorzystaj z tego rozdziału, aby się upewnić,
że rozumiesz, jak działa hiperwizor Hyper-V, a także by zapewnić zasoby niezbędne do zbudo-
wania go i zarządzania nim, jeśli zajdzie taka potrzeba.
Jak w pełni wykorzystać tę książkę?

Każda technologia, którą omawiamy na stronach tej książki, jest zawarta w systemie Windows
Server 2019 lub dotyczy go bezpośrednio. Jeśli uzyskasz dostęp do sprzętu i plików instalacyj-
nych systemu Server 2019, będziesz w stanie postępować zgodnie ze wskazówkami opisanymi
w książce i przetestować każdą z przeanalizowanych technologii. Będziemy także omawiać —
i odwoływać się do nich — wybrane technologie klasy korporacyjnej o zaostrzonych wyma-
ganiach infrastrukturalnych, które trzeba spełnić, aby mogły w pełni działać, więc być może
będziesz musiał odłożyć ich faktyczne przetestowanie, dopóki nie uzyskasz dostępu do bardziej
zaawansowanego środowiska lub laboratorium testowego. Oczywiście, bez względu na to
w książce zostaną omówione wszystkie pojęcia.
16
Przedmowa
Przeanalizujemy również wybrane elementy, które nie są zawarte w samym systemie Server 2019,
ale służą do rozszerzenia jego możliwości i funkcjonalności. Niektóre z tych elementów pozwa-
lają na połączenie ze środowiskiem Azure Cloud, a inne są dostarczane przez firmy zewnętrzne
— przykładowo w systemie Server 2019 można używać środowisk Docker i Kubernetes do
interakcji z kontenerami aplikacji. Nie musisz wykorzystywać tych narzędzi, aby zarządzać
nowym środowiskiem Windows Server 2019, ale pozwalają one na dostęp do kilku całkiem
ciekawych funkcji, z którymi, jak sądzę, będziesz się chciał zapoznać.
Konwencje formatowania tekstu

W tej książce zastosowano wiele konwencji formatowania tekstu.
KodWTekście: oznacza fragmenty kodu w tekście oraz dane wprowadzane i wyświetlane w wier-
szu poleceń. Oto przykład: „Możesz wyświetlić nazwę serwera z użyciem polecenia hostname”.
Każda informacja wprowadzana lub wyświetlana w wierszu poleceń jest prezentowana w nastę-
pujący sposób:
Uninstall-WindowsFeature -Name Windows-Defender
CzcionkaPogrubiona: wskazuje nowe pojęcie lub ważne słowo. Przykład: „Windows Admin
Center jest platformą służącą do zarządzania serwerem i klientem”.
Kursywa: wykorzystywana w przypadku komunikatów, nazw plików i ścieżek, adresów interne-

towych oraz twitterowych. Oto przykład: „Możesz zauważyć, że wartość parametru Minimalna
długość hasła wynosi siedem znaków”.
W ten sposób oznaczone są ostrzeżenia, ważne uwagi, wskazówki i opisy przydatnych sztuczek.
17
18
1
Pierwsze kroki
w systemie Windows
Server 2019
Około 10 lat temu firma Microsoft zmieniła metodę publikowania systemów operacyjnych.
Polega ona obecnie na tym, że najnowsza wersja systemu Windows Server jest zawsze bardzo
podobna do najnowszego systemu operacyjnego klienta Windows. Ten sposób publikacji stał
się już standardem, ponieważ Server 2008 R2 ściśle odzwierciedla Windows 7, Server 2012
wygląda podobnie jak Windows 8, a wiele funkcji, które były dostarczane z aktualizacją
Windows 8.1, jest też zawartych w systemie Server 2012 R2. Zastosowano tę metodę także
w przypadku systemu Server 2016, ponieważ używając go, odnosisz wrażenie, jakbyś był
zalogowany na stacji roboczej z systemem Windows 10.
Gdy znamy interfejs systemu Windows 10 i umiemy go dobrze obsługiwać, zwykle nie ma-
my problemów z przejściem do interfejsu systemu Server 2016 i przetestowaniem go. Także
Windows Server 2019 nie jest wyjątkiem od tej reguły, z wyjątkiem tego, że sposób wersjo-
nowania systemów operacyjnych po stronie klienta nieco się zmienił. Zamiast publikować
nowe wersje systemu Windows (11, 12, 13 itd.), Microsoft na razie po prostu wciąż oferuje
Windows 10 i nadaje mu numery wersji podrzędnych wskazujące daty ich wydania. Na przykład
wersja systemu Windows 10 1703 została opublikowana w marcu 2017 roku, a wersja systemu
Windows 10 1709 — we wrześniu 2017 roku. Później mieliśmy również wersje 1803 i 1809,
chociaż wersja 1809 była nieco opóźniona i nie została opublikowana przed listopadem, jed-
nakże pierwotny plan nie przewidywał takiego problemu. Obecnie nowe wersje systemu
operacyjnego Windows pojawiają się co mniej więcej pół roku, ale oczekiwanie od działów IT,
by uaktualniały i przenosiły wszystkie serwery tylko w celu zainstalowania systemu opera-
cyjnego nowszego jedynie o 6 miesięcy, jest zupełnie nierealne — czasami samo zaplanowa-
nie migracji wymaga więcej czasu.
Trochę wyprzedzam zagadnienia zaprezentowane w tej książce, ponieważ w dalszej części

tego rozdziału, w podrozdziale zatytułowanym „Wersje systemu Windows Server i jego licencjo-
nowanie”, będziemy omawiać sposób wersjonowania systemu Windows Server. Chodzi o to,
że Windows Server 2019 wygląda jak najnowsza wersja systemu operacyjnego klienta Win-
dows, która została wydana mniej więcej w tym samym czasie — tym systemem operacyj-
nym jest Windows 10 1809. Zanim zaczniemy omawiać funkcje systemu Windows Server,
ważne jest ustalenie poziomu użyteczności i znajomości samego systemu operacyjnego
przed głębszym zanurzeniem się w technologie działające pod maską.
Poświęćmy kilka minut na zapoznanie się z interfejsem graficznym i dostępnymi opcjami

najnowszej wersji systemu Windows Server, a także przeanalizujmy w tym rozdziale poniższe
zagadnienia:
 Cel systemu Windows Server.
 Robi się pochmurno.
 Wersje systemu Windows Server i jego licencjonowanie.
 Przegląd nowych i zaktualizowanych funkcji.
 Poruszanie się po interfejsie.
 Korzystanie z nowszego okna ustawień.
 Menedżer zadań.
 Widok zadań.
Cel systemu Windows Server

Czy pytanie o cel systemu Windows Server jest niemądre? Nie wydaje mi się. Warto się nad
tym zastanowić, szczególnie w obecnych czasach, gdy definicje serwerów i mocy obliczeniowej
zmieniają się regularnie. Odpowiedź na to pytanie w przypadku klientów Windows jest
prostsza. Komputer kliencki z systemem Windows jest obiektem żądającym danych oraz ich
konsumentem i współtwórcą.
Skąd te dane są pobierane i dokąd są przesyłane? Co umożliwia mechanizmom i aplikacjom

działającym w systemach operacyjnych klienta komunikację z tymi danymi? Co zabezpiecza
użytkowników i ich dane? Odpowiedzi na te pytania ujawniają ogólny cel serwerów. Serwery
przechowują, chronią i obsługują dane, które mają być konsumowane przez klientów.
W obecnych czasach wszystko dotyczy danych biznesowych. Nasz e-mail, dokumenty, bazy
danych, listy klientów — wszystko, czego potrzebujemy do dobrego prowadzenia biznesu,
to dane. Są one dla nas kluczowe. Serwery są tym, czego używamy do budowania zaufanej
struktury, która będzie przechowywać nasze dane.
Tradycyjnie uważamy, że serwery wykorzystują architekturę klient-serwer. Użytkownik otwiera

program w swoim komputerze klienckim. Ten program sięga do serwera w celu otrzymania
czegoś, a serwer odpowiada w razie potrzeby. Pomysł ten można poprawnie zastosować do
niemal każdej transakcji, która jest realizowana w połączeniu z serwerem. Gdy komputer
20
Rozdział 1. • Pierwsze kroki w systemie Windows Server 2019
dodany do domeny musi Cię uwierzytelnić jako użytkownika, kontaktuje się z usługą Active
Directory na serwerze, aby zweryfikować poświadczenia i uzyskać token uwierzytelnienia.
Gdy musisz skontaktować się z zasobem według jego nazwy, komputer pyta serwer DNS,
jak się do niego dostać. Jeśli musisz otworzyć plik, prosisz serwer plików, aby wysłał go do
Ciebie zgodnie ze swoim protokołem.
Serwery zostały zaprojektowane tak, aby wspomagały naszą pracę i często funkcjonowały w spo-
sób niezauważalny dla użytkownika. W ostatnich latach podjęto szeroko zakrojone działania,
aby zapewnić, że zasoby będą zawsze dostępne w sposób niewymagający szkolenia ani podej-
mowania dużego wysiłku ze strony naszych pracowników.
W większości organizacji istnieje potrzeba zdefiniowania różnych serwerów, aby zapewnić

pracownikom wymagane przez nich funkcje. Każda usługa w systemie Windows Server jest
dostarczana jako rola lub jako jej część. Kiedy myślisz o stworzeniu nowych serwerów lub
skonfigurowaniu jakiegoś serwera w celu wykonania określonego zadania, tak naprawdę
chodzi Ci o indywidualną rolę lub więcej ról, które zostaną skonfigurowane na tym serwerze
w celu wykonania danej pracy. Serwer bez zainstalowanych ról jest bezużyteczny, jednakże
w odpowiedniej obudowie może być znakomitym przyciskiem do papieru. Urządzenie SAN
o wysokości 3U może ważyć ponad 50 kg i utrzymywać porządek na biurku nawet podczas
huraganu!
Możesz porównać role do mięsa i ziemniaków dostępnych na serwerze, jednakże następnym

razem, gdy będziemy o nich rozmawiać, będą one czymś w rodzaju uzupełniania jedzenia o sól
i pieprz. Oprócz ogólnych ról instalowanych i konfigurowanych na serwerach, Windows zawiera
wiele funkcji, które można dodać i które czasem wprawdzie są samodzielne, ale częściej
uzupełniają określone role w systemie operacyjnym. Funkcje mogą być czymś, co uzupełnia
i dodaje określoną funkcjonalność do podstawowego systemu operacyjnego. Jako przykład
może służyć klient Telnetu. Funkcja może także zostać dodana do serwera w celu wzmoc-
nienia istniejącej roli — przykładem może być dodanie funkcji równoważenia obciążenia
sieciowego do już działającego serwera zdalnego dostępu lub serwera IIS. Połączenie ról i funk-
cji w systemie Windows Server jest tym, co powoduje, że ten kawałek żelastwa staje się przydat-
nym sprzętem w Twojej pracy.
W tej książce będziemy oczywiście omawiać infrastrukturę firmy Microsoft. W tego typu
środowiskach system operacyjny Windows Server jest najważniejszy i występuje we wszyst-
kich aspektach technologii. Istnieją alternatywy dla systemu Windows Server, a także różne
produkty, które mogą zapewnić organizacji część funkcjonalności, ale dość rzadko można
spotkać środowisko biznesowe, które działa bez jakiejkolwiek infrastruktury firmy Microsoft.
Windows Server zawiera niesamowitą ilość technologii, które są spakowane w jednym małym
dysku instalacyjnym. W przypadku systemu Windows Server 2019 firma Microsoft zdefinio-
wała, co to znaczy być serwerem, i dlatego zaoferowano kilka nowych, ekscytujących funkcji,
o których opowiem w tej książce. Składniki takie, jak PowerShell, Windows Admin Center
i Storage Spaces Direct, zmieniają sposób, w jaki zarządzamy swoimi środowiskami kompu-
terowymi i je modyfikujemy. Dla administratorów serwerów to ekscytujący czas!
21
Robi się pochmurno

Istnieje nowy termin, być może nawet słyszałeś o nim… To chmura. Chociaż słowo „chmura”
z pewnością zamieniło się w modne hasło, które jest często niewłaściwie używane, idea infra-
struktury chmurowej jest niezwykle potężna. Struktura chmurowa jest związana z zasobami
wirtualnymi — maszynami wirtualnymi, dyskami wirtualnymi, a nawet sieciami wirtualny-
mi. Podłączenie do chmury zwykle pozwala wykonywać takie działania jak spontaniczne
uruchamianie nowych serwerów, a nawet umożliwia automatyczne zwiększanie lub zmniej-
szanie wymaganych zasobów przez określone usługi, w zależności od ich wykorzystania.
Weź pod uwagę przykładową prostą stronę internetową związaną z handlem elektronicz-
nym, którą konsument może odwiedzić w celu wykonania zamówienia. Być może przez 75%
czasu ta strona może być obsługiwana przez jeden serwer WWW o ograniczonych zasobach,
co przekłada się na dość niski koszt usługi. Jednakże przez pozostałe 25% czasu (być może
w okresach świątecznych) wykorzystanie znacznie rośnie, co wymaga znacznie większej mocy
obliczeniowej. W czasach gdy rozwiązania chmurowe jeszcze nie istniały, oznaczałoby to, że
firma musiałaby wciąż dostosowywać swoje środowisko do maksymalnych wymagań, na wy-
padek gdyby kiedykolwiek były one potrzebne. Przez dużą część roku płacono by za większą
liczbę serwerów i znacznie więcej mocy obliczeniowej, niż byłoby to potrzebne. Dzięki infra-
strukturze chmurowej udostępniającej stronie internetowej możliwość zwiększenia lub
zmniejszenia liczby serwerów, które może mieć do dyspozycji w razie potrzeby, całkowity
koszt usługi można drastycznie zmniejszyć. Jest to obecnie główny czynnik powodujący
rozwój zastosowań chmurowych w biznesie.
Chmura publiczna
Przez większość czasu, gdy Twoja sąsiadka Zuzia Wszystkowiedząca opowiada Ci o chmurze,
po prostu ma na myśli internet. Dokładniej rzecz ujmując, mówi o jakiejś usłudze, z której
korzysta i do której łączy się za pomocą internetu. Na przykład Office 365, Dysk Google,
OneDrive, Dropbox — to wszystko są zasoby chmury publicznej, gdyż przechowują dane
w chmurze. W rzeczywistości Twoje dane znajdują się tylko na serwerach, do których uzyskujesz
dostęp przez internet. Ponieważ jednak tych serwerów nie widzisz i nie musisz nimi zarzą-
dzać ani ich obsługiwać, wydaje się, że jest to magia, którą następnie nazywa się chmurą.
Dla działów IT termin „chmura” częściej oznacza jednego z trzech największych dostawców
hostingu w chmurze. Ponieważ jest to książka o produktach firmy Microsoft, uważam (i to moje
prawdziwe przekonanie), że Azure znajduje się w tej kategorii na pierwszym miejscu. Platforma
Azure mogłaby być tematem innej książki (lub wielu innych), ale krótko mówiąc, jest scentrali-
zowaną architekturą obliczeniową w chmurze, która może zarządzać Twoimi danymi, usługami,
a nawet całą siecią serwerów.
Dzięki przeniesieniu centrum danych na platformę Azure przestaniesz martwić się o sprzęt
serwerowy, wymieniać dyski twarde i wykonywać wiele innych czynności. Zamiast kupować
serwery, rozpakowywać je, instalować w szafach, instalować w nich system Windows, a następnie
konfigurować role, których chcesz użyć, wystarczy kliknąć kilka przycisków, aby uruchomić
22
nowe serwery wirtualne, których wielkość można zmienić w dowolnym momencie. Oprócz tego
ponosisz mniejsze koszty operacyjne tych serwerów — są to miesięczne lub roczne stawki
za uruchamianie systemów w chmurze, a nie duże opłaty za fizyczny sprzęt komputerowy.
Istnieje wielu dostawców usług chmurowych o podobnych możliwościach, jednak wielka trójka
to Azure, Amazon (AWS) i Google. Z punktu widzenia przedsiębiorstwa Azure po prostu po-
zwala mieć ciastko i jednocześnie jeść to ciastko. Nie jestem pewien, czy inne firmy kiedykol-
wiek będą w stanie nadążyć za wszystkimi zmianami i aktualizacjami, które Microsoft stale
wprowadza do infrastruktury platformy Azure.
Chmura prywatna
Chociaż większość osób pracujących obecnie w sektorze IT całkiem dobrze rozumie, co to
znaczy być częścią usługi w chmurze, a wiele z nich rzeczywiście już to realizuje, przedsiębior-
stwom jest wciąż prezentowany termin „chmura prywatna”, który jednak jest często niezrozu-
miały. Na początku uznałem go za głupią sztuczkę marketingową, rażące i niewłaściwe użycie
terminu „chmura”. Traktowałem to po prostu jako próbę dotarcia do tych osób, które ekscytują
modne słowa. Na szczęście się myliłem. Na początku swojego istnienia technologia chmury
prywatnej nie była po prostu jeszcze gotowa, by sprostać oczekiwaniom rozbudzonym przez
jej reklamę.
Czasy jednak się zmieniły. Obecnie całkowicie możliwe jest pobranie infrastruktury, która została
uruchomiona w prawdziwej, publicznej chmurze, i zainstalowanie jej bezpośrednio we własnym
centrum danych. Dzięki temu możesz zapewnić swojej firmie korzyści pracy w chmurze, takie
jak możliwość zwiększania i zmniejszania zasobów, uruchamiania wszystkiego, co zostało zwirtu-
alizowane, a także implementowania wszystkich wskazówek i porad związanych ze środowiskami
chmurowymi, przy jednoczesnym przechowywaniu danych w Twojej lokalizacji, która została
odpowiednio przez Ciebie zabezpieczona. Zapewnienie bezpieczeństwa danych przez firmy
zajmujące się technologiami chmurowymi jest absolutnie jedną z największych przeszkód
we wdrażaniu rozwiązań w prawdziwych chmurach publicznych. Kiedy jednak instalujesz
własną chmurę prywatną, otrzymujesz z obu światów to, co najlepsze, a w szczególności
uniwersalne i bezpieczne środowisko obliczeniowe, wiedząc przy tym, że nadal kontrolujesz
i posiadasz wszystkie swoje dane.
Nie jest to książka o chmurach publicznych czy prywatnych. Wspominam o nich, by przekazać
punkt odniesienia dla niektórych zagadnień omawianych w późniejszych rozdziałach, a także
po to, aby trochę Cię zachęcić do zdobycia wiedzy na temat technologii chmurowej. Będziesz
mógł poznać interfejs Windows Server 2019, związany na wiele różnych sposobów z chmurą,
a także zauważysz, że dużo podstawowych usług systemu Server 2019 jest podobnych (jeśli nie
takich samych) do tych, które stają się dostępne w Microsoft Azure.
Na stronach tej książki nie będziemy omawiać możliwości platformy Azure, ale raczej skoncen-
trujemy się na bardziej tradycyjnym działaniu systemu Windows Server, który będzie wykorzy-
stywany lokalnie. Dzięki natarczywej reklamie technologii chmurowych łatwo jest stracić
zdolność rozsądnego myślenia i zacząć uważać, że wszyscy szybko pobiegną do chmury ze
wszystkimi swoimi potrzebami technologicznymi — jednak jest to po prostu nieprawdą.
23
Większość firm będzie potrzebować jeszcze przez długi czas wielu lokalnych serwerów; w rze-
czywistości dużo takich przedsiębiorstw może nigdy nie zaufać chmurze i zawsze będzie utrzy-
mywać własne centra danych. Te centra danych będą miały lokalne serwery, które będą wyma-
gały od administratorów zarządzania nimi. To jest właśnie Twoje zadanie.
Wersje systemu Windows Server

i jego licencjonowanie
Każdy, kto zajmował się w minionych latach projektowaniem lub instalacją systemu Windows
Server, prawdopodobnie zastanawia się, jaki kierunek obierzemy w tej książce. System Windows
Server występuje w wersjach o różnych możliwościach i w różnych wersjach technicznych,
są też różne modele licencjonowania go. Poświęćmy kilka minut na omówienie tych różnic,
abyś mógł dobrze poznać dostępne opcje i abyśmy mogli określić, które wersje planujemy
przeanalizować w tej książce.
Wersje Standard i Datacenter

Podczas instalowania na sprzęcie systemu operacyjnego Windows Server 2019, o czym będzie
mowa w rozdziale 2., „Instalowanie systemu Windows Server 2019 i zarządzanie nim”, będziesz
mieć dwie możliwości wyboru serwera. Pierwszą z nich jest Server 2019 Standard, która jest
opcją domyślną i zawiera większość tradycyjnych ról systemu Windows Server. Chociaż nie
mogę podać szczegółów dotyczących cen, ponieważ mogą się one różnić w zależności od umowy
z firmą Microsoft, Standard jest generalnie tańszą opcją i dlatego jest najczęściej używany do
instalacji systemu Windows Server 2019.
Datacenter jest natomiast modelem luksusowym. Istnieje kilka ról i funkcji w systemie Windows
Server 2019, które działają tylko z wersją systemu operacyjnego Datacenter i nie są dostęp-
ne w standardzie. Jeśli kiedykolwiek będziesz szukać nowej technologii firmy Microsoft,
której powierzysz odpowiednie zadanie w swoim środowisku, sprawdź wymagania i dowiedz się,
czy będziesz musiał zainstalować serwer w wersji Datacenter. Pamiętaj, że wersja Datacenter
może kosztować znacznie więcej niż Standard, więc zazwyczaj powinieneś jej używać tylko
tam, gdzie będzie rzeczywiście wymagana. Na przykład, jeśli chcesz zarządzać chronionymi
maszynami wirtualnymi lub wykorzystywać funkcjonalność Storage Spaces Direct, będziesz
musiał na serwerach, które będą używać tych technologii, zainstalować wersję Server 2019
Datacenter.
Jedną z największych różnic funkcjonalnych między wersjami Standard i Datacenter jest liczba
maszyn wirtualnych, które mogą one hostować. Wersja 2019 Standard może uruchamiać tylko
dwie maszyny wirtualne w danym momencie, co jest dość dużym ograniczeniem, jeśli
chcesz zbudować serwer Hyper-V. Datacenter pozwala na uruchamianie nieograniczonej liczby
maszyn wirtualnych, co sprawia, że nie trzeba się zastanawiać podczas budowania serwerów
będących hostami wirtualizacji. Wersja Datacenter jest wówczas najlepszym rozwiązaniem.
24
Desktop Experience, Server Core, Nano Server

Poniżej zaprezentowane wersje są związane z różnymi obszarami działania i różnymi interfejsami
użytkownika, które można uruchomić w komputerach z systemem Windows Server 2019.
Istnieją trzy odmienne rodzaje systemu Windows Server, a wybór zależy od możliwości i zabez-
pieczeń, jakich potrzebujesz.
Desktop Experience
Jest to najczęstszy wybór wśród serwerów Windows na całym świecie. Niezależnie od tego,
czy budujesz system Windows Server 2019 Standard czy Datacenter, możesz wybrać serwer
z graficznym interfejsem użytkownika lub bez niego. Tradycyjny interfejs typu „wskaż i kliknij”
nazywa się Desktop Experience. Pozwala on na wykonywanie połączeń RDP do Twoich serwe-
rów, ma tradycyjny pulpit, a także możliwość korzystania z graficznego menedżera serwera
bezpośrednio z maszyny, do której się zalogowałeś — w sumie jest to najlepszy wybór, jeśli jesteś
niedoświadczonym administratorem serwera.
Jeśli umiesz obsługiwać system Windows 10, powinieneś być w stanie przynajmniej poruszać
się w systemie Windows Server 2019 w wersji Desktop Experience. Jest to wersja systemu Win-
dows Server 2019, na której będziemy się koncentrować przez większość tej książki. Z niej też
będą pochodzić prawie wszystkie zrzuty ekranu.
Server Core
Jak będziesz mógł zauważyć w trakcie procesu instalacji systemu Windows Server 2019, do-
myślną opcją nie jest Desktop Experience. Oznacza to, że wybranie domyślnej ścieżki instalacyj-
nej spowodowałoby umieszczenie w komputerze bezobsługowej wersji systemu Windows
Server, zwanej najczęściej Server Core. Charakter bezobsługowy sprawia, że Server Core
jest szybszy i bardziej wydajny, niż wersja Desktop, co ma sens, ponieważ nie trzeba uruchamiać
całego dodatkowego kodu i zużywać wszystkich niezbędnych zasobów służących do prezento-
wania złożonego interfejsu graficznego.
Niemal wszystko, co chcesz zrealizować w systemie Windows Server, jest dostępne zarówno
w Server Core, jak i Desktop Experience, główne zaś różnice to interfejs i poziom bezpie-
czeństwa. Aby móc korzystać z Server Core, musisz naprawdę sprawnie obsługiwać interfejs
wiersza poleceń (a mianowicie PowerShell), a także powinieneś rozważyć zdalne zarządza-
nie jako niezawodny sposób interakcji z serwerami. Więcej szczegółów na ten temat dowiesz
się w rozdziale 8., „Server Core”.
Oprócz zwiększonej wydajności największą korzyścią z użycia wersji Server Core jest bezpie-
czeństwo. Większość złośliwego oprogramowania, które próbuje zaatakować serwery Windows,
zależy od elementów istniejących w graficznym interfejsie użytkownika Desktop Experience.
Ponieważ te składniki nie działają wewnątrz środowiska Server Core (niestety, nie możesz
się dostać na pulpit, nawet gdybyś chciał), ataki na maszyny z tą wersją systemu są znacznie
mniej skuteczne.
25
Nano Server
Istnieje też trzecia platforma Windows Server 2019, znana jako Nano Server. To zminiatury-
zowana wersja Windows Server, bezobsługowa jak Server Core, ale wykorzystująca jeszcze
mniej zasobów. Gdy ostatnio uruchamiałem Nano Server, zauważyłem, że zużył on mniej niż
500 MB pamięci na dane pochodzące z całego systemu operacyjnego, co jest naprawdę niesa-
mowitym rezultatem.
Wygląda na to, że zainteresowanie platformą Nano Server wzrosło w związku z wydaniem

wersji Server 2016. W tym czasie firma Microsoft planowała zaimplementować mnóstwo ról
w środowisku Nano Server. Celem było zastąpienie systemem Nano naszych nadmiernie
rozrośniętych i zbyt dużych serwerów, jednakże te plany spaliły na panewce.
W trakcie pisania tego tekstu Nano Server jest już całkiem dobrze związany z technologią
kontenerów. W rzeczywistości uważam, że jedynym sensownym rozwiązaniem pozwalającym na
obsługę wersji Nano Server jest uruchomienie jej jako obrazu w kontenerze. To zagadnienie
omówimy dokładniej w rozdziale 11., „Kontenery i Nano Server”, jednakże już w tej chwili
można śmiało powiedzieć, że jeśli wiesz, czym są kontenery, i jesteś zainteresowany ich użyciem,
na pewno skorzystasz z przedstawionych później informacji o wersji Nano Server. Jeśli nie
zamierzasz pracować z kontenerami, prawdopodobnie nigdy nie uruchomisz serwera Nano
w swoim środowisku.
Modele licencjonowania — SAC i LTSC

Następna decyzja dotycząca konfiguracji serwerów Windows dotyczy wyboru modelu licen-
cjonowania i wsparcia technicznego, a także odpowiedniego harmonogramu wydań. Istnieją
dwie różne ścieżki, z których możesz skorzystać. Jeśli potrzebujesz ich obu, możesz je także
połączyć ze sobą w jednym środowisku.
Kanał obsługi półrocznej (SAC)

Jeśli zdecydujesz się zainstalować wersję SAC dla produktu Windows Server, konwencja nazew-
nicza dotycząca systemu operacyjnego zmieni się. Zamiast nazywać go Server 2019, w rzeczywi-
stości będziesz używać nazw Windows Server 1803, 1809 itd. Wynika to z tych samych zasad,
które wykorzystuje system Windows 10. Oznacza to, że nowe wersje systemu Windows Server
SAC są wydawane w znacznie krótszych odstępach czasu niż jakikolwiek z wcześniejszych
systemów przeznaczonych do serwerów. Kanał obsługi półrocznej powinien udostępniać w każ-
dym roku dwa główne wydania — zwykle wiosną i jesienią. Ze względu na częsty harmonogram
wydań wsparcie dla wersji SAC systemu Windows Server trwa 18 miesięcy. Jeśli używasz
kanału obsługi półrocznej, lepiej przyzwyczaj się do przechodzenia do najnowszej wersji
systemu wkrótce po jej wydaniu.
Jeśli wymiana systemów operacyjnych serwera dwa razy w ciągu roku wydaje Ci się zniechęca-
jącą perspektywą, wiedz, że nie jesteś w tym osamotniony. Na szczęście Microsoft zna ten
problem i zdaje sobie sprawę, że większość administratorów serwerów nie będzie używać
tego modelu w swoich zwykłych serwerach. Wersje SAC systemu Windows Server będą raczej
26
używane tylko do uruchamiania kontenerów. W tym nowym świecie uniwersalnego hostingu

aplikacji, w którym programy są pisane w taki sposób, że ich zasoby infrastrukturalne mogą
być zwiększane lub zmniejszane w razie potrzeby, kontenery są bardzo ważnym elementem
pracy inżyniera DevOps. Jeśli hostujesz lub tworzysz tego rodzaju aplikacje, prawie na pewno
będziesz używać kontenerów — teraz lub w przyszłości. Gdy znajdziesz się w sytuacji, w której
będziesz poszukiwać kontenerów i zastanawiać się nad ich użyciem, prawdopodobnie okaże
się, że najlepszym sposobem na uzyskanie wysoce wydajnego środowiska kontenerowego
jest hostowanie go w serwerze z kanałem obsługi półrocznej.
Kanał obsługi długoterminowej (LTSC)

Prawdopodobnie niektórzy czytelnicy pomyślą, że skrót LTSC zawiera literówkę, ponieważ
w poprzednich latach model wydań nazywał się Long-Term Servicing Branch (LTSB).
Mógłbyś zapewne używać obu tych skrótów, a odpowiednie osoby na ogół wiedziałyby, o czym
mówisz, jednakże obecnie LTSC jest właściwym terminem.
Windows Server 2019 jest wersją z kanałem obsługi długoterminowej (LTSC). Zasadniczo
wersje LTSC są tym, co zawsze uważaliśmy za tradycyjne wersje systemu operacyjnego
Windows Server. Server 2008, Server 2008 R2, Server 2012, Server 2012 R2, Server 2016,
a obecnie Server 2019 są wersjami LTSC. Zmiana polega na tym, że początkowe wersje wydań
LTSC będą teraz wyposażone w mniej elementów, które są jejku, superniesamowite i zupełnie
nowe, ponieważ będziemy otrzymywać wskazówki na temat tych zupełnie nowych składników
w trakcie ich tworzenia i udostępniania w bardziej krótkoterminowych modelach dzięki wyda-
niom SAC. Twoje wydania SAC będą publikowane mniej więcej co 6 miesięcy, a następnie
co 2 lub 3 lata będziemy otrzymywać nowe wydanie LTSC, które będzie zawierać wszystkie
wcześniejsze zmiany dostępne w SAC.
Podczas gdy kanał obsługi półrocznej jest generalnie przeznaczony tylko dla inżynierów
DevOps i kontenerów, serwery działające w trybie LTSC przydają się w zasadzie w każdym
innym przypadku. Jeśli nie chciałbyś instalować kontrolera domeny, serwera certyfikatów
lub serwera plików i następnie wymieniać ich co 6 miesięcy, powinieneś wybrać kanał obsługi
długoterminowej.
Inna główna różnica między zaprezentowanymi powyżej dwoma kanałami polega na tym, że
jeśli chciałbyś korzystać z systemu Windows Server w wersji Desktop Experience (z graficznym
interfejsem służącym do interakcji ze środowiskiem), powinieneś wybrać LTSC. Wersje SAC
systemu Windows Server NIE zawierają opcji Desktop Experience — jesteś ograniczony tylko
do Server Core lub Nano Server.
Dzięki wersjom LTSC systemu Windows Server nadal uzyskujesz ten sam rodzaj wsparcia,
do którego jesteśmy przyzwyczajeni: 5 lat wsparcia podstawowego, a następnie 5 lat dostępnego
wsparcia dodatkowego.
W tej książce będziemy omawiać system Windows Server 2019 w wersji z kanałem obsługi
długoterminowej (LTSC).
27
Przegląd nowych i zaktualizowanych

funkcji
Najnowsza wersja systemu operacyjnego Windows Server jest zawsze rezultatem ewolucji
poprzednika. Na pewno są w tym systemie zawarte technologie, które są zupełnie nowe, ale jest
jeszcze więcej miejsc, w których istniejące technologie zostały uzupełnione o dodatkowe
opcje i funkcje. Poświęćmy kilka minut na zaprezentowanie niektórych nowych funkcji dostęp-
nych w systemie Windows Server 2019.
System Windows 10 wciąż działa

Dawniej każda nowa wersja dowolnego systemu operacyjnego Microsoftu oznaczała konieczność
nauczenia się nowego interfejsu użytkownika, jednakże Server 2019 jest pierwszym wyjąt-
kiem od tej reguły. Wydanie systemu Windows 10 pozwoliło nam zapoznać się z obecną
platformą graficzną, która następnie pojawiła się w systemie Windows Server 2016. Wtedy
po raz pierwszy zobaczyliśmy obecny interfejs na platformie serwerowej. Kolejne aktualizacje
systemu Windows 10 nadal mają zasadniczo ten sam interfejs graficzny — to samo dotyczy
systemu Server 2019. Logowanie się do systemu Windows Server 2019 i korzystanie z niego
jest pod wieloma względami takim samym doświadczeniem jak używanie systemu Windows
Server 2016. Zakładając jednak, że niektórzy czytelnicy nigdy wcześniej nie mieli możliwości
pracy na jakimkolwiek serwerze, postaram się przeanalizować interfejs graficzny, a także za-
prezentuję wskazówki i porady pozwalające na płynne i wydajne poruszanie się po systemie
Server 2019.
Infrastruktura hiperkonwergentna
Gdy napotykasz termin infrastruktura hiperkonwergentna (ang. Hyper-Converged Infra-
structure — HCI), ważne jest, abyś zrozumiał, że nie mówimy o konkretnej technologii istnieją-
cej w środowisku serwera. Infrastruktura hiperkonwergentna jest raczej zbiorem różnych
technologii, które mogą ze sobą współpracować i którymi można zarządzać. Jej celem jest
stworzenie programowalnego centrum danych (ang. Software-Defined Datacenter —
SDDC). HCI jest najczęściej określane jako połączenie funkcji Hyper-V i Storage Spaces
Direct (S2D) w tym samym klastrze serwerów. Klastrowanie tych usług zapewnia duże korzyści
w zakresie szybkości i niezawodności w porównaniu z hostowaniem ich oddzielnie w ich wła-
snych systemach.
Innym komponentem, który jest częścią programowalnego centrum lub jest z nim związany,
jest programowalna sieć komputerowa (ang. Software Defined Networking — SDN). Podobnie
jak wprowadzenie platform do wirtualizacji obliczeń (takich jak Hyper-V) całkowicie zmieniło
sposób przetwarzania danych w serwerach, który jeszcze 10 lat temu wyglądał zupełnie inaczej,
tak obecnie jesteśmy w stanie odłączyć warstwę sieciową od sprzętu fizycznego oraz umieścić
obszary projektowania sieci i administrowania nimi na poziomie wirtualnym zarządzanym
przez system Windows Server.
28
Nowym narzędziem, które pomaga konfigurować i utrzymywać klastry (włączając w to klastry

HCI), a także nimi zarządzać, jest aplikacja Windows Admin Center (WAC). WAC jest centrum
zarządzania, które można podłączyć do infrastruktury hiperkonwergentnej.
Windows Admin Center

Opublikowana oficjalnie aplikacja WAC jest jednym z najciekawszych elementów w obecnym
wydaniu systemu Server 2019. Jest to bezpłatne narzędzie, dostępne dla każdego, którego
można użyć, by centralnie zarządzać infrastrukturą serwera. Chociaż nie jest ono w stanie za-
stąpić wszystkich tradycyjnych narzędzi administracyjnych, takich jak PowerShell, RDP czy
konsola MMC, umożliwia wykonywanie za pomocą jednego interfejsu wielu zwykłych codzien-
nych zadań na serwerach.
Jeśli taka funkcjonalność wydaje Ci się znajoma, może tak być dlatego, że w ciągu ostatniego
roku testowałeś narzędzie o nazwie Project Honolulu. Zgadza się — Windows Admin Center to
Project Honolulu, obecnie udostępniony do publicznego użytkowania.
Aplikacji Windows Admin Center przyjrzymy się bliżej w rozdziale 2., „Instalowanie systemu
Windows Server 2019 i zarządzanie nim”.
Windows Defender Advanced Threat Protection

Może do tej pory nie wiedziałeś nic na temat zaawansowanej ochrony przed zagrożeniami
(ang. Advanced Threat Protection — ATP), w tytule widzisz jednak słowa Windows Defender
i możesz założyć, że mam na myśli po prostu opcje antywirusowe lub zabezpieczające przed
szkodliwymi programami (malware), które są od 2016 roku wbudowane w oba systemy ope-
racyjne Windows — kliencki i serwerowy. Chociaż to prawda, że Windows Server 2019 ma
wbudowane oprogramowanie antywirusowe, usługa ATP jest czymś znacznie więcej.
Omówimy ją dokładniej w rozdziale 7., „Hardening i bezpieczeństwo”, ale można w skrócie

stwierdzić, że Windows Defender Advanced Threat Protection to usługa oparta na chmurze,
do której podłączasz swoje maszyny. Potęgą ATP jest to, że wiele tysięcy urządzeń, a może
nawet miliony, przesyła dane i tworzy ogromny magazyn informacji, który dzięki sztucznej
inteligencji i uczeniu maszynowemu można następnie wykorzystać do generowania w czasie
rzeczywistym kompleksowych informacji o nowych zagrożeniach, wirusach i włamaniach.
Klienci ATP uzyskują odpowiednio wzmocnioną ochronę w miarę pojawiania się nowych
problemów. To prawie tak jak opcje przeciwdziałania zagrożeniom uzyskiwane na podstawie
analizy zachowań tłumu, z platformą Azure obsługującą całe przetwarzanie w tle.
Hasła zabronione
Usługa katalogowa Active Directory (AD) od wielu lat przechowuje wszystkie informacje
o koncie użytkownika, w tym hasła. W ostatnich kilku wersjach systemu operacyjnego Windows
Server nie dodano zbyt dużo uaktualnień ani nowych funkcji do AD, jednakże Microsoft
29
obsługuje obecnie wielu klientów w opartym na chmurze środowisku Azure AD, w którym
są uruchamiane nowe funkcje. Hasła zabronione to jedna z nich. Były one kiedyś opcją dostępną
w usłudze Azure AD, a teraz można ją zsynchronizować z lokalnymi serwerami kontrolerów
domeny, co daje możliwość utworzenia listy haseł, których użytkownicy nie mogą w żaden
sposób używać. Weźmy przykładowo słowo hasło. Zakazem użycia słowa hasło jako hasła sku-
tecznie zabezpieczasz się przed każdym hasłem zawierającym słowo hasło. Mogą to być na
przykład słowa H@sło, Hasło123! lub cokolwiek innego o podobnym znaczeniu.
Miękki restart
Możliwość wykonania miękkiego restartu była nową opcją w wersji systemu Server 2016,
ale administrator, aby ją aktywować, musiał dodać ją jawnie i nie sądzę, by ktokolwiek naprawdę
zaczął jej używać. W ciągu ostatnich 3 lat nigdy nie widziałem, aby ktoś zainicjował miękki
restart, więc zakładam, że nie jest to opcja dobrze znana, i dlatego umieszczę ją na naszej
liście funkcji. Aby przyspieszyć ponowne uruchomienie, udostępniono opcjonalny przełącznik
zwany miękkim restartem, który jest obecnie automatycznie zawarty w wersji Server 2019.
Czym jest miękki restart? Jest to restart bez inicjalizowania sprzętu.
Inaczej mówiąc, restartuje on system operacyjny bez restartowania całego komputera. Jest
on aktywowany przez dodanie specjalnego przełącznika do polecenia shutdown. Co ciekawe,
w wersji Server 2016 można również wywołać miękki restart za pomocą polecenia cmdlet
Restart-Computer w powłoce PowerShell, ale ta opcja prawdopodobnie nie zadziała w systemie
Server 2019. Jeśli więc chcesz przyspieszyć ponowne uruchomienie, musisz wrócić do starego
dobrego wiersza poleceń, jak zaprezentowano poniżej (zwróć uwagę na użyte opcje):
shutdown /r /soft /t 0
Opcja /r oznacza restart, /soft odpowiada miękkiemu restartowi, a /t 0 oznacza odstęp czasowy
równy 0 sekund przed rozpoczęciem restartu.
Integracja z Linuksem
Herezja! Kto upoważnił mnie do użycia słowa Linux w książce o systemie Windows Server?!
Dawniej w korporacyjnych środowiskach komputerowych działał system Windows albo Linux,
a czasami oba jednocześnie, jednakże wyraźnie oddzielone od siebie. Windows Server 2019
zaciera tę linię podziału. Obecnie mamy możliwość uruchamiania maszyn wirtualnych systemu
Linux w ramach Microsoft Hyper-V, a nawet poprawnego komunikowania się z nimi. Czy wiesz,
że niektóre systemy operacyjne Linux potrafią obsługiwać mysz? Wcześniej nie miałeś dużej
szansy, by to sprawdzić, próbując uruchomić w systemie Windows Server maszynę wirtualną
opartą na Linuksie, jednakże teraz w hiperwizorze Hyper-V jest zaimplementowana pewna
kompatybilność.
Kontenery oparte na systemie Linux można również uruchamiać w środowisku Server 2019,
co jest dużą zaletą dla każdego administratora, który chce wdrażać aplikacje skalujące za pośred-
nictwem kontenerów.
30
Możesz także zabezpieczać swoje systemy Linux przez szyfrowanie ich za pomocą chronio-
nych maszyn wirtualnych!
Ulepszona funkcja Shielded Virtual Machines

W bardzo wielu firmach większość serwerów stanowią maszyny wirtualne, ale jednym z du-
żych problemów tego rozwiązania jest to, że na platformach hostów wirtualizacji istnieją luki
zabezpieczeń. Jedną z tych luk jest dostęp typu backdoor do plików znajdujących się na
dyskach maszyn wirtualnych. Każdy, kto ma uprawnienia administracyjne do hosta wirtuali-
zacji, może w prosty sposób zobaczyć, zmodyfikować lub uszkodzić dowolną maszynę wirtu-
alną działającą na nim. Co gorsza, takie modyfikacje mogą być prawie niemożliwe do wykrycia.
Zapoznaj się z treścią rozdziału 12., „Wirtualizacja centrum danych za pomocą hiperwizora
Hyper-V”, aby dowiedzieć się, w jaki sposób nowa funkcja tworzenia chronionych maszyn
wirtualnych (ang. Shielded Virtual Machines) zamyka tę lukę w zabezpieczeniach przez
wdrożenie pełnego szyfrowania dysku dla plików VHD.
System Server 2019 zapewnia określone korzyści dla świata chronionych maszyn wirtual-
nych: możemy obecnie chronić maszyny wirtualne zarówno z systemem Windows, jak też
Linux i nie jesteśmy już tak zależni od komunikacji z usługą Host Guardian Service podczas
próby uruchamiania chronionych maszyn wirtualnych znajdujących się na hostach chronio-
nych. Omówimy to szerzej w rozdziale 12.
Azure Network Adapter

Chmura hybrydowa — czy nie jest wspaniale, gdy możesz użyć dwóch popularnych słów i połą-
czyć je ze sobą, aby stworzyć jeszcze bardziej modny termin? Chmura hybrydowa to marzenie
szefa działu IT. Oczywiście trochę żartuję; idea chmury hybrydowej jest niezwykle potężna,
ponieważ jest pomostem umożliwiającym korzystanie z chmury. Możemy używać zarówno
serwerów lokalnych, jak i serwerów hostowanych na platformie Azure, dzięki czemu uzyskujemy
jedną wielką i szczęśliwą sieć, w której można otrzymać dostęp do dowolnego zasobu z dowol-
nego miejsca.
Obecnie istnieje już niezliczona liczba technologii, które umożliwiają podłączenie sieci lokalnej
do sieci Azure. Są to sieci VPN typu lokacja-lokacja i Azure Express Route. Jednakże od
przybytku głowa nie boli, szczególnie w przypadku małych firm, które nie chcą stawiać czoła
złożoności tworzenia sieci VPN typu lokacja-lokacja ani ponosić kosztów Express Route.
Użyj rozwiązania Azure Network Adapter. Ta nowa funkcja pozwala bardzo szybko i łatwo
dodać wirtualną kartę sieciową do systemu Windows Server (nawet do takiego jak 2012 R2),
a następnie podłączyć ją bezpośrednio do sieci platformy Azure! Jest do tego wymagana aplikacja
Windows Admin Center; przyjrzymy się temu bliżej w rozdziale 5., „Obsługa sieci w Windows
Server 2019”.
31
Always On VPN
Użytkownicy nienawidzą nawiązywania połączeń VPN. Wiem o tym, ponieważ codziennie
słyszę tego rodzaju uwagi. Konieczność ręcznego nawiązania połączenia z siecią służbową to
strata czasu, który można byłoby wykorzystać do wykonywania rzeczywistej pracy. W roz-
dziale 6., „Użycie opcji zdalnego dostępu”, omówimy różne technologie zdalnego dostępu
zawarte w systemie Windows Server 2019. W rzeczywistości są dwie różne technologie, które
umożliwiają w pełni automatyczne połączenie do sieci korporacyjnej bez zmuszania użytkowni-
ków do wykonywania jakichkolwiek działań. Jedną z nich jest DirectAccess, dostępna od
wersji Server 2008 R2. Omówimy ją szczegółowo, ponieważ jest to wciąż realna i popularna
opcja połączenia. Zaprezentujemy także najnowszą wersję zautomatyzowanej łączności zdalnej
— Always On VPN.
Poruszanie się po interfejsie

Niestety, firma Microsoft zniechęciła wiele osób, wprowadzając systemy Windows 8 i Server 2012,
jednakże nie z powodu tego, że brakowało im jakichś ważnych funkcji lub niezawodności,
lecz dlatego, że interfejs był zupełnie odmienny od poprzednich. To było prawie jak jedno-
czesne uruchamianie dwóch oddzielnych systemów operacyjnych. W zwykły sposób korzy-
stałeś z pulpitu, na którym wszyscy spędzaliśmy 99,9% swojego czasu, więc bardzo rzadko
pojawiały się sytuacje, w których musiałeś odwiedzić menu Start. Bardziej prawdopodobne
było to, że uruchamiałeś je przypadkowo. Bez względu na to, jak tam trafiłeś, przez pozo-
stałą 0,01% czasu pracy z systemem Server 2012 na tym pełnoekranowym interfejsie przy-
pominającym tablet byłeś zdezorientowany i zaniepokojony oraz chciałeś się znaleźć z powrotem
na tradycyjnym pulpicie. Mówię tu oczywiście wyłącznie o własnych doświadczeniach. Mogą
występować różnice w ilości czasu spędzonego w menu Start, ale na podstawie rozmów z użyt-
kownikami jestem pewien, że nie jestem osamotniony w swoich poglądach. Już nie mówię o ma-
gicznie pojawiającym się pasku Charms-Bar. Niektóre złe wspomnienia lepiej ukryć głęboko
w zakamarkach mózgu.
Główna aktualizacja systemów Windows 8.1 i Server 2012 R2 znacząco zmniejszyła poziom
stresu. W lewym dolnym narożniku ekranu znów pojawił się przycisk Start, a oprócz tego
mogłeś wybrać, by system uruchomił się w normalnym trybie pulpitu. Jednak jeśli kiedy-
kolwiek musiałbyś kliknąć przycisk Start, znalazłbyś się z powrotem na pełnym ekranie me-
nu Start, którego prawie wszyscy administratorzy serwerów starają się cały czas za wszelką
cenę unikać.
Okazuje się, że Microsoft wysłuchał użytkowników i odpowiednio zreorganizował interfejs

w systemach Windows 10 i Windows Server 2016. Chociaż niezupełnie wróciliśmy do tradycyj-
nego menu Start, które istniało w 2008 roku, mamy obecnie do dyspozycji dobre połączenie
zarówno starych, jak i nowych sposobów uruchamiania narzędzi, do których musimy uzyskać do-
stęp na swoich platformach serwerowych.
32
Jeśli chodzi o interfejs graficzny, Windows Server 2019 niewiele różni się od środowiska
Server 2016, ponieważ w systemie operacyjnym klienta nie było żadnej poważnej aktualizacji
tego interfejsu. Jak już wiesz, każda nowa wersja systemu Windows Server otrzymuje aktualiza-
cje interfejsu typu „wskaż i kliknij”, takie same jak w najnowszym systemie operacyjnym
klienta Windows. Po raz pierwszy od wielu lat zdarzyło się, że została wydana kolejna wersja
serwerowego systemu operacyjnego, podczas gdy wersja systemu operacyjnego klienta pozostała
niezmieniona — Windows 10. Jeśli więc nie masz problemów z poruszaniem się po systemie
Windows 10, łatwo się odnajdziesz w systemie Windows Server 2019.
Poniższy punkt będzie przydatny dla tych, którzy dopiero rozpoczynają pracę w systemie
Windows lub szukają odpowiednich wskazówek, które mogłyby ją ułatwić.
Uaktualnione menu Start

Wraz z wprowadzeniem wersji systemu Windows 10 nastąpiły niewielkie zmiany w menu Start.
Wydaje się, że wiele wcześniejszych modyfikacji jest wycofywanych z powodu fiaska systemu
Windows 8. Wróciliśmy obecnie do prawdziwego przycisku Start, który uruchamia prawdziwe
menu Start, niezajmujące całej powierzchni pulpitu. Szczerze mówiąc, prawie nigdy nie otwie-
ram menu Start, z wyjątkiem wyszukiwania aplikacji lub funkcji, których chcę użyć. Wkrótce
opowiem więcej na ten temat. Gdy jednak otwieram menu Start i przyglądam mu się, mogę
sformułować kilka ciekawych spostrzeżeń:
 Wszystkie aplikacje zainstalowane na serwerze są wymienione w kolejności
alfabetycznej. Jest to bardzo przydatne do uruchamiania programów lub szybkiego
sprawdzania, czy dana aplikacja lub funkcja znajduje się na serwerze.
 Lewa strona menu Start zawiera kilka przycisków umożliwiających szybki dostęp
do pewnych elementów. Prawdopodobnie najbardziej przydatne są te, które służą
do wyłączania lub ponownego uruchamiania serwera, oraz ikona Settings (Ustawienia)
w kształcie kółka zębatego, która uruchamia okno z ustawieniami systemowymi.
 Domyślnie prawa strona menu Start pokazuje większe przyciski, czasami nazywane
żywymi kafelkami. Możliwość przypinania w tym miejscu elementów, z których
często się korzysta, pozwala łatwo je odnajdywać. Większe przyciski są przydatne,
gdy kontrolujesz serwer za pomocą laptopa z ekranem dotykowym lub innego
podobnego urządzenia.
Te trzy funkcje możesz zobaczyć na zrzucie ekranu na następnej stronie.
To jest faktycznie powiew świeżego powietrza. Proste, ale przydatne menu Start i, co ważniejsze,
uruchamiające się szybko przez połączenia zdalne, takie jak konsola RDP lub Hyper-V.
33
Menu szybkich zadań administracyjnych

Mimo że miło jest mieć funkcjonalne menu Start, jako administrator serwera nadal bardzo
rzadko w codziennej pracy potrzebuję dostępu do niego. Jest tak, ponieważ wiele elementów,
do których muszę uzyskać dostęp, znajduje się w menu szybkich zadań, które otwiera się po
prostu po kliknięciu przycisku Start prawym przyciskiem myszy. To menu jest dostępne od
czasu wydania systemu Windows 8, ale wielu specjalistów IT wciąż nie jest tego świadomych.
Stało się ono ważną częścią mojej interakcji z systemami operacyjnymi Windows Server i mam
nadzieję, że będzie przydatne również dla Ciebie. Kliknięcie przycisku Start prawym przyci-
skiem myszy powoduje natychmiastowe wyświetlenie szybkich łączy do takich elementów,
34
jak Event Viewer (Podgląd zdarzeń), System, Device Manager (Menedżer urządzeń), a nawet
umożliwia zamykanie lub ponowne uruchamianie serwera. Dwie najczęściej używane opcje,
które wykorzystuję w tym menu kontekstowym, to funkcja Run (Uruchom) i uruchamianie po-
włoki PowerShell. Jeszcze lepsza jest zdolność tego menu do otwierania programu PowerShell
z uprawnieniami zwykłego użytkownika oraz z podwyższonym, czyli administracyjnym, po-
ziomem uprawnień. Właściwe użycie tego menu oszczędza wiele kliknięć myszą i skraca czas
rozwiązywania problemów.
Menu to można wywołać również za pomocą skrótu klawiszowego WinKey+X!
35
Używanie funkcji wyszukiwania

Chociaż menu szybkich zadań administracyjnych ukryte pod przyciskiem Start jest przydatne
do wykonywania typowych zadań administracyjnych, korzystanie z funkcji wyszukiwania jest
potężnym narzędziem do łączenia się dosłownie ze wszystkim w systemie Windows Server.
W zależności od tego, kto zainstalował aplikacje i role na serwerach, możesz mieć w menu Start
dostępne odpowiednie skróty do uruchamiania. Mogą także istnieć skróty do pulpitu lub łącza
do otwierania programów z paska zadań. Uważam, że często trudno jest znaleźć określone
ustawienia, które mogą wymagać dostosowania, aby nasze serwery zaczęły działać tak, jak tego
chcemy. W nowszych wersjach systemu Windows okno Control Panel (Panel sterowania) jest
powoli zastępowane przez bardziej nowoczesne menu Settings (Ustawienia), co czasami powo-
duje, że dostęp do określonych ustawień jest trudny. Wszystkie te problemy można rozwią-
zać za pomocą paska wyszukiwania w menu Start. Po kliknięciu przycisku Start lub, jeszcze
łatwiej, naciśnięciu klawisza Windows (WinKey) na klawiaturze możesz po prostu zacząć wpisy-
wać nazwę dowolnego programu, ustawienia lub dokumentu, który chcesz otworzyć. Pasek
wyszukiwania przeszuka wszystko na Twoim serwerze lokalnym i wyświetli odpowiednią aplika-
cję, ustawienie, a nawet dokument.
Oto najprostszy przykład użycia paska wyszukiwania: naciśnij klawisz WinKey na klawiaturze,
a następnie wpisz słowo notepad i naciśnij klawisz Enter. Zobaczysz, że stary, dobry notatnik
otwiera się właśnie przed Tobą. Nie musieliśmy wcale przeszukiwać folderu Program Files, aby
go znaleźć i otworzyć. W rzeczywistości nawet nie dotknęliśmy myszy, co jest muzyką dla uszu
kogoś takiego jak ja, który uwielbia wykonywać wszystko, co możliwe, z użyciem klawiatury:
Jeszcze lepszym przykładem jest wyszukanie czegoś, co zostało schowane dość głęboko w usta-
wieniach lub panelu sterowania. Co powiesz na zmianę czasu, po którego upływie ekran prze-
chodzi w tryb oszczędzania energii i sam się wyłącza? Tradycyjny administrator serwera
otworzy Control Panel (Panel sterowania — jeśli będzie go mógł znaleźć), następnie prawdopo-
dobnie przejdzie do sekcji Appearance and Personalization (Wygląd i personalizacja), ponieważ
nic innego nie wydaje się choćby w miarę odpowiednie, a wciąż nie znajdzie tego, czego
36
szukał. Po kilku minutach wyszukiwania zacznie myśleć, że Microsoft po prostu zapomniał

dodać to ustawienie. Niestety, te ustawienia zasilania zostały przeniesione do nowego kontenera
i nie są już dostępne za pośrednictwem panelu sterowania. W tym rozdziale omówimy za
chwilę nowy ekran Settings (Ustawienia), ale wróćmy jeszcze do naszego przykładu: utknąłeś
podczas wyszukiwania ustawienia, które chcesz zmienić. Czy istnieje szybkie rozwiązanie tego
problemu? Naciśnij klawisz WinKey, aby otworzyć menu Start, i wpisz słowo screen (lub
power albo cokolwiek innego, co dotyczyłoby szukanego ustawienia). Na liście dostępnych
opcji w menu wyszukiwania będziesz mógł zobaczyć wiersz o nazwie Choose when to turn
off the screen (Wybierz czas wyłączenia ekranu). Kliknij ten wiersz, a znajdziesz ustawienie,
którego szukałeś przez cały czas:
Zauważysz również, że na ekranie wyszukiwania pojawiło się znacznie więcej opcji, niż się spo-
dziewałeś. Wyszukiwanie wyświetliło wiele różnych elementów, z których każdy był związany
z podanym przeze mnie słowem screen. Nie znam bardziej skutecznego sposobu otwierania
aplikacji lub ustawień w systemie Windows Server 2019 niż używanie paska wyszukiwania
wewnątrz menu Start. Wypróbuj go jeszcze dziś!
Przypinanie programów do paska zadań

Chociaż system Windows Server 2019 zapewnia doskonałe możliwości wyszukiwania, dzięki
czemu uruchamianie trudnych do znalezienia aplikacji jest bardzo łatwe, czasami prościej
jest mieć szybkie skróty do często używanych elementów, które będą wywoływane przez
pojedyncze kliknięcie odpowiedniej ikony na tradycyjnym pasku zadań. Bez względu na to,
czy szukałeś konkretnej aplikacji, przeglądając menu Start, czy też używałeś funkcji wyszu-
kiwania, by znaleźć wybrany program, możesz po prostu kliknąć prawym przyciskiem myszy
odnaleziony element i z menu podręcznego wybrać opcję Pin to taskbar (Przypnij do paska
zadań), aby utworzyć stały skrót na pasku zadań u dołu ekranu. Gdy to zrobisz, podczas następ-
nych sesji pracy na serwerze Twoje ulubione i najczęściej używane aplikacje będą czekać na
uruchomienie za pomocą pojedynczego kliknięcia myszy. Jak widać na poniższym zrzucie ekranu,
masz także możliwość przypięcia programów do menu Start, które oczywiście jest kolejnym
przydatnym miejscem pozwalającym na ich regularne uruchamianie:
37
Wielu czytelników jest już na pewno bardzo dobrze zaznajomionych z procesem przypinania
programów do paska zadań, więc przejdźmy o krok dalej, aby przedstawić dodatkową funkcję
związaną z przypiętymi aplikacjami, której możesz jeszcze nie znać.
Potęga klikania prawym przyciskiem myszy

Wszyscy dobrze wiemy, że kliknięcie prawym przyciskiem myszy w dowolnym obszarze
systemu operacyjnego Windows pozwala uzyskać dostęp do bardziej zaawansowanych funkcji.
Od początku istnienia myszy komputerowej tworzono w programach niewielkie menu kon-
tekstowe wyświetlane po kliknięciu prawym przyciskiem. Często klikamy prawym przyci-
skiem myszy, aby skopiować tekst lub dokumenty, wkleić je lub uzyskać bardziej zaawansowany
zestaw właściwości dla określonego pliku lub folderu. Za pomocą tego przycisku można wy-
konywać wiele codziennych zadań. Chciałbym zwrócić uwagę na to, że twórcy oprogramowania,
na przykład firma Microsoft i inne, zwiększają funkcjonalność operacji klikania aplikacji prawym
przyciskiem myszy, więc tym lepiej mieć pod ręką często używane programy, na przykład na pa-
sku zadań.
Liczba funkcji dostępnych po kliknięciu aplikacji prawym przyciskiem myszy na pasku zadań
różni się w zależności od aplikacji. Na przykład, jeśli kliknę prawym przyciskiem myszy
Command Prompt (Wiersz polecenia), zostaną wyświetlone opcje pozwalające na uruchomienie
tego programu lub odpięcie go od paska zadań — Unpin from taskbar (Odepnij od paska zadań).
Jak widać, są to bardzo proste działania. Jeśli kliknę teraz prawym przyciskiem myszy opcję
menu Command Prompt, będę miał dostęp do tych samych funkcji co poprzednio, ale mogę także
wybrać Properties (Właściwości) lub Run as administrator (Uruchom jako administrator).
Im głębiej wchodzę, tym bardziej zyskuję na funkcjonalności (zobacz pierwszy rysunek na
następnej stronie).
W przypadku innych programów zobaczysz jednakże więcej wyników. Im częściej korzystasz

z serwerów, tym więcej danych i opcji zaczniesz widzieć w menu kontekstowym po kliknięciu
prawym przyciskiem myszy. Dwa świetne przykłady to Notepad (Notatnik) i Remote Desktop
Client (Klient pulpitu zdalnego). Na swoim serwerze pracowałem nad kilkoma tekstowymi plika-
mi konfiguracyjnymi, a dodatkowo przełączałem się na inne serwery w celu wykonywania
niektórych zdalnych zadań. Tę drugą czynność wykonywałem za pomocą klienta pulpitu
zdalnego. Gdy klikam prawym przyciskiem myszy aplikację Notepad przypiętą do paska zadań,
uzyskuję łatwo dostępne łącza do najnowszych dokumentów, nad którymi pracowałem (zo-
bacz drugi rysunek na następnej stronie).
38
Obecnie po kliknięciu ikony RDP prawym przyciskiem myszy mam na liście łącza do ostatnio
odwiedzonych serwerów. Nie wiem, czy Ty tak postępujesz, ale ja codziennie uruchamiam
sesje RDP do wielu różnych serwerów. Dzięki temu, że mam odnośnik do klienta pulpitu zdal-
nego na pasku zadań, automatycznie zapamiętuje on serwery, które ostatnio odwiedziłem, co zde-
cydowanie oszczędza mi czas oraz kliknięcia myszą podczas wykonywania codziennych zadań
(zobacz rysunek na następnej stronie).
Funkcje klikania prawym przyciskiem myszy istnieją już od kilku wersji systemu operacyjnego,
więc nie jest to nowa technologia, jednak jest ona regularnie ulepszana w miarę wydawania
nowych wersji aplikacji. Omawiamy ją w tej książce również dlatego, że korzysta z niej niewielu
administratorów serwerów. Być może powinni oni zacząć jej używać, aby wydajniej pracować.
39
Inna funkcja, która została ulepszona na platformach Windows 10 oraz Server 2019 i również jest
bardzo przydatna w codziennej pracy, to widok Quick access (Szybki dostęp), domyślnie wyświe-
tlany po otwarciu aplikacji File Explorer (Eksplorator plików). Wszyscy od dawna znamy
eksploratora plików i używamy go, ale zazwyczaj, gdy chcemy dostać się do określonego miej-
sca na dysku twardym lub do jakiegoś pliku, musimy wykonać wiele kliknięć myszą, aby osiągnąć
docelowy rezultat. Widok szybkiego dostępu w systemie Windows Server 2019 natychmiast
wyświetla zarówno najnowsze, jak i często używane pliki oraz foldery, do których zwykle
uzyskujemy dostęp z serwera. Jako administratorzy często musimy odwiedzać te same miej-
sca na dysku twardym i wielokrotnie otwierać te same pliki. Czy nie byłoby wspaniale, gdyby
eksplorator plików umieścił wszystkie popularne lokalizacje i łącza do plików w jednym
miejscu? Właśnie tak działa widok szybkiego dostępu.
Na poniższym zrzucie ekranu widzimy, że otwarcie eksploratora plików zapewnia szybki dostęp
do łączy do zarówno często używanych folderów, jak i najnowszych plików. Użycie takiej funkcji
może się wiązać z oszczędnością czasu, dlatego regularne korzystanie z niej pozwala na zwięk-
szenie wydajności pracy, a także udowadnia kolegom i innym osobom znajdującym się w pobliżu,
że bardzo dobrze znasz najnowszą wersję systemu operacyjnego i umiesz ją obsługiwać (zo-
bacz rysunek na następnej stronie).
Korzystanie z nowszego ekranu Settings

Jeśli pracujesz w dziale IT i od jakiegoś czasu używasz systemu Windows 10 na komputerze
klienckim, założę się, że na pewno natknąłeś się na nowy interfejs Settings (Ustawienia) —
być może przypadkowo, jak ja, gdy go po raz pierwszy zobaczyłem. Wiele osób uruchamia in-
terfejs ustawień podczas próby wyświetlenia lub skonfigurowania aktualizacji Windows. Ten
interfejs w systemie Windows Server 2019 zawiera po prostu to, o czym mówi jego nazwa —
konfigurujesz w nim różne ustawienia w systemie operacyjnym. Co jest w nim takiego trudnego
lub mylącego? Cóż, mamy już platformę do zarządzania wszystkimi ustawieniami zawartymi
w systemie Windows, która istnieje od miliardów lat. To Control Panel (Panel sterowania).
40
Menu Settings w Windows nie jest zupełnie nowym pomysłem, ale wydaje się całkiem świeżą
rzeczą w porównaniu z panelem sterowania. Windows Server 2012 i 2012 R2 miały coś w ro-
dzaju okna ustawień, które jednak, o ile mi wiadomo, nie było prawie wcale używane przez
administratorów systemów. Uważam, że to wynik złego wykonania; otóż menu ustawień w wersji
Windows 2012 było ukryte za paskiem Charms (Zaklęcia), co zdaniem większości ludzi nie
miało sensu. Nie poświęcimy zbyt wiele czasu na technologię pochodzącą z przeszłości, ale
chciałbym, abyś wiedział, że pasek Charms w systemie Server 2012 był pewnym rodzajem
menu, które pojawiało się po przesunięciu palca z prawej krawędzi ekranu. Tak, masz rację —
serwery zwykle nie mają ekranów dotykowych. Nie spotkałem go na żadnym serwerze spośród
tych, które kiedykolwiek obsługiwałem. Jednak pasek Charms wyświetlał się również po
przemieszczeniu kursora myszy w okolice prawego górnego narożnika ekranu. Dostęp do niego
był dość trudny, ale miał on tendencję do pojawiania się, kiedy akurat tego nie chciałeś, na
przykład gdy próbowałeś kliknąć coś po prawej stronie pulpitu i zamiast tego kliknąłeś jakiś
element na pasku Charms, który nagle się pojawił.
Podaję tylko ogólne informacje, aby przejść do następnego pomysłu. Znaczną część interfejsu
użytkownika w systemie Windows 10, a zatem także w systemach Windows Server 2016 i 2019,
można uznać za mały krok wstecz w dziedzinie obsługi palcami i ekranów dotykowych. Win-
dows 8 i Server 2012 były tak bardzo skoncentrowane na obsłudze palcami dużych kafelków
aplikacji, że wiele osób pogubiło się w tym wszystkim. Różniło się to bardzo od tego, co widzieli-
śmy wcześniej, i było trudne do użycia na poziomie administracyjnym. Opinie otrzymane
od użytkowników sprawiły, że interfejs graficzny i kontrolki w systemie Windows Server 2019
41
(w tym zarówno menu Start, jak i menu Settings) można umieścić gdzieś pomiędzy systemem
Server 2008 a Server 2012. Ten krok wstecz był właściwy i na razie nie słyszałem nic innego
oprócz pochwał za nowy interfejs użytkownika.
Wracając do menu Settings: jeśli klikniesz przycisk Start, a następnie małą ikonę koła zębatego
tuż nad przyciskami zasilania, zobaczysz nowy interfejs:
Jest wiele ustawień i elementów systemu operacyjnego, które można skonfigurować w nowym
menu Settings. Niektóre ustawienia systemu Windows istnieją obecnie wyłącznie w tym interfejsie,
ale do wielu nadal można uzyskać dostęp zarówno z niego, jak i za pośrednictwem tradycyjnego
panelu sterowania. Wydaje się, że celem jest przejście w przyszłych wydaniach do konfiguro-
wania tylko za pomocą nowego menu. Na razie możemy jednak wciąż zarządzać większością
ustawień za pomocą swoich tradycyjnych metod, jeśli tak zdecydujemy. Wspomniałem wcześniej
o aktualizacjach systemu Windows i jest to dobry przykład do przeanalizowania. Tradycyjnie
konfigurowalibyśmy swoje ustawienia aktualizacji Windows za pomocą panelu sterowania,
ale w systemie Windows Server 2019 zostały one całkowicie przeniesione do nowego menu
ustawień. Wyszukaj w panelu sterowania słowa Windows Update, a jedynym wynikiem będą
obecnie zainstalowane aktualizacje. Jeśli jednak przeszukasz nowe menu Settings przy użyciu
tych samych słów, od razu znajdziesz opcje związane z aktualizacjami Windows.
42
Pamiętaj, że dowolne ustawienie zawsze możesz znaleźć za pomocą funkcji wyszu-

kiwania systemu Windows! Naciśnij klawisz WinKey, a następnie wpisz Windows Update,
a otrzymasz łącza, które prowadzą bezpośrednio do odpowiednich pozycji menu Settings.
Niekiedy będziesz musiał użyć kombinacji panelu sterowania i menu ustawień, aby wyko-
nać swoją pracę. Czasami jest to mylące. Czasem nawet klikniesz coś w menu Settings, a otworzy
się okno Control Panel! Wypróbuj to. Otwórz menu Settings i kliknij Network & Internet
(Sieć i Internet). Kliknij opcję Ethernet w lewej kolumnie. W tym miejscu możesz zobaczyć
status swoich kart sieciowych, ale nie możesz nic zmodyfikować, na przykład zmienić adresu
IP. Następnie zauważysz łącze Change adapter options (Zmień opcje karty). Tak, to wygląda już
znacznie ciekawiej. Kliknij to łącze, a przejdziesz do tradycyjnego ekranu Network Connections
(Połączenia sieciowe) o wyglądzie i stylu panelu sterowania:
Dwie metody wykonania tej samej czynności

Potencjalnie mylące (dopóki się nie przyzwyczaisz) może być to, że czasami to samo zadanie
można wykonać w panelu sterowania lub menu ustawień, jednakże sposób jego realizacji może
być zupełnie odmienny. Sprawdźmy to, próbując utworzyć nowe konto użytkownika na naszym
serwerze — pierwszy raz za pomocą panelu sterowania, a następnie za pomocą ustawień.
43
Tworzenie nowego użytkownika za pomocą panelu sterowania

Prawdopodobnie jesteś z tym dobrze zaznajomiony. Otwórz Control Panel, a następnie kliknij
opcję User Accounts (Konta użytkowników). Następnie kliknij nagłówek User Accounts. Teraz
kliknij łącze Manage another account (Zarządzaj innym kontem). W oknie wyświetli się opcja
Add a user account (Dodaj konto użytkownika). Kliknij ją, a pojawi się okno dialogowe, w którym
wprowadzisz nazwę nowego użytkownika i jego hasło:
Tworzenie nowego użytkownika za pomocą menu ustawień

Przetestujmy nowszy interfejs ustawień. Otwórz menu Settings i kliknij opcję Accounts (Konta).
Teraz kliknij opcję Other users (Inni użytkownicy) w lewej kolumnie. Znajduje się tu łącze
Add someone else to this PC (Dodaj kogoś innego do tego komputera); kliknij je bez wahania
(zobacz rysunek na następnej stronie).
Co się dzieje? Niestety, nie tego się spodziewałem. Ku mojemu zaskoczeniu stary panel sterowa-
nia uruchamia ładny, świeżo wyglądający interfejs, z którego mogę tworzyć nowe konta użyt-
kowników. Z drugiej strony dostęp do kont użytkowników za pośrednictwem nowszej konsoli
ustawień przenosi mnie do starego interfejsu Local Users and Groups (Użytkownicy i grupy
lokalne). Technicznie rzecz biorąc, za jego pomocą mógłbym bez problemu założyć nowe konto
użytkownika, ale wygląda na to, że występuje tutaj pewna niespójność. Oczywiście, miałeś
nadzieję, że nowy interfejs Settings wywoła nowszy, ładniejszy ekran dodawania kont użytkowni-
ków, jednak okazało się, że jest odwrotnie.
Zaprezentowaliśmy prosty przykład wykonania tej samej funkcji z użyciem dwóch różnych
interfejsów, aby pokazać, że istnieją pewne elementy, które można (i trzeba) wykonać w nowym
kontekście menu Settings. W systemie Windows jest jednak jeszcze wiele funkcji, które wciąż
44
należy wykonywać za pomocą tradycyjnych interfejsów. Mimo że panel sterowania nadal

jest dostępny i prawdopodobnie będzie istnieć przez bardzo długi czas, powinieneś zacząć po-
ruszać się po menu ustawień i zdobywać wiedzę o tym, co się w nim znajduje, abyś mógł zacząć
jak najlepiej łączyć oba światy w celu skutecznego zarządzania serwerami.
Jeszcze jedna i zarazem ostatnia sprawa, na którą powinieneś zwrócić uwagę, gdy już za-
czniesz swobodnie obsługiwać menu Settings: wiele parametrów, które konfigurujemy na
swoich serwerach, to ustawienia typu „włącz i wyłącz”. Oznacza to, że mamy do dyspozycji
dwie opcje, z których wybieramy jedną. Dawniej tego rodzaju ustawienia były obsługiwane
przez rozwijane menu lub przyciski radiowe. Jest to normalne, jest to oczekiwane — to jest
Windows. W nowej wersji serwera zauważysz jednak małe paski przeciągania lub suwaki
podobne do wyłącznika światła, które pozwalają włączać i wyłączać ustawienia. Każdy, kto korzy-
stał z interfejsu ustawień w dowolnym smartfonie, wie dokładnie, co mam na myśli. To zacho-
wanie interfejsu użytkownika znalazło zastosowanie w systemach operacyjnych Windows
i prawdopodobnie już w nich pozostanie. Aby dać Ci wyobrażenie o tym, jak to wygląda
w kontekście nowego menu Settings, poniżej umieszczam zrzut obecnego ekranu ustawień
Windows Update, dostępnego w opcji Update & Security (Aktualizacja i zabezpieczenia).
To dobry przykład użycia suwaków służących do włączania i wyłączania:
45
Menedżer zadań
Task Manager (Menedżer zadań) to narzędzie, które było dostępne we wszystkich systemach
operacyjnych Windows od pierwszych dni interfejsu graficznego, ale zarazem przez lata ewolu-
owało. Jednym z celów Windows Server 2019 jest bycie systemem jeszcze bardziej użytecznym
i niezawodnym niż jakakolwiek poprzednia wersja. Ma więc sens to, że ostatecznie całkowi-
cie usunęliśmy menedżera zadań — po prostu nie będzie już potrzebny.
Oczywiście żartuję! Co prawda mam nadzieję, że Server 2019 rzeczywiście okaże się najbardziej
stabilnym i najmniej wymagającym systemem operacyjnym, jaki kiedykolwiek stworzyła
firma Microsoft, jednakże menedżer zadań nadal istnieje i wciąż będzie potrzebny administrato-
rom serwerów na całym świecie. Jeśli od dłuższego czasu nie przyglądałeś się menedżerowi
zadań, wiedz, że zmienił się on znacznie w ciągu ostatnich kilku wydań.
Menedżer zadań nadal zwykle jest wywoływany przez naciśnięcie kombinacji klawiszy
Ctrl+Alt+Del, a następnie wybranie opcji Task Manager. Można także kliknąć prawym przyci-
skiem myszy pasek zadań i wybrać opcję Task Manager. Możesz również uruchomić menedżera
zadań za pomocą kombinacji klawiszy Ctrl+Shift+Esc lub przez wpisanie polecenia taskmgr
w oknie dialogowym Run (Uruchom) lub Search (Wyszukaj). Pierwszą rzeczą, jaką zauważysz,
jest to, że w domyślnym widoku wyświetlanych jest bardzo mało informacji: tylko prosta lista
46
obecnie uruchomionych aplikacji. Jest to interfejs przydatny do wymuszania zamknięcia ja-

kiejś aplikacji, która może się zawiesić, ale do niczego więcej. Kliknij więc śmiało łącze More
details (Więcej szczegółów), a zobaczysz faktyczne informacje dostępne w tym potężnym interfejsie.
Od razu można zauważyć, że wyświetlane informacje są bardziej przyjazne dla użytkownika

niż w poprzednich latach, przy czym zarówno procesy Apps (Aplikacje), jak i Background
processes (Procesy w tle) są kategoryzowane w bardziej intuicyjny sposób, a wiele instancji tej
samej aplikacji jest skracanych w celu ułatwienia przeglądania. Daje to szybszy wgląd w to,
co dzieje się z systemem, a jednocześnie pozwala w razie konieczności przyjrzeć się szczegółom
każdej aplikacji lub procesu, aby się dowiedzieć, jakie poszczególne komponenty lub okna
są w nich aktywne, co widać na poniższym zrzucie ekranu:
Przetestuj także inne zakładki dostępne w menedżerze zadań. Zakładka Users (Użytkowni-
cy) wyświetli listę zalogowanych użytkowników oraz ilość zasobów sprzętowych zużywanych
przez ich sesje. Jest to dobry sposób, by na hoście sesji usług pulpitu zdalnego zidentyfikować
użytkownika, który może powodować jego nadmierne obciążenie. Zakładka Details (Szczegóły)
jest nieco bardziej tradycyjnym widokiem zakładki Processes (Procesy), wyświetlającym wiele
takich samych informacji, ale w stylu, do jakiego byliśmy od dawna przyzwyczajeni w starszych
47
wersjach systemu operacyjnego. Następna zakładka, Services (Usługi), jest dość zrozumiała —
pokazuje usługi Windows zainstalowane na serwerze oraz ich status, a także w razie potrzeby
umożliwia ich uruchomienie lub zatrzymanie bez konieczności otwierania oddzielnej kon-
soli Services.
Zakładka, którą wcześniej pominąłem, aby teraz omówić ją bardziej szczegółowo, ma nazwę
Performance (Wydajność). Ma ona dość potężne możliwości. Wewnątrz niej możesz monitorować
wykorzystanie procesora, pamięci i łącza Ethernet. Jak widać na poniższym zrzucie ekranu, nie
udało mi się dobrze zaplanować zasobów dla tej konkretnej maszyny wirtualnej, ponieważ
procesor prawie nie pracuje, za to niemalże brakuje pamięci systemowej:
Inną przydatną informacją dostępną na tym ekranie jest czas pracy serwera. Odnalezienie
tej informacji może być kluczowe w szybkim rozwiązywaniu problemów, ponieważ
administratorzy czasami wyznaczają czas pracy systemu na podstawie sygnatur czasowych
dziennika. Korzystanie z menedżera zadań jest znacznie łatwiejszym sposobem na znale-
zienie tej informacji!
Jeśli chcesz wyświetlić bardziej szczegółowe dane na temat wydajności serwera, w dolnej części
okna menedżera zadań znajdziesz łącze o nazwie Open Resource Monitor (Otwórz monitor
zasobów). Dwie dostępne w Server 2019 technologie do monitorowania stanu systemu,
w szczególności wydajności sprzętu, to Resource Monitor (Monitor zasobów) i Performance
Monitor (Monitor wydajności). Koniecznie uruchom te narzędzia i zacznij ich używać, ponieważ
48
mogą one dostarczyć zarówno informacji dotyczących rozwiązywania problemów, jak i waż-
nych danych podstawowych uzyskiwanych po uruchomieniu nowego serwera. Te dane można
następnie porównać z przyszłymi danymi testowymi, dzięki czemu możesz sprawdzać, w jaki
sposób nowe aplikacje lub usługi zainstalowane na określonym serwerze wpłynęły na zużycie
zasobów.
Wracając do menedżera zadań: udostępnia on jeszcze jedną ciekawą sztuczkę, którą chciałbym
zaprezentować. Pozostając w zakładce Performance, kliknij prawym przyciskiem myszy dowolny
interesujący Cię obszar z danymi, na przykład informacje o procesorze w pobliżu lewej krawędzi
okna. Spowoduje to otwarcie okna dialogowego z kilkoma opcjami, z których będę chciał
kliknąć Summary view (Widok podsumowania). Spowoduje to zmniejszenie obszaru zajmującego
poprzednio około połowy powierzchni mojego ekranu do wielkości małego okna, które mogę
po prostu przenieść do narożnika. Jest to dobry sposób na wyświetlanie przez cały czas informa-
cji o sprzęcie podczas wykonywania działań na serwerze, dzięki czemu można obserwować
wszelkie zmiany lub poziom zużycia zasobów w trakcie wprowadzania modyfikacji w systemie:
Widok zadań
Task View (Widok zadań) to nowa funkcja systemu Windows 10 i Windows Server 2016, która
została również zaimplementowana w środowisku Server 2019. Funkcjonalnie jest podobna
do tej, która polega na przytrzymaniu klawisza Alt, a następnie naciśnięciu klawisza Tab, aby
przełączać się między działającymi aplikacjami. Jeśli tego nigdy wcześniej nie robiłeś, po prostu
spróbuj nacisnąć i przytrzymać te dwa klawisze. W zależności od używanej wersji systemu
Windows ekran może się trochę różnić, ale w rzeczywistości są wyświetlanie te same informacje.
Będziesz mógł zobaczyć wszystkie programy, które masz otwarte, a za pomocą dodatkowych
naciśnięć klawisza Tab — przełączać się między nimi, od lewej do prawej. Alternatywnie użyj
kombinacji klawiszy Alt+Shift+Tab, aby przełączać się między nimi w odwrotnej kolejności.
Gdy masz wiele otwartych okien, być może łatwiej będzie po prostu użyć myszy, aby przejść
do określonego okna:
49
Widok zadań jest o wiele bardziej wydajny, ponieważ pozwala na zarządzanie wieloma pulpi-
tami zawierającymi aplikacje i okna. Na przykład, jeśli na tym samym serwerze pracujesz nad
dwoma różnymi projektami, a każdy z nich wymaga, aby mieć wiele różnych okien otwartych
w tym samym czasie, zaczniesz tracić dużo czasu na przełączanie się między wszystkimi
aplikacjami i oknami, aby znaleźć ten element, którego szukasz. Korzystając z widoku zadań,
możesz na pierwszym pulpicie zostawić wszystkie otwarte okna dla pierwszego projektu, a na-
stępnie na drugim pulpicie otworzyć wszystkie okna dotyczące drugiego projektu. Za pomocą
dwóch kliknięć, z użyciem przycisku Task View, możesz łatwo przełączać się między różnymi
pulpitami. Domyślnie Task View jest niewielką ikoną znajdującą się na pasku zadań, bezpośred-
nio po prawej stronie lupy wyszukiwania w pobliżu przycisku Start. Kliknij ją teraz:
Będziesz mógł zobaczyć listę otwartych okien — wygląda to bardzo podobnie do efektu naci-
śnięcia kombinacji Alt+Tab, o której wspominaliśmy przed chwilą. Różnica polega na istnieniu
małego przycisku o nazwie New desktop (Nowy pulpit) w lewym górnym narożniku ekranu.
Kliknij go:
Zobaczysz Desktop 1 (Pulpit nr 1) i Desktop 2 (Pulpit nr 2) dostępne do użycia. Możesz kliknąć

Pulpit nr 2 i otworzyć kilka nowych programów, a nawet przeciągać i upuszczać otwarte okna
między różnymi pulpitami, bezpośrednio na ekranie widoku zadań:
50
Widok zadań to świetny sposób na utrzymanie porządku i wydajności dzięki wykorzystaniu wielu
pulpitów na tym samym serwerze. Uważam, że to jak gdyby zarządzanie kilkoma wirtualnymi
ekranami z jednego fizycznego monitora.
Jeśli nie chcesz klikać ikony, aby włączyć widok zadań, to samo osiągniesz kombinacją
klawiszy WinKey+Tab!
Podsumowanie
Ten pierwszy rozdział dotyczący nowego systemu Windows Server 2019 pozwolił Ci zapoznać
się z nim w celu wygodnego poruszania po interfejsie. Istnieją różne sposoby interakcji z syste-
mem Server 2019 — wiele z nich omówimy w tej książce. Większość administratorów będzie
jednak z nim współpracować za pośrednictwem pełnego interfejsu graficznego, z użyciem
myszy i klawiatury. Jeśli wykorzystujesz poprzednie wersje Windows Server, wiele narzędzi,
których użyjesz do obsługi nowej platformy, będzie takich samych jak te, które były używane
w przeszłości, lub przynajmniej podobnych. Każdy nowy system operacyjny powinien być re-
zultatem ewolucji poprzedników, a nie starać się być zupełnie nowym systemem. Myślę, że jest
to wniosek na przyszłość, wynikły z oceny systemów Windows 8 i Server 2012.
W systemie Server 2019 nastąpił daleko idący kompromis między dostępnością do tradycyjnych
funkcji wcześniejszych wersji Windows a nowymi korzyściami z zastosowania przyjaznych
ekranów dotykowych z zaokrąglonymi krawędziami, które będą używane coraz częściej w urzą-
dzeniach opartych na systemie operacyjnym firmy Microsoft. W następnym rozdziale zajmiemy
się instalowaniem systemu Windows Server i zarządzaniem nim.
51
Pytania
1. W jaki sposób w Windows Server 2019 za pomocą dwóch kliknięć myszy można
uruchomić okno PowerShell z uprawnieniami administracyjnymi?
2. Jaka kombinacja klawiszy służy do otwarcia menu szybkich zadań
administracyjnych?
3. Jak się nazywa oferta usług chmurowych firmy Microsoft?
4. Jakie są dwie wersje licencyjne systemu Windows Server 2019?
5. Ile maszyn wirtualnych może działać na hoście Windows Server 2019 Standard?
6. Jaka opcja instalacji systemu Windows Server 2019 nie udostępnia graficznego
interfejsu użytkownika?
7. Która z nazw jest poprawna w przypadku najnowszej wersji systemu Windows
Server 2019: Long-Term Servicing Branch (LTSB) czy Long-Term Servicing
Channel (LTSC)?
8. Jak nazywa się narzędzie służące do zmiany konfiguracji w systemie Windows
Server 2019: Windows Settings (Ustawienia systemu Windows) czy Control Panel
(Panel sterowania)?
52
2
Instalowanie systemu
Windows Server 2019
i zarządzanie nim
Po krótkiej prezentacji funkcji graficznego interfejsu systemu Windows Server 2019 zdaję
sobie sprawę, że niektórzy z czytelników mogliby pomyśleć: „Wspaniale jest czytać o tym
wszystkim, ale czy mogę w jakiś sposób naprawdę zacząć używać tego systemu?”. Czytanie
o technologii nigdy nie jest tak dobre jak jej używanie, dlatego chciałbym, aby w tym rozdziale
pojawiło się już kilka praktycznych tematów. Jednym z głównych celów tej książki jest zapew-
nienie, że będziesz umiał korzystać z produktu. Prezentowanie faktów dotyczących nowych
funkcji i ulepszonej wydajności może być przyjemne, ale ostatecznie będzie bezwartościowe,
jeśli nie będziesz w stanie sprawić, by wszystko to, o czym czytasz, zadziałało w prawdziwym ży-
ciu. Sprawmy więc, by kawałek serwerowego żelastwa wykonał dla nas trochę pracy.
W tym rozdziale omówimy następujące zagadnienia:

 Wymagania dotyczące instalacji.
 Instalowanie systemu Windows Server 2019.
 Instalowanie ról i funkcji.
 Scentralizowane zarządzanie i monitorowanie.
 Windows Admin Center (WAC).
 Umożliwienie szybkiego wdrożenia serwera za pomocą narzędzia Sysprep.
Wymagania dotyczące instalacji

Przed utworzeniem nowego serwera musisz podjąć różne decyzje, z których wiele dotyczy ro-
dzaju licencjonowania. Jakie role zamierzasz zainstalować na tym serwerze? Czy wystarczy
wersja Server 2019 Standard, czy też potrzebujesz Datacenter Edition? Czy użycie Server Core
będzie korzystne z punktu widzenia bezpieczeństwa, czy też potrzebujesz pełnej wersji Desktop
Experience? W czasach gdy mamy do dyspozycji serwery Hyper-V z możliwością genero-
wania w każdej chwili maszyn wirtualnych, często nie zastanawiamy się zbytnio nad sprzętem
serwerowym, ale z pewnością nadal bywa tak, że system Windows Server 2019 jest insta-
lowany na sprzęcie fizycznym. W takich sytuacjach musisz zdawać sobie sprawę z wymagań
nowej platformy, więc poświęć chwilę na to, aby się zapoznać ze szczegółami technicznymi. Jeśli
jesteś zainteresowany, bardziej szczegółowe informacje znajdziesz na stronie Microsoft Docs
(https://docs.microsoft.com/en-us/windows-server/get-started-19/sys-reqs-19), jednak poniżej
podaję skrócone podsumowanie minimalnych wymagań systemowych:
 Procesor: 64-bitowy procesor taktowany z częstotliwością 1,4 GHz, który
obsługuje funkcje NX, DEP, CMPXCHG16b, LAHF/SAHF, PrefetchW i SLAT.
 Pamięć RAM: co najmniej 512 MB pamięci ECC lub minimum 2 GB w przypadku
serwera z systemem Desktop Experience. Mogę potwierdzić, że możliwe jest
zainstalowanie i uruchomienie serwera Desktop Experience w konfiguracji z mniej
niż 2 GB pamięci (na przykład w laboratorium testowym), ale powinieneś zdawać
sobie sprawę z tego, że wydajność takiego rozwiązania nie będzie najwyższa.
 Dysk: Server 2019 wymaga adaptera pamięci PCI Express (PCIe). Interfejsy ATA,
PATA i IDE nie są dozwolone dla dysków rozruchowych. Minimalne zapotrzebowanie
na miejsce wynosi 32 GB, przy czym Desktop Experience potrzebuje około 4 GB
więcej miejsca niż Server Core, więc weź to pod uwagę.
Są to w pewnym sensie minimalne wymagania, które musisz spełnić, jeśli chciałbyś po prostu
uruchomić Server 2019 i trochę się nim pobawić. W przypadku systemów produkcyjnych
znacznie zwiększ powyższe wartości. Nie ma żadnej magicznej odpowiedzi — określone para-
metry zależą od rodzaju obciążenia, które będzie obsługiwane przez serwer. Istnieją dodatkowe
komponenty, na które warto zwrócić uwagę przy budowaniu nowego systemu, a które są również
wymagane do określonych ról i funkcji. Elementy takie, jak UEFI czy standard TPM, szybko
stają się popularne i są wykorzystywane przez coraz więcej usług w każdej nowej aktualizacji
systemu operacyjnego. Jeśli jesteś w szczególności zainteresowany poprawą bezpieczeństwa
i dodatkową ochroną realizowaną za pośrednictwem funkcji BitLocker lub wykorzystujesz
silne certyfikaty albo funkcję Shielded VM, powinieneś się upewnić, że Twoje systemy będą
zawierać układy TPM 2.0.
Instalowanie systemu Windows Server 2019

Proces instalacji systemów operacyjnych firmy Microsoft zasadniczo znacznie się poprawił
w ciągu ostatnich 15 lat. Zakładam, że wielu spośród czytelników, profesjonalistów IT, jest rów-
nież de facto specami od komputerów, wciąż proszonymi przez rodzinę i znajomych o naprawę
54
Rozdział 2. • Instalowanie systemu Windows Server 2019 i zarządzanie nim
lub przebudowę sprzętu komputerowego. Jeśli jesteś podobny do mnie, oznacza to, że nadal
od czasu do czasu reinstalujesz starsze systemy operacyjne, takie jak Windows XP. Umiejętność
przyglądania się jasnoniebieskiemu ekranowi konfiguracji i wiedza o położeniu klawisza F8
na klawiaturze to niezbędne wymagania. Poświęcenie 2 godzin na zwykłe zainstalowanie
podstawowego systemu operacyjnego i zaktualizowanie go do najnowszego pakietu serwisowego
to normalna sytuacja. W porównaniu z tymi zamierzchłymi czasami instalacja nowoczesnego
systemu operacyjnego, takiego jak Windows Server 2019, jest po prostu niewiarygodnie
szybka i prosta.
Jest bardzo prawdopodobne, że większość czytelników już wiele razy wykonywała ten proces.
Jeśli jesteś jednym z nich, możesz pominąć kilka następnych stron. Każda osoba, która dopiero
zaczyna poruszać się po świecie Microsoftu lub ogólnie po branży IT, powinna jednak poświęcić
trochę czasu na zapoznanie się z procedurą instalacji, aby uzyskać podstawową wiedzę po-
zwalającą na rozpoczęcie pracy z systemem Server 2019. Jeśli nie masz jeszcze odznaki po-
twierdzającej umiejętności instalacji kolejnego systemu operacyjnego, nie musisz się nigdzie
spieszyć.
Wypalanie pliku ISO

Pierwszą czynnością, którą musisz wykonać, jest zdobycie nośnika instalacyjnego. Najprost-
szym sposobem pozwalającym na wdrożenie pojedynczego serwera jest pobranie pliku ISO
ze strony firmy Microsoft, wypalenie go na dysku DVD, a następnie użycie do instalacji. Ponie-
waż odnośniki i adresy URL witryn internetowych mogą się zmieniać w czasie, najpewniej-
szym sposobem na zdobycie pliku ISO, który powinien zostać użyty do instalacji, jest otwar-
cie wyszukiwarki, takiej jak Bing, a następnie wpisanie słów Pobranie Windows Server 2019.
Po otwarciu oficjalnej strony pobierania plików firmy Microsoft kliknij odnośnik, aby pobrać
plik ISO i zapisać go na dysku twardym komputera.
Najtrudniejszym elementem procedury przekształcenia pliku ISO w działający dysk DVD

zawsze było pobranie jakiegoś narzędzia innej firmy, które pozwalało wypalić dysk i uczynić
go przy tym rozruchowym. Jeśli na swoim komputerze używasz starszego systemu operacyj-
nego, wciąż może być to konieczne. Miałem okazję widzieć, jak wielu początkujących użytkow-
ników pobiera plik ISO, przeciąga go myszą na ikonę swojej nagrywarki i zaczyna proces nagry-
wania. To działanie tworzy płytę DVD z plikiem ISO, który jednak wciąż będzie spakowany
i nie będzie go można w żaden sposób uruchomić. Taki dysk będzie więc zupełnie bezuży-
teczny w Twoim nowym sprzęcie serwerowym. Na szczęście nowsze wersje klienckich syste-
mów operacyjnych Windows mają wbudowane funkcje do obsługi plików ISO, które bardzo
upraszczają prawidłowe przeprowadzenie procesu nagrywania.
Po pobraniu pliku ISO w celu instalacji systemu Windows Server 2019 włóż czystą płytę
DVD do napędu i w Eksploratorze Windows wyszukaj ten plik. Następnie kliknij go prawym
przyciskiem myszy i wybierz opcję menu Burn disc image (Nagraj obraz płyty). Spowoduje
to uruchomienie prostego kreatora, który wyodrębni i poprawnie wypali Twój nowy plik ISO na
płycie DVD, czyniąc go rozruchowym nośnikiem instalacyjnym dla nowego serwera. Zostało
to przedstawione na poniższym zrzucie ekranu:
55
Jeśli pobierzesz system Windows Server 2019 i użyjesz narzędzia Windows Disc Image Burner
do wypalenia standardowej płyty DVD, może pojawić się następujący komunikat o błędzie:
The disc image file is too large and will not fit on the recordable disc (Plik obrazu dysku jest za
duży i nie zmieści się na płycie do nagrywania).
Nie powinno to dziwić, ponieważ z biegiem lat pliki instalatora systemu operacyjnego stają
się coraz większe. Dotarliśmy do punktu krytycznego, w którym rozmiar standardowego pliku ISO
instalatora systemu Server 2019 jest większy od typowego dysku DVD o pojemności 4,7 GB.
Aby nagrać ten plik ISO na płycie DVD, musisz pójść do sklepu i kupić dysk dwuwarstwowy,
który może przechować więcej danych.
Tworzenie rozruchowej pamięci USB (pendrive)

Płyty DVD mogą być uciążliwe i irytujące, a ponadto obecnie mają zbyt małą pojemność, nie-
wystarczającą do naszych celów. Dlatego do instalowania nowszych, większych systemów opera-
cyjnych zamiast dysków DVD powszechnie używa się pamięci USB.
Aby przygotować taki nośnik, wystarczy mieć komputer z systemem Windows, pendrive o po-
jemności co najmniej 8 GB i dostęp do internetu. Będziesz musiał pobrać ten sam plik ISO,
o którym wspominaliśmy wcześniej, ponieważ zawiera on wszystkie pliki instalacyjne systemu
Server 2019. Następnie musisz pobrać i zainstalować jakieś narzędzie do tworzenia rozruchowej
pamięci USB. Dostępne są różne bezpłatne programy (dość popularny jest Rufus); jest także
produkt pochodzący prosto z firmy Microsoft, który nazywa się Windows 7 USB/DVD Download
Tool. Dlaczego ma taką dziwną nazwę, która zawiera słowa Windows 7? Nie pytaj mnie o to.
Ale mimo to działa poprawnie i umożliwia szybkie, łatwe i darmowe przygotowanie rozruchowej
pamięci USB do nowych instalacji. Należy zaznaczyć, że to narzędzie nie ma nic wspólnego
z systemem Windows 7. Pobierze ono dowolny plik ISO i zamieni go w rozruchowy pendrive.
Taki plik ISO może zawierać system Windows 10 lub Server 2019 i w obu tych przypadkach
procedura zadziała poprawnie.
Po zainstalowaniu aplikacji uruchom ją i po prostu wykonaj kolejne kroki.
56
Program wyczyści i sformatuje pamięć USB. Upewnij się, że nie przechowujesz tam nic
ważnego!
Musisz określić plik ISO, z którego narzędzie powinno pobrać informacje, a następnie wybrać
pamięć USB z listy rozwijanej. Następnie wystarczy nacisnąć przycisk Begin copying (Rozpocznij
kopiowanie), a program spowoduje, że pamięć USB stanie się rozruchowa i umożliwi instalację
całego systemu operacyjnego Windows Server 2019, jak pokazano na poniższym zrzucie
ekranu:
Uruchamianie instalatora
Teraz włóż nowo utworzoną płytę DVD lub rozruchową pamięć USB do nowego sprzętu
serwerowego. Włącz go, a pojawi się kreator instalacji systemu Windows Server 2019.
Obecnie w tym kreatorze nie ma zbyt wielu opcji do wyboru, więc nie poświęcimy mu wiele
miejsca. W większości przypadków wystarczy kliknąć przycisk Next (Dalej), aby przejść do
następnego ekranu. Jest jednak kilka sytuacji, w których trzeba będzie podjąć odpowiednią
decyzję.
Po wybraniu języka instalacji kolejny ekran wydaje się dość prosty. Znajduje się na nim tylko
jeden przycisk, z napisem Install now (Zainstaluj teraz). Tak — to jest właśnie ten przycisk,
który powinieneś kliknąć, ale chciałbym też, abyś zwrócił uwagę na tekst w lewym dolnym
narożniku ekranu. Jeśli kiedykolwiek znajdziesz się w sytuacji, gdy Twojego serwera nie będzie
można uruchomić, a Ty będziesz chciał użyć funkcji odzyskiwania lub diagnostyki w celu rozwią-
zania problemu, możesz kliknąć łącze Repair your computer (Napraw komputer), aby przejść
do konsoli odzyskiwania. W przypadku naszej nowej instalacji serwera nie ma takiej potrzeby,
więc kliknij po prostu przycisk Install now, jak pokazano na poniższym zrzucie ekranu:
57
Teraz zostaniesz poproszony o wprowadzenie klucza produktu w celu aktywacji systemu

Windows. Jeśli masz już taki klucz, podaj go. W przeciwnym razie, jeśli po prostu przepro-
wadzasz instalację w celu sprawdzenia systemu Server 2019 i chcesz przez jakiś czas działać
w trybie testowym, możesz kliknąć łącze I don’t have a product key (Nie mam klucza produktu),
aby pominąć ten ekran.
Następny ekran jest już interesujący. Jest on pierwszym miejscem, na które naprawdę musisz
zwrócić uwagę. Zobaczysz cztery różne opcje instalacji systemu Windows Server 2019. Jak
widać, istnieją typowe ścieżki instalacyjne zarówno dla wersji Server 2019 Standard, jak
i Server 2019 Datacenter, a oprócz tego każda z nich ma dodatkową opcję, która zawiera słowa
Desktop Experience. Zazwyczaj w programach instalacyjnych firmy Microsoft kliknięcie przyci-
sku Next (Dalej) pozwala uzyskać najbardziej typową i ogólną ścieżkę instalacji bez względu
na to, co się instaluje. Nie jest tak, niestety, w przypadku tego kreatora. Jeśli po prostu opu-
ścisz ekran kliknięciem Next, zostanie wybrany typ instalacji Server Core. Wersję Server
Core omówimy w jednym z dalszych rozdziałów, tu zaś informuję, że jeśli chciałbyś mieć
serwer w takiej postaci, o jakiej wspominaliśmy w rozdziale 1., „Pierwsze kroki w systemie
Windows Server 2019”, ta domyślnie wybrana opcja nie będzie właściwa. Wersja Desktop
Experience, która jest dostępna w drugiej opcji kreatora, zapewnia pełny interfejs graficzny
systemu Windows Server, którego można się spodziewać po zakończeniu instalacji. My chcemy
współpracować z serwerem przy użyciu pełnej grafiki i myszy, dlatego bez względu na to,
czy zdecydujesz się na wersję Standard lub Datacenter, przed kliknięciem przycisku Next
musisz się upewnić, że wcześniej wybrałeś opcję zawierającą słowa Desktop Experience. Zostało
to przedstawione na zrzucie ekranu na następnej stronie.
W niektórych poprzednich wersjach systemu Windows Server mieliśmy możliwość migracji

z Desktop Experience na Server Core i odwrotnie — nawet po zainstalowaniu systemu
operacyjnego. Niestety, taka opcja nie jest dostępna w systemie Windows Server 2019!
Zniknęła możliwość przechodzenia między tymi dwoma trybami, dlatego jeszcze waż-
niejsze staje się właściwe zaplanowanie instalacji serwerów na samym początku.
58
Kolejny ekran zawiera szczegóły warunków licencjonowania, na które musisz się zgodzić.
Następnie przechodzimy do innego ekranu, na którym najlepsza opcja nie jest najprawdopo-
dobniej tą, którą zamierzasz kliknąć. Rozumiem, dlaczego funkcja Upgrade (Uaktualnij) jest
wymieniona jako pierwsza w przypadku komputera z systemem Windows 10 klasy konsumenc-
kiej, ale nikt nie dokonuje lokalnej aktualizacji dla serwerów Windows. W idealnym świecie,
w którym po aktualizacjach wszystko zawsze działa bezbłędnie, byłaby to świetna metoda.
Możesz mieć wiele serwerów wykonujących swoje zadania, a za każdym razem, gdy jest
udostępniany nowy system operacyjny, wystarczy uruchomić instalatora i je zaktualizować.
Proszę bardzo, oto magia! Niestety, nie działa to w ten sposób i właściwie nie znam administrato-
rów gotowych podjąć ryzyko lokalnej aktualizacji istniejącego serwera produkcyjnego. O wiele
częściej jest tak, że tworzymy zupełnie nowe serwery obok już działających serwerów produk-
cyjnych. Gdy nowy serwer jest skonfigurowany i gotowy do przyjęcia na siebie obowiązków,
wtedy i tylko wtedy faktyczne aplikacje są przenoszone na ten serwer ze starego. W przypadku
zaplanowanego, starannie wymodelowanego procesu migracji stary serwer zostaje wyłączony
i usunięty po jej zakończeniu. Gdybyśmy byli w stanie po prostu zaktualizować istniejące
serwery do najnowszego systemu operacyjnego, zaoszczędziłoby to nam mnóstwo czasu i pracy.
Jest to jednak możliwe tylko wtedy, gdy wiesz, że aktualizacja faktycznie zadziała bez proble-
mów. W większości przypadków nie jesteśmy przygotowani na takie ryzyko. Jeśli proces
aktualizacji nie wykonuje się poprawnie i kończy się uszkodzeniem systemu, zastanawiasz się
nad kosztownym procesem naprawy i odzyskiwania danych na krytycznym dla firmy serwerze
produkcyjnym. Równie dobrze mógłbyś myśleć o pracy w nocy lub w weekend. Czy wolisz
spędzić czas na zaplanowaniu starannie zdefiniowanej migracji, czy na odzyskiwaniu krytycznego
serwera, mając za plecami dział biznesowy patrzący Ci na ręce? Założę się, że wybierzesz tę
pierwszą opcję.
59
Firma Microsoft ogłosiła, że instalator systemu Windows Server 2019 potrafi uaktualnić
system Windows Server 2016 znacznie lepiej niż jakikolwiek inny program migracji lokalnej
środowiska Windows Server. W przypadku wcześniejszych wersji systemu operacyjnego
nadal zalecane jest, by przygotować zupełnie nowy serwer, a następnie przenieść na niego
dane i aplikacje. Obecnie jednak firma Microsoft najwyraźniej sugeruje, by administratorzy
zaczęli testować lokalne migracje z wersji Server 2016 do Server 2019. Czy to zadziała
w realnym świecie? Sam powinieneś podjąć odpowiednią decyzję…
Biorąc powyższe pod uwagę, wróćmy do głównego wątku. W świecie systemów Windows
Server rzadko używamy opcji Upgrade. Wybierz więc opcję Custom: Install Windows
only (advanced) (Niestandardowa: Zainstaluj tylko system Windows (opcja zaawansowana)),
która pozwoli na zainstalowanie wersji systemu Windows Server 2019 w nowej lokalizacji na
dysku twardym. Zostało to przedstawione na poniższym zrzucie ekranu:
Teraz zdecydujemy, gdzie chcemy zainstalować nową kopię systemu Windows Server 2019.
Często po prostu klikniesz przycisk Next, ponieważ serwer będzie miał tylko jeden dysk twardy,
a być może jedną macierz RAID. W obu tych przypadkach zobaczysz jedną pulę wolnego
miejsca, na której możesz zainstalować system operacyjny. Jeśli jednak masz wiele dysków
twardych zainstalowanych na serwerze i nie zostały one jeszcze w żaden sposób powiązane
ze sobą, będziesz miał na tym ekranie dostępnych wiele możliwości wyboru miejsca instala-
cji systemu Windows Server. Ponieważ mamy tutaj tylko jeden dysk twardy, który nigdy nie
był używany, możemy po prostu kliknąć przycisk Next, aby kontynuować. Zwróć uwagę na to,
że jeśli na dyskach były jakieś dane, masz możliwość sformatowania tych dysków lub usunięcia
ich poszczególnych partycji za pomocą przeznaczonych do tego narzędzi. Jeśli korzystasz
z pewnych specjalizowanych dysków, które wymagają określonych sterowników, możesz użyć
przycisku Load driver (Wczytaj sterownik), aby dodać je do kreatora instalacji w celu uzyskania
dostępu do tego rodzaju dysków.
60
Ważne jest również, by zdać sobie sprawę z tego, że w przypadku większości nowych instalacji
serwerów nie ma potrzeby wykonywania jakiejkolwiek czynności. Na poniższym zrzucie
ekranu widzimy przycisk New (Nowy), którego można użyć w celu samodzielnego utworzenia
partycji dysku twardego. Wielu administratorów zakłada, że musi ją utworzyć, aby zainstalować
nowy system operacyjny.
W tym przypadku tak nie jest. Nie ma potrzeby tworzenia partycji, chyba że z jakiegoś konkret-
nego powodu chcesz ją skonfigurować samodzielnie. Jeśli Twój dysk twardy to tylko zbiór pu-
stych, nieprzydzielonych miejsc, nie musisz nic zrobić oprócz kliknięcia przycisku Next, a insta-
lator systemu Windows Server 2019 sam odpowiednio skonfiguruje partycje.
Otóż to! Zobaczysz, że instalator serwera zacznie kopiować pliki, instalować funkcje i rozmiesz-
czać wszystko na dysku twardym. Ta część instalatora pracuje samodzielnie przez kilka minut.
Gdy będziesz musiał ponownie wejść w interakcję z serwerem, instalator będzie już działać
w trybie graficznym, w którym możesz zdefiniować hasło administratora. Po wybraniu hasła
znajdziesz się na pulpicie systemu Windows. Teraz naprawdę jesteś gotowy, aby zacząć korzystać
z nowego systemu Windows Server 2019.
Instalowanie ról i funkcji

Instalacja systemu operacyjnego wieńczy pierwszy etap procesu pozwalającego na użycie
Twojej maszyny w roli realnego serwera. Jednak na razie na tym serwerze nie można nic
zrobić. W klienckim systemie komputerowym podstawowy system operacyjny to zasadniczo
wszystko, czego potrzeba, aby rozpocząć pracę i przetwarzanie danych. Zadaniem serwera jest
przede wszystkim udostępnianie tych danych, więc dopóki nie powiesz mu, jaki jest jego cel
w życiu, tak naprawdę w podstawowym systemie operacyjnym nie będzie się działo nic ciekawego.
Nadszedł czas, by wykorzystać role i funkcje. Windows Server 2019 zawiera wiele różnych
61
opcji ról. Rola jest dokładnie tym, co sama jej nazwa wskazuje: instalacja określonej roli na ser-
werze określa rolę tego serwera w sieci. Innymi słowy, rola nadaje serwerowi jakiś cel w życiu.
Z drugiej strony funkcja jest raczej zestawem usług, które można zainstalować na serwerze.
Funkcje mogą uzupełniać określone role lub działać samodzielnie. W systemie Windows
Server 2019 dostępne są technologie, które nie są domyślnie instalowane ani włączane, po-
nieważ te funkcje nie byłyby używane we wszystkich okolicznościach. Wszelkie informacje
przekazane w dalszych rozdziałach tej książki są związane z funkcjonalnością zapewnianą
przez role i funkcje. Są one chlebem powszednim systemu Windows Server, a bez ich zainstalo-
wania serwery stają się w zasadzie tylko dobrymi przyciskami do papieru. Ponieważ w dalszych
rozdziałach nie poświęcimy już czasu na opisy instalacji każdej konkretnej roli lub funkcji,
przyjrzyjmy się teraz dokładniej najczęściej stosowanym praktykom, które wykorzystują
administratorzy, aby uzyskać odpowiednie role i funkcje na serwerach.
Instalowanie roli za pomocą kreatora

Najczęściej używanym narzędziem służącym do instalowania ról i funkcji jest bez wątpienia
graficzny kreator, dostępny od razu po zainstalowaniu systemu operacyjnego. Aplikacja o nazwie
Server Manager (Menedżer serwera) uruchamia się automatycznie po każdym zalogowaniu
się do systemu Windows Server 2019. W dalszej części tego rozdziału przyjrzymy się bliżej
temu programowi, jednakże teraz wykorzystamy go po prostu jako platformę uruchamiania,
pozwalającą dostać się do kreatora, który poprowadzi nas przez proces instalacji pierwszej,
wspólnie utworzonej roli na nowym serwerze.
Ponieważ właśnie zalogowałeś się na serwerze, powinieneś wpatrywać się w pulpit nawigacyjny
Menedżera serwera. Pośrodku pulpitu nawigacyjnego zobaczysz łącza, które można klikać,
inaczej mówiąc — listę szybkiego uruchamiania pięciu różnych działań. Jeśli jeszcze tego nie
zrobiłeś, kliknij pierwsze i najważniejsze łącze, Configure this local server (Konfiguruj ten
serwer lokalny), aby uzyskać dostęp do podstawowej konfiguracji serwera.
Elementami, które prawdopodobnie należy zdefiniować, będą nazwa hosta dla serwera i adres IP.
Jeśli dołączasz serwer do istniejącej domeny, zazwyczaj zajmujesz się procesem wstępnej
konfiguracji przed wdrożeniem jakichkolwiek nowych ról. My jesteśmy jednak bardziej zaintere-
sowani samą instalacją roli, więc założymy, że skonfigurowałeś już te drobne opcje, pozwa-
lające na identyfikację serwera i łączność sieciową.
Kliknij więc drugie łącze, Add roles and features (Dodaj role i funkcje). Innym sposobem
uruchomienia tego samego kreatora jest kliknięcie w Menedżerze serwera menu Manage
(Zarządzaj) na górnym pasku, a następnie wybranie z listy rozwijanej opcji Add Roles and
Features (Dodaj role i funkcje). Spowoduje to przejście do takiego samego kreatora instalacji
roli, co zaprezentowano na pierwszym zrzucie ekranu na następnej stronie.
Najpierw zostanie wyświetlony ekran podsumowujący, dotyczący instalowania ról. Kliknij przy-
cisk Next (Dalej), aby go pominąć. Teraz przechodzimy do pierwszej interesującej opcji. Naj-
pierw zostanie zadane pytanie, czy chcemy kontynuować instalację opartą na rolach lub funk-
cjach, o czym wcześniej mówiliśmy. Należy jednak zwrócić uwagę na drugą opcję: Remote
62
Desktop Services installation (Instalacja usług pulpitu zdalnego). Większość z nas uważa składniki
usług pulpitu zdalnego (RDS) systemu Windows Server za kolejną rolę, którą możemy wy-
brać podczas konfigurowania serwera, podobnie jak ma to miejsce w przypadku instalacji
dowolnej innej roli. Chociaż jest to w zasadzie prawdą, należy zauważyć, że RDS jest tak
funkcjonalnie odmienny od innych rodzajów ról, że po wybraniu drugiej opcji ścieżka pro-
wadząca do instalacji dowolnego z elementów RDS wywołuje własnego kreatora. Tak więc
jeśli kiedykolwiek będziesz szukać opcji dotyczącej instalacji RDS, a ten ekran po prostu
przeskoczysz, ponieważ podobnie jak ja jesteś bardzo przyzwyczajony do automatycznego
klikania przycisku Next, pamiętaj o cofnięciu się, aby poinformować kreatora, że chcesz się
zająć komponentem RDS — wówczas reszta ekranów odpowiednio się dostosuje.
Obecnie pracuję nad stworzeniem nowego laboratorium testowego wypełnionego maszynami

z systemem Windows Server 2019. Nadal potrzebuję kontrolera domeny do zarządzania
w swoim środowisku usługą katalogową Active Directory. Bardzo ważne jest, by przed zain-
stalowaniem na serwerze usługi Active Directory spełnić kilka wymagań wstępnych. Na na-
szym nowym serwerze już zostały spełnione. Przed instalacją roli AD DS muszę przypisać
do serwera statyczny adres IP i upewnić się, że ustawienia DNS we właściwościach karty
sieciowej wskazują na coś, nawet jeśli jest to tylko własny adres IP tego serwera. Muszę także się
upewnić, że nazwa hosta mojego serwera została ostatecznie zdefiniowana, ponieważ po prze-
kształceniu go w kontroler domeny jej zmiana nie będzie możliwa. Udało mi się już wcze-
śniej spełnić te wymagania dla serwera, więc będę kontynuował obsługę kreatora instalacji
roli: wybiorę opcję Role-based or feature-based installation (Instalacja oparta na rolach lub
oparta na funkcjach), a następnie kliknę przycisk Next, jak pokazano na poniższym zrzucie
ekranu:
63
Ekran Server Selection (Wybieranie serwera docelowego) ma duże możliwości. Jeśli już wcze-
śniej definiowałeś jakąś rolę, prawdopodobnie szybko opuściłeś ten ekran przez kliknięcie
przycisku Next, aby przejść dalej. W zasadzie główne zadanie tego ekranu polega na zapytaniu,
gdzie chcesz zainstalować nową rolę lub funkcję. Domyślnie na wyświetlonej liście znajduje
się serwer, na którym jesteś właśnie zalogowany, dlatego kliknięcie przycisku Next w celu
kontynuowania jest bardziej niż prawdopodobne. Mamy tu jednak kilka innych ciekawych opcji.
Po pierwsze, jeśli Twój Menedżer serwera wie o istnieniu innych serwerów w sieci i został
skonfigurowany w celu ich monitorowania, będzie tu dostępna opcja zdalnego zainstalowania roli
lub funkcji na jednym z nich. Wkrótce omówimy tę możliwość. Następna rzadko wykorzystywa-
na funkcja na tej stronie polega na możliwości określenia, czy chciałbyś zainstalować rolę lub
funkcję na wirtualnym dysku twardym. W dzisiejszych czasach wielu z nas używa przede
wszystkim serwerów wirtualnych, dlatego nie jest wymagane, aby tego rodzaju serwer był włą-
czony w celu zainstalowania na nim roli lub funkcji! Możesz wybrać tę opcję, jeśli masz dostęp
do pliku VHDX, czyli pliku dysku twardego, z którego uruchamiany jest Menedżer serwera.
Pozwoli Ci to na umieszczenie nowej roli lub funkcji bezpośrednio na dysku twardym. W 99%
przypadków użycia tego ekranu będziesz jednak zalogowany bezpośrednio na serwerze, na któ-
rym zamierzasz zainstalować jakąś rolę, więc po prostu klikniesz przycisk Next, co zaprezento-
wano na poniższym zrzucie ekranu:
Została wyświetlona lista ról, które można zainstalować. Kliknięcie wiersza z nazwą roli pozwala
wyświetlić krótki opis dotyczący jej funkcjonowania. Podstawowe elementy infrastruktury
omówimy dokładniej w następnym rozdziale, co zapewni Ci dodatkowe informacje na temat
ról. Aby zainstalować rolę na naszym nowym serwerze, wystarczy zaznaczyć pole wyboru i klik-
nąć przycisk Next (Dalej). Ponieważ zamierzamy mieć kontroler domeny, wybiorę rolę Active
Directory Domain Services. Dodatkowo będę chciał, by serwer miał także zainstalowane
role DNS Server i DHCP Server. Nie trzeba uruchamiać jeszcze trzy razy tego samego
kreatora, aby zainstalować te wszystkie role. Mogę po prostu zaznaczyć je na liście i pozwolić
kreatorowi uruchomić wszystkie niezbędne instalatory. Gdy kliknąłem swoje pierwsze pole
wyboru, otrzymałem komunikat, że rola Active Directory Domain Services wymaga dodatko-
wych funkcji, aby mogła poprawnie działać. Jest to normalne zachowanie i będziesz mógł
w przyszłości zauważyć, że wiele ról wymaga zainstalowania dodatkowych składników lub
funkcji. Musisz tylko kliknąć przycisk Add Features (Dodaj funkcje), aby automatycznie do-
dać niezbędne elementy podczas procesu instalacji. Przykład tego pokazano na poniższym
zrzucie ekranu:
64
Po zaznaczeniu wszystkich trzech ról czas kliknąć przycisk Next. Aby sytuacja była jasna: nie
musiałem instalować jednocześnie tych ról — nie wszystkie są od siebie zależne. Role te są bar-
dzo często instalowane na jednym serwerze, ale mógłbym je rozdzielić na różne serwery.
W większym środowisku możesz co prawda mieć usługi AD DS i DNS zainstalowane
wspólnie na jednym serwerze, ale mógłbyś umieścić rolę DHCP na oddzielnym serwerze i to
byłoby w porządku.
Konfiguruję ten serwer do obsługi małego środowiska laboratoryjnego, więc ma sens włączenie
tych podstawowych usług infrastruktury na jednej liście, co pokazano na pierwszym zrzucie
ekranu na następnej stronie.
Po kliknięciu przycisku Next pojawiła się strona, na której możemy zainstalować dodatkowe
funkcje systemu Windows Server 2019. Niekiedy możesz chcieć jedynie dodać konkretną
funkcję. Wówczas wszystkie ekrany związane z rolami zostaną pominięte, a Ty zostaniesz prze-
niesiony od razu do ekranu instalacji funkcji. Podobnie jak na ekranie instalacji roli, przejrzyj
jeszcze raz wszystkie funkcje, które chcesz zainstalować, a następnie ponownie kliknij przycisk
Next. W przypadku naszego kontrolera domeny nie wymagamy obecnie żadnych dodatkowych
funkcji, dlatego zakończę pracę kreatora, który rozpocznie instalację nowych ról.
W zależności od zainstalowanych ról lub funkcji oraz od tego, czy wymagają one ponownego
uruchomienia, po zakończeniu procesu instalacji może pojawić się monit o ponowny restart
serwera. Po powrocie do Menedżera serwera w górnej części ekranu pojawi się żółty trójkąt
z wykrzyknikiem. Kliknięcie go spowoduje wyświetlenie komunikatów o dalszych działaniach,
które będą wymagane w celu dokończenia konfiguracji nowych ról i uruchomienia ich na
65
serwerze. Role dla usług AD DS, DNS i DHCP są teraz pomyślnie instalowane, ale trzeba
je dodatkowo skonfigurować, aby mogły one wykonywać swoją pracę. Na przykład, aby zakoń-
czyć przekształcanie swojego serwera w kontroler domeny, muszę przejść proces promowa-
nia w celu zdefiniowania domeny lub określenia tej, do której chcę dołączyć. Istnieją również
pewne czynności, które należy wykonać przed uruchomieniem usługi DHCP:
66
Instalowanie funkcji przy użyciu powłoki PowerShell

Gdy już sprawdziłeś działanie graficznych kreatorów instalacji ról i funkcji, z pewnością zawsze
będziesz mógł ich użyć, aby dodać odpowiednie komponenty do swoich serwerów. Firma
Microsoft włożyła jednak wiele wysiłku w stworzenie środowiska Windows Server, w którym
można zarządzać prawie wszystkimi elementami systemu operacyjnego za pomocą powłoki
PowerShell. Dodawanie ról i funkcji także zawiera się w tych możliwościach. Rzućmy okiem
na odpowiednie polecenia, których możemy używać do modyfikowania ról i funkcji na serwerze
bezpośrednio z wiersza poleceń programu PowerShell. Zapoznasz się z dostępną listą ról i funk-
cji, a ponadto wydamy polecenie instalacji szybkiej funkcji na naszym serwerze.
Otwórz powłokę PowerShell z uprawnieniami administratora. Można to najłatwiej wykonać

za pomocą menu szybkich zadań administracyjnych, dostępnego po kliknięciu przycisku Start
prawym przyciskiem myszy. Następnie użyj poniższego polecenia, aby wyświetlić wszystkie
dostępne role i funkcje, które możemy zainstalować na naszym serwerze. Wyświetlone zostaną
także te, które są obecnie zainstalowane:
Get-WindowsFeature
Na serwerze chciałbym zainstalować funkcję Telnet Client. Używam klienta Telnetu dość regu-
larnie do testowania połączeń sieciowych, więc warto go mieć zainstalowanego na kompute-
rze. Niestety, moje okno programu PowerShell wyświetla obecnie informacje o wielu różnych
rolach i funkcjach, więc nie jestem pewien, jaka jest dokładna nazwa funkcji klienta Telnet.
Uruchommy więc ponownie polecenie Get-WindowsFeature, ale tym razem zastosujmy dodatkową
składnię, aby zmniejszyć ilość wyświetlanych informacji. Chcę zobaczyć tylko funkcje o nazwach
rozpoczynających się od liter TEL, jak pokazano na następującym przykładzie:
Get-WindowsFeature -Name TEL*
67
Otóż to! Gdy znamy poprawną nazwę funkcji, możemy uruchomić polecenie, aby ją zainstalo-
wać, jak pokazano poniżej:
Add-WindowsFeature Telnet-Client
Na koniec chciałbym zaprezentować składnię polecenia cmdlet Get-WindowsFeature, pozwalają-

cego wyświetlić tylko role i funkcje obecnie zainstalowane na serwerze. Wygląda ona nastę-
pująco: Get-WindowsFeature | Where Installed. Jeśli uruchomię to polecenie na swoim
kontrolerze domeny, będę mógł zobaczyć wszystkie składniki ról AD DS, DNS i DHCP, jak
pokazano na poniższym zrzucie ekranu:
68
Scentralizowane zarządzanie
i monitorowanie
Niezależnie od tego, czy instalujesz nowe role, wykonujesz kopie zapasowe i używasz progra-
mów konserwacyjnych, czy też rozwiązujesz problemy i naprawiasz system, warto, żebyś logował
się na tym właśnie serwerze, który zamierzasz obsługiwać. Dawno temu oznaczało to pod-
chodzenie do fizycznego serwera i logowanie się za pomocą klawiatury i myszy podłączonych
bezpośrednio do sprzętu. Później, wciąż całkiem sporo lat temu, stało się to uciążliwe, technolo-
gia zaś rozwinęła się do takiego poziomu, że pojawił się protokół zdalnego pulpitu (RDP).
Zaczęliśmy się więc logować do swoich serwerów zdalnie, za pomocą RDP. Mimo że ten
protokół istnieje już od wielu lat, wciąż jest niezwykle potężnym i bezpiecznym narzędziem,
które pozwala na szybkie i komfortowe łączenie się z serwerami wprost z biurka. Jeśli tylko sieć
ma odpowiednią topologię i zapewnione trasy routingu, możesz pracować na serwerze znajdują-
cym się po drugiej stronie świata tak sprawnie, jakby był on umieszczony w szafie obok Ciebie.
Niedawno przeczytałem, że zostały wydane pierwsze zezwolenia na wydobywanie kopalin
w kosmosie. Zastanów się więc nad swoim centrum danych! Może kiedyś będziemy używać RDP
do łączenia się z serwerami znajdującymi się w kosmosie. Co roku mam okazję współpracować
z dziesiątkami nowych firm i chociaż istnieją różne narzędzia pozwalające na zdalne zarządzanie
infrastrukturą serwerów, RDP jest platformą, którą wybiera 99% administratorów.
Dlaczego wspominamy o protokole RDP? Ponieważ system Windows Server 2019 zawiera
pewne narzędzia, które sprawiają, że jest on znacznie mniej potrzebny w naszej codziennej
pracy. Idea scentralizowanego zarządzania serwerami rozwijała się w kilku ostatnich wersjach
systemu operacyjnego Windows Server. Większość z nas obsługuje tak wiele serwerów, że co-
dzienne logowanie się na nie zajmowałoby zbyt dużo czasu. Potrzebujemy narzędzi, które mo-
żemy wykorzystać, aby nasze zarządzanie i monitorowanie, a nawet procesy konfiguracyjne
były bardziej wydajne, dzięki czemu będziemy mieli czas na ważniejsze projekty.
Menedżer serwera
Jeśli ostatnio pracowałeś w systemie Windows Server, wiesz o tym, że po zalogowaniu jest wy-
świetlane automatycznie duże okno na pulpicie. Tym programem jest Server Manager (Menedżer
serwera). Jak sama nazwa wskazuje, ma on za zadanie wsparcie w zarządzaniu serwerem.
Jednak z mojego doświadczenia wynika, że większość administratorów nie korzysta z Mene-
dżera serwera. Zamiast tego zamykają go tak szybko, jak to możliwe, i przeklinają pod nosem,
ponieważ jego okno wyskakuje i denerwuje ich podczas każdego logowania do serwera przez
ostatnie 10 lat.
Nie rób tak! Ten program jest to po, aby Ci pomóc. Poniższy zrzut ekranu przedstawia domyślny
widok Menedżera serwera na moim nowym kontrolerze domeny:
69
W tym programie, który się automatycznie otwiera, podoba mi się to, że umożliwia on szybkie
sprawdzenie, co jest obecnie zainstalowane na serwerze. Kolumna po lewej stronie prezentuje
listę ról zainstalowanych i możliwych do zarządzania. Kliknięcie każdej z nich powoduje
przejście do bardziej szczegółowej konfiguracji i dostępnych opcji. Często podczas pracy nad
projektem przełączam się między wieloma różnymi serwerami, a pozostawienie otwartego
Menedżera serwera pozwala mi szybko sprawdzić, czy znajduję się na właściwej maszynie.
Bardzo interesująca jest również sekcja Roles and Server Groups (Role i grupy serwerów),
znajdująca się w dolnej części okna. Kolory na powyższym zrzucie ekranu nie są widoczne, ale
gwarantuję, że pozwalają bardzo szybko stwierdzić, czy usługi działające na serwerze działają
poprawnie. W tej chwili obie funkcje AD DS i DHCP działają normalnie — ich nazwy są
podkreślone ładną zieloną linią. Gdyby jednak którakolwiek z tych ról miała problemy, oznaczono
by to kolorem jaskrawoczerwonym, a ja mógłbym kliknąć dowolny z odnośników wyświetlo-
nych w nagłówkach ról, aby znaleźć problem.
W pobliżu prawego górnego narożnika ekranu zobaczysz kilka pozycji menu, z których dla
mnie najbardziej przydatna jest opcja Tools (Narzędzia). Kliknij ją, a zobaczysz listę wszystkich
dostępnych narzędzi administracyjnych do użycia na tym serwerze. Tak, jest to zasadniczo
ten sam folder narzędzi administracyjnych, który istniał w każdej z poprzednich wersji systemu
Windows Server. Obecnie jest on jednak przechowywany w innej lokalizacji. Z mojego doświad-
czenia wynika, że Server Manager jest teraz najłatwiejszym sposobem uzyskania z jednego
miejsca dostępu do niezliczonych narzędzi:
70
Funkcje Menedżera serwera, o których dotychczas mówiliśmy, są dostępne w dowolnym syste-

mie Windows Server 2019, niezależnie od tego, czy jest on samodzielnym składnikiem, czy też
stanowi część domeny. Wszystko, co wykonujemy, dotyczy tylko lokalnego serwera, na którym
jesteśmy zalogowani. Teraz przyjrzyjmy się, jakie opcje w Menedżerze serwera służą do centrali-
zacji zarządzania na wielu serwerach. Nowy styl zarządzania wieloma maszynami z jednego
serwera jest często określany jako zarządzanie z jednego monitora. Będziemy używać Menedżera
serwera na jednym z serwerów w sieci, aby nawiązywać połączenia z innymi maszynami. Po
zakończeniu naszych działań Menedżer serwera będzie zawierał znacznie więcej informacji,
które pomogą nam zachować kontrolę nad wszystkimi dostępnymi maszynami.
Obszar centralny konsoli Menedżera serwera to sekcja zatytułowana Welcome to Server Manager
(Menedżer Serwera — zapraszamy). Poniżej znajduje się szereg łączy, które można klikać.
Pierwsze pozwala skonfigurować ustawienia specyficzne tylko dla lokalnego serwera. Drugie
łącze już przetestowaliśmy, gdy dodawaliśmy nową rolę do naszego serwera. Teraz sprawdzimy
trzecie: Add other servers to manage (Dodaj inne serwery do zarządzania).
Nawiasem mówiąc, tę samą funkcję można również wywołać przez kliknięcie górnego menu
Manage (Zarządzaj), a następnie wybranie opcji Add Servers (Dodaj serwery). Zostało to pokazane
na pierwszym zrzucie ekranu na następnej stronie.
Większość czytelników będzie pracować w środowisku domenowym, w którym wszystkie

serwery są podłączone do domeny. Dzięki temu operacja, którą zaraz wykonamy, będzie na-
prawdę łatwa. Po prostu kliknij przycisk Find Now (Znajdź teraz), a zostaną wyświetlone
maszyny dostępne w Twojej sieci. Z listy możesz wybrać serwery, którymi chcesz zarządzać,
a następnie przenieść je do kolumny Selected (Wybrane), znajdującej się po prawej stronie,
jak pokazano na drugim zrzucie ekranu na następnej stronie.
71
Po kliknięciu przycisku OK zobaczysz, że wygląd Menedżera serwera zmienił się, tak by wy-
świetlał on więcej informacji o serwerach i rolach, które są na nich zainstalowane. Gdy zalogu-
jesz się na którymś z nich, natychmiast zobaczysz krytyczne informacje dotyczące działania
wszystkich systemów, które zamierzasz dodać. Możesz nawet użyć oddzielnego serwera,
który byłby przeznaczony wyłącznie do zarządzania. Jestem obecnie zalogowany na zupełnie
nowym serwerze o nazwie CA1. Nie ma tam zainstalowanych żadnych ról, więc Menedżer
serwera — w domyślnej konfiguracji — wygląda dość prosto. Gdy tylko dodam inne serwery
(moje kontrolery domeny) w celu zarządzania nimi, mój Menedżer serwera na maszynie CA1
będzie znał wszystkie szczegóły dotyczące działania zarówno jej, jak i moich kontrolerów
domeny, dzięki czemu na jednym panelu będę mógł wyświetlić informacje o całej infrastruktu-
rze. Jak widać na poniższym zrzucie ekranu, wyświetlonych zostało nawet kilka znaczników
wskazujących, że w mojej infrastrukturze niektóre usługi nie działają poprawnie:
72
Kliknięcie łącza All Servers (Wszystkie serwery) lub jednej z określonych ról zapewnia jeszcze
bardziej wyczerpujące informacje pobrane ze zdalnych serwerów. Dodanie wielu serwerów
do Menedżera serwera jest przydatne nie tylko do ich monitorowania; przyda się również do
modyfikowania konfiguracji. Czy pamiętasz, że kilka stron wcześniej dodaliśmy nową rolę za
pomocą kreatora? Proces ten zmienił się i stał się teraz bardziej wszechstronny, ponieważ połą-
czyliśmy nasz serwer z innymi maszynami w sieci.
Jeśli teraz zdecyduję się dodać nową rolę, wówczas po przejściu do ekranu z pytaniem, gdzie
chcę ją zainstalować, będę mógł wybrać także moje zdalne serwery, mimo że nie jestem na nich
zalogowany, co pokazano na poniższym zrzucie ekranu:
73
Gdybym chciał zainstalować rolę AD DS na serwerze DC2, który będzie drugim kontrolerem
domeny w moim środowisku, nie musiałbym już się na nim logować. Właśnie tutaj, z Menedżera
serwera działającego na CA1, mogłem uruchomić kreatora dodawania ról i wskazać DC2
jako serwer, który chcę zmodyfikować, by następnie bezpośrednio z tego samego miejsca zain-
stalować na nim rolę.
Narzędzia administracji zdalnej serwera (RSAT)

Możliwość korzystania z Menedżera serwera po to, aby logować się do pojedynczej maszyny
oraz zarządzać zdalnymi serwerami i je monitorować, jest bardzo przydatna. A może dałoby się
ten proces jeszcze bardziej usprawnić? Czy mógłbyś sobie wyobrazić sytuację, w której nie
musisz się logować do żadnego z serwerów, ale możesz wykonać wszystkie zadania ze swojego
komputera stojącego na biurku?
Jest to możliwe po zainstalowaniu zestawu narzędzi o nazwie Remote Server Administration

Tools (Narzędzia administracji zdalnej serwera, w skrócie RSAT), stworzonego przez firmę
Microsoft. Mam zwykły komputer kliencki z systemem Windows 10 z dostępem do internetu,
działający również w lokalnej sieci. Komputer jest podłączony do domeny. Na tym komputerze
chcę pobrać i zainstalować narzędzia RSAT z następującej lokalizacji: https://www.microsoft.
com/pl-PL/download/details.aspx?id=45520.
Jeśli używasz systemu Windows 10 1809 lub nowszego, zestaw narzędzi RSAT został
już do niego dołączony. Jest on jednak opcjonalną funkcją, którą dopiero trzeba włączyć.
Robi się to w Ustawieniach systemu Windows, w kategorii Aplikacje, za pomocą przycisku
Zarządzaj funkcjami opcjonalnymi.
Po zakończeniu działania instalatora na komputerze klienckim z systemem Windows 10 nie mogę

jednak znaleźć programu o nazwie Remote Server Administration Tools. Nie jest to błąd.
Chociaż aplikacja podczas pobierania i instalowania nazywa się RSAT, program, który został fak-
tycznie umieszczony na komputerze, ma nazwę Menedżer serwera. Ma to sens, z wyjątkiem
tego, że jeśli nie zauważysz rozbieżności w nazwach, może minąć kilka minut, zanim zrozumiesz,
dlaczego nie możesz znaleźć tego, co właśnie zainstalowałeś.
Uruchom więc Menedżera serwera — znajdź go w menu Start lub użyj paska wyszukiwania,
albo nawet powiedz: Hej, Cortana, otwórz Menedżera serwera. Przepraszam, nie mogłem się
powstrzymać. Bez względu na metodę otwórz Menedżera serwera na swoim komputerze,
a zobaczysz, że wygląda on i działa tak samo jak Menedżer serwera w systemie Windows
Server 2019. Na swoim komputerze klienckim możesz wykonać te same kroki co w systemie
operacyjnym serwera, aby dodać serwery w celu zarządzania nimi.
Na poniższym zrzucie ekranu można zauważyć, że w swoim Menedżerze serwera w Windows 10

mam teraz dostęp do funkcji monitorowania wszystkich serwerów z mojego laboratorium i za-
rządzania nimi, nawet bez logowania się na nich:
74
Czy to oznacza, że RDP jest martwy?

Czy nowe i ulepszone sposoby zarządzania podstawowymi komponentami serwerów bez
konieczności bezpośredniego logowania się na nich oznaczają, że można wyrzucić naszego
starego przyjaciela RDP? Zdecydowanie nie! Nadal będziesz czasami potrzebować bezpośred-
niego dostępu do swoich serwerów, nawet jeśli będziesz korzystać z nowszych narzędzi do
zarządzania. Spodziewam się również, że wielu administratorów będzie nadal wykorzystywać
protokół RDP i pełen dostęp do pulpitu w celu zarządzania wszystkimi serwerami i ich monito-
rowania — po prostu dlatego, że jest to dla nich wygodniejsze, nawet jeśli istnieją nowsze,
bardziej wydajne sposoby na osiągnięcie tego samego celu.
Remote Desktop Connection Manager

Ponieważ większość z nas nadal okazjonalnie (lub częściej) korzysta z protokołu RDP podczas
przełączania się między serwerami, rzućmy okiem na narzędzie, które może przynajmniej
uczynić to zadanie łatwiejszym do wykonania i centralnie zarządzanym. Nie poświęcę wiele
czasu na analizowanie jego poszczególnych funkcji lub możliwości, ponieważ jest ono narzę-
dziem klienckim, a nie czymś, co jest specyficzne dla systemu Windows Server 2019. Możesz je
wykorzystać do obsługi połączeń RDP dla wszystkich serwerów, a nawet wszystkich kompute-
rów klienckich w sieci. Remote Desktop Connection Manager jest niezwykle użyteczną
platformą służącą do przechowywania różnych połączeń RDP, które tworzysz w swoim śro-
dowisku. Możesz zapisywać połączenia, abyś nie musiał tracić czasu na zapamiętywanie
75
nazw serwerów, umieszczać je w odpowiednich kategoriach, a nawet przechowywać poświad-

czenia, by nie trzeba było wprowadzać haseł podczas łączenia się z serwerami. Uważaj jednak,
bo osoby odpowiedzialne za bezpieczeństwo systemów informatycznych mogą nie być zadowo-
lone, jeśli zdecydujesz się na użycie funkcji przechowywania haseł. Oto adres, z którego mo-
żesz pobrać aplikację: https://www.microsoft.com/en-us/download/details.aspx?id=44989.
Zamieściłem także poniższy zrzut ekranu — sam powinieneś zdecydować, czy to narzędzie
będzie przydatne w Twoich codziennych zadaniach:
Windows Admin Center (WAC)

Teraz zapomnij o wszystkim, co właśnie napisałem w poprzednim podrozdziale o zdalnym za-
rządzaniu serwerem, i skoncentruj się na tym, o czym za chwilę opowiem. Spokojnie, tak so-
bie tylko żartuję. Wszystkie narzędzia, które już omawialiśmy, są wciąż stabilne oraz właści-
we i stanowią doskonałe sposoby interakcji z serwerami Windows i zarządzania nimi. Jednak
w mieście pojawił się nowy dzieciak, a firma Microsoft oczekuje, że stanie się on bardzo
znany.
Windows Admin Center (WAC) to platforma do zarządzania serwerami i klientami, która

została zaprojektowana, aby pomóc w wydajniejszym administrowaniu komputerami. Jest to
narzędzie oparte na przeglądarce, co oznacza, że po jego zainstalowaniu uzyskujesz dostęp do
WAC z przeglądarki internetowej, co jest świetnym pomysłem. Nie musisz instalować na stacji
roboczej oddzielnej aplikacji do zarządzania — po prostu używasz odpowiedniego adresu URL.
WAC może zarządzać Twoimi serwerami (począwszy od wersji Server 2008 R2), ich klastrami,
a nawet ma pewne specjalne funkcje służące do zarządzania klastrami infrastruktury hiperkon-
wergentnej. Możesz także zarządzać komputerami klienckimi z systemem Windows 10.
76
Ile kosztuje to niesamowicie potężne narzędzie? Nic, jest rozdawane za darmo! Jeśli
interesowała Cię działalność firmy Microsoft w ciągu ostatniego roku, być może spo-
tkałeś się już z tym narzędziem w takiej czy innej formie. Czy słowa Project Honolulu
brzmią znajomo? Tak, Windows Admin Center to Project Honolulu, w końcu gotowy
do zastosowań produkcyjnych.
Windows Admin Center obsługuje nawet zewnętrznych dostawców, którzy mogą tworzyć
rozszerzenia interfejsu, więc to narzędzie będzie się wciąż rozwijało. Jeśli do tej pory naślado-
wałeś na swoim serwerze modyfikacje laboratorium testowego wprowadzone w tej w książce,
na pewno będziesz pamiętać Windows Admin Center z treści zawartej w wyskakującym oknie,
które pojawia się przy każdym otwarciu Menedżera serwera. Firma Microsoft tak bardzo
chce, aby administratorzy dowiedzieli się o aplikacji WAC, że przypomina Ci o tym narzę-
dziu za każdym razem, gdy logujesz się do serwera Server 2019. Widać to na poniższym
zrzucie ekranu:
Instalacja Windows Admin Center

Dość gadania, rozpocznijmy testy narzędzia! Najpierw musimy wybrać lokalizację instalacji
komponentów WAC. Co prawda stwierdziłem, że jedną z zalet programu jest to, że nie trzeba go
instalować, ale miałem raczej ma myśli to, że po wdrożeniu narzędzia WAC jego uruchomienie
jest tak proste jak otwarcie przeglądarki. Strona, która będzie otwarta, musi zostać gdzieś
zainstalowana i uruchomiona, nieprawdaż? Chociaż możesz umieścić cały system WAC na
kliencie Windows 10, przyjmijmy podejście, które będzie częściej stosowane w praktyce, i zain-
stalujmy go na serwerze w naszej sieci. Mam maszynę o nazwie WEB3, która nie obsługuje
jeszcze żadnych stron internetowych, więc uważam, że będzie ona dobrą lokalizacją docelową.
77
Pobierz Windows Admin Center z następującego adresu: https://www.microsoft.com/pl-pl/cloud-

-platform/windows-admin-center.
Po pobraniu wystarczy uruchomić instalator na komputerze hosta. Jest kilka prostych decyzji,
które należy podjąć w kreatorze instalacji. Najbardziej zauważalny jest ekran, na którym
określasz ustawienia portu i certyfikatu. W środowisku produkcyjnym najlepszym rozwiązaniem
będzie użycie portu 443 i podanie ważnego certyfikatu SSL, aby ruch do tej witryny i z niej
był odpowiednio chroniony przez protokół HTTPS. W swoim małym laboratorium zamierzam
użyć portu 443 z certyfikatem z podpisem własnym — wyłącznie do celów testowych. Nie
używaj certyfikatów z podpisem własnym w trybie produkcyjnym!
Po zakończeniu instalacji witryna Windows Admin Center zostanie umieszczona na naszym

serwerze. W przypadku mojej konkretnej instalacji właściwym adresem internetowym jest
https://WEB3.contoso.local.
Uruchamianie Windows Admin Center

A teraz pobawimy się trochę naszym nowym narzędziem. Aby skorzystać z Windows Admin
Center, wystarczy otworzyć obsługiwaną przeglądarkę na dowolnym komputerze podłączonym
do sieci i wprowadzić odpowiedni adres URL. Powtarzam, że w moim przypadku jest nim
https://WEB3.contoso.local. Co ciekawe, program Internet Explorer nie jest obsługiwaną prze-
78
glądarką. Microsoft zaleca Edge, ale WAC współpracuje również z Chrome1. Jestem zalo-
gowany na swojej stacji roboczej z systemem Windows 10, więc po prostu otworzę przeglą-
darkę Edge i spróbuję przejść do nowej witryny, jak pokazano na poniższym zrzucie ekranu:
Pojawi się ostrzeżenie dotyczące certyfikatu. Tego należało się spodziewać, ponieważ używamy
certyfikatu z podpisem własnym, co nie jest dobrym pomysłem. Jego użycie uzasadniam jedynie
tym, że pracuję w laboratorium testowym. Bardziej interesującym zdarzeniem związanym
z powyższym zrzutem ekranu jest jednak to, że pojawi się okno z prośbą o podanie poświad-
czeń. Mimo że zalogowałem się na komputerze z systemem Windows 10, który jest podłączony
do domeny, więc wykorzystuję jej poświadczenia, witryna internetowa WAC nie próbuje ich
automatycznie użyć, ale raczej stara się dowiedzieć, kim jest użytkownik. Jeśli po prostu podam
tutaj poświadczenia mojej domeny, zostanie mi przedstawiony interfejs Windows Admin Center,
jak pokazano na poniższym zrzucie ekranu:
1
Firefox również działa poprawnie — przyp. tłum.
79
Dodawanie większej liczby serwerów

do Windows Admin Center
Logowanie do WAC działa świetnie, ale będzie niezbyt przydatne, dopóki nie dodasz kilku kom-
puterów, którymi chcesz zarządzać. Aby to zrobić, wystarczy kliknąć przycisk +Add (+Dodaj)
pokazany na poprzednim zrzucie ekranu. Zostaną wyświetlone opcje dodania nowego serwera
lub komputera, klastra pracy awaryjnej, a nawet klastra hiperkonwergentnego. Dokonaj od-
powiednich wyborów i wprowadź wymagane dane. W swoim laboratorium testowym nie mam
jeszcze żadnych klastrów, więc dodam połączenia ze standardowymi serwerami, które urucho-
miłem w środowisku, jak pokazano na poniższym zrzucie ekranu:
80
Zarządzanie serwerem
przy użyciu Windows Admin Center
Rozpoczęcie zarządzania serwerem z poziomu WAC jest równie proste jak kliknięcie jego na-
zwy. Jak widać na poniższym zrzucie ekranu, wybrałem serwer DC1, ponieważ jest to obecnie
jedyna maszyna z zainstalowanymi i uruchomionymi prawdziwymi rolami:
Za pomocą powyższego interfejsu mogę zarządzać wieloma różnymi aspektami systemu opera-
cyjnego w swoim serwerze DC1. Są dostępne funkcje kontroli zasilania, jest możliwość urucha-
miania kopii zapasowych — mogę stąd nawet instalować certyfikaty! Możesz monitorować
wydajność serwera, przeglądać dzienniki zdarzeń, modyfikować ustawienia lokalnej zapory
systemu Windows i uruchamiać zdalne połączenie PowerShell z serwerem. Windows Admin
Center został stworzony po to, aby być kompleksowym punktem obsługi, zdalnie zarządzającym
Twoimi serwerami. Myślę, że jest on na dobrej drodze do tego celu.
W swoim laboratorium nie mam co prawda jeszcze żadnych instancji systemu Server Core,
ale zapewniam, że WAC może być używany do zarządzania nimi, a także serwerami w wersji
Desktop Experience. To sprawia, że Windows Admin Center staje się jeszcze bardziej wydajnym
i intrygującym narzędziem dla administratorów serwerów.
81
Umożliwienie szybkiego wdrożenia

serwera za pomocą narzędzia Sysprep
Na początku tego rozdziału przeprowadziliśmy instalację systemu operacyjnego Windows Server
2019 na nowym serwerze. Niezależnie od tego, czy mieliśmy do czynienia ze sprzętem fizycz-
nym czy maszyną wirtualną, proces instalacji był zasadniczo taki sam. Podłączenie dysku
DVD lub pamięci USB oraz wczytanie i uruchomienie instalatora jest dość łatwe, ale co będzie
w przypadku, gdy należy utworzyć 10 nowych serwerów zamiast tylko jednego? Ten proces
stanie się wkrótce nudny i wydawać się będzie, że marnujesz dużo czasu na powtarzanie tych
samych czynności. Jest w tym dużo prawdy — na szczęście istnieje łatwiejszy i szybszy sposób
na wdrożenie nowych serwerów, o ile każdy tworzysz mniej więcej na tej samej platformie
sprzętowej. Jeśli Twoje serwery mają być maszynami wirtualnymi, co obecnie jest dość częste,
ten sposób działa świetnie i może zaoszczędzić sporo czasu w przypadku nowych wersji
systemów operacyjnych.
Zanim zacznę dokładniej opisywać proces Sysprep, chciałbym wcześniej wspomnieć, że w infra-
strukturze Windows dostępnych jest więcej odpowiednich technologii, które umożliwiają
automatyczne wdrażanie systemu operacyjnego oraz instalowanie serwerów i mogą uczynić
ten proces jeszcze łatwiejszym, niż to narzędzie, o którym właśnie zamierzam opowiedzieć.
Problem z niektórymi zautomatyzowanymi technologiami polega na tym, że infrastruktura
wymagana do ich prawidłowego działania jest bardziej zaawansowana niż ta, która jest dostępna
dla większości osób dopiero uczących się obsługi systemu Windows Server. Innymi słowy,
dostępność w pełni zautomatyzowanego mechanizmu wdrażania serwerów nie jest zbyt realna
w małych środowiskach lub laboratoriach testowych, których większość z nas używa, ucząc się
nowych technologii.
Nie przeanalizujemy więc dokładniej automatycznych metod instalowania serwerów, ale po-
święcimy kilka minut dodatkowej pracy na naszej pierwszej maszynie, co następnie pozwoli
zaoszczędzić mnóstwo czasu na każdym innym serwerze, który zbudujemy później. Głównym
elementem całego procesu jest narzędzie Sysprep, które jest umieszczane we wszystkich wer-
sjach systemu Windows, dzięki czemu można je uruchomić na dowolnym komputerze, niezależ-
nie od tego, czy jest to klient czy serwer.
Sysprep to narzędzie, które przygotowuje system do wykonania duplikatu. Jego oficjalną nazwą
jest Microsoft System Preparation Tool. Mówiąc krótko, narzędzie pozwala utworzyć dla serwera
obraz wzorcowy, którego następnie można użyć dowolną liczbę razy w celu zainstalowania
dodatkowych maszyn. Kluczową zaletą korzystania z programu Sysprep jest to, że na swoim
serwerze możesz wprowadzić niestandardowe ustawienia i wcześniej zainstalować takie składniki
jak aktualizacje Windows, co spowoduje, że te wszystkie konfiguracje i łatki pojawią się w Twoim
obrazie wzorcowym. Korzystanie z Sysprep pozwala zaoszczędzić czas, ponieważ nie trzeba
przeprowadzać instalacji systemu operacyjnego. Dodatkowo oszczędzamy czas dzięki temu, że
nie czekamy, aż funkcja aktualizacji Windows zainstaluje wszystkie bieżące poprawki w każdym
nowo tworzonym systemie. W tym miejscu niektórzy czytelnicy mogą się zastanawiać, dlaczego
Sysprep jest w ogóle potrzebny.
82
Przecież jeśli chcesz sklonować serwer główny, możesz po prostu użyć narzędzia do tworzenia
obrazu dysku twardego lub (jeśli masz do czynienia z maszynami wirtualnymi) skopiować i wkleić
sam plik VHDX. Zgadza się, jednakże dużym problemem jest to, że właśnie utworzony nowy
obraz lub dysk twardy będzie dokładną repliką oryginalnego. Nazwa hosta będzie taka sama,
a co ważniejsze, identyczne będą również niektóre podstawowe informacje identyfikacyjne
w systemie Windows, takie jak numer identyfikatora zabezpieczeń systemu operacyjnego
(SID). Jeśli włączyłbyś zarówno oryginalny serwer główny, jak i nowy serwer oparty na dokład-
nej replice, spowodowałbyś konflikty i kolizje w sieci, ponieważ te dwie maszyny walczyłyby
o swoje prawo do bycia jedynym serwerem o unikatowej nazwie i wartości SID. Ten problem
nasila się w środowiskach domenowych, gdzie jeszcze ważniejsze jest, aby każdy system w sieci
miał unikatowe identyfikatory SID oraz GUID (identyfikator w usłudze Active Directory).
Jeśli utworzysz dokładne kopie serwerów i uruchomisz je, założę się, że żaden z nich nie będzie
zadowolony z tej sytuacji.
Narzędzie Sysprep rozwiązuje wszystkie problemy pojawiające się w procesie duplikacji syste-
mu przez zastosowanie losowo generowanych identyfikatorów. Aby przygotować się do wdroże-
nia wielu serwerów przy użyciu obrazu wzorcowego utworzonego za pomocą Sysprep, należy
wykonać następujące działania:
1. Zainstaluj system Windows Server 2019 na nowym serwerze.
2. Skonfiguruj ustawienia i aktualizacje na tym serwerze.
3. Uruchom narzędzie Sysprep, aby przygotować i wyłączyć serwer główny.
4. Utwórz swój wzorcowy obraz dysku.
5. Wdrażaj nowe serwery z użyciem kopii obrazu wzorcowego.
Poniżej omówimy te czynności bardziej szczegółowo.
Instalacja systemu Windows Server 2019

na nowym serwerze
Po pierwsze, tak jak już to robiłeś, musimy przygotować nasz pierwszy serwer — zainstalować
system operacyjny Windows Server 2019. Powstrzymaj się jednak od instalowania pełnych ról na
tym serwerze, ponieważ w zależności od ich rodzaju lub unikatowych konfiguracji uruchamiany
przez nas proces Sysprep może spowodować problemy z poszczególnymi ustawieniami ról.
Zainstaluj system operacyjny i upewnij się, że wszystkie sterowniki urządzeń są skonfigurowane,
a będziesz gotowy do wykonania następnego kroku.
Konfigurowanie ustawień i aktualizacji

na nowo utworzonym serwerze
W dalszej kolejności będziesz chciał na nowym serwerze skonfigurować ustawienia i zainstalo-
wać aktualizacje. Te ustawienia lub instalacje, które są takie same dla całej partii serwerów,
pozwolą Ci w przyszłości uniknąć konieczności wykonywania tego samego kroku na swoich
83
maszynach. To, co przed chwilą powiedziałem, może być nieco mylące, ponieważ wcześniej
mówiłem, aby nie instalować ról na serwerze głównym. Wynika to z faktu, że instalacja roli
powoduje wiele zmian w systemie operacyjnym. Niektóre z instalowanych ról wiążą się z okre-
śloną nazwą hosta zdefiniowanego w systemie. Jest bardzo prawdopodobne, że tego typu
rola przestałaby działać, gdyby została sklonowana na nowym serwerze. Modyfikacje, które
można wprowadzić na serwerze głównym, to między innymi umieszczanie plików i folderów,
które mogą być potrzebne na wszystkich serwerach, na przykład katalogu Narzędzia administra-
cyjne lub czegoś podobnego. Możesz także uruchamiać lub zatrzymywać usługi, które powinny
być tak samo zdefiniowane na każdym z Twoich serwerów, a także zmieniać ustawienia rejestru,
jeśli jest to element normalnego procesu przygotowywania serwera lub jego hardeningu.
Niezależnie od wprowadzonych modyfikacji warto wykonać pełen zestaw testów na pierwszym
nowym serwerze zbudowanym na podstawie obrazu wzorcowego, aby upewnić się, że wszystkie
zmiany zostały poprawnie zaakceptowane przez proces Sysprep.
Teraz możesz też zezwolić na zainstalowanie w nowym serwerze tych poprawek Windows,
które powinny się w przyszłości pojawić na wszystkich pozostałych maszynach. Nie ma nic
bardziej frustrującego niż instalacja nowego systemu operacyjnego w 5 minut, a następnie
czekanie 4 godziny na wgranie wszystkich aktualizacji i poprawek, zanim będzie można sko-
rzystać z nowego serwera. Jeśli uwzględnisz te wszystkie składniki w obrazie wzorcowym,
oszczędzisz czas, który w przeciwnym razie musiałbyś poświęcić na ich pobieranie i instalację
dla każdego z nowo tworzonych serwerów.
Aby oszczędzić czas i siły, twórz co kilka miesięcy nowe kopie obrazów wzorcowych.
W ten sposób najnowsze poprawki zawsze będą dołączane do obrazu wzorcowego,
co pozwoli zaoszczędzać coraz więcej czasu przez cały okres użytkowania systemu
Windows Server 2019.
Uruchomienie narzędzia Sysprep,

aby przygotować i wyłączyć serwer główny
Gdy mamy już odpowiednio przygotowany serwer główny, czas wreszcie uruchomić narzędzie
Sysprep. Aby to zrobić, otwórz wiersz poleceń z uprawnieniami administratora oraz przejdź
do katalogu C:\Windows\System32\Sysprep. Następnie uruchom znajdujący się tam program
Sysprep.exe, który jest właściwym narzędziem Sysprep.
Podobnie jak w przypadku wielu plików wykonywalnych uruchamianych z wiersza poleceń,

jest dużo opcjonalnych przełączników, które można dodać na końcu polecenia uruchamiającego
Sysprep.exe, aby wykonać określone zadania. Jeśli w oknie wiersza poleceń wprowadzisz po pro-
stu nazwę sysprep.exe, zobaczysz interfejs graficzny programu Sysprep, w którym możesz
wybrać odpowiednie opcje, jak pokazano na poniższym zrzucie ekranu:
84
Ponieważ do narzędzia Sysprep zawsze używam tego samego zestawu opcji, wolę po prostu
użyć wszystkich niezbędnych przełączników bezpośrednio w wierszu poleceń, dzięki czemu
całkowicie pomijam ekran graficzny. Oto kilka informacji o różnych przełącznikach, które można
wykorzystać:
 /quiet: nakazuje programowi, aby nie wyświetlał na ekranie komunikatów
o swoim działaniu.
 /generalize: określa, że Sysprep powinien usunąć wszystkie unikatowe informacje
systemowe (SID) z instalacji systemu Windows, dzięki czemu końcowego obrazu
będzie można używać na wielu komputerach w sieci, ponieważ każda nowa
maszyna wygenerowana z niego otrzyma odmienny, unikatowy SID.
 /audit: powoduje ponowne uruchomienie komputera w specjalnym trybie audytu,
w którym przed wykonaniem finalnego obrazu masz możliwość dodania
niestandardowych sterowników do systemu Windows.
 /oobe: powoduje, że przy następnym uruchomieniu systemu Windows zostanie
uruchomiony kreator uproszczonej konfiguracji.
 /reboot: uruchamia ponownie maszynę po zakończeniu działania narzędzia
Sysprep.
 /shutdown: wyłącza system (nie wykonuje restartu) po zakończeniu działania
narzędzia Sysprep. Jest to ważny przełącznik i zazwyczaj go używam.
 /quit: zamyka narzędzie Sysprep po zakończeniu jego działania.
 /unattend: można utworzyć specjalny plik answerfile, który będzie używany
w połączeniu z procesem Sysprep w celu dalszej konfiguracji nowych serwerów,
gdy staną się dostępne w sieci. Na przykład w tym pliku można określić, że określony
instalator lub plik wsadowy powinien zostać uruchomiony przy pierwszym
uruchomieniu systemu Windows już po użyciu narzędzia Sysprep. Może to być
przydatne do wykonywania wszelkiego rodzaju zadań porządkujących, na przykład
pliku wsadowego usuwającego wpisy w plikach dzienników po pierwszym
uruchomieniu nowo utworzonych serwerów.
85
Dwoma najważniejszymi przełącznikami niezbędnymi do utworzenia pliku obrazu wzorcowego,

którego będziemy mogli użyć do szybkiego wdrażania serwerów, są /generalize i /shutdown.
Przełącznik /generalize jest bardzo ważny, ponieważ w nowo utworzonych kopiach systemu
Windows, które są dostępne w sieci, powoduje zastąpienie wszystkich unikatowych informacji
identyfikacyjnych, czyli identyfikatorów SID. Dzięki temu nowe serwery mogą poprawnie
działać w sieci, w której znajduje się także serwer oryginalny. Przełącznik /shutdown również
jest bardzo istotny, ponieważ chcielibyśmy, aby po zakończeniu działania narzędzia Sysprep
główny serwer został natychmiast wyłączony, co pozwoli na utworzenie obrazu wzorcowego.
Upewnij się, że serwer NIE uruchomi się ponownie z systemem Windows, dopóki nie
utworzysz obrazu wzorcowego lub nie wykonasz wzorcowej kopii pliku VHDX. Przy
pierwszym uruchomieniu systemu Windows zostanie utworzony nowy identyfikator
SID, a przecież chciałbyś, aby to działanie wykonało się tylko na nowych serwerach,
które utworzyłeś na podstawie nowego obrazu.
Zamiast zaprezentować wszystkie przełączniki, a następnie pozwolić Ci podjąć decyzję o tym,

które z nich wybrać, pokażę Ci konfigurację najczęściej używaną przeze mnie. Wykorzystuję
przełącznik /generalize, aby uczynić swoje nowe serwery unikatowymi. Lubię także używać
przełącznika /oobe, aby podczas pierwszego uruchomienia systemu Windows na dowolnym
z moich nowych systemów pojawił się kreator uproszczonej konfiguracji. Oczywiście użyję rów-
nież przełącznika /shutdown, ponieważ chciałbym, aby serwer został wyłączony zaraz po zakoń-
czeniu działania narzędzia Sysprep. Dzięki temu będę mógł utworzyć kopię dysku twardego,
aby następnie użyć jej w postaci obrazu wzorcowego. Poniżej zaprezentowałem w pełni gotowe
polecenie sysprep:
sysprep.exe /generalize /oobe /shutdown
Po uruchomieniu tego polecenia zobaczysz, jak narzędzie Sysprep wykonuje pewne działania
w systemie Windows, a po kilku minutach wyłącza serwer, jak pokazano na poniższym zrzucie
ekranu:
Możesz teraz utworzyć obraz wzorcowy z dysku twardego.
86
Tworzenie wzorcowego obrazu dysku

Nasz serwer główny został zamknięty i jesteśmy gotowi do utworzenia na jego podstawie
obrazu wzorcowego. Jeśli jest to serwer fizyczny — możesz użyć dowolnego narzędzia do two-
rzenia obrazów dysku twardego. Narzędzie do zarządzania obrazami, na przykład stworzone
przez firmę Acronis, wygeneruje pojedynczy plik z Twojego dysku. Będzie on zawierać obraz
całego dysku, którego w przyszłości użyjesz do odtworzenia systemów operacyjnych w nowych
serwerach. Z drugiej strony większość czytelników w codziennym życiu zawodowym ma praw-
dopodobnie do czynienia z serwerami wirtualnymi, a przygotowanie nowych maszyn w świecie
wirtualnym jest jeszcze łatwiejsze. Gdy zakończy się działanie narzędzia Sysprep na serwerze
głównym, który następnie zostanie zamknięty, wystarczy utworzyć kopię pliku VHDX. Cała
praca polega na zalogowaniu się na serwer Hyper-V oraz skopiowaniu i wklejeniu pliku dysku
twardego. Aby ułatwić obserwowanie bieżącego stanu tego pliku, możesz nadać mu nazwę
WS2019_Wzorcowy_z_aktualizacjami.VHDX lub dowolną inną. Zapisz plik obrazu lub kopię
pliku VHDX w bezpiecznym miejscu w sieci, z którego będziesz mógł szybko go pobrać,
gdy zajdzie potrzeba uruchomienia nowego systemu Windows Server 2019.
Wdrażanie nowych serwerów przy użyciu kopii obrazu

wzorcowego
Teraz przejdziemy do prostszej części zadania. W przyszłości, aby utworzyć nowy serwer, wy-
starczy skopiować i wkleić plik wzorcowy w nowej lokalizacji zdefiniowanej dla planowanej
maszyny, zmienić jego nazwę w taki sposób, aby był odpowiedni dla tworzonego serwera, a na-
stępnie uruchomić nową maszynę wirtualną. Oto korzyść w postaci czasu zaoszczędzonego
przez narzędzie Sysprep — możesz teraz jednocześnie wdrażać wiele serwerów przez szybkie
skopiowanie i wklejenie pliku obrazu wzorcowego, by następnie uruchomić każdą nową maszy-
nę na jego podstawie. Nie trzeba instalować systemu Windows ani wyciągać zakurzonego
dysku instalacyjnego DVD!
Gdy nowo utworzone serwery włączą się po raz pierwszy i uruchomią system Windows, pojawi
się na nich gotowy do użycia kreator uproszczonej konfiguracji. Ponadto system operacyjny
otrzyma w tle losową i unikatową nazwę hosta oraz wartość identyfikatora SID, dzięki czemu
będziesz mieć pewność, że w sieci nie występują żadne konflikty.
Serwery utworzone z pliku obrazu wygenerowanego przez narzędzie Sysprep zawsze

otrzymują nową nazwę hosta podczas uruchamiania. Jest to często mylące dla administra-
torów, którzy mogli inaczej nazwać swój serwer główny, na przykład jako MASTER.
Po uruchomieniu nowych serwerów możesz więc się spodziewać losowych nazw hostów,
które będziesz musiał odpowiednio zmienić, by odzwierciedlały ich role w firmie.
Na przykład serwer, nad którym pracowałem, otrzymał nazwę DC1 przed uruchomieniem
narzędzia Sysprep i utworzeniem obrazu wzorcowego, pierwotnie bowiem zamierzałem go
użyć jako kontrolera domeny w mojej sieci. Ponieważ jednak nie zainstalowałem na nim odpo-
87
wiedniej roli ani nie skonfigurowałem żadnej związanej z nią domeny, był on idealnym kandy-
datem do zaprezentowania działania procesu Sysprep, więc użyłem go przykładowo podczas
pisania tej książki. Uruchomiłem na nim narzędzie Sysprep, zamknąłem go, wykonałem kopię
jego pliku VHDX (która stała się wzorcowym plikiem obrazu), a następnie ponownie go uru-
chomiłem. Teraz we właściwościach systemu możesz zauważyć, że nazwa hosta stała się losowa,
zatem jeśli nadal chciałbym używać tego serwera jako DC1, musiałbym ją zmienić, gdy zakończy
się wczytywanie systemu poprzez kreatora uproszczonej konfiguracji, co pokazano na poniższym
zrzucie ekranu:
Mam nadzieję, że zaprezentowany przeze mnie proces pomoże zaoszczędzić czas podczas two-
rzenia nowych serwerów w Twoim środowisku. Wypróbuj go koniecznie następnym razem,
gdy będziesz musiał zainstalować nową maszynę! Możesz dodatkowo skorzystać z narzędzia
Sysprep, przechowując wiele różnych plików obrazów wzorcowych. Być może masz kilka ro-
dzajów serwerów, które regularnie instalujesz. Nic nie stoi na przeszkodzie, abyś utworzył od-
powiednią liczbę serwerów głównych, a na ich podstawie — różne obrazy wzorcowe.
Podsumowanie
Każdy, kto jest zainteresowany stanowiskiem administratora systemu Windows Server, musi
wprawnie instalować serwery i nimi zarządzać. Te czynności stanowią ważną podstawę do dal-
szych działań. W dzisiejszym świecie IT powszechne stało się dokładne testowanie nowych
wersji systemu operacyjnego, zarówno dlatego, że dzięki technologiom wirtualizacji zasoby
sprzętowe serwera są dla nas tak łatwo dostępne, jak też dlatego, że większość systemów bizne-
sowych jest teraz projektowana w taki sposób, by działać bezprzerwowo. Taki poziom niezawod-
ności wymaga bardzo dokładnego testowania wszelkich zmian platformy. Aby przeprowadzić
testy systemu operacyjnego Windows Server 2019 w swoim środowisku, będziesz musiał po-
święcić sporo czasu na wielokrotne wykonywanie podstawowych procesów instalacyjnych.
Mam nadzieję, że dobrze wykorzystasz sugestie zawarte w tym rozdziale, aby zaoszczędzić
dodatkowe cenne minuty podczas wykonywania tych zadań w świecie systemów Windows
Server.
Wiele lat temu sporo wysiłku włożono w ustalenie, które role i usługi mogłyby współistnieć,
ponieważ wówczas liczba dostępnych serwerów była ograniczona. Dzięki nowemu paradygma-
towi wirtualizacji i chmury wiele firm ma właściwie nieograniczoną liczbę serwerów, które
mogą być uruchamiane, a to oznacza, że obsługujemy znacznie większą liczbę maszyn, które
wykonują te same zadania i funkcje. Procesy zarządzania i administrowania tymi serwerami stają
88
się wówczas kosztami działów IT, dlatego zastosowanie scentralizowanych narzędzi i rozwiązań
dostępnych w systemie Windows Server 2019 pozwala zaoszczędzić sporo czasu i wysiłku
podczas codziennej pracy. W następnym rozdziale przyjrzymy się podstawowym usługom
infrastrukturalnym.
Pytania
1. Jak nazywa się nowe sieciowe narzędzie służące do centralnego zarządzania
serwerami firmy Microsoft (wcześniej znane jako Project Honolulu)?
2. Windows Server 2019 musi zostać zainstalowany na sprzęcie serwerowym
umożliwiającym montaż w szafie — prawda czy fałsz?
3. Jeśli wybierzesz domyślną opcję instalacji systemu Windows Server 2019, uzyskasz
interfejs użytkownika podobny do systemu Windows 10 — prawda czy fałsz?
4. Jak nazywa się polecenie cmdlet programu PowerShell, które wyświetla obecnie
zainstalowane role i funkcje w systemie Windows Server 2019?
5. Menedżera serwera można używać do zarządzania wieloma różnymi serwerami
jednocześnie — prawda czy fałsz?
6. Jak nazywa się zestaw narzędzi, który można zainstalować na komputerze z systemem
Windows 10 w celu uruchomienia Menedżera serwera?
7. Jakie przeglądarki internetowe mogą być używane z platformą Windows
Admin Center?
89
90
3
Podstawowe usługi
infrastrukturalne
Każdy z czytelników tej książki ma odmienne nabyte umiejętności i poziom doświadczenia

w środowisku Windows Server. Jak wspomniałem, sprawienie, by serwery poprawnie używały
systemu operacyjnego, jest właściwym i bardzo ważnym pierwszym krokiem procesu, którego
zadaniem jest wykonanie prawdziwej pracy w Twoim środowisku. Dopóki nie zrozumiesz,
jakie są cele głównych ról dostępnych w systemie Windows Server 2019, i ich nie poznasz,
Twój serwer będzie jedynie zużywać energię elektryczną.
Serwer jest przeznaczony do obsługi danych. Rodzaje danych, które udostępnia, oraz cel,
jakiemu one służą, zależą całkowicie od tego, jakie role serwer powinien obsługiwać. Musisz
po prostu zainstalować role w systemie Windows Server 2019, aby móc coś zrobić. Wiesz
już, jak zainstalować role na serwerze, ale nie omawialiśmy żadnego związanego z nimi celu.
W tym rozdziale przyjrzymy się podstawowym rolom infrastrukturalnym dostępnym w systemie
Windows Server. Przeanalizujemy ogólne cele ról, a także zdefiniujemy wybrane zadania,
które są z nimi związane i które będziesz musiał codziennie wykonywać jako administrator
serwera.

 Co to jest kontroler domeny?
 Używanie roli AD DS do zarządzania siecią.
 Potęga zasad grupy.
 System nazw domen (DNS).
 DHCP a adresowanie statyczne.
 Kopia zapasowa i jej przywracanie.
 Skróty MMC i MSC.
Co to jest kontroler domeny?

Omówienie podstawowych usług infrastrukturalnych, których potrzebujesz, aby uruchomić
sieć obsługiwaną przez produkty firmy Microsoft, najlepiej rozpocząć od roli kontrolera domeny.
Kontroler domeny (ang. Domain Controller — DC) jest centralnym punktem kontaktowym
i czymś w rodzaju głównego koncentratora, do którego dostęp uzyskuje się przed rozpoczęciem
prawie każdego rodzaju komunikacji sieciowej. Najłatwiej można go zdefiniować jako pojemnik
do przechowywania wszystkich danych identyfikacyjnych w sieci. Nazwy użytkowników,
hasła, konta komputerów, grupy komputerów, serwery, grupy i kolekcje serwerów, zasady
bezpieczeństwa, usługi replikacji plików i wiele innych elementów jest przechowywanych
w kontrolerze domeny i zarządzanych przez niego. Jeśli w sieci zorientowanej na produkty
firmy Microsoft nie zamierzasz zdefiniować jednego z pierwszych powstałych serwerów jako
kontrolera domeny, równie dobrze możesz nie zaczynać jej budować. Kontrolery domeny mają
zasadnicze znaczenie dla sposobu, w jaki komputery i urządzenia komunikują się ze sobą
oraz z infrastrukturą serwerów wewnątrz naszych firm.
Active Directory Domain Services

Jeśli właśnie przestałeś czytać tę książkę, aby zainstalować rolę kontrolera domeny na serwe-
rze, witaj ponownie, ponieważ nie ma żadnej roli o nazwie Domain Controler. Odpowiednia
rola nazywa się Active Directory Domain Services, w skrócie AD DS. To jest właściwa rola,
którą musisz zainstalować na serwerze. Jej zainstalowanie zmieni serwer w kontroler domeny.
Celem uruchomienia kontrolera domeny jest utworzenie katalogu lub bazy danych obiektów
w sieci. Ta baza danych jest znana jako Active Directory i jest platformą, na której budujesz
hierarchiczną strukturę do przechowywania obiektów, takich jak nazwy użytkowników, hasła
i konta komputerowe.
Po utworzeniu domeny, w której możesz przechowywać różne dane, możesz następnie założyć
konta użytkowników i hasła, które będą wykorzystywane przez pracowników do uwierzytel-
niania. Następnie możesz dołączyć inne serwery i komputery do tej domeny, aby mogły akcep-
tować poświadczenia użytkowników i z nich korzystać. Posiadanie domeny i dołączenie urządzeń
do niej to tajny przepis na sukces, który pozwoli Ci przeglądać komputery w firmie i logować się
do każdego z nich przy użyciu własnej nazwy użytkownika i hasła, nawet jeśli nigdy wcze-
śniej tego w nich nie robiłeś. Jeszcze bardziej imponująca jest funkcjonalność umożliwiająca
aplikacjom kompatybilnym z usługą Active Directory uwierzytelnianie się w razie potrzeby
bezpośrednio w niej. Na przykład, gdy jako użytkownik domeny loguję się do komputera
w pracy przy użyciu swojej nazwy użytkownika i hasła, system operacyjny Windows działający
na moim komputerze kontaktuje się z serwerem kontrolera domeny i sprawdza, czy moje
hasło jest poprawne.
Gdy kontroler domeny potwierdzi, że naprawdę jestem tym, za kogo się podaję, wydaje token
uwierzytelniający i przesyła go z powrotem na mój komputer, dzięki czemu jestem w stanie
się zalogować. Później otwieram jakąś aplikację — powiedzmy, że jest nią Outlook, dzięki
któremu chcę uzyskać dostęp do swojej poczty e-mail. Ten program pocztowy został zapro-
92
Rozdział 3. • Podstawowe usługi infrastrukturalne
jektowany w taki sposób, aby połączyć się z serwerem poczty elektronicznej zwanym serwerem
Exchange, a następnie uwierzytelnić się na nim, by się upewnić, że zostanie udostępniona
skrzynka pocztowa należąca do mnie, a nie do jakiegoś innego użytkownika. Czy to oznacza,
że muszę ponownie wprowadzić nazwę użytkownika i hasło do programu Outlook lub jakiejkol-
wiek innej aplikacji, którą otwieram z komputera? Otóż nie. Powodem, dla którego nie mu-
szę ponownie wprowadzać danych uwierzytelniających, jest to, że moja nazwa użytkownika,
mój komputer i serwery aplikacji są częścią domeny. Jeśli jest to prawdą i dotyczy większo-
ści sieci, mój token uwierzytelniania może być współużytkowany przez różne programy.
Gdy więc zaloguję się do komputera, moje programy będą mogły uruchamiać się i otwierać,
a także przekazywać dane uwierzytelniające poprzez serwer aplikacji bez potrzeby żadnych
dodatkowych działań z mojej strony. Byłoby to naprawdę frustrujące doświadczenie, gdyby-
śmy wymagali od swoich użytkowników wprowadzania haseł za każdym razem, gdy otwie-
rają programy, których potrzebują do wykonywania swojej pracy.
Pierwszy skonfigurowany kontroler domeny będzie miał pełne uprawnienia do zapisu oraz
będzie mógł przyjmować dane od przyłączonych do domeny użytkowników i komputerów
pracujących w sieci. W rzeczywistości większość kontrolerów domeny w sieci będzie najpraw-
dopodobniej w pełni funkcjonalna. Warto jednak poświęcić krótką chwilę, aby wspomnieć
o kontrolerze domeny o ograniczonym zakresie działania, zwanym kontrolerem domeny tylko
do odczytu (ang. Read-Only Domain Controller — RODC). Jak sama nazwa wskazuje, z kontro-
lera RODC można jedynie odczytywać dane. Modyfikacje, które mogą być wykonywane
w domenie, takie jak zmiana hasła lub utworzenie nowego konta użytkownika, są niemożliwe
przy użyciu kontrolera RODC. Zamiast tego kontrolery RODC czytają od innych, bardziej
tradycyjnych kontrolerów domeny dane katalogowe, a następnie wykorzystują je do weryfikacji
żądań uwierzytelnienia pochodzących od użytkowników i komputerów. Gdzie taki kontroler
domeny o ograniczonym dostępie miałby zastosowanie? Wiele firm instaluje je w mniejszych
oddziałach lub mniej bezpiecznych biurach, aby lokalne komputery w tych miejscach miały
szybki i łatwy dostęp do odczytu i uwierzytelniania w domenie, bez możliwości naruszania
polityki bezpieczeństwa związanego z dostępem nieautoryzowanego użytkownika do serwera
fizycznego i modyfikowania domeny w nieodpowiedni sposób.
Sama usługa Active Directory jest wystarczająco obszernym zagadnieniem, aby można było
jej poświęcić całą książkę, i rzeczywiście wiele napisano na jej temat. Skoro masz już podsta-
wową wiedzę na temat tego, czym ona jest i dlaczego powinniśmy jej używać w środowisku
Windows Server, zajmijmy się czymś bardziej praktycznym i skorzystajmy z niektórych narzędzi
zainstalowanych na kontrolerze domeny podczas instalacji roli AD DS.
Używanie roli AD DS do zarządzania siecią

Nie istnieje jedno narzędzie, które służy do zarządzania wszystkimi aspektami usługi Active
Directory. Ze względu na zaawansowaną technologię konfiguracja katalogu jest zarządzana przez
wiele różnych konsol. Rzućmy okiem na każdą z nich i przeanalizujmy najczęstsze zadania,
które będziesz wykonywać w tych narzędziach. Każdą z konsol zarządzania można uruchomić
93
z dowolnego serwera kontrolera domeny. Jak widziałeś w poprzednim rozdziale, najłatwiejszym

sposobem uruchamiania tych konsol jest menu Narzędzia dostępne w prawym górnym narożniku
Menedżera serwera.
Active Directory Users and Computers

Zacznę od aplikacji, która jest alfabetycznie ostatnia na liście narzędzi Active Directory, ponie-
waż zdecydowanie jest ona najczęściej wykorzystywana w codziennej pracy administratora
serwera. Narzędzie Active Directory Users and Computers (Użytkownicy i komputery usługi
Active Directory) to konsola, z której są tworzone i zarządzane wszystkie konta użytkowników
i komputerów. Otwórz ją, a w lewej kolumnie zobaczysz nazwę swojej domeny. Po rozwinię-
ciu tej nazwy pojawi się lista folderów. Jeśli uruchomiłeś to narzędzie w istniejącym kontrolerze
domeny zarządzającym dobrze rozwiniętą siecią, będziesz mógł zauważyć wiele elementów
składowych. Jeśli używasz nowo utworzonego środowiska, lista folderów będzie niewielka. Naj-
ważniejszymi elementami, na które należy zwrócić uwagę, są Computers (Komputery) i Users
(Użytkownicy). Zgodnie ze zdrowym rozsądkiem są to domyślne kontenery, w których będą
umieszczane nowe konta komputerowe i konta użytkowników dołączane do domeny.
Chociaż okno wygląda trochę jak Eksplorator plików z drzewem folderów, nie są one tak na-
prawdę żadnymi katalogami. Większość folderów reprezentowanych przez ikony w kolorze żół-
tym jest znana pod nazwą jednostek organizacyjnych (ang. Organizational Units — OU).
Mam na myśli większość, ponieważ istnieje kilka poprawnych kontenerów, które służą do prze-
chowywania elementów, ale nie są one oficjalnie jednostkami organizacyjnymi. Te, które wskaza-
liśmy wcześniej, czyli Users i Computers, są w rzeczywistości kontenerami ogólnego zasto-
sowania i nie są prawdziwymi jednostkami organizacyjnymi. Jednak wszelkie nowe foldery,
które utworzysz w AD, będą jednostkami organizacyjnymi. Różnicę można zauważyć w wyglą-
dzie ikon. Na poniższych zrzutach ekranu widać, że niektóre ikony mają dodatkową grafikę
nałożoną na obraz reprezentujący folder. Tylko te katalogi, których ikony zawierają dodatkowy,
mały element, są prawdziwymi jednostkami organizacyjnymi.
Jednostki organizacyjne to kontenery strukturalne, których używamy w usłudze Active Directory

w celu organizowania swoich obiektów i przechowywania ich w odpowiednich miejscach.
Podobnie jak w przypadku folderów na serwerze plików, możesz tutaj utworzyć własną hierar-
chię jednostek organizacyjnych, aby w usłudze Active Directory sortować i modyfikować
położenie wszystkich obiektów sieciowych i urządzeń przyłączonych do domeny. Na poniższym
zrzucie ekranu można zauważyć, że zamiast używać zwykłych folderów Users i Computers,
utworzyłem kilka nowych jednostek organizacyjnych, włącznie z podkategoriami (bardziej ofi-
cjalnie nazywanych zagnieżdżonymi jednostkami organizacyjnymi), dzięki czemu wraz z rozwo-
jem środowiska będę dysponował lepiej uporządkowaną strukturą i zorganizowanym katalogiem:
94
Konta użytkowników
Mamy już gotowe jednostki organizacyjne służące do przechowywania naszych obiektów,
stwórzmy więc nowego użytkownika. Załóżmy, że mamy nowego administratora serwera,
więc powinniśmy mu zdefiniować konto w usłudze Active Directory, aby mógł rozpocząć
pracę. Po prostu znajdź odpowiednią jednostkę organizacyjną, w której założysz konto, kliknij
prawym przyciskiem myszy jej ikonę i z menu podręcznego wybierz opcję New/User
(Nowy/Użytkownik). Pojawi się okno dialogowe umożliwiające wprowadzenie wszelkich
niezbędnych informacji, których AD potrzebuje do utworzenia nowego konta. Większość
z wyświetlonych pól jest zrozumiała, ale jeśli dopiero zaczynasz korzystać z usługi Active
Directory, chciałbym zwrócić uwagę na pole User logon name (Nazwa logowania użytkownika).
Wszelkie umieszczone w nim informacje będą stanowić oficjalną nazwę użytkownika w sieci.
Podczas każdego logowania się do komputera lub serwera będzie on musiał podać tę nazwę.
Po zakończeniu wprowadzania danych nasz nowy administrator będzie mógł użyć swojej nazwy
użytkownika i hasła w celu zalogowania się do komputerów i serwerów w sieci, oczywiście
w ramach zasad bezpieczeństwa ustanowionych na tych urządzeniach. Jest to jednak temat
następnego rozdziału.
95
Grupy zabezpieczeń
Innymi przydatnymi jednostkami organizacyjnymi w usłudze Active Directory są grupy zabez-
pieczeń (ang. Security Groups). Jednostki organizacyjne pozwalają odróżnić typy i rodzaje
użytkowników od kont komputerowych, ale jak poradzić sobie w sytuacji, gdy swoją upo-
rządkowaną strukturę trzeba trochę „zanieczyścić krzyżowo”? Być może masz pracownika,
który zajmuje się kadrami i realizuje pewne operacje księgowe. Jeszcze bardziej prawdopodobne
jest, że tak skonfigurowałeś uprawnienia do plików i folderów na swoich serwerach plików,
aby tylko osoby należące do niektórych grup miały możliwość odczytu i zapisu w określonych
folderach. Zuzanna z działu HR musi mieć dostęp do folderu płac, ale Janek z tego samego
działu już nie. Zarówno Zuzanna, jak i Janek znajdują się w tej samej jednostce organizacyjnej,
więc na tym poziomie będą mieli te same uprawnienia i możliwości. Wyraźnie jednak potrzebu-
jemy innego sposobu ich rozróżnienia, aby tylko Zuzanna miała dostęp do informacji o liście
płac. Utworzenie grup zabezpieczeń w usłudze Active Directory umożliwia dodawanie i usuwa-
nie określonych kont użytkowników, kont komputerów, a nawet innych grup, dzięki czemu
możemy precyzyjnie określać dostęp do zasobów. Nowe grupy tworzysz w taki sam sposób jak
konta użytkowników. Wyszukujesz jednostkę organizacyjną, w której dana grupa powinna
się znajdować, klikasz prawym przyciskiem myszy i wybierasz opcję New/Group (Nowy/Grupa).
Po utworzeniu grupy kliknij ją prawym przyciskiem myszy i przejdź do opcji Properties
(Właściwości). Następnie możesz kliknąć zakładkę Members (Członkowie) — w tym miejscu
dodasz wszystkich użytkowników, którzy mają należeć do tej nowej grupy:
96
Wstępne przygotowywanie kont komputerów

Konsola Active Directory Users and Computers jest bardzo często używana do tworzenia nowych
kont użytkowników, ponieważ bez wykonania tego działania nowo zatrudniona osoba nie będzie
mogła w ogóle się zalogować w sieci. O wiele rzadziej jednak myśli się o użyciu tego narzędzia
podczas dodawania nowych komputerów do domeny, większość domen jest bowiem skonfigu-
rowana w taki sposób, że nowe komputery mogą zostać dodane do domeny przez odpowiednie
działania wykonywane w nich samych, bez wcześniejszej pracy w konsoli Active Directory.
Innymi słowy, jeśli ktoś potrafi się zalogować użytkownikiem mającym uprawnienia administra-
cyjne w domenie, może usiąść przy dowolnym komputerze podłączonym do sieci i w nim
lokalnie przeprowadzić proces dołączania go do domeny. Zadanie zakończy się powodzeniem,
a Active Directory automatycznie utworzy nowy obiekt komputera. Te automatycznie gene-
rowane obiekty pojawiają się domyślnie w kontenerze Computers, więc jeśli go otworzysz,
zobaczysz w przypadku wielu sieci listę zawierającą różne komputery, zarówno stacjonarne,
jak i serwery, które zostały niedawno dołączone do domeny i których jeszcze nie przeniesiono
do odpowiedniej, właściwszej jednostki organizacyjnej. W swoim rozbudowywanym środowisku
laboratoryjnym dołączyłem ostatnio wiele komputerów do domeny. Zrobiłem to bez otwierania
konsoli Active Directory Users and Computers, a jednak można zauważyć, że nowo dodane
obiekty komputerów znajdują się w domyślnym kontenerze Computers:
97
Zezwolenie, by nowe konta komputerów pojawiały się w domyślnym kontenerze Computers,

nie stanowi zazwyczaj większego problemu dla systemów klienckich, ale jeśli pozwolisz na
automatyczne umieszczanie tam serwerów, może to powodować poważne kłopoty. Wiele
firm używa sieciowych zasad bezpieczeństwa, które są często tworzone w taki sposób, że są
stosowane do każdego konta komputera znajdującego się w jednej z ogólnych jednostek organi-
zacyjnych. Korzystanie z zasad bezpieczeństwa może być świetnym sposobem na zablokowanie
tych obszarów komputerów klienckich, do których użytkownik nie musi uzyskiwać dostępu
ani z których nie musi korzystać. Jeśli jednak przypadkowo sprawisz, że te zasady blokowania
zostaną zastosowane na nowych serwerach, które dopiero pojawiły się w domenie, mogą je sku-
tecznie uszkodzić, zanim jeszcze zaczniesz je konfigurować. Możesz mi uwierzyć, kiedyś tak
zrobiłem. Niestety, Twoje nowe konta serwerów, które zostaną dodane do Active Directory,
zostaną zidentyfikowane i skategoryzowane w taki sam sposób jak każda stacja robocza klienta
dodana do domeny. Nie możesz więc zdefiniować innego domyślnego kontenera dla serwerów
tylko z tego powodu, że nie są zwykłymi stacjami roboczymi.
Co więc można zrobić, aby rozwiązać ten potencjalny problem? Odpowiedzią jest wstępne
przygotowanie kont domenowych dla nowych serwerów. Zasadniczo możesz wstępnie przygo-
towywać wszystkie nowe konta komputerowe, ale zazwyczaj jest to wymagane tylko w dużych
przedsiębiorstwach. Wstępne utworzenie konta komputera przypomina tworzenie nowego konta
użytkownika. Przed dołączeniem komputera do domeny tworzysz dla niego obiekt w usłudze
Active Directory. Zakładając obiekt przed procesem przyłączania komputera do domeny,
możesz wybrać, w której jednostce organizacyjnej będzie się on znajdować. Oprócz tego możesz
się upewnić, że będzie to jednostka organizacyjna z odpowiednimi ustawieniami i zasadami
bezpieczeństwa, które zamierzasz stosować na nowo utworzonym komputerze lub serwerze.
Zdecydowanie zalecam wstępne przygotowywanie kont komputerów w usłudze Active Directory
dla wszystkich nowych serwerów udostępnianych w sieci. Jeśli sprawisz, że stanie się to praktyką,
98
stworzysz dobry nawyk, który nawet jeśli nie będzie zawsze wymagany, może Cię kiedyś
uratować przed koniecznością odbudowywania serwera, który zepsujesz przez zwykłe przyłą-
czenie go do swojej domeny.
Przygotowanie obiektu komputera jest niezwykle szybkie i proste — zróbmy to razem. W przy-
szłości planuję utworzyć system Windows Server obsługujący rolę dostępu zdalnego, aby
podłączać użytkowników mobilnych do sieci z ich domów, kawiarni itd. Niektóre komponenty
zawarte w roli Remote Access są „wybredne”, jeśli chodzi o bezpieczeństwo sieci, dlatego
wolałbym się upewnić, że mój nowy serwer RA1 nie otrzyma całego zestawu zasad blokowania,
gdy tylko dołączę go do domeny. Wcześniej utworzyłem jednostkę organizacyjną o nazwie
Remote Access Servers, a teraz wstępnie przygotuję w niej obiekt komputera dla swojego
serwera RA1.
Kliknij prawym przyciskiem myszy jednostkę OU Remote Access Servers, a następnie wybierz
opcję New/Computer (Nowy/Komputer). Potem w polu Computer name (Nazwa komputera)
podaj nazwę swojego serwera. Chociaż jeszcze nie utworzyłem serwera, planuję go nazwać RA1,
więc wpisuję tę nazwę w polu:
Otóż to! Za pomocą kilku prostych kliknięć myszą i przez wpisanie nazwy jednego serwera
przygotowałem (wstępnie utworzyłem) obiekt mojego komputera dla serwera RA1. Jeśli przyj-
rzysz się uważnie poprzedniemu zrzutowi ekranu, zauważysz, że możesz również ustalić,
którzy użytkownicy lub jakie grupy mogą dołączać ten konkretny komputer do domeny. Jeśli
planujesz zbudować nowy serwer i chciałbyś się upewnić, że będziesz jedyną osobą, która
może go dołączyć do domeny, powinieneś zaktualizować odpowiednie pole, aby spełnić ten
wymóg.
99
Gdy zacznę budować serwer i przejdę do dalszych kroków związanych z przyłączeniem go do

mojej domeny, Active Directory powiąże go z wcześniej zdefiniowanym obiektem RA1, zamiast
tworzyć zupełnie nowy obiekt w ogólnym kontenerze Computers:
Active Directory Domains and Trusts

To narzędzie jest zwykle używane tylko w większych środowiskach, które mają więcej niż jedną
domenę w ramach tej samej sieci. Firma może wykorzystywać wiele nazw domen w celu segre-
gacji zasobów lub usług albo w celu uzyskania lepszej struktury organizacyjnej dla swoich
serwerów i przestrzeni nazw. Istnieje również inny poziom w hierarchicznej strukturze usługi
Active Directory, o którym jeszcze nie wspominałem — jest on nazywany lasem (ang. forest).
Las jest zasadniczo najwyższym poziomem struktury usługi Active Directory, a wszystkie
domeny i poddomeny znajdują się pod nim. Innym sposobem myślenia o lesie jest obszar Twojej
struktury AD. Jeśli masz wiele domen znajdujących się w jednym lesie, niekoniecznie oznacza
to, że mogą one sobie ufać. Tak więc w zależności od poziomu zaufania między domenami użyt-
kownicy z jednej z nich mogą (ale nie muszą) mieć uprawnienia do korzystania z zasobów innej
domeny. Gdy masz jakąś domenę i dodajesz do niej domeny podrzędne, między tymi dome-
nami definiowane są automatycznie relacje zaufania. Jeśli jednak chcesz połączyć niektóre
domeny w taki sposób, aby uzyskać niestandardowe uprawnienia, narzędzie Active Directory
Domains and Trusts (Domeny i relacje zaufania usługi Active Directory) może Ci posłużyć
do ich ustanawiania i modyfikowania.
Rozwijające się organizacje często znajdują się w sytuacji, w której muszą regularnie zarządzać
relacjami zaufania w wyniku przejęć biznesowych. Jeśli firma Contoso przejmie Fabrikam,
wówczas zakładając, że obie mają w pełni funkcjonalne środowiska domenowe, często korzystne
będzie wykonanie rozszerzonego procesu migracji w celu przeniesienia pracowników firmy
Fabrikam do Active Directory firmy Contoso, w przeciwnym razie należałoby ponieść
wszelkie straty związane z wyłączeniem sieci Fabrikam. Tak więc przez pewien czas obie
domeny musiałyby działać jednocześnie, mając ustanowioną relację zaufania między nimi.
100
Jeśli znajdziesz się w sytuacji, w której konieczna będzie jakakolwiek migracja domeny, zainte-
resuj się narzędziem, którego możesz użyć. Nazywa się ono Active Directory Migration
Tool (ADMT) i może być bardzo przydatne w sytuacjach takich jak ta opisana wcześniej.
Gdybyś chciał się zapoznać z tym narzędziem, możesz je pobrać z następującego adresu:
https://www.microsoft.com/en-us/download/details.aspx?id=19188.
Active Directory Sites and Services

Active Directory Sites and Services (Lokalizacje i usługi Active Directory) to następne narzędzie
zwykle wykorzystywane tylko przez firmy, które mają większą infrastrukturę Active Directory.
Jeśli posiadanie jednego kontrolera domeny jest dobre, wówczas posiadanie dwóch kontrolerów
domeny jest jeszcze lepsze. Wraz ze wzrostem firmy rośnie również infrastruktura Active
Directory. Zanim się zorientujesz, będziesz chciał skonfigurować serwery w drugiej lokalizacji,
następnie w trzeciej itd. Posiadanie serwerów kontrolera domeny w każdym znaczącym
miejscu jest ogólnie przyjętą praktyką w sieci zorientowanej na domeny. Być może wkrótce
będziesz miał dziesiątki serwerów będących kontrolerami domeny działającymi w sieci.
Uruchamianie nowych kontrolerów domeny i dołączanie ich do istniejącej domeny w celu

obsługi użytkowników oraz komputerów jest dość łatwe. Najtrudniejsze jest utrzymanie całego
ruchu i płynności działania tam, gdzie jest to konieczne. Jeśli zarządzasz głównym centrum
danych, w którym znajduje się większość Twoich serwerów, prawdopodobnie masz tam wiele
kontrolerów domeny. Aby Twoja usługa AD była wysoce dostępna, musisz mieć co najmniej
dwa kontrolery domeny. Załóżmy, że zamierzasz wybudować nowe biuro, na tyle duże, by można
było zainstalować w nim również lokalny serwer kontrolera domeny, dzięki czemu komputery
nie będą musiały się komunikować przez sieć rozległą (WAN) w celu uwierzytelniania. Jeśli
musiałbyś uruchomić serwer w nowym biurze i przekształcić go w kontroler domeny dla swojej
sieci, mógłby on zacząć działać natychmiast. Problem polega na tym, że komputery klienckie nie
zawsze są wystarczająco inteligentne, aby wiedzieć, z którym kontrolerem domeny muszą
się komunikować. Może się więc zdarzyć, że Twoje komputery w zdalnym biurze nadal będą
uwierzytelniać się w kontrolerach domeny głównego centrum danych. Co gorsza, niektóre
z nich będą używały sieci WAN, aby uwierzytelnić się za pomocą nowego kontrolera domeny
dostępnego w Twoim zdalnym biurze, nawet jeśli znajduje się on w sieci lokalnej!
W takiej sytuacji narzędzie Active Directory Sites and Services staje się niezbędne. Za jego
pomocą budujesz różne fizyczne witryny i przypisujesz do nich kontrolery domeny. Użytkownicy
i komputery przyłączeni do domeny podlegają teraz regułom wprowadzonym za pośrednictwem
tego narzędzia, dzięki czemu zawsze łączą się ze swoimi lokalnymi kontrolerami domeny i uwie-
rzytelniają się na nich. To oszczędza czas, ponieważ połączenia są szybsze i bardziej wydajne,
a także chroni przed niepotrzebnym przesyłaniem danych po sieci WAN, co często oszczędza
także pieniądze.
Oto krótka prezentacja narzędzia Active Directory Sites and Services. Jak widać, na liście przed-
stawiono wiele lokalizacji, które są powiązane z odpowiednimi informacjami o podsieciach.
W ten sposób następuje odwzorowanie adresów IP na odpowiednie lokalizacje. Gdy komputer
kliencki przechodzi w tryb online, wie na podstawie adresu IP, którego używa, jakiej podsieci
jest częścią. Ten adres informuje także narzędzie Active Directory Sites and Services o tym,
101
w której lokalizacji przebywa obecnie klient. Identyfikacja lokalizacji pomaga następnie usłudze
Active Directory w kierowaniu żądań uwierzytelnienia do odpowiednich kontrolerów domeny.
Wspomaga także inne składniki domeny, takie jak zasady grupy (które wkrótce omówimy),
ponieważ umożliwia przetwarzanie informacji specyficznych dla lokalizacji. Jeśli jesteś częścią
rozwijającej się organizacji, jest duża szansa, że pewnego dnia będziesz musiał skorzystać z tego
narzędzia:
Active Directory Administrative Center

Chociaż do zarządzania usługą Active Directory niezbędne jest zapoznanie się z narzędziami,
które do tej pory przeanalizowaliśmy, a także zrozumienie ich działania, możesz stwierdzić,
że ich interfejs jest nieco przestarzały. Z drugiej strony narzędzie Active Directory Administrative
Center (Centrum administracyjne usługi Active Directory — ADAC) ma znacznie usprawniony
interfejs, wyglądający jak nowy Menedżer serwera, którego obsługa jest coraz bardziej komfor-
towa. Wiele funkcji dostępnych w ADAC realizuje te same czynności, które możemy wykonać za
pomocą innych narzędzi, jednakże znajdują się one w bardziej uporządkowanym interfejsie
i są łatwiej dostępne dla użytkownika, który może je szybko uruchomić.
Świetnym przykładem tej funkcjonalności jest główna strona narzędzia ADAC. Częstym zada-
niem pracowników pomocy technicznej w dowolnej sieci jest resetowanie haseł do kont użyt-
kowników. Bez względu na to, czy użytkownik zapomniał hasła, zmienił je ostatnio, ale wpisał
niepoprawnie, czy też administrator musiał zresetować hasło podczas rozwiązywania proble-
mów, ta czynność zwykle wymaga wielu kliknięć myszą w narzędziu Active Directory Users
and Computers. Na głównej stronie centrum administracyjnego usługi Active Directory mamy
obecnie dostępne szybkie łącze Reset Password (Resetowanie hasła). Przydatna jest także znaj-
dująca się obok funkcja Global Search (Wyszukiwanie globalne), która pobiera dowolny ciąg
102
znaków. Zostanie on następnie przeszukany w całym katalogu. To kolejne typowe zadanie

w środowisku Active Directory, które wcześniej wymagało wielu kliknięć:
Jeśli klikniesz nazwę swojej domeny w drzewie nawigacyjnym znajdującym się po lewej stronie
okna, dokładniej poznasz możliwości ADAC. Jak widzimy, wyświetlane tutaj informacje są
pobierane z Active Directory i wyglądają tak samo jak te, które można zobaczyć w narzędziu
Active Directory Users and Computers. To prawda, z wyjątkiem tego, że zamiast musieć klikać
prawym przyciskiem myszy w celu wykonania administracyjnych czynności, takich jak tworzenie
nowych użytkowników lub wyszukiwanie, masz dostępnych po prawej stronie okna kilka opcji,
które pozwolą na szybki dostęp do odpowiednich funkcji. Interesujące są również łącza pozwa-
lające na podniesienie poziomu funkcjonalności lasu lub domeny. Wykonanie tych zadań za
pomocą klasycznych narzędzi wymaga najczęściej uruchomienia interfejsu Active Directory
Domains and Trusts. Jedną z największych zalet nowszego narzędzia ADAC jest to, że jest ono
w stanie udostępnić scentralizowany interfejs zarządzania, z którego można wykonywać zadania
wymagające w razie jego braku użycia wielu okien i konsol zarządzania. Czy dostrzegasz, że
zastosowano tu znajomą strategię polegającą na scentralizowanym zarządzaniu wszystkimi
aspektami środowiska w systemie Windows Server 2019?
103
Dynamic Access Control

Oprócz uczenia starych psów nowych sztuczek Centrum administracyjne usługi Active Directory
wprowadza nowe funkcje, które nie są dostępne w żadnym z klasycznych narzędzi. Jeśli ponownie
spojrzysz na drzewo po lewej stronie okna, zobaczysz, że następną sekcją na liście jest Dynamic
Access Control (Dynamiczna kontrola dostępu — DAC). Jest to technologia zarządzająca
bezpieczeństwem plików i danych firmowych, które musisz chronić przed nieautoryzowanym
dostępem. DAC umożliwia oznaczanie plików, a tym samym klasyfikowanie ich do określonych
grup lub zastosowań. Następnie możesz utworzyć zasady kontroli dostępu, które określają,
kto ma dostęp do tych wyróżnionych plików. Inną potężną możliwością dynamicznej kontroli do-
stępu jest funkcja raportowania. Po zdefiniowaniu i uruchomieniu w swoim środowisku
kontroli dostępu możesz tworzyć raporty i analizy śledcze dotyczące plików, na przykład uzy-
skać listę osób, które ostatnio uzyskały dostęp do jakiegoś dokumentu niejawnego.
Dynamiczna kontrola dostępu może być również używana do modyfikowania uprawnień

użytkowników w zależności od tego, jakiego urządzenia w danej chwili używają. Jeśli nasz
użytkownik Zuzanna zaloguje się do sieci na swojej firmowej stacji roboczej, powinna mieć
dostęp do poufnych plików działu HR. Z drugiej strony, jeśli przyniesie prywatnego laptopa
do biura i połączy go z siecią, możemy nie pozwolić jej na dostęp do tych samych plików,
nawet gdy poprawnie poda poświadczenia użytkownika jej domeny. Powodem tego odmien-
nego zachowania jest to, że po prostu nie zarządzamy zabezpieczeniami w jej laptopie i nie
znamy ich. Tego rodzaju rozróżnienia można wprowadzać za pomocą zasad dynamicznej
kontroli dostępu.
Kontrolery domeny tylko do odczytu (RODC)

Nie możemy podsumować naszego przeglądu ważnych narzędzi i składników usługi Active
Directory bez bardziej szczegółowego omówienia kontrolerów domeny tylko do odczytu
(RODC). Instalując nowe kontrolery domeny w sieci, dodajesz zazwyczaj odpowiednią rolę
w taki sposób, że stają się one standardowymi, w pełni funkcjonalnymi systemami z możli-
wością zapisu, dzięki czemu mogą realizować wszystkie zadania roli AD DS. Istnieją pewne
okoliczności, w których nie jest to najlepszy wybór, i właśnie w takich sytuacjach kontrolery
RODC mogą służyć pomocą. Nie instaluje się ich z użyciem oddzielnej roli, raczej w inny
sposób konfiguruje się tę samą rolę AD DS podczas przechodzenia przez kolejne okna kreatora
nowego kontrolera domeny. RODC to wyspecjalizowany kontroler domeny, do którego nie można
zapisywać nowych danych. Zawiera buforowaną kopię tylko niektórych części katalogu, któ-
ra ma dostęp tylko do odczytu. Możesz polecić kontrolerowi RODC, aby zachował kopię
wszystkich poświadczeń w domenie, a nawet nakazać mu, by zapamiętał listę tylko tych,
które będą ważne dla tego konkretnego kontrolera. Jakie są powody korzystania z kontrolerów
RODC? Odpowiedzią są oddziały firmy i strefy DMZ.
Jeśli w firmie istnieje mniejszy oddział z niewielką liczbą zatrudnionych osób, być może warto
mieć lokalny kontroler domeny, aby przetwarzanie danych logowania było szybkie i wydajne.
Ponieważ jednak nie potrafisz w pełni zarządzać bezpieczeństwem fizycznym w tym małym
biurze, wolałbyś nie używać tam w pełni funkcjonalnego kontrolera domeny, który ktoś mógłby
ukraść. W tym przypadku można wykorzystać kontroler RODC. Inna sytuacja dotyczy bez-
104
piecznej sieci DMZ. Taką sieć strefową zwykle projektuje się pod kątem bardzo ograniczonego
dostępu, ponieważ jest podłączona do publicznego internetu. Niektóre z Twoich serwerów
i usług znajdujących się w sieci DMZ mogą wymagać dostępu do usługi Active Directory.
Nie chcesz jednakże otwierać kanału komunikacyjnego łączącego strefę DMZ z pełnoprawnym
kontrolerem domeny w sieci lokalnej. Możesz więc zdefiniować kontroler RODC w strefie DMZ,
nakazać mu buforowanie informacji potrzebnych do obsługi określonych serwerów, które się
w niej znajdują, i dzięki temu stworzyć znacznie bezpieczniejsze środowisko domeny lub
subdomeny.
Potęga zasad grupy

W sieci opartej na serwerach Windows i usłudze Active Directory podstawowy zbiór komputerów
klienckich prawie zawsze również jest oparty na systemach operacyjnych Microsoft Windows;
wszystkie te maszyny są przyłączone do domeny. Konfigurowanie wszystkiego w ten sposób
w usłudze Active Directory nie tylko ma sens w kontekście wewnętrznego zorganizowania
danych, ale także umożliwia scentralizowane uwierzytelnianie na różnych urządzeniach i w róż-
nych aplikacjach, o czym już wspominałem. Wiem, że przedstawiając wcześniej kilka przykła-
dów, stwierdzałem coś w stylu: „A co w sytuacji, gdy firma ma zasady bezpieczeństwa, które…”
lub „Upewnij się, że Twoje serwery nie wczytają istniejących zasad bezpieczeństwa, ponie-
waż…”. Jakie są więc te magiczne zasady bezpieczeństwa i jak je skonfigurować?
Odpowiedzią jest potęga zasad grupy. Umożliwia ona tworzenie obiektów zasad grupy (ang.
Group Policy Objects — GPO) zawierających ustawienia i konfiguracje, które chcesz zastosować
do komputerów lub użytkowników w domenie Active Directory. Po utworzeniu obiektu GPO
z różnymi ustawieniami możesz umieścić go w odpowiednim miejscu katalogu domeny. Jeśli
masz zasadę, którą chciałbyś zastosować do wszystkich systemów komputerowych, możesz
przypiąć ją do odpowiedniej jednostki organizacyjnej lub grupy zabezpieczeń w usłudze
Active Directory, która zawiera wszystkie komputery stacjonarne dołączone do domeny. A może
utworzyłeś obiekt GPO, który dotyczy tylko komputerów z systemem Windows 7? Możesz
użyć odpowiedniego filtrowania, aby tylko określone systemy otrzymały zasady. Prawdziwą
magią jest to, że wprowadzanie ustawień odbywa się automatycznie — po prostu przez dołącze-
nie komputerów do Twojej domeny. Nie musisz wcale logować się na systemy klienckie, aby
przekazywać im ustawienia przez GPO. Za pomocą zasad grupy możesz dostosować lub zablo-
kować prawie wszystkie składniki w systemie operacyjnym Windows.
Po raz kolejny patrzę na listę dostępnych ról w moim systemie Windows Server 2019 i po
prostu nie widzę żadnej o nazwie Group Policy. Powtarzam: nie ma takiej roli! Okazuje się
jednak, że jeśli powtarzasz kroki wykonane podczas konfigurowania środowiska laboratoryjnego
w tej książce, masz już w pełni funkcjonalne zasady grupy w sieci. Wszystko, czego potrzebują
zasady grupy do działania, jest już zawarte w roli Active Directory Domain Services. Tak więc
jeśli w sieci zainstalowałeś kontroler domeny, masz również zasady grupy działające na tym sa-
mym serwerze, ponieważ wszystkie informacje, które one wykorzystują, są przechowywane
w katalogu. Instalacja roli AD DS jest wszystkim, czego potrzebujemy, aby korzystać z zasad
grupy. Taką rolę już zainstalowaliśmy na naszym kontrolerze domeny, zatem przejdźmy od razu
105
do rzeczy i przeanalizujmy kilka zagadnień, które od razu pozwolą Ci zacząć korzystać w swoim
środowisku z zasad grupy. Przez lata współpracowałem z wieloma małymi przedsiębiorstwami,
które używały systemu Windows Server, ponieważ wszyscy tak właśnie robili. Niestety,
informatyk lub firma, która konfigurowała serwer, z pewnością nigdy nie powiedzieli niczego na
temat obiektów GPO, więc sytuacja wyglądała tak, że to potężne narzędzie po prostu było
schowane w pudełku, nikt go nie używał i mogło ono jedynie czekać na uwolnienie. Jeśli jeszcze
nie używasz obiektów zasad grupy, chcę, abyś otworzył to pudełko i dał im szansę.
Domyślne zasady domeny

Najpierw musisz się dowiedzieć, czego należy użyć w naszym kontrolerze domeny, abyśmy
mogli stworzyć i modyfikować obiekty zasad grupy. W systemie Windows Server 2019 centralną
platformą służącą do otwierania różnych konsoli jest narzędzie Menedżer serwera. Kliknij więc
menu Tools (Narzędzia) i wybierz opcję Group Policy Management (Zarządzanie zasadami grupy).
Po otwarciu konsoli rozwiń nazwę lasu w drzewie nawigacyjnym znajdującym się po lewej
stronie okna, a następnie rozwiń opcję Domains (Domeny) i wybierz nazwę domeny. Wewnątrz
zobaczysz kilka znajomo wyglądających elementów. Będzie tam lista jednostek organizacyj-
nych, które utworzyłeś wcześniej, a także kilka innych folderów:
Wkrótce wyjaśnię, dlaczego znajduje się tu lista jednostek organizacyjnych. Na razie chciałbym
jednak omówić jeden obiekt zasad grupy, który zwykle znajduje się na jej górze, bezpośrednio
pod nazwą Twojej domeny. Nazywa się on Default Domain Policy (Domyślne zasady domeny).
106
Ten obiekt GPO jest podczas instalacji domyślnie podłączony do usługi Active Directory i jest
stosowany do każdego użytkownika i komputera, który jest częścią katalogu domeny. Ponieważ
jest on aktywny od samego początku i używany przez wszystkie elementy katalogu, może
być centralnym miejscem pozwalającym na egzekwowanie globalnych zasad haseł lub reguł
bezpieczeństwa, które muszą obowiązywać wszystkich w firmie.
Kliknięcie prawym przyciskiem myszy dowolnego obiektu GPO wyświetlanego w konsoli

zarządzania, a następnie wybranie opcji Edit… (Edytuj…) spowoduje otwarcie nowego okna
z edytorem, który będzie zawierać wszystkie elementy wewnętrzne danej zasady. Tutaj wprowa-
dzasz wszelkie ustawienia lub konfiguracje, które mają być częścią danego obiektu zasad
grupy. Przejdź więc do edycji domyślnych zasad domeny, a następnie wybierz opcję Computer
Configuration/Policies/Windows Settings/Security Settings/Account Policies/Password Policy
(Konfiguracja komputera/Zasady/Ustawienia systemu Windows/Ustawienia zabezpieczeń/Zasady
konta/Zasady haseł):
W tym miejscu możesz zobaczyć listę różnych dostępnych opcji umożliwiających konfigu-
rowanie zasad haseł w Twojej domenie. Dwukrotne kliknięcie dowolnego z tych ustawień
pozwala je zmodyfikować, a zmiana natychmiast zaczyna obowiązywać na wszystkich kompute-
rach przyłączonych w sieci do domeny. Na przykład widzimy, że domyślna wartość parametru
Minimum password length (Minimalna długość hasła) jest ustawiona na 7 znaków. Wiele firm
analizowało już zagadnienie związane ze standardową długością haseł w komputerach podłączo-
nych do sieci. Aby pozwolić infrastrukturze katalogowej zaakceptować podjętą decyzję, wystar-
czy zmodyfikować to pole. Zmiana minimalnej długości hasła na 12 znaków wymagałaby odpo-
wiednich modyfikacji dla wszystkich kont użytkowników przy następnym resetowaniu haseł.
Jeśli przyjrzysz się drzewu opcji w edytorze Group Policy Management Editor (Edytor za-
rządzania zasadami grupy), zauważysz, że istnieje niewiarygodnie duża liczba ustawień i konfi-
guracji, które można zmodyfikować za pomocą zasad grupy. Chociaż domyślne zasady domeny to
bardzo szybki i łatwy sposób na skonfigurowanie niektórych ustawień i przekazanie ich wszyst-
kim, należy ostrożnie wprowadzać zmiany w taki sposób. Za każdym razem, gdy wprowadzasz
107
tu zmianę ustawienia, pamiętaj, że wpłynie ona na wszystkie obiekty w Twojej domenie, wlicza-
jąc w to Ciebie. Wiele razy będziesz jednak tworzyć zasady, które nie muszą mieć zastosowania
do wszystkich. W takich przypadkach zdecydowanie zaleca się unikanie domyślnych zasad do-
meny, a zamiast tego skonfigurowanie zupełnie nowego obiektu zasad grupy do zadania, które
zamierzasz zrealizować. W rzeczywistości niektórzy administratorzy zalecają, aby w ogóle nie
używać domyślnych zasad domeny, a w sytuacji, w której należy zdefiniować nowe ustawienia,
utworzyć oddzielny obiekt zasad grupy. W praktyce wiele firm korzysta z wbudowanych
domyślnych zasad domeny jedynie w celu spełnienia wymagań dotyczących złożoności haseł1.
Wszystkie inne modyfikacje lub ustawienia powinny zostać uwzględnione w nowym obiekcie
zasad grupy.
Tworzenie i podłączanie nowego obiektu zasad grupy

Jeśli najlepszą, ogólnie przyjętą praktyką w sytuacji, gdy musimy zastosować pewne ustawie-
nia, jest utworzenie nowego obiektu zasad grupy, powinieneś poświęcić chwilę na zapozna-
nie się z tym procesem. W naszym przykładzie utworzymy nowy obiekt GPO, który podłą-
cza listę zaufanych witryn do programu Internet Explorer zainstalowanego na komputerach
stacjonarnych. Jeśli uruchamiasz aplikację sieciową, która musi obsługiwać kontrolki JavaScript,
ActiveX lub inne, to żeby zapewnić jej poprawne działanie w przeglądarce Internet Explorer,
być może będziesz musiał dodać daną stronę do listy zaufanych. Możesz wydrukować instrukcje
dla kolegów z helpdesku, by wiedzieli, w jaki sposób należy zmodyfikować każdy z kompu-
terów, a następnie pozwolić im obsłużyć wszystkie zgłoszenia od użytkowników, którzy będą
dzwonić, ponieważ nie będą mieli dostępu do aplikacji. Możesz też po prostu utworzyć obiekt
GPO, który dokonuje tych zmian automatycznie na każdej stacji roboczej, i uniknąć dodatkowej
pracy i rozmów telefonicznych. To tylko jeden mały przykład potęgi zasad grupy. Jest on jednak
odpowiedni, ponieważ tworzy coś użytecznego i wykorzystuje parametr, który jest głęboko
schowany w ustawieniach GPO, dzięki czemu można się dowiedzieć, jak wysoki poziom szcze-
gółowości one mają.
W konsoli zarządzania zasadami grupy kliknij prawym przyciskiem myszy folder o nazwie Group
Policy Objects (Obiekty zasad grupy), a następnie wybierz opcję New (Nowe). Nazwij odpowied-
nio swój nowy obiekt zasad grupy — mój nazywa się Adding Trusted Sites (Dodawanie zaufanych
witryn), a następnie kliknij przycisk OK. Nowy obiekt zasad grupy pojawi się teraz na liście
dostępnych obiektów, ale nie ma jeszcze zastosowania do żadnego użytkownika ani komputera.
Zanim przypiszemy komukolwiek ten nowy obiekt GPO, utwórzmy listę zaufanych witryn,
aby zasady zawierały odpowiednie informacje o konfiguracji. Mamy nowe zasady, ale obecnie są
one pozbawione jakichkolwiek ustawień.
1
Ponieważ w całej domenie jest możliwe użycie tylko jednej, wspólnej zasady dotyczącej złożoności
haseł, nie można utworzyć oddzielnego obiektu GPO, który pozwalałby na stosowanie innych ustawień
np. dla określonej jednostki organizacyjnej. Jedynym rozwiązaniem jest więc zdefiniowanie globalnych
ustawień w domyślnych zasadach domeny — przyp. tłum.
108
Kliknij prawym przyciskiem myszy nowo utworzony obiekt zasad grupy i wybierz opcję Edit…
(Edytuj…). Następnie przejdź do opcji Computer Configuration/Policies/Administrative
Templates/Windows Components/Internet Explorer/Internet Control Panel/Security Page
(Konfiguracja komputera/Zasady/Szablony administracyjne/Składniki systemu Windows/Internet
Explorer/Internetowy panel sterowania/Strona zabezpieczeń). A nie mówiłem, że tam znaj-
dziemy to ustawienie?
Teraz dwukrotnie kliknij pozycję Site to Zone Assignment List (Lista przypisywanie witryn
do stref) i ustaw ją na Enabled (Włączone). Dzięki temu będziesz mógł kliknąć przycisk
Show… (Pokaż…), w którym wybierzesz strony internetowe i przypiszesz im strefy. Każde
ustawienie GPO zawiera dokładny opis, który dokładnie informuje, do czego służą i co oznaczają
określone opcje. Aby ustawić witryny jako zaufane, muszę nadać im wartość strefy równą 2.
Z ciekawości dodałem także witrynę, która nie powinna być dostępna dla moich użytkowników,
i nadałem jej wartość strefy równą 4, dzięki czemu strona badsite.contoso.com stała się elemen-
tem strefy witryn z ograniczeniami na wszystkich moich komputerach stacjonarnych. Oto
moja pełna lista — zobacz pierwszy rysunek na następnej stronie.
Czy to wszystko? Prawie. Gdy tylko kliknę przycisk OK, ustawienia zostaną zapisane w moim
obiekcie zasad grupy i będą gotowe do wdrożenia. Dotąd jednak nowego obiektu zasad gru-
py do niczego nie przypisałem, więc po prostu oczekuje on na zastosowanie.
109
Wróć do konsoli zarządzania zasadami grupy i znajdź lokalizację, z którą chcesz połączyć ten
nowo utworzony obiekt GPO. Możesz połączyć obiekt zasad grupy z całą domeną w sposób
podobny do stosowania domyślnych zasad domeny, ale wówczas dotyczyłby wszystkich elemen-
tów. W rezultacie zacząłby on obowiązywać na każdym komputerze w sieci domeny. W naszej
sytuacji nie chcielibyśmy, aby ustawienia zaufanych witryn były globalne, dlatego utworzymy
łącze do określonej jednostki organizacyjnej. W ten sposób nowy obiekt zasad grupy będzie
miał zastosowanie tylko do komputerów przechowywanych w tej jednostce OU. Chciałbym
przypisać obiekt GPO do jednostki organizacyjnej Accounting Desktops, którą utworzyłem
wcześniej. Po prostu wyszukuję tę jednostkę OU, klikam ją prawym przyciskiem myszy, a na-
stępnie wybieram opcję Link an Existing GPO… (Połącz z istniejącym obiektem zasad grupy…):
Teraz widzę listę obiektów GPO, które można połączyć. Wybierz nowo utworzony obiekt
Adding Trusted Sites, a następnie kliknij przycisk OK — to wszystko! Nowy obiekt zasad grupy
jest teraz połączony z jednostką organizacyjną Accounting Desktops i zastosuje swoje ustawienia
do wszystkich komputerów, które w niej umieszczę.
Możesz połączyć obiekt zasad grupy z więcej niż jedną jednostką organizacyjną. Po prostu
wykonaj ponownie ten sam proces, tym razem wybrawszy inną jednostkę organizacyj-
ną, w której chcesz utworzyć łącze, a dany obiekt zasad grupy zacznie działać w obu
jednostkach organizacyjnych. Możesz również usunąć pojedyncze łącza po tym, jak klik-
niesz sam obiekt zasad grupy i wyświetlisz jego właściwości.
110
Filtrowanie obiektów zasad grupy

z uwzględnieniem określonych urządzeń
Po utworzeniu obiektu zasad grupy i powiązaniu go z określoną jednostką organizacyjną
masz wystarczającą ilość informacji, aby naprawdę zacząć korzystać z zasad grupy w swoim
środowisku. Używanie łączy w celu ustalenia, którzy użytkownicy lub maszyny powinni wyko-
rzystywać określone zasady, jest najczęstszą metodą stosowaną przez administratorów. Jest jed-
nak wiele sytuacji, w których musisz wykonać coś więcej. Co będzie w przypadku, gdy nowy
obiekt zasad grupy połączyłeś z jednostką organizacyjną, która zawiera wszystkie komputery
stacjonarne, jednak później zdecydowałeś, że niektóre z nich nie powinny używać tej zasady?
Problemem stanie się umieszczenie komputerów w dwóch oddzielnych jednostkach organiza-
cyjnych tylko ze względu na tworzone zasady. Wchodzimy tu w zakres zagadnienia o nazwie
GPO Security Filtering (Filtrowanie zabezpieczeń).
Filtrowanie zabezpieczeń to możliwość przydzielania obiektu zasad grupy do określonych

obiektów usługi Active Directory. Dla dowolnego obiektu zasad grupy można ustawić filtry, by
dotyczył on tylko określonych użytkowników, komputerów, a nawet grup użytkowników lub
komputerów. Uważam, że używanie grup jest szczególnie przydatne. Tak więc w przypadku
poprzedniego przykładu z zasadą, która powinna działać tylko w niektórych komputerach
stacjonarnych, moglibyśmy utworzyć nową grupę zabezpieczeń w usłudze Active Directory
i dodać do niej wyłącznie te komputery. Po powiązaniu obiektu zasad grupy z grupą wymie-
nioną w sekcji filtrowania zasady będą miały zastosowanie tylko w komputerach należących
do tej grupy. Jeśli w przyszłości trzeba będzie usunąć zasadę z niektórych komputerów lub
dodać ją do nowych, wystarczy po prostu dodać komputery do grupy lub je z niej usunąć i wcale
nie będzie trzeba modyfikować obiektu zasad grupy.
Sekcja Filtrowanie zabezpieczeń jest wyświetlana po kliknięciu dowolnego obiektu zasad grupy
z poziomu konsoli zarządzania zasadami grupy. Otwórz więc konsolę GPMC i po prostu
kliknij jeden z obiektów zasad grupy. Po prawej stronie okna pojawi się zakładka Scope (Zakres).
W górnej części zakładki znajduje się obszar o nazwie Links (Linki), w którym pokazano łącza
aktywne dla danej zasady. W dolnej połowie zakładki wyświetlono sekcję Security Filtering
(Filtrowanie zabezpieczeń). Widzimy, że połączyłem mój obiekt zasad grupy z jednostką organi-
zacyjną Accounting Desktops, a ponadto ustawiłem dodatkowy filtr zabezpieczeń, aby tylko
komputery należące do grupy Accounting — Trusted Sites faktycznie wczytały ustawienia
z tego obiektu zasad grupy (zobacz rysunek na następnej stronie).
Inną ciekawą funkcją, którą można wykorzystać, jest zakładka Settings (Ustawienia),
znajdująca się na tym samym ekranie. Kliknij tę zakładkę, aby wyświetlić konfigurację
zdefiniowaną w Twoim obiekcie zasad grupy. Jest to bardzo przydatne do sprawdza-
nia obiektów GPO utworzonych przez kogoś innego, możesz bowiem się dowiedzieć,
które ustawienia zostały modyfikowane.
111
Jak wspomniałem, mógłbyś zająć się dowolną z konsol zarządzania lub tematem dotyczącym
podstawowych usług infrastruktury w systemie Windows Server i stworzyć na tej podsta-
wie własną książkę. Tak właśnie zrobiłem w przypadku zasad grupy. Jeśli chcesz dowiedzieć
się więcej o zasadach grupy i sposobach, w jakie można je wykorzystać do zabezpiecze-
nia infrastruktury, zapoznaj się z książką Mastering Windows Group Policy (wyd. Packt,
https://www.packtpub.com/networking-and-servers/mastering-windows-group-policy).
System nazw domen (DNS)

Jeśli uznamy rolę Active Directory Domain Services za najczęściej wykorzystywaną i główną
rolę podczas tworzenia sieci zorientowanych na produkty firmy Microsoft, wówczas rola
Domain Name System (System nazw domen, w skrócie DNS) znajdzie się na drugim miejscu.
Nie spotkałem jeszcze administratora, który zdecydował się wdrożyć domenę bez jednoczesnego
wdrożenia DNS — te dwie role zawsze idą w parze.
DNS to usługa, która zazwyczaj jest dostarczana przez system Windows Server. Istnieje
jednak wiele różnych platform, poczynając od serwerów Linux, a kończąc na wyspe-
cjalizowanych urządzeniach zaprojektowanych specjalnie do zarządzania usługą DNS
w sieci, które można wykorzystać w tym celu. W przypadku większości sieci zoriento-
wanych na produkty firmy Microsoft, a także na potrzeby tej książki, założymy, że będziesz
chciał używać systemu Windows Server 2019 do obsługi roli DNS.
112
Usługa DNS jest podobna do Active Directory, ponieważ jest strukturalną bazą danych, którą
często przechowuje się na serwerach kontrolera domeny i automatycznie dystrybuuje w sieci
do innych kontrolerów domeny i serwerów DNS. Baza danych AD zawiera informacje o samych
obiektach domeny, a usługa DNS jest odpowiedzialna za przechowywanie i rozpoznawanie
wszystkich nazw w sieci. Co mam na myśli, używając słowa „nazwy”? Za każdym razem, gdy
użytkownik lub komputer próbuje skontaktować się z dowolnym zasobem z użyciem jego
nazwy, DNS próbuje przekształcić ją w coś innego, aby zezwolić na ruch sieciowy do właściwego
miejsca docelowego. Przesyłanie danych z klienta do serwera odbywa się za pośrednictwem
sieci (zazwyczaj poprzez stos TCP/IP) przy wykorzystaniu adresu IP miejsca docelowego.
Gdy otwieram aplikację na komputerze, aby uzyskać dostęp do niektórych danych znajdujących
się na serwerze, mogę skonfigurować ją w taki sposób, aby komunikowała się bezpośrednio
z tym serwerem za pomocą jego adresu IP dostępnego w sieci.
Jeśli swojej aplikacji podam adres IP 10.10.10.15, wówczas zadziała ona bez problemu.
Gdybym w ten sposób skonfigurował setki różnych komputerów, z których każdy wskazywałby
na adresy IP, wszystko funkcjonowałoby poprawnie tylko przez jakiś czas. Ale nadejdzie
dzień, w którym z jakiegokolwiek powodu ten adres IP będzie wymagał zmiany. A może dodam
drugi serwer, aby rozdzielić obciążenie i obsłużyć zwiększony ruch użytkowników? Co należało-
by zrobić w takiej sytuacji? Musiałbyś ponownie zalogować się na każdym komputerze klienckim
i zaktualizować używany adres IP. Zdecydowanie nie jest to dobre rozwiązanie. Jest to jeden
z powodów, dla których DNS ma decydujące znaczenie dla sposobu projektowania infrastruktury
i zarządzania nią. Korzystając z DNS, możemy stosować nazwy zamiast adresów IP. Dzięki
DNS moja aplikacja może zostać skonfigurowana do komunikowania się z serwerem Server01
lub jakąkolwiek inną nazwą przypisaną do maszyny docelowej. Jeśli będę musiał później
zmienić adres IP, po prostu zmodyfikuję go w konsoli DNS i natychmiast wszystkie komputery
klienckie zaczną przypisywać nazwę Server01 do nowego adresu IP (inaczej mówiąc, rozwiązy-
wać ją). Mogę nawet użyć bardziej ogólnej nazwy, takiej jak intranet, i rozwiązywać ją na
wielu różnych serwerach. Omówimy to nieco później.
Za każdym razem, gdy komputer nawiązuje połączenie z serwerem, usługą lub witryną,
używa usługi DNS, aby przekształcić ich nazwy w bardziej przydatną informację, co pozwoli na
zrealizowanie połączenia sieciowego. To samo dotyczy zarówno sieci korporacyjnych lokalnych,
jak i zewnętrznych. Jeśli na swoim laptopie otworzę przeglądarkę Internet Explorer i spróbuję
przejść na adres https://www.bing.com, serwer DNS mojego dostawcy usług sieciowych prze-
kształci nazwę http://www.bing.com na odpowiadający jej adres IP w internecie, czyli taki,
z którym mój laptop się połączy i dzięki temu pomyślnie otworzy docelową stronę. Jednak
w sieciach korporacyjnych w przypadku wewnętrznych informacji o nazwach serwerów nie
chcemy polegać na dostawcy publicznym, dlatego tworzymy własne, wewnętrzne systemy DNS.
Ponieważ rekordy DNS w sieci domeny prawie zawsze tłumaczą nazwy na obiekty znajdujące
się w Active Directory, sensowne jest, aby role DNS i AD DS były ze sobą ściśle zintegrowane.
To odnosi się do większości sieci firmy Microsoft, dla których bardzo powszechną praktyką
jest instalowanie zarówno roli AD DS, jak i DNS na serwerach kontrolera domeny.
113
Różne rodzaje rekordów DNS

Po zainstalowaniu na serwerze roli DNS możemy zacząć używać go do tworzenia rekordów
DNS, które tłumaczą nazwy na odpowiadające im adresy IP lub inne informacje potrzebne
do kierowania ruchem w sieci. Zakładając, że pracujesz w sieci domenowej, możesz być
mile zaskoczony, widząc, że w usłudze DNS istnieje już wiele rekordów, których wcale nie
utworzyłeś. Gdy korzystasz z Active Directory wspólnie z usługą DNS, proces przyłączania
komputerów i serwerów do domeny automatycznie dodaje rekord do bazy DNS.
W moim nowym środowisku laboratoryjnym nie utworzyłem jeszcze żadnych rekordów DNS,
a jednak gdy w menu Tools Menedżera serwera otwieram konsolę o nazwie DNS Manager
(Menedżer DNS), widzę zestaw istniejących już rekordów. Wynika to z faktu, że w czasie,
gdy dołączałem każdą z maszyn do domeny, automatycznie dodawały one swoje rekordy do
bazy DNS, dzięki czemu nazwy nowych serwerów i klientów były natychmiast poprawnie
rozwiązywane wewnątrz naszej domeny:
Rekord hosta (A lub AAAA)

Pierwszy rodzaj rekordu DNS, który omawiamy, jest najczęstszym typem używanym przez
administratorów. Rekord hosta tłumaczy określoną nazwę na określony adres IP. Jest to dość
prosta operacja i w przypadku większości urządzeń w sieci rekord hosta będzie jedynym rodza-
jem zapisu, jaki istnieje dla nich w DNS. Dostępne są dwie różne klasy rekordów hosta, o któ-
rych powinieneś wiedzieć, nawet jeśli przez co najmniej kilka lat będziesz prawdopodobnie
używać tylko jednej z nich. Dwa różne rodzaje rekordów hosta są zwane rekordami A i rekor-
dami AAAA (wymawianymi w języku angielskim jako Quad A). Jaka jest różnica między nimi?
114
Rekordy A dotyczą adresów IPv4 i będą używane w większości firm jeszcze przez wiele lat.
Rekordy AAAA mają dokładnie ten sam cel, którym jest tłumaczenie nazwy na adres IP, ale doty-
czą tylko adresów IPv6 i przydadzą się wyłącznie w razie wykorzystania w sieci protokołu IPv6.
Na poprzednim zrzucie ekranu widzimy rekordy Host (A), które zostały automatycznie utworzone,
gdy komputery łączyły się z naszą domeną. Mam również inny serwer działający w mojej sieci,
który nie został jeszcze dołączony do domeny, więc nie zarejestrował się sam w usłudze
DNS. Ten serwer nazywa się RA1, ale nie będę mógł się z nim skontaktować, jeśli zaloguję
się do dowolnego innego systemu dostępnego w sieci, ponieważ jego nazwa nie została jeszcze
wprowadzona do bazy DNS:
Na razie nie zamierzam dołączać tego serwera do domeny, abyśmy mogli samodzielnie utworzyć
dla niego rekord DNS i upewnić się, że po wykonaniu tej czynności będę w stanie poprawnie
rozwiązać jego nazwę. Będąc z powrotem w Menedżerze DNS na serwerze DNS, kliknij pra-
wym przyciskiem myszy nazwę swojej domeny wymienioną w folderze Forward Lookup Zones
(Strefy wyszukiwania do przodu), a następnie wybierz opcję New Host (A or AAAA) (Nowy host
(A lub AAAA)). Aby utworzyć nowy rekord hosta, w wyświetlonym oknie dialogowym wy-
starczy wprowadzić nazwę serwera i adres IP zdefiniowany w interfejsie sieciowym:
115
Po utworzeniu nowego rekordu hosta powinniśmy być w stanie natychmiast zacząć rozwiązywać
wprowadzoną nazwę w naszej sieci domenowej. Wrócę do komputera klienckiego, z którego
wcześniej próbowałem łączyć się z serwerem RA1, a następnie spróbuję ponownie wykonać to
samo polecenie ping. Tym razem nazwa została poprawnie rozwiązana, a serwer odpowiedział:
Rekord aliasu (CNAME)

Innym przydatnym typem rekordu DNS jest CNAME, który obecnie częściej jest nazywany
rekordem aliasu. Jest to rekord, który używa nazwy wskazującej na inną nazwę. Na pierw-
szy rzut oka brzmi to trochę bez sensu, przecież nadal będziesz musiał rozwiązać ostateczną
nazwę na adres IP, aby uzyskać połączenie sieciowe do docelowego urządzenia. Zastosowania
rekordu aliasu mogą być jednak różnorodne. Dobrym przykładem użyteczności rekordu aliasu
jest uruchomienie serwera WWW obsługującego strony w sieci wewnętrznej. Zamiast zmuszać
wszystkich użytkowników do zapamiętywania adresu URL, takiego jak http://web1.contoso.local,
w celu uzyskania dostępu do strony internetowej, możemy utworzyć rekord aliasu o nazwie
intranet i zrobić tak, by wskazywał na web1. W ten sposób komputery klienckie mogą zawsze
wykorzystywać bardziej ogólny rekord intranet, którego nazwa jest o wiele łatwiejsza do zapa-
miętania przez użytkowników.
Nowy rekord DNS nie tylko ułatwił pracę użytkownikowi, ale jednocześnie uprościł admi-
nistrowanie siecią, ponieważ obecnie możesz łatwo zmieniać składniki serwera, które odpo-
wiadają temu rekordowi, bez konieczności modyfikowania żadnych ustawień w maszynach
klienckich lub ponownego szkolenia pracowników w zakresie dostępu do strony. Może mu-
sisz zmienić serwer WWW? Nie ma problemu, po prostu wskaż rekordem aliasu nowy ser-
wer. Chcesz dodać kolejny serwer WWW? To również łatwe, możemy bowiem utworzyć
wiele rekordów aliasu z tą samą nazwą intranet, a następnie skierować je na różne serwery
stron WWW, które działają w środowisku. Tworzy to bardzo prostą formę równoważenia ob-
ciążenia, ponieważ DNS zacznie wyrównywać ruch sieciowy pomiędzy różnymi serwerami
na podstawie rekordu CNAME o nazwie intranet.
Zamiast omawiać to rozwiązanie, spróbujmy je zastosować w praktyce. Mam witrynę uru-

chomioną w moim środowisku pod określonym adresem URL, ale obecnie mogę uzyskać do
niej dostęp tylko po wpisaniu nazwy http://web1.contoso.local. Wewnątrz DNS zamierzam
utworzyć rekord aliasu, który przekieruje intranet na web1:
116
Gdy użyję teraz polecenia ping z adresem intranet, będzie można zauważyć, że następuje roz-
wiązanie nazwy serwera web1. Aby wyświetlić stronę, mogę po prostu wpisać słowo intranet
w pasku adresu przeglądarki Internet Explorer. Strona docelowa nie wie nic o zmianie nazwy,
więc nie musiałem wprowadzać żadnych zmian w witrynie, tylko w samej usłudze DNS:
117
Rekord wymiany poczty (MX)

Trzeci typ rekordu DNS zwany jest rekordem wymiany poczty (MX). Podczas wykonywania
typowych zadań nie będziesz musiał mieć do czynienia z rekordami MX (podobnie zresztą
jak z rekordami A lub CNAME), ale mimo to należy o nich wspomnieć. Rekord MX dotyczy
usług e-mail i dostarczania poczty. Niezależnie od nazwy domeny występującej po znaku @
w adresie e-mail, serwery DNS, które obsługują tę nazwę, muszą zawierać rekord MX informu-
jący domenę, gdzie należy szukać usług pocztowych. Rekordy MX są używane tylko w publicz-
nie dostępnym serwerze DNS, aby rozpoznawanie nazw odbywało się przez internet. W przy-
padku firm przechowujących własne wiadomości e-mail na lokalnych serwerach Exchange,
publiczne serwery DNS będą zawierały rekord MX wskazujący na Twoje środowisko pocz-
towe. W przypadku firm udostępniających pocztę e-mail w chmurze publiczne rekordy
DNS musiałyby zawierać rekord MX, który kierowałby ruch e-mail do dostawcy chmury
zarządzającego skrzynkami pocztowymi.
Rekord serwera nazw (NS)

Oto kolejny rekord, którego nie będziesz codziennie obsługiwać, jednakże powinieneś wie-
dzieć, do czego służy. Rekord NS to identyfikator w strefie DNS informujący, które serwery
nazw (Twoje serwery DNS) mają być używane dla danej strefy. Jeśli spojrzysz na rekordy NS
znajdujące się w Twojej konfiguracji, zauważysz, że zawierają one sieciowe nazwy Twoich serwe-
rów DNS. Po dodaniu do domeny nowego serwera usług DC i DNS nowy rekord NS dla
tego serwera zostanie automatycznie dodany do strefy DNS:
Istnieje wiele innych możliwych typów rekordów, które można przechowywać i wykorzy-
stywać w bazie danych DNS, ale nie są one zasadniczo istotne dla typowego administratora
serwera w standardowej sieci opartej na środowisku firmy Microsoft.
Polecenie ipconfig /flushdns

Na zakończenie tego punktu mam jeszcze jedną uwagę. Zapewne pamiętasz, że używałem
takich sformułowań, jak „Zaraz po tym, gdy zrobiłem…” lub „Natychmiast po tej zmianie…”.
Jeśli jednak tworzysz własne rekordy, być może zauważyłeś, że komputery klienckie potrze-
118
bują czasu, aby je rozpoznać. Jest to normalne zachowanie, a czas, jaki upłynie, zanim Twoja
zmiana zostanie rozpoznana przez całą sieć, będzie zależał całkowicie od tego, jak duża ona
jest i w jaki sposób została skonfigurowana replikacja Active Directory. Po utworzeniu no-
wego rekordu DNS na jednym kontrolerze domeny musi się on zreplikować na wszystkich
pozostałych kontrolerach domeny w sieci. Ten proces może potrwać nawet kilka godzin, jeśli
usługa AD nie została skonfigurowana w celu wykonywania szybszej replikacji. W przeciw-
nym razie rozpowszechnienie zmian zajmuje tylko kilka minut. Gdy nowy rekord będzie już
istnieć na wszystkich kontrolerach, może jeszcze trochę potrwać, zanim użytkownicy będą
mogli z niego skorzystać, ponieważ komputery klienckie w sieci domenowej przechowują
dane DNS w pamięci podręcznej. Dzięki temu nie muszą się kontaktować z serwerem DNS
przy każdym żądaniu rozpoznawania nazwy. Zamiast tego odwołują się szybciej do swojej
lokalnej pamięci podręcznej, aby sprawdzić dane odczytane podczas ostatniego zalogowania
się na serwerze DNS. Jeśli spróbujesz przetestować nowo utworzony przez siebie rekord DNS
i okaże się, że nie działa, możesz uruchomić na komputerze klienckim polecenie ipconfig /
flushdns. Zmusi ono klienta do usunięcia lokalnie przechowywanych kopii rekordów usługi
rozpoznawania nazw i pobrania nowych informacji z serwera DNS. Po opróżnieniu pamięci
podręcznej rekord najprawdopodobniej zacznie działać poprawnie.
DHCP a adresowanie statyczne

Adresy IP w Twojej sieci są jak adresy domów na Twojej ulicy. Gdy chcesz wysłać do kogoś list,
piszesz na kopercie adres odbiorcy i umieszczasz ją w skrzynce pocztowej lub zanosisz na
pocztę. Podobnie, gdy komputer chce wysłać dane do serwerów lub innych urządzeń znajdują-
cych się w sieci, wykorzystuje przydzielone im adresy IP. Wiesz już, że serwer DNS jest odpo-
wiedzialny za informowanie komputerów, która nazwa odpowiada danemu adresowi IP, ale
w jaki sposób te adresy są umieszczane w serwerach i komputerach?
Adresowanie statyczne to po prostu proces ręcznej konfiguracji adresów IP w systemie w celu

wprowadzenia wszystkich informacji o adresie IP do ustawień karty sieciowej na danym
urządzeniu. Chociaż jest to szybki i łatwy sposób na uzyskanie ruchu sieciowego między kilkoma
punktami końcowymi o określonych adresach IP, nie jest skalowalny. Swoje serwery często ad-
resujemy w sposób statyczny, aby mieć pewność, że ich adresy się nie zmienią, ale co powinni-
śmy zrobić po stronie klientów i urządzeń? Nawet w małej firmie z 10 pracownikami każda
osoba może mieć komputer stacjonarny i laptop. W sieci będą prawdopodobnie również istnieć
serwery wydruku, które także potrzebują adresów IP, oraz sieć bezprzewodowa, do której pra-
cownicy, lub nawet goście, mogą podłączać swoje telefony oraz inne urządzenia w celu uzyskania
dostępu do internetu. Czy zamierzasz ręcznie przypisywać adresy IP wszystkim tym urządze-
niom? Zdecydowanie nie jest to dobry pomysł.
Odpowiedzią jest protokół dynamicznej konfiguracji hosta (ang. Dynamic Host Configuration
Protocol — DHCP). Został on tak zaprojektowany, aby umożliwić podłączanie maszyn i urzą-
dzeń do sieci oraz automatyczne uzyskiwanie informacji o adresie IP. Prawie każdy użytkownik
dowolnego urządzenia na całym świecie korzysta codziennie z DHCP, nawet nie zdając sobie
z tego sprawy. Po podłączeniu laptopa lub smartfona do routera Wi-Fi w celu uzyskania dostępu
119
do internetu serwer DHCP umożliwia kierowanie ruchem w sieci bezprzewodowej przez

przypisanie urządzeniu informacji adresowych IP. W przypadku publicznej sieci Wi-Fi serwer
DHCP często działa na samym routerze, jednakże w firmach, w których Windows Server
zarządza centrum danych, usługi DHCP są najczęściej obsługiwane przez jeden lub kilka od-
dzielnych serwerów w sieci.
Zakres DHCP
Do tej pory statycznie przypisywałem adresy IP wszystkim tworzonym serwerom w projektowa-
nym przeze mnie środowisku laboratoryjnym z systemem Windows Server 2019. Nie jest to
zbyt nowoczesne rozwiązanie i nie można nim dobrze zarządzać. Gdy skonfigurowałem
pierwszy kontroler domeny, faktycznie zainstalowałem na nim również rolę DHCP, która jednak
nie otrzymała jeszcze żadnego zadania. Czego potrzebuje serwer DHCP, aby zacząć przydzielać
adresy IP? Aby mógł on rozpocząć przekazywanie odpowiedniej informacji komputerom,
musi wiedzieć, jakie adresy IP, maska podsieci, brama domyślna i adresy serwerów DNS są
dostępne w Twojej sieci. Ten pakiet informacji wewnątrz serwera DHCP jest nazywany zakre-
sem DHCP. Serwer DHCP po zdefiniowaniu zakresu zacznie przekazywać jego adresy IP do
nowych serwerów i komputerów, które nie mają jeszcze zdefiniowanych adresów statycznych.
Po raz kolejny musimy w naszym systemie Windows Server 2019 uruchomić odpowiednie
narzędzie do zarządzania i ponownie najłatwiejszym sposobem jest użycie menu Tools w Mene-
dżerze serwera i kliknięcie opcji DHCP. Po otwarciu konsoli zobaczysz nazwę serwera, na
którym działa serwer DHCP. Rozwiń ją, a pojawią się opcje o nazwach IPv4 oraz IPv6. Tak
— oznacza to, że możesz użyć tego serwera DHCP do rozpowszechniania zarówno adresów
IPv4, jak i IPv6 dla tych klientów, którzy testują nowy protokół lub planują jego użycie
w przyszłości. Na razie trzymajmy się jednak starego, dobrego protokołu IPv4. Kliknę więc
prawym przyciskiem myszy nazwę IPv4 i wybiorę opcję New Scope (Nowy zakres). Spowoduje
to uruchomienie kreatora New Scope Wizard (Kreator nowych zakresów), który poprosi Cię
o podanie kilku informacji potrzebnych serwerowi DHCP do utworzenia zakresu i rozpoczęcia
przydzielania adresów IP w sieci. Zdefiniuję nowy zakres w taki sposób, aby udostępniał ad-
resy IP od 10.10.10.100 do 10.10.10.150 (zobacz pierwszy rysunek na następnej stronie).
Gdy tylko zakończysz tworzenie zakresu, stanie się on aktywny i każdy komputer w sieci,
którego karta sieciowa została skonfigurowana do automatycznego pobierania adresu z serwera
DHCP, zacznie to wykonywać.
Po utworzeniu nowego zakresu możesz go kliknąć w konsoli DHCP i dzięki temu wyświetlić
dodatkowe związane z nim informacje. Kliknięcie folderu Address Leases (Dzierżawy adresów)
pozwoli zobaczyć wszystkie dynamiczne adresy, które zostały przekazane przez ten serwer
DHCP. Jak widać na poniższym zrzucie ekranu, mam w sieci komputer kliencki z systemem
Windows 10, który nie miał skonfigurowanego adresu statycznego, więc pobrał adres dynamiczny
z mojego serwera DHCP. Otrzymał pierwszy dostępny adres IP, który zdefiniowałem w moim
zakresie, czyli 10.10.10.100. Następna maszyna, która sięgnie po adres IP z tego serwera DHCP,
otrzyma 10.10.10.101 itd. (zobacz drugi rysunek na następnej stronie).
120
121
Zastrzeżenia DHCP
Przypisywanie adresów IP przy wykorzystaniu dużej puli dostępnych pozycji jest świetnym
rozwiązaniem, jednak dzierżawy adresów podlegają wygaśnięciu i zmianom. Oznacza to, że
komputer z adresem 10.10.10.100 może jutro otrzymać adres 10.10.10.125. Z punktu widzenia
komputera użytkownika nie jest to zazwyczaj problemem, ponieważ ogólnie rzecz biorąc, takie
urządzenia nie muszą mieć wciąż takiego samego adresu IP. Komputery klienckie zwykle
używają usług spoza sieci lokalnej, ale inne urządzenia rzadko próbują się z nimi kontaktować.
Jak rozwiązać jednak sytuację, w której masz bardziej stacjonarne urządzenie w sieci, takie
jak Windows Server, ale nie chcesz się zajmować jego statycznym adresowaniem? W takim
przypadku należy zastosować zastrzeżenia DHCP. Zastrzeżenie to czynność polegająca na
przejęciu jednego adresu IP w ramach zakresu DHCP i zarezerwowaniu go dla określonego
urządzenia. Będzie ono otrzymywać ten sam adres IP za każdym razem, gdy połączy się z serwe-
rem DHCP. Ten adres IP na pewno nie zostanie przekazany żadnemu innemu urządzeniu
w sieci. Z wykorzystaniem opcji zastrzeżeń DHCP możesz zezwolić serwerowi DHCP na
przypisywanie adresów IP nawet serwerom stacjonarnym, dzięki czemu nie będziesz musiał
ręcznie konfigurować ich kart sieciowych, a jednocześnie będą one nadal zachowywać stałe
adresy IP.
W konsoli DHCP możesz zauważyć folder Reservations (Zastrzeżenia). Obecnie nic w nim nie
ma, ale przez kliknięcie prawym przyciskiem myszy nazwy Reservations i wybranie opcji
New Reservation… (Nowe zastrzeżenie…) utworzymy nowe zastrzeżenie. Użyjmy jeszcze raz
serwera web1. W tej chwili do tego serwera jest przypisany statyczny adres IP, jednakże zamiast
niego utworzę rezerwację na adres 10.10.10.150:
Zaraz, zaraz, momencik. Większość informacji wyświetlanych na tym ekranie ma sens, na przy-
kład krótki opis nazwy serwera i sam adres IP — ale o co chodzi z adresem MAC? Adres
MAC to fizyczny adres karty sieciowej w sieci. Gdy urządzenie sieciowe próbuje wysłać infor-
122
macje na określony adres IP lub (jak w naszym przypadku) serwer DHCP musi przekazać
określony adres IP karcie sieciowej zainstalowanej w serwerze, wówczas potrzebny jest fizyczny
identyfikator karty. Tak więc adres MAC jest unikatowy dla karty sieciowej znajdującej się
w moim serwerze web1. Będąc zalogowanym na tym serwerze, mogę wydać polecenie
ipconfig /all i wyświetlić adres MAC przypisany do mojej karty sieciowej — jest to ta śmieszna
kombinacja liter i cyfr wyświetlana w wierszu o nazwie Physical Address (Adres fizyczny).
Tam znajdę informację, której szukam. W taki sposób serwer DHCP decyduje, kiedy należy
użyć zastrzeżenia. Jeśli interfejs sieciowy prosi go o adres dynamiczny, a adres MAC urządzenia
znajduje się w bazie zastrzeżeń, wówczas serwer DHCP przekazuje do tego urządzenia zastrze-
żony adres, a nie bierze go z puli ogólnej:
Po utworzeniu rezerwacji DHCP przejdę do ustawień karty sieciowej na swoim serwerze web1
i pozbędę się wszystkich parametrów dotyczących adresowania statycznego przez wybranie
opcji Obtain an IP address automatically (Uzyskaj adres IP automatycznie):
Gdy wykonam powyższą czynność, serwer web1 skontaktuje się z usługą DHCP i poprosi o adres.
Jak widać na rysunku, przydzielono mi zarezerwowany adres 10.10.10.150. Od tego momentu
ten adres będzie zawsze nadawany serwerowi web1, chyba że zmienię zastrzeżenie DHCP
lub w jakiś sposób zmodyfikuję adres MAC karty sieciowej. Mogłoby się to zdarzyć, gdybym
zainstalował nową kartę sieciową w serwerze:
123
W swojej sieci możesz także tworzyć zastrzeżenia DHCP dla obiektów innych niż maszyny
z systemem Windows. Ponieważ wszystko, czego potrzebujesz, to adres MAC urządzenia
(a każdy sprzęt z kartą sieciową ma adres MAC), łatwo jest zdefiniować zastrzeżenie
dla urządzeń takich, jak serwery druku, maszyny kopiujące i systemy alarmowe.
Kopia zapasowa i jej przywracanie

Tworzenie kopii zapasowych i od czasu do czasu przywracanie serwerów to operacje, które
w systemie Windows Server 2019 wciąż, niestety, trzeba wykonywać. Marzę o dniu, w którym
serwery będą w stu procentach niezawodne i stabilne przez cały okres eksploatacji, nienarażone
na wirusy i nieuczciwe oprogramowanie, jednakże nie jest to jeszcze możliwe. Chociaż na
rynku jest dostępnych wiele narzędzi innych firm, które mogą ulepszyć i zautomatyzować two-
rzenie kopii zapasowych podczas zarządzania wieloma serwerami, odpowiednie funkcje są już
wbudowane w system operacyjny Server 2019 i każdy z nas powinien wiedzieć, jak z nich
skorzystać.
Planowanie wykonywania regularnych kopii zapasowych

Logowanie się do serwerów i codzienne uruchamianie ręcznego zadania tworzenia kopii za-
pasowych jest oczywiście niemożliwe w przypadku większości organizacji, ponieważ taki
proces wymagałby oddzielnego stanowiska. Na szczęście funkcja tworzenia kopii zapasowych
systemu Windows Server daje nam możliwość utworzenia odpowiedniego harmonogramu.
W ten sposób możemy określić, jakie dane chcemy uwzględnić w kopii zapasowej, gdzie chcemy
124
ją zapisać i jak często powinna być uruchamiana. Następnie możemy po prostu usiąść, zrelakso-
wać się i mieć świadomość, że nasze systemy wykonują to zadanie samodzielnie.
Zanim zrobimy cokolwiek z kopiami zapasowymi, musimy zainstalować odpowiednią funk-

cję w systemie Windows. Z wykorzystaniem łącza Add roles and features (Dodaj role i funk-
cje) zainstaluj funkcję o nazwie Windows Server Backup (Kopia zapasowa systemu Windows
Server). Pamiętaj, że użyłem słowa funkcja — nie znajdziesz instalatora kopii zapasowej
systemu Windows Server na głównym ekranie wyboru ról serwera. Aby znaleźć funkcje, musisz
w kreatorze przejść o jeden ekran dalej. Po zakończeniu instalacji będziesz mógł uruchomić
konsolę Windows Server Backup (Kopia zapasowa systemu Windows Server), dostępną w menu
Tools Menedżera serwera. Gdy już ją uruchomisz, kliknij wiersz Local Backup (Lokalna kopia
zapasowa) w kolumnie po lewej stronie okna, a po prawej pojawią się dostępne opcje Actions
(Akcje).
Jak widać, na liście znajduje się opcja o nazwie Backup Once… (Jednorazowa kopia zapaso-
wa…), która, jak sama nazwa wskazuje, wykona na poczekaniu zadanie tworzenia kopii zapaso-
wej. Chociaż jest to przydatna funkcja, żaden administrator serwera nie będzie logował się
na wszystkich swoich serwerach i uruchamiał jej codziennie. Zamiast tego kliknięcie akcji
Backup Schedule… (Harmonogram wykonywania kopii zapasowych…) spowoduje uruchomienie
kreatora konfiguracji w celu zdefiniowania zaplanowanego, cyklicznego zadania tworzenia
kopii zapasowej:
Najpierw będziesz musiał zdecydować, jakie dane mają być uwzględnione w backupie danych.
Domyślnie wybraną opcją jest Full server (Cały serwer), dzięki czemu narzędzie wykona kopię
zapasową wszystkich plików z systemu operacyjnego. Jeśli jednak chcesz dostosować ilość da-
nych, możesz wybrać opcję Custom (Niestandardowa) i przejść do następnego etapu kreatora.
Ponieważ mam dużo miejsca na dysku, zastosuję zalecaną ścieżkę tworzenia pełnych kopii
zapasowych serwera.
Następnie skorzystamy z rzeczywistej zalety koncepcji użycia harmonogramu: ustalimy czę-

stotliwość uruchamiania kopii zapasowej. Najczęściej stosowaną metodą jest wybranie określonej
pory dnia i pozwolenie, aby kopia zapasowa była uruchamiana codziennie o wyznaczonej
godzinie. Jeśli masz serwer, którego dane są regularnie aktualizowane w ciągu dnia, i chciałbyś
zmniejszyć ilość utraconych informacji w przypadku, gdy będzie trzeba je przywrócić, możesz
również wybrać opcję tworzenia kopii zapasowych wiele razy dziennie:
125
Ostatnim miejscem, w którym musimy podjąć decyzję dotyczącą zaplanowanego backupu

danych, jest ekran Specify Destination Type (Określanie typu miejsca docelowego). Wskazu-
jemy na nim lokalizację służącą do przechowywania plików kopii zapasowych. Zauważysz,
że istnieje kilka różnych opcji lokalnego przechowywania kopii danych na fizycznych dyskach
twardych serwera, na którym konfigurujesz funkcję kopii zapasowych. Przechowywanie pli-
ków kopii zapasowej na lokalnym, oddzielnym dysku lub woluminie może być korzystne,
ponieważ wydajność procesu będzie wyższa. W przypadku serwerów, których kopię zapa-
sową próbujesz wykonywać w dni robocze w celu ciągłego zabezpieczania danych, prawdo-
podobnie będziesz chciał wybrać opcję lokalnego ich przechowywania, aby proces działał
szybko i bezproblemowo. Następną zaletą korzystania z dysku podłączonego lokalnie w celu
tworzenia na nim backupu danych jest to, że można utworzyć wiele punktów przywracania,
zachowując informacje o kopiach zapasowych z wielu dni, na wypadek gdyby trzeba było
powrócić do określonego momentu w czasie.
Uważam jednak, że większość administratorów woli przechowywać wszystkie swoje kopie

zapasowe w scentralizowanej lokalizacji, a to oznacza wybranie trzeciej opcji dostępnej na ekra-
nie, Back up to a shared network folder (Utwórz kopię zapasową w udostępnionym folderze
sieciowym). Wybrawszy tę opcję, można określić lokalizację sieciową, taką jak serwer plików
lub dysk sieciowy NAS. Dodatkowo w taki sam sposób można skonfigurować tworzenie kopii
zapasowych dla wszystkich serwerów znajdujących się w tej samej lokalizacji. Tak uzyskujemy
centralną, standardową lokalizację, w której będą dostępne wszystkie nasze pliki backupu,
na wypadek gdybyśmy musieli pobrać jeden z nich i użyć go do przywrócenia danych.
Trudno mi określić, która opcja jest najlepsza, ponieważ zależy to od tego, w jaki sposób pla-
nujesz korzystać z kopii zapasowych we własnym środowisku. Ekran, na którym wybieramy
typ docelowy kopii zapasowych, zawiera kilka wartych przeczytania pomocniczych wskazówek.
Wśród nich znajduje się ważna uwaga mówiąca o tym, że podczas korzystania z udostępnionego
126
folderu sieciowego można na nim zapisać tylko jeden plik backupu serwera, ponieważ uru-
chamiany następnego dnia proces tworzenia nowej kopii zastąpi poprzednią:
Po wybraniu miejsca docelowego dla kopii zapasowych i określeniu lokalizacji udziału siecio-
wego (jeśli tę opcję wybrałeś) kreator zakończy pracę. Twoje zadania tworzenia kopii zapa-
sowych zostaną automatycznie uruchomione w wyznaczonym czasie, określonym w kreatorze,
więc jutro pojawi się nowy plik backupu Twojego serwera. Jeśli podobnie jak ja jesteś
niecierpliwy i chciałbyś zobaczyć, w jaki sposób działa zadanie tworzenia kopii zapasowej,
możesz w konsoli Windows Server Backup wybrać inną akcję, o nazwie Backup Once…
(Jednorazowa kopia zapasowa…), aby natychmiast ręcznie uruchomić backup:
127
Przywracanie danych z systemu Windows

Mimo że jesteś sumienny i poprawnie tworzysz kopie zapasowe swoich serwerów, masz nadzieję,
że nigdy nie będziesz musiał faktycznie wykorzystywać plików backupu w celu przywrócenia
danych. Niestety, prawdopodobnie znajdziesz się w sytuacji, gdy któryś z serwerów przestanie
poprawnie działać lub jego dane zostaną przypadkowo usunięte, a wtedy będziesz musiał
rozpocząć w infrastrukturze proces przywracania danych lub całego serwera. Jeśli serwer jest
nadal widoczny w sieci i działa, proces przywracania jest dość łatwy i wymaga użycia tej samej
konsoli Windows Server Backup. Otwórz tę konsolę i wybierz akcję o nazwie Recover…
(Odzyskaj…).
Spowoduje to wywołanie innego kreatora, który przeprowadzi Cię przez proces odzyskiwania.
Najpierw określasz lokalizację pliku kopii zapasowej. Jeśli na serwerze lokalnym masz lokalizację
przeznaczoną wyłącznie do backupu, znalezienie jej jest dość proste. W przeciwnym razie, tak
jak w moim przykładzie, w którym określono lokalizację sieciową, wybierz opcję A backup
stored on another location (Kopia zapasowa przechowywana w innej lokalizacji), a następnie
Remote shared folder (Zdalny folder udostępniony), aby wskazać, gdzie można znaleźć plik
kopii zapasowej:
Na podstawie wybranej lokalizacji kopii zapasowej kreator wyświetli obecnie wszystkie daty wy-
konania backupów. Jeśli przechowujesz pliki kopii zapasowej na dysku lokalnym i masz dostępne
punkty przywracania z wielu dni, zobaczysz wiele dat, które możesz wybrać. Ponieważ zdecy-
dowałem się przechowywać kopie zapasowe w lokalizacji sieciowej, dostępne są tylko informacje
o backupie z jednego dnia, dlatego wczorajsza data jest jedyną, którą mógłbym wybrać. Zdecy-
duję się więc przywrócić wczorajszą kopię zapasową i wykonywać dalsze działania za pomocą
kreatora.
Gdy już zidentyfikowaliśmy określony plik kopii zapasowej, który będzie używany do odzy-
skiwania danych, możemy wybrać, jakie informacje powinny zostać przywrócone. Jest to intere-
sująca opcja systemu backupu, ponieważ przywracanie kopii zapasowej często dotyczy wyłącznie
określonych plików i folderów, które mogły zostać usunięte lub uszkodzone. W takim przy-
padku wybierz górną opcję, o nazwie Files and folders (Pliki i foldery). W innych może być
konieczne przywrócenie z określonej daty całego serwera, więc należy wówczas wybrać opcję
Volume (Woluminy). Ponieważ brakuje mi tylko kilku plików, które w jakiś sposób zniknęły
między dniem wczorajszym a dzisiejszym, wybiorę domyślną opcję Files and folders.
128
Zostanie wyświetlony ekran Select Items to Recover (Wybieranie elementów do odzyskania),

który po analizie pliku kopii zapasowej wyświetli listę zawartych w nim plików i folderów.
Po prostu wybiorę z niej te elementy, które będę chciał przywrócić. Ten rodzaj odzyskiwania
może mieć kluczowe znaczenie w codziennym zarządzaniu serwerem plików, na którym praw-
dopodobieństwo przypadkowego usunięcia informacji przez użytkowników jest duże:
Pozostaje tylko określić, gdzie chcesz umieścić odzyskane pliki. Możesz zdecydować, by odtwo-
rzone pliki zostały umieszczone z powrotem w pierwotnej lokalizacji, lub — jeśli urucha-
miasz ten proces odzyskiwania na innym komputerze — możesz przywrócić pliki w nowym
miejscu, z którego następnie będziesz mógł je pobrać i samodzielnie umieścić w wybranej
lokalizacji.
Przywracanie z płyty instalacyjnej

Odzyskiwanie danych z konsoli w systemie Windows jest wygodne z użyciem kreatora, ale
co zrobić w sytuacji, gdy serwer ma poważną awarię? Jeśli na serwerze nie możesz uzyskać
dostępu do systemu Windows, nie możesz również uruchomić konsoli Windows Server Backup
w celu zainicjowania procesu odzyskiwania. W takim przypadku nadal możemy wykorzystać
utworzony plik kopii zapasowej, ale musimy go użyć w połączeniu z dyskiem instalacyjnym
systemu Windows Server 2019, z którego będziemy mogli uruchomić proces odzyskiwania.
129
Należy pamiętać, że omawiany proces odzyskiwania nie będzie miał dostępu do lokali-
zacji w sieci, a plik kopii zapasowej będzie musiał być przechowywany na dysku podłączo-
nym do serwera. Jeśli pierwotnie nie skonfigurowałeś zadania kopii zapasowej do
współpracy z istniejącym dyskiem lokalnym, podczas odzyskiwania danych możesz skorzy-
stać z napędu USB.
Żeby było ciekawiej, zamierzam uszkodzić własny serwer. Jest to maszyna, której kopię zapasową
wykonaliśmy kilka minut temu. Przypadkowo usunąłem niektóre bardzo ważne pliki z kata-
logu C:\Windows, i proszę — to wszystko, co widzę, gdy próbuję uruchomić ten serwer:
Taki ekran z samego rana może zepsuć cały dzień! Ponieważ wydaje mi się, że tu utknąłem i nie
mogę uruchomić systemu Windows, moje szanse na uruchomienie kreatora odzyskiwania są
zerowe. Co robić? Uruchomić system Windows Server 2019 z instalacyjnego dysku DVD?
Nie chcę ponownie instalować systemu Windows, ponieważ w takim przypadku wszystkie moje
programy i dane mogą zostać nadpisane. Gdy jednak przejdziesz do ekranów instalatora, zauwa-
żysz, że w dolnym narożniku jest wyświetlana opcja Repair your computer (Napraw komputer).
Wybierz ją, aby z instalacyjnego dysku DVD uzyskać dostęp do opcji odzyskiwania danych.
Zobaczysz, że ekran zmieni kolor na niebieski, co oznacza, że uruchomiliśmy specjalne oprogra-

mowanie z płyty instalacyjnej. Po kliknięciu przycisku Troubleshoot (Rozwiąż problemy) będziemy
mogli zobaczyć wszystkie dostępne opcje (zobacz pierwszy rysunek na następnej stronie).
Jeśli uważasz, że możesz rozwiązać problem przy użyciu opcji Command Prompt (Wiersz
polecenia), wybierz ją i spróbuj samodzielnie naprawić uszkodzone środowisko. W naszym
przypadku jestem prawie pewien, że znacząco zmodyfikowałem system operacyjny, więc użyję
opcji System Image Recovery (Odzyskiwanie obrazu systemu) (zobacz drugi rysunek na na-
stępnej stronie).
130
Gdy do maszyny zostanie podłączony dysk twardy zawierający plik kopii zapasowej systemu
Windows Server, nastąpi uruchomienie kreatora, który odczyta z niej odpowiednie informacje.
Ponieważ pierwotnie postanowiłem przechowywać plik kopii zapasowej w lokalizacji sieciowej,
skopiowałem go na dysk. Następnie dysk ten podłączyłem do serwera. Kreator automatycznie
rozpoznał plik kopii zapasowej i wyświetlił go na ekranie Select a system image backup (Wybierz
kopię zapasową obrazu systemu):
131
Po kliknięciu w kreatorze kilka razy przycisku Next (Dalej) kopia zapasowa obrazu zacznie
się przywracać na mój serwer:
Po zakończeniu procesu odtwarzania serwer uruchomi się ponownie, by powrócić do w pełni

funkcjonalnego systemu Windows z punktu przywracania. Na moim serwerze testowym nie ma
zbyt wielu zainstalowanych aplikacji, więc przywracanie nie trwa długo. W przypadku maszyny
produkcyjnej może to potrwać nieco dłużej, ale moim zdaniem 20 minut od uszkodzenia
serwera do w pełni odzyskanego systemu jest niesamowicie krótkim czasem!
Przechowywanie poprawnych i jak najbardziej aktualnych plików kopii zapasowych ma kluczowe

znaczenie dla jakości Twoich działań. Pracowałem z kilkoma systemami, w których administrato-
rzy wykonali ręczne kopie zapasowe po początkowej konfiguracji swoich serwerów, ale nigdy
nie zdefiniowali regularnego harmonogramu. Nawet jeśli dane na maszynie nigdy się nie
zmieniają, nie powinieneś tak postępować, jeśli Twój serwer należy do domeny. Jeśli serwer
ulegnie awarii i konieczne będzie jego odzyskanie, wówczas przywrócenie kopii zapasowej
132
sprzed zaledwie kilku dni będzie na ogół rozwiązaniem problemu. Jeśli jednak przywrócisz
obraz, który ma 6 miesięcy, sam system Windows zostanie co prawda odzyskany bez żadnych
kłopotów i wszystkie dane będą istnieć, ale w tym czasie Twoje konto komputera dla tego
serwera z pewnością nie zsynchronizuje się z domeną, co spowoduje błędy uwierzytelnienia
w kontrolerach domeny. W celu odzyskania połączenia z domeną w niektórych przypadkach
może być nawet konieczne wykonanie tak dziwnych czynności, jak odłączenie i ponowne
dołączenie serwera do domeny po przywróceniu obrazu. Jeśli będziesz regularnie tworzył
kopie zapasowe, takie problemy nie pojawią się.
Skróty MMC i MSC

Prawdopodobnie zauważyłeś, że wiele konsol zarządzania, których używamy do konfigurowa-
nia komponentów w systemie Windows Server 2019, wygląda dość podobnie. W takich
przypadkach w rzeczywistości używasz funkcji przystawki, czyli określonego zestawu narzędzi,
które są dołączane do ogólnego narzędzia konsoli o nazwie Microsoft Management Console
(Konsola zarządzania — MMC). W rzeczywistości, zamiast otwierać wszystkie funkcje zarządza-
nia z poziomu Menedżera serwera, często można po prostu wpisać MMC w opcji Start/Run
(Start/Uruchom) lub w samym wierszu poleceń, co spowoduje wywołanie ogólnej konsoli
MMC. Stąd możesz już kliknąć menu File (Plik) i wybrać opcję Add or Remove Snap-ins
(Dodaj/Usuń przystawkę):
133
Wybierz przystawkę zarządzania, której chcesz używać, i dodaj ją do konsoli. Istnieje wiele
funkcji zarządzania, do których można uzyskać dostęp za pośrednictwem standardowej konsoli
MMC. W przypadku niektórych szczególnych funkcji konsola MMC jest preferowaną, a niekiedy
jedyną metodą interakcji ze składnikami systemu Windows. Na przykład w dalszej części tej
książki zajmiemy się magazynami certyfikatów w systemie Windows Server 2019 i wykorzystamy
MMC do niektórych z tych interakcji.
Innym ciekawym sposobem na otwarcie wielu konsol zarządzania jest bezpośrednie użycie
odpowiedniej nazwy MSC. Plik MSC to po prostu zapisana konfiguracja sesji konsoli MMC.
Istnieje wiele skrótów MSC przechowywanych w systemie Windows Server 2019 i od razu
gotowych do użycia po jego zainstalowaniu. Jeśli daną konsolę zarządzania można uruchomić
przez plik MSC, wystarczy wpisać jego nazwę po przejściu do opcji Start/Run (Start/Uruchom)
lub w wierszu poleceń czy też oknie programu PowerShell. Określona konsola zarządzania
uruchomi się natychmiast bez konieczności naciskania jakiegokolwiek klawisza i otwierania
Menedżera serwera. Ponieważ wolę używać klawiatury zamiast myszy, w każdym systemie
mam zawsze otwarte okno programu PowerShell lub okno wiersza poleceń. Dzięki temu
mogę bardzo szybko użyć tego okna, aby otworzyć dowolną konsolę administracyjną MSC.
Zaprezentuję jeden przykład, abyś dokładnie wiedział, jak korzystać z tej funkcji, a następnie
przedstawię listę typowych konfiguracji MSC, które uważam za przydatne do codziennej pracy.
Otwórz okno programu PowerShell z uprawnieniami administracyjnymi, wprowadź nazwę

WF.MSC i naciśnij klawisz Enter:
Zostanie otwarte okno aplikacji Windows Defender Firewall with Advanced Security (Zapora
Windows Defender z zabezpieczeniami zaawansowanymi), gotowe do interakcji z użytkowni-
kiem. Nie musieliśmy wykonywać typowych działań pozwalających na dostęp do tej konsoli
za pomocą myszy, czyli otwierać narzędzi Control Panel (Panel sterowania) lub Windows
Settings (Ustawienia systemu Windows), w których należałoby wyszukać opcję Firewall and
network protection (Zapora i ochrona sieci), a następnie kliknąć łącze Advanced Settings (Usta-
wienia zaawansowane). Ponieważ znałem nazwę skrótu MSC, mogłem od razu otworzyć w pełni
działającą konsolę WFAS, w której często sprawdzam określone reguły zapory lub jej status:
134
Gdy wiesz już, jak działa polecenie MSC i w jaki sposób można je wywołać, chciałbym przed-
stawić listę typowych konfiguracji MSC, które możesz uruchomić w celu szybkiego dostępu
do różnych konsol administracyjnych na swoich serwerach:
 DSA.MSC: Active Directory Users and Computers (Użytkownicy i komputery usługi
Active Directory),
 DSSITE.MSC: Active Directory Sites and Services (Lokacje i usługi Active Directory),
 DNSMGMT.MSC: DNS Manager (Menedżer DNS),
 GPEDIT.MSC: Local Group Policy Editor (Edytor lokalnych zasad grupy),
 GPMC.MSC: Group Policy Management Console (Zarządzanie zasadami grupy),
 CERTSRV.MSC: Certification Authority Management (Zarządzanie urzędem certyfikacji),
 CERTTMPL.MSC: Certificate Template Management (Zarządzanie szablonami certyfikatów),
 CERTLM.MSC: Local Computer Certificates Store (Lokalny magazyn z certyfikatami
komputerowymi),
 CERTMGR.MSC: Current User Certificates Store (Magazyn certyfikatów bieżącego użytkownika),
 COMPMGMT.MSC: Computer Management (Zarządzanie komputerem),
 DEVMGMT.MSC: Device Manager (Menedżer urządzeń),
 DHCPMGMT.MSC: DHCP Manager (Menedżer DHCP),
 DISKMGMT.MSC: Disk Management (Zarządzanie dyskami),
 EVENTVWR.MSC: Event Viewer (Podgląd zdarzeń),
 PERFMON.MSC: Performance Monitor (Monitor wydajności),
 SECPOL.MSC: Local Security Policy Console (Zasady zabezpieczeń lokalnych),
135
 FSMGMT.MSC: Shared Folders (Foldery udostępnione),

 WF.MSC: Windows Defender Firewall with Advanced Security (Zapora Windows
Defender z zabezpieczeniami zaawansowanymi).
Podsumowanie
W tym rozdziale omówiliśmy niektóre role i składniki systemu Windows Server 2019, z których
będziesz musiał umieć skorzystać, jeśli chciałbyś uruchomić infrastrukturę rzeczywiście zorien-
towaną na produkty firmy Microsoft. Active Directory, DNS i DHCP to podstawowe główne
usługi, które leżą u podstaw systemu i obsługują całą infrastrukturę. Ich podstawowa znajo-
mość jest niezbędna każdemu administratorowi systemu Windows Server, a dogłębna wiedza na
temat współpracy tych narzędzi ze sobą otworzy przed Tobą wiele drzwi w miarę postępów
w karierze zawodowej w obszarze IT. Prawie wszystkie inne role i funkcje dostępne w systemie
Windows Server są obsługiwane przez te podstawowe usługi lub zależą od nich. Mam nadzieję,
że swobodnie poruszasz się po nich po wykonaniu przykładów z tego rozdziału.
Za chwilę będziemy kontynuować naszą podróż przez system Windows Server 2019, analizu-
jąc jedno z bardziej przerażających zagadnień (w każdym razie dla wielu administratorów)
— mam na myśli certyfikaty! W następnym rozdziale przyjrzymy się certyfikatom w systemie
Windows Server 2019.
Pytania
1. Jak się nazywa kontener (folder) znajdujący się wewnątrz usługi Active Directory,
który przechowuje konta komputerów i użytkowników?
2. Jak zwana jest operacja tworzenia konta komputera w usłudze Active Directory
przed jego dołączeniem do domeny?
3. Które narzędzie zarządzania służy do wiązania fizycznych lokalizacji w sieci
z określonymi podsieciami IP?
4. Jak nazywa się specjalny kontroler domeny, który nie zapisuje nowych informacji,
tylko synchronizuje się z istniejącym kontrolerem domeny?
5. Który obiekt zasad grupy w nowo zainstalowanym systemie zawiera ustawienia
złożoności hasła?
6. Jaki rodzaj rekordu DNS rozwiązuje nazwę na adres IPv6?
7. Jak się nazywa skrót MSC służący do otwierania konsoli Active Directory Users
and Computers (Active Directory Users and Computers)?
136
4
Certyfikaty w systemie
Windows Server 2019
„Och, musimy użyć certyfikatów, żeby to zadziałało”

— słowa wypowiedziane przez anonimowego administratora, który właśnie odkrył,
że jego najnowsza technologia wymaga wdrożenia certyfikatów w organizacji.
Jeśli powyższe słowa brzmią znajomo, nie rezygnuj jeszcze z zaplanowanego projektu! Korzysta-
nie z certyfikatów wydaje się z jakiegoś powodu trudnym zadaniem dla wielu z nas — nawet
dla tych, którzy pracują w środowisku IT od wielu lat. Dzieje się tak prawdopodobnie dlatego,
że na serwerze certyfikatów dostępnych jest wiele różnych opcji, a jednocześnie konsola zarzą-
dzania nie została zbyt sensownie zaprojektowana i nie jest przyjazna dla użytkownika w zakresie
obsługi certyfikatów. Ta cecha w połączeniu z wieloletnim brakiem wymagań dotyczących
certyfikatów na serwerach oznacza, że chociaż odpowiednia technologia od dawna istnieje,
wielu administratorów nie miało jeszcze okazji samodzielnie wdrażać certyfikatów. Regularnie
implementuję technologie, które wymagają szerokiego zastosowania certyfikatów w organizacji.
Często wydaje się je wszystkim stacjom roboczym lub użytkownikom w sieci, a jednak przez cały
czas słyszę różnego rodzaju obawy. Wydanie certyfikatu jednemu kluczowemu dla biznesu
serwerowi WWW wydaje się dość zniechęcające, jeśli nie ma się żadnego doświadczenia w tym
procesie, już nie mówiąc o wydawaniu setek lub tysięcy certyfikatów jednocześnie. Innym
typowym scenariuszem jest sytuacja, w której przedsiębiorstwo interesuje się certyfikatami,
ale brakuje mu odpowiednio wyszkolonych pracowników i dlatego wynajmuje firmę zewnętrzną
w celu wdrożenia certyfikatów w sieci. Chociaż powoduje to, że certyfikaty się pojawiają,
często pozostaje brak wiedzy, która nigdy nie zostaje uzupełniona. Możesz więc mieć urucho-
miony serwer certyfikatów, ale nie będziesz umiał go modyfikować ani wykorzystywać.
Środowisko certyfikatów jest dobrze znane pod nazwą infrastruktury klucza publicznego
(ang. Public Key Infrastructure — PKI). Taką nazwę prawdopodobnie napotkasz w pewnym
momencie w dokumentacji lub wymaganiach technicznych. Twoja infrastruktura PKI jest za-
pewniana przez określone serwery w sieci, a sposób ich konfiguracji zostanie zaprezentowany
w tym rozdziale. Maszyny, które określasz jako serwery certyfikatów, są znane pod nazwą ser-
werów urzędu certyfikacji (ang. certification authority — CA) i tak będziemy je nazywać
w tej książce.
Oto zagadnienia, które omówimy w tym rozdziale w celu wdrożenia środowiska certyfikatów
w Twojej sieci:
 Ogólnie używane typy certyfikatów.
 Planowanie środowiska PKI.
 Tworzenie nowego szablonu certyfikatu.
 Wydawanie nowych certyfikatów.
 Określanie sposobu automatycznej rejestracji certyfikatów.
 Uzyskanie certyfikatu SSL organu publicznego.
 Eksportowanie i importowanie certyfikatów.
Ogólnie używane typy certyfikatów

Istnieje wiele różnych typów certyfikatów, które mogą być publikowane. Przekonasz się, że
w sytuacji, gdy potrzebujesz certyfikatu, który zawiera listę określonych wymagań, możesz zbu-
dować szablon certyfikatu zgodnie z dowolną specyfikacją. W pewnym sensie tak naprawdę
nie ma w ogóle typów certyfikatów, lecz jedynie szablony certyfikatów, które można zdefiniować
w taki sposób, aby zawierały wszelkie informacje potrzebne do użycia danego certyfikatu.
Chociaż jest to technicznie prawdziwe, generalnie łatwiej jest podzielić certyfikaty na różne
grupy, dzięki czemu są one bardziej rozpoznawalne ze względu na określone zadanie, które
mają wykonać.
Certyfikaty użytkownika
Jak można się domyślić, certyfikat użytkownika służy do celów, które są specyficznie związane
z nazwą użytkownika. Jednym z elementów zachęcających do zastosowania certyfikatów jest
proces uwierzytelniania w sieci. Firmy, które wymagają silniejszego uwierzytelniania w swoich
środowiskach, często chcą użyć certyfikatów jako składnika procesu uwierzytelniania. Karty
inteligentne są jednym ze specyficznych mechanizmów, które można w tym celu wykorzystać.
Może to być w szczególności jakaś fizyczna karta, którą należy podłączyć do komputera, aby
użytkownik mógł uzyskać do niego dostęp.
Karty inteligentne można również przechowywać wirtualnie w nowszych komputerach w spe-

cjalnym module zwanym TPM1. Ale to dyskusja na inny dzień. Powodem, dla którego wspomi-
nam o kartach inteligentnych, jest to, że często podstawową funkcjonalność ich uwierzytelnia-
1
ang. Trusted Platform Module — układ cyfrowy służący do bezpiecznego przechowywania poświadczeń
oraz unikatowych par kluczy PKI — przyp. tłum.
138
Rozdział 4. • Certyfikaty w systemie Windows Server 2019
nia zapewnia certyfikat użytkownika zapisany na takiej karcie. Jeśli zostaniesz zaangażowany
w projekt wdrożenia kart inteligentnych, prawdopodobnie będziesz potrzebować PKI.
Inną popularną formą silnego uwierzytelniania są hasła jednorazowe. Od użytkownika oprócz

standardowych kryteriów logowania wymagane jest wprowadzenie losowo wygenerowanego
kodu PIN. W niektórych przypadkach po podaniu kodu PIN wydawany jest tymczasowy certyfi-
kat użytkownika, który może zostać użyty jako część łańcucha uwierzytelniania. Z certyfika-
tami użytkowników często można się spotkać również w sytuacjach, w których firmy stosują
technologie szyfrowania plików, takie jak EFS (skrót od słów Encrypting File System), a także
podczas budowania systemów wirtualnej sieci prywatnej (VPN), kiedy to umożliwiają zdalnym
użytkownikom podłączanie laptopów do sieci korporacyjnej. Wiele firm nie chce polegać
wyłącznie na nazwie użytkownika i haśle w procesie uwierzytelniania VPN, więc powszechne
jest wydawanie certyfikatów użytkowników, a następnie wymaganie ich obecności w momencie
ustanawiania tunelu VPN.
Certyfikaty komputera
Certyfikaty komputera (inaczej zwane certyfikatami maszyny) są wydawane komputerom w celu
wspierania interakcji między siecią a samym kontem komputera. Technologie takie jak SCCM,
które współdziałają z systemami komputerowymi i zarządzają nimi niezależnie od tego, jacy
użytkownicy są w nich zalogowani, korzystają z certyfikatów komputerów. Tego rodzaju certyfi-
katy są również używane do wspierania szyfrowania między systemami w sieci, na przykład
w protokole IPsec, służącym do szyfrowania komunikacji między klientami a wysoce bezpiecz-
nym serwerem plików. Wydawanie certyfikatów komputerów dla punktów końcowych w tym
łańcuchu komunikacji jest niezbędne do jego prawidłowego działania. Często zdarza się, że
wystawiam certyfikaty komputerowe dla maszyn firmy w celu uwierzytelnienia tuneli DirectAccess,
czyli pewnej formy automatycznego dostępu zdalnego. Na pewno istnieje wiele interesujących
technologii wymagających wydawania certyfikatów stacjom roboczym klienta w Twoim środowi-
sku, a także innych powodów, by to robić.
Certyfikaty SSL
Jeśli znajdziesz się w sytuacji, w której tak naprawdę nie zarządzałeś serwerem CA, ale w pew-
nym momencie wydałeś i zainstalowałeś jakiś certyfikat, jest szansa, że był to certyfikat SSL.
Jest to zdecydowanie najczęstszy typ certyfikatu używany w dzisiejszej infrastrukturze technolo-
gicznej. Twoja firma najprawdopodobniej korzysta już z certyfikatów SSL, nawet jeśli nie jesteś
tego świadomy i nie masz ani jednego serwera CA w sieci.
Certyfikaty SSL są najczęściej używane do zabezpieczenia ruchu na stronie WWW. Za każdym

razem, gdy otwierasz jakąś stronę i widzisz HTTPS w pasku adresu, Twoja przeglądarka
używa strumienia pakietów SSL do komunikacji z serwerem, który obsługuje tę stronę. Serwer
WWW ma zainstalowany certyfikat SSL, a Twoja przeglądarka będzie musiała go sprawdzić,
zanim pozwoli Ci wejść na stronę, aby upewnić się, że jest on ważny i że witryna jest naprawdę
tym, za co się podaje. Jeśli nie użylibyśmy certyfikatów SSL na stronie WWW, każdy mógłby się
pod nią podszyć i uzyskać dostęp do informacji, które są do niej przesyłane.
139
Oto prosty przykład. Załóżmy, że jeden z Twoich użytkowników jest w kawiarni i korzysta
z publicznej sieci Wi-Fi. Osoba atakująca wymyśliła sposób manipulowania systemem DNS
w tej sieci, więc gdy użytkownik spróbuje odwiedzić firmową stronę mail.contoso.com w celu
uzyskania dostępu do programu Outlook Web Access i sprawdzenia wiadomości e-mail, atakujący
przechwyci ten ruch i spowoduje, że użytkownik otworzy inną stronę, która co prawda wygląda
jak portal firmy, ale w rzeczywistości jest zarządzana przez atakującego. Użytkownik wpisuje
swoją nazwę użytkownika i hasło, a atakujący odczytuje teraz jego poświadczenia i może ich
użyć do uzyskania dostępu do Twojej prawdziwej sieci. Co sprawia, że taka sytuacja nie zdarza
się codziennie w prawdziwym świecie? Odpowiedzią są certyfikaty SSL. Gdy witryna ze-
wnętrzna, na przykład strona logowania do poczty e-mail, jest typu HTTPS, przeglądarka
klienta musi sprawdzić certyfikat SSL, który jest prezentowany na danej stronie. Ten certyfikat
SSL zawiera informacje, które ma tylko Twoja firma i których nie można podmienić. Gdy więc
użytkownik uzyskuje dostęp do prawdziwej strony logowania, przeglądarka sprawdza jej certyfi-
kat SSL, a następnie stwierdza, że jest on poprawny, i po prostu kontynuuje swoje działanie.
Użytkownik nawet nie wie, że jest chroniony — może tylko zauważyć mały symbol kłódki
w pobliżu paska adresu przeglądarki. Z drugiej strony, jeśli ruch sieciowy zostanie przechwycony
i przekierowany na fałszywą stronę WWW, sprawdzenie certyfikatu SSL zakończy się niepowo-
dzeniem (ponieważ osoba atakująca nie będzie miała ważnego certyfikatu SSL powiązanego
z nazwą witryny Twojej firmy), a przeglądarka wyświetli odpowiednie ostrzeżenie. W tym mo-
mencie użytkownik powinien się wycofać i zdać sobie sprawę, że coś jest nie w porządku, a na-
stępnie skontaktować się z administratorami IT, aby mogli dokładniej zbadać problem.
Certyfikaty SSL używane na stronach internetowych są prawie zawsze dostarczane nie przez
wewnętrzny serwer CA, ale przez publiczny urząd certyfikacji. Prawdopodobnie słyszałeś
o wielu z nich, na przykład Unizeto, Verisign, Entrust, DigiCert lub GoDaddy. Firmy zazwyczaj
kupują od tych organów publicznych certyfikaty SSL, ponieważ są one domyślnie zaufane w no-
wych komputerach, które użytkownicy mogą kupować w sklepach. Jeśli po zakupie nowego
komputera (nawet w sklepie detalicznym) otworzysz lokalny magazyn certyfikatów, który istnieje
od samego początku w systemie operacyjnym, znajdziesz listę zaufanych organów publicznych.
Gdy odwiedzisz witrynę chronioną certyfikatem SSL wydanym przez jeden z nich, certyfikatowi
temu, a zatem stronie internetowej, będzie automatycznie ufać Twój komputer. Publiczne urzędy
certyfikacji są powszechnie uznanymi podmiotami, znanymi ze zdolności do bezpiecznego
wydawania certyfikatów SSL.
Gdy firma nabywa certyfikat SSL od jednego z tych organów publicznych, przeprowadza on do-
głębną weryfikację, aby upewnić się, że osoba wnioskująca o certyfikat (czyli Ty) naprawdę
pracuje we właściwej firmie i jest upoważniona do wydawania certyfikatów. Jest to podstawa
bezpieczeństwa przy korzystaniu z certyfikatów SSL zakupionych w publicznym urzędzie
certyfikacji. Wszystkie nowe komputery domyślnie ufają certyfikatom wydanym przez te organy
i nie musisz podejmować żadnych specjalnych działań, aby otwierać witryny internetowe.
Z drugiej strony możliwe jest wydawanie certyfikatów SSL z serwera CA, który sam zbudo-
wałeś i który znajduje się w sieci lokalnej. W tym przypadku pojawiają się jednakże utrud-
nienia, ponieważ Twojemu serwerowi CA nie ufają, oczywiście, wszystkie komputery na całym
świecie — tak nawet nie powinno być. Po pierwsze, jeśli chcesz wystawić własny certyfikat
SSL do użytku na publicznej stronie internetowej, musisz przekazać na zewnątrz przynajm-
niej część swojej wewnętrznej infrastruktury PKI, znanej jako lista odwołania certyfikatów
140
(ang. Certificate Revocation List — CRL). Za każdym razem, gdy publikujesz jakiś kompo-
nent, który należy do Twojej sieci wewnętrznej, wprowadzasz ryzyko bezpieczeństwa, więc
generalnie nie powinieneś tego robić, jeśli absolutnie nie musisz. Drugim powodem, dla którego
trudno jest używać własnych certyfikatów SSL w publicznych witrynach, jest to, że tylko
komputery przyłączone do domeny Twojej firmy będą umiały zaufać takiemu certyfikatowi SSL.
Jeśli więc użytkownik zabierze swojego firmowego laptopa do domu i użyje go do uzyskania
dostępu do firmowej strony w celu odczytania poczty e-mail, prawdopodobnie wszystko będzie
działać dobrze. Jeśli jednak użytkownik spróbuje uzyskać dostęp do tej samej strony poczty
e-mail ze swojego komputera domowego, który nie jest częścią Twojej domeny ani sieci, otrzyma
komunikat ostrzegawczy certyfikatu i będzie musiał podjąć specjalne kroki, aby uzyskać wła-
ściwy dostęp. Jakże wielka uciążliwość dla użytkowników. Nigdy nie należy zachęcać użytkowni-
ków do zaakceptowania ryzyka i pominięcia komunikatu ostrzegawczego związanego z certyfi-
katem. Jest to przepis na katastrofę, nawet jeśli certyfikat został wydany przez urząd certyfikacji
własnej firmy. Zasadniczo nigdy nie należy akceptować takiego ryzyka.
Tych problemów pozwala uniknąć zakup certyfikatu SSL od jednego z publicznych urzędów
certyfikacji. Jest to standardowy i zalecany sposób wykorzystywania protokołu SSL w publicznie
dostępnych witrynach internetowych. Strony intranetowe znajdujące się w sieci lokalnej to
już całkiem inna historia, ponieważ nie są one udostępnione w internecie, a ich poziom bezpie-
czeństwa jest znacznie mniejszy. Możesz użyć wewnętrznego serwera CA do wydawania certyfi-
katów SSL dla swoich wewnętrznych stron intranetowych, więc nie musisz ponosić kosztów
związanych z zakupem certyfikatów.
Istnieje kilka różnych poziomów certyfikatów SSL, które można kupić w publicznym urzędzie
certyfikacji. Informacje o nich są podawane na stronach internetowych takiego urzędu. Zasadni-
czo chodzi o to, że im wyższa cena certyfikatu, tym bardziej jest on bezpieczny. Poziomy są
związane ze sposobem kontroli osoby żądającej certyfikatu, ponieważ to właśnie decyduje o od-
powiednim bezpieczeństwie w przypadku certyfikatów SSL. Urząd gwarantuje, że jego certyfi-
kat został wydany prawdziwej firmie, która jest właścicielem danej witryny internetowej.
Oprócz poziomu kontroli, który można ustalić przy zakupie certyfikatu, należy wybrać jeszcze
jedną opcję. Jest ona o wiele ważniejsza z technicznego punktu widzenia i jest związana ze
sposobem działania certyfikatów. Dostępne są różne konwencje nazewnictwa i nie ma najlepszej
odpowiedzi na pytanie o to, jaką opcję powinno się wybrać. Każda sytuacja, która wymaga
użycia certyfikatu, będzie wyjątkowa i każdą należy ocenić indywidualnie przed podjęciem
decyzji, który schemat nazewnictwa zadziała najlepiej. Omówmy w skrócie trzy wersje konwen-
cji nazewnictwa certyfikatów SSL.
Certyfikaty dla pojedynczej nazwy

Jest to najtańsza i najczęściej stosowana metoda wyboru certyfikatu dla indywidualnej strony
internetowej. Certyfikat dla pojedynczej nazwy (ang. single-name certificate) zawiera informacje
o jednej nazwie DNS i chroni ją. Gdy konfigurujesz nową stronę internetową o adresie
portal.contoso.com i chcesz, aby ruch sieciowy był chroniony przy użyciu protokołu HTTPS,
zainstalujesz na niej certyfikat SSL. Gdy będziesz chciał prosić urząd certyfikacji o wydanie
nowego certyfikatu, powinieneś wpisać nazwę portal.contoso.com w polu Common name
141
(Nazwa pospolita) formularza wniosku. Ta pojedyncza nazwa DNS jest jedyną nazwą, która może
być chroniona i sprawdzana przez ten certyfikat.
Certyfikaty dla wielu adresów

Certyfikaty dla wielu adresów (ang. Subject Alternative Name — SAN) zazwyczaj kosztują
nieco więcej niż certyfikaty dla pojedynczej nazwy, ponieważ mają więcej możliwości. Żądając
certyfikatu SAN, można określić wiele nazw DNS, które certyfikat może chronić. Po wystawieniu
certyfikat SAN będzie zawierał podstawową nazwę DNS, która zazwyczaj jest główną nazwą
witryny, a w jego właściwościach znajdziesz listę dodatkowych nazw DNS podanych podczas
żądania. Ten pojedynczy certyfikat można zainstalować na serwerze WWW i wykorzystać do
sprawdzania poprawności ruchu dla dowolnej nazwy DNS zawartej w certyfikacie. Przykładem
zastosowania certyfikatu SAN jest konfiguracja serwera Lync (Skype dla firm). Lync używa
wielu różnych nazw, ale wszystkie należą do tej samej domeny DNS. Ważna uwaga dotycząca
certyfikatów SAN: Twoje nazwy muszą należeć do tej samej domeny lub subdomeny.
Oto przykładowa lista nazw, które możemy zawrzeć w jednym certyfikacie SAN na potrzeby
systemu Lync:
 Lync.contoso.com (adres podstawowy),
 Lyncdiscover.contoso.com,
 Meet.contoso.com,
 Dialin.contoso.com,
 Admin.contoso.com.
Różne witryny (usługi) używane przez serwer Lync są następnie udostępniane na jednym lub
wielu serwerach. Aby zweryfikować ruch sieciowy skierowany do dowolnego z tych serwerów,
możesz użyć tego samego certyfikatu SAN.
Certyfikaty wieloznaczne
Ostatni, ale na pewno nie mniej ważny jest certyfikat wieloznaczny (ang. wildcard certificate).
To model luksusowy, który ma najwięcej możliwości i jest najbardziej uniwersalny, a jednocze-
śnie zapewnia najłatwiejszy sposób implementacji na wielu serwerach. Nazwa na certyfika-
cie wieloznacznym zaczyna się od gwiazdki (*). Oznacza ona, że każda subdomena, której
nazwa poprzedza nazwę domeny DNS, zostanie objęta tym certyfikatem. Jeśli jesteś właścicielem
adresu contoso.com i planujesz określić wiele publicznych rekordów DNS, które będą przy-
pisane do różnych witryn i serwerów internetowych, możesz kupić pojedynczy certyfikat
wieloznaczny o nazwie *.contoso.com, który zapewni zabezpieczenie wszystkich Twoich
subdomen.
Certyfikaty wieloznaczne zazwyczaj możesz zainstalować na tylu serwerach, na ilu masz

ochotę. Nie istnieje tu ograniczenie związane z liczbą różnych nazw DNS, które można
zweryfikować. Natknąłem się jednak na wyjątek od tej zasady: gdy umowa określonego
klienta z jego urzędem certyfikacji określała, że musi on zgłaszać każdą instancję używanego
certyfikatu wieloznacznego i za każdą płacić. Czytaj więc dokładnie umowy, gdy zawierasz
je z urzędem certyfikacji. Certyfikatu wieloznacznego można używać w firmie w całkowicie
142
dowolny sposób, dzięki czemu możesz wdrożyć różne witryny i usługi na wielu serwerach, a także
wszędzie z niego korzystać.
Wadą certyfikatu wieloznacznego jest jego wysoka cena. Jeśli jednak masz duże potrzeby
związane z certyfikatami lub rozległe plany ich rozwoju, administrowanie certyfikatami wielo-
znacznymi będzie w dłuższej perspektywie znacznie łatwiejsze, szybsze i bardziej opłacalne.
Planowanie środowiska PKI

Ponieważ w tej książce omawiamy system Windows Server 2019, oznacza to, że Twój serwer
CA może i powinien być obsługiwany przez ten najnowszy i najlepszy z systemów operacyj-
nych. Podobnie jak w przypadku większości funkcji systemu Server 2019, również utworze-
nie serwera urzędu certyfikacji w sieci jest tak proste, jak zainstalowanie odpowiedniej roli
w środowisku Windows. Znajduje się ona na samej górze listy i możesz ją rozpoznać po na-
zwie Active Directory Certificate Services (Usługi certyfikatów w systemie Active Directory
— AD CS). Podczas instalowania tej roli pojawi się kilka ważnych opcji do wyboru, dlatego
musisz zrozumieć ich znaczenie przed utworzeniem poprawnie działającego środowiska PKI.
Po zaimplementowaniu roli urzędu certyfikacji nie można zmienić nazwy serwera i jego
statusu w domenie. Upewnij się, że przed zainstalowaniem roli AD CS nadałeś serwerowi
właściwą nazwę i dołączyłeś go do domeny (jeśli to konieczne). Nie będziesz później
mógł zmienić tych ustawień!
Usługi roli AD CS
Pierwszą decyzją, jaką musisz podjąć podczas instalowania roli AD CS, jest wybór odpowiednich
usług, co zaprezentowano na poniższym zrzucie ekranu:
143
Po kliknięciu danej opcji zostanie wyświetlony opis jej możliwości, co prawdopodobnie pomoże
Ci wybrać, których elementów roli będziesz potrzebować. Oto krótkie podsumowanie tych
opcji. Zwróć uwagę na to, że nie wymieniam ich w kolejności, w jakiej są wyświetlone na ekra-
nie, ale raczej sugeruję się ich poziomem ważności podczas konfiguracji:
 Certification Authority (Urząd certyfikacji): jest to podstawowy komponent
certyfikatów, który musi zostać zainstalowany, aby serwer mógł oficjalnie stać się
urzędem certyfikacji.
 Certification Authority Web Enrollment (Obsługa urzędu certyfikacji przez serwer
WWW): ta usługa również jest często instalowana, szczególnie w środowiskach,
które są na tyle małe, by można było uruchomić jeden serwer CA dla całej sieci.
Powoduje ona zainstalowanie na serwerze funkcji IIS (serwera WWW) i uruchomienie
prostej witryny WWW służącej do wysyłania żądań wydania certyfikatów.
Omówimy ją w dalszej części rozdziału, gdy przejdziemy do wydawania certyfikatów
za pomocą interfejsu WWW.
 Certificate Enrollment Web Service (Usługa sieciowa dla rejestracji certyfikatów)
i Certificate Enrollment Policy Web Service (Usługa sieciowa dla zasad rejestracji
certyfikatów): przez większość czasu będziemy się zajmować wydawaniem
certyfikatów tylko swoim firmowym systemom dołączonym do domeny. W takich
przypadkach te dwie opcje nie są konieczne. Jeśli planujesz wydawać ze swojego
serwera certyfikaty dla komputerów nieprzyłączonych do domeny, musisz wybrać
te opcje.
 Network Device Enrollment Service (Usługa rejestracji urządzeń sieciowych):
jak sama nazwa wskazuje, ta usługa urzędu certyfikacji umożliwia wydawanie
certyfikatów routerom i innym urządzeniom sieciowym.
 Online Responder (System odpowiedzi na zapytania): jest to specjalna usługa
zarezerwowana dla większych środowisk. Wewnątrz każdego certyfikatu znajduje
się specyfikacja listy odwołania certyfikatów (CRL). Gdy komputer kliencki próbuje
skorzystać z certyfikatu, sprawdza listę CRL, aby się upewnić, że certyfikat nie
został odwołany. Lista CRL jest ważnym elementem zabezpieczeń certyfikatu.
W środowisku składającym się z tysięcy klientów Twoja lista CRL może być
bardzo zajęta odpowiadaniem na wszystkie ich żądania. Aby zmniejszyć obciążenie,
możesz wdrożyć dodatkowe serwery CA, które będą działać w trybie odpowiedzi
na te zapytania.
Na potrzeby naszego laboratorium i w celu uwzględnienia potrzeb większości małych i średnich

firm wybiorę dwie opcje zaprezentowane na wcześniejszym zrzucie ekranu: Certification
Authority i Certification Authority Web Enrollment.
Urząd certyfikacji przedsiębiorstwa czy autonomiczny?

Po zainstalowaniu roli AD CS Menedżer serwera powiadomi Cię, że usługi certyfikatów wyma-
gają dodatkowej konfiguracji, podobnie jak ma to miejsce w przypadku wielu pozostałych ról.
Podczas konfigurowania roli urzędu certyfikacji po raz pierwszy staniesz przed koniecznością
144
dokonania poważnego wyboru. Czy chcesz, aby nasz serwer był urzędem certyfikacji przedsię-
biorstwa (ang. Enterprise CA) czy urzędem autonomicznym (ang. Standalone CA)?
Zacznijmy od urzędu certyfikacji przedsiębiorstwa. Jak poinformuje kreator, serwer CA dla

przedsiębiorstwa musi należeć do domeny. Tego typu serwery pracują zwykle przez cały czas,
aby mogły wystawiać certyfikaty komputerom i użytkownikom, którzy ich potrzebują. Moment
— dlaczego w ogóle chcielibyśmy wyłączyć serwer certyfikatów? Odpowiemy na to pytanie
za chwilę, ale jeśli zamierzasz wykorzystać ten rodzaj urzędu certyfikacji do wydawania certyfi-
katów, musi on oczywiście pozostać włączony. Większość serwerów urzędów certyfikacji w śro-
dowisku domenowym obsługuje urzędy certyfikacji przedsiębiorstwa. Podczas tworzenia urzędu
certyfikacji przedsiębiorstwa szablony i niektóre informacje specyficzne dla certyfikatów mogą
być przechowywane w usłudze Active Directory, co sprawia, że integracja certyfikatów i domeny
jest ściślejsza i bardziej korzystna. Jeśli dopiero zapoznajesz się z rolą urzędu certyfikacji,
zalecamy, byś rozpoczął od stworzenia urzędu certyfikacji przedsiębiorstwa, ponieważ lepiej
spełnia on wymagania większości organizacji.
Wnioskując z powyższego akapitu, możesz stwierdzić, że autonomiczny urząd certyfikacji jest

rzadziej wdrażany. Takiego typu urzędy mogą należeć do domeny lub pozostawać poza tą zor-
ganizowaną częścią sieci i znajdować się w lokalnej grupie roboczej. Jeśli istnieje wymóg bezpie-
czeństwa, który określa, że Twój serwer certyfikatów nie powinien zostać dołączony do domeny,
może to być powodem, dla którego użyjesz autonomicznego urzędu certyfikacji. Innym może
być to, że usługa Active Directory po prostu nie istnieje w wybranym środowisku. Moim zda-
niem niezwykle trudno byłoby znaleźć sieć, w której ktoś próbowałby użyć systemu Windows
Server 2019 jako swojego urzędu certyfikacji, a zarazem nie uruchomił usług domenowych
Active Directory, ale jestem pewien, że gdzieś istnieją takie skrajne przypadki. Wówczas również
musisz wybrać autonomiczny urząd certyfikacji. Trzeci przykład, w którym wybierzesz opcję
autonomiczną, to już wspomniana sytuacja — konieczność wyłączenia serwera. Tego rodzaju
scenariusz jest zwykle określany jako urząd główny w trybie offline. Nie omawialiśmy jeszcze
głównych urzędów certyfikacji, ale za chwilę poruszymy ten temat. Jeśli uruchamiasz urząd
główny w trybie offline, tworzysz najwyższy poziom hierarchii PKI w postaci samodzielnego,
głównego urzędu certyfikacji, a poniżej umieszczasz urzędy podrzędne. Twoje podrzędne
urzędy certyfikacji wydają certyfikaty, co oznacza, że urząd główny można bezpiecznie wyłączyć,
ponieważ nie ma on żadnych bieżących obowiązków. Dlaczego miałbyś to zrobić? Cóż, więk-
szość firm tego nie robi, ale współpracowałem też z takimi, które miały wdrożone zasady
bezpieczeństwa na bardzo wysokim poziomie i dla których to był właśnie powód wyłączenia
urzędu głównego. Jeśli wszystkie serwery CA są powiązanymi ze sobą urzędami certyfikacji
przedsiębiorstwa, a odpowiednie informacje przechowuje się w usłudze Active Directory,
zaatakowanie jednego z podrzędnych urzędów certyfikacji może oznaczać katastrofę dla całej
infrastruktury PKI. Być może jedynym ratunkiem będzie wówczas zlikwidowanie całego środo-
wiska PKI i wszystkich serwerów urzędów certyfikacji oraz ich ponowne utworzenie. Gdybyś
musiał to zrobić, oznaczałoby to nie tylko odbudowę serwerów, ale także ponowne wydanie
zupełnie nowych kopii certyfikatów wszystkim użytkownikom i urządzeniom, którzy je wcze-
śniej posiadali.
Z drugiej strony, jeśli samodzielny, główny urząd certyfikacji jest wyłączony, atak nie będzie
miał na niego żadnego wpływu. W takim przypadku możesz po prostu usunąć zaatakowane
145
serwery certyfikatów, ale Twój serwer główny pozostanie w bezpiecznym miejscu. Możesz
następnie przywrócić tę maszynę do trybu online, dołączyć do niego nowe serwery podrzędne
i w prosty sposób zapewnić ciągłość usług. Główne klucze przechowywane w urzędzie certyfi-
kacji nie będą musiały zostać ponownie wydane, ponieważ nigdy nie zostały narażone na szwank
podczas ataku.
Jak wspominałem, powyższe rozwiązanie nie jest zbyt często stosowane, ale można je zaim-
plementować. Jeśli chcesz dowiedzieć się więcej na temat głównych urzędów certyfikacji
działających w trybie offline i ich zastosowań, zdecydowanie polecam zapoznanie się z artykułem
TechNet znajdującym się pod adresem http://social.technet.microsoft.com/wiki/contents/articles/
2900.offline-root-certification-authority-ca.aspx. Jeśli zastanawiasz się nad wyborem głównego
urzędu certyfikacji działającego w trybie offline dlatego, że to rozwiązanie wydaje się bardziej
bezpieczne, ale poza tym nie masz żadnego innego powodu, zalecam zmianę planów i użycie
urzędu certyfikacji przedsiębiorstwa dostępnego online. Wprawdzie użycie głównego urzędu
w trybie offline jest bezpieczniejsze, ale większość firm uważa, że taka konfiguracja nie jest
warta dodatkowych kłopotów, które towarzyszą korzystaniu z niej. Jeśli ją wybierzesz, pojawią
się pewne ograniczenia w zakresie użyteczności.
W większości przypadków powinieneś więc wybrać opcję Enterprise CA (Urząd certyfikacji

przedsiębiorstwa) i kontynuować instalację od tego miejsca.
Główny czy podrzędny urząd certyfikacji?

Podczas tworzenia nowego urzędu certyfikacji stoisz przed kolejnym poważnym wyborem.
Czy Twój nowy serwer będzie głównym (ang. Root CA) czy podrzędnym urzędem certyfikacji
(ang. Subordinate CA)? W niektórych przypadkach, nawet w wielu dokumentach firmy Microsoft,
podrzędny urząd certyfikacji jest częściej nazywany urzędem wystawiającym. W wielowarstwo-
wej strukturze PKI podrzędne (wystawiające) urzędy certyfikacji zasadniczo wydają certyfikaty
użytkownikom i urządzeniom w sieci.
Odpowiedni wybór jest tak naprawdę tylko kwestią tego, jak ma wyglądać Twoja hierarchia
urzędów certyfikacji. W drzewie PKI znajduje się jeden najważniejszy certyfikat wysokiego
poziomu, podpisany przez główny urząd certyfikacji. Z drugiej strony w drzewie hierarchii
poniżej głównego urzędu certyfikacji znajduje się podrzędny urząd certyfikacji, który ma certyfi-
kat wystawiony przez ten główny urząd.
Jeśli masz zamiar uruchomić tylko jeden serwer CA, musi zostać na nim uruchomiony głów-
ny urząd certyfikacji. Jeśli chcesz stworzyć wielopoziomową konfigurację służącą do wydawania
certyfikatów, pierwszy urząd certyfikacji w Twoim środowisku powinien być głównym, a pod
nim możesz umieścić podrzędne. W sieci dozwolone jest posiadanie wielu urzędów głównych,
a zatem wielu drzew hierarchii, tak więc konfiguracja środowiska PKI może zostać zdefiniowana
według Twojego uznania. W mniejszych firmach bardzo często spotyka się tylko jeden serwer CA
— jest nim główny urząd certyfikacji przedsiębiorstwa. Ze względu na prostotę administracji
użytkownicy są gotowi podjąć ryzyko, że w przypadku jeśli coś stanie się z tym serwerem,
stworzenie nowego i ponowne wydanie certyfikatów nie będzie wielkim problemem.
146
W większych sieciach częściej występuje pojedynczy urząd główny z kilkoma podrzędnymi

poniżej niego. W tym przypadku urząd główny jest zazwyczaj „grubą rybą”, a podrzędne urzędy
certyfikacji wykonują realną pracę — wystawiają certyfikaty klientom.
Nazwa serwera urzędu certyfikacji

Jak zapewne pamiętasz, po zainstalowaniu roli nazwa serwera musi pozostać niezmieniona.
Jednak po przejściu na kolejny ekran kreatora konfiguracji urzędu certyfikacji pojawi się okno
Specify the name of the CA (Określ nazwę urzędu certyfikacji). O co chodzi? Myślałem, że już to
zrobiliśmy, gdy określiliśmy nazwę serwera!
Otóż nadaliśmy serwerowi nazwę, która została zapisana w bazie Active Directory, ponieważ jest
on dołączony do domeny. Rzeczywista nazwa urzędu certyfikacji to jednak coś zupełnie innego.
Jest to nazwa, która będzie widnieć we właściwościach każdego certyfikatu wystawianego przez
ten urząd certyfikacji. Zostanie ona także skonfigurowana w różnych miejscach usługi Active
Directory, ponieważ tworzę urząd certyfikacji przedsiębiorstwa. Kreator sam określa możliwą
do użycia nazwę, którą wielu administratorów po prostu przyjmuje i stosuje. Jeśli chcesz zapro-
ponować własną nazwę, powinieneś to zrobić na obecnym ekranie. Po określeniu nazwy nie
będzie można już jej zmienić:
Czy mogę zainstalować rolę CA na kontrolerze domeny?

Skoro ta rola jest oficjalnie zwana usługami certyfikatów w systemie Active Directory, czy to
oznacza, że powinienem ją zainstalować na jednym ze swoich kontrolerów domeny? Nie! Nie-
stety, znam wiele małych i średnich firm, które właśnie tak zrobiły i do tej pory tylko szczęśliwym
trafem nie mają zbyt wielu problemów. Technicznie jest to w porządku. Nie jest to jednak
147
ścieżka instalacji zalecana przez firmę Microsoft, dlatego powinieneś tworzyć urzędy certyfikacji
na oddzielnych serwerach. Jeśli to tylko możliwe, staraj się nie instalować na nich żadnych
innych ról.
Tworzenie nowego szablonu certyfikatu

Dość gadania, czas na pracę. Gdy rola urzędu certyfikacji została już zainstalowana, zróbmy
coś! Celem serwera certyfikatów jest wydawanie certyfikatów, nieprawdaż? Czy powinniśmy
więc zacząć je wydawać? Moment, nie tak szybko. Kiedy chcesz z serwera CA wydać certyfikat
na urządzenie lub użytkownika, nie wybierasz samego certyfikatu, ale używasz jego szablonu.
Dzięki temu wdrażasz certyfikat oparty na ustawieniach skonfigurowanych w tym szablonie.
Szablony certyfikatów są czymś w rodzaju przepisów na potrawy. Na serwerze urzędu certyfi-
kacji tworzysz szablony i dołączasz do nich wszystkie poszczególne składniki lub ustawienia,
które powinny zostać zawarte w docelowym certyfikacie. Gdy następnie użytkownicy lub
komputery chcą uzyskać certyfikat z serwera CA, w pewnym sensie „pieką” certyfikat w swoim
systemie, by następnie poinformować urząd certyfikacji, który przepis na szablon należy zasto-
sować. Certyfikaty i potrawy? Może to zbyt przesadne porównanie, ale jest już dość późno i to
pierwsza rzecz, która przyszła mi do głowy.
Po zakończeniu konfigurowania pierwszego serwera urzędu certyfikacji jest on dostarczany

z gotowymi szablonami certyfikatów dostępnymi bezpośrednio z konsoli. W rzeczywistości
jeden z tych szablonów, o nazwie Computer (Komputer), jest zazwyczaj wstępnie skonfigurowany
do tego stopnia, że gdyby komputer kliencki poprosił nowy urząd certyfikacji o certyfikat,
byłby w stanie pomyślnie go zainstalować. Ale czy używanie gotowych szablonów i certyfikatów
jest w ogóle zabawne? Wolę stworzyć własny szablon, aby móc w nim zdefiniować określoną
konfigurację i ustawienia. W ten sposób będę dokładnie wiedział, jak skonfigurowane zostaną
certyfikaty, które ostatecznie będą wydawane moim komputerom w sieci.
Aby wykonać działanie, po raz kolejny musimy uruchomić odpowiednią konsolę administra-
cyjną. W menu Tools (Narzędzia) Menedżera serwera kliknij opcję Certification Authority
(Urząd certyfikacji). Wewnątrz konsoli możesz rozwinąć nazwę swojego urzędu certyfikacji i zo-
baczyć niektóre foldery, w tym jeden na dole o nazwie Certificate Templates (Szablony certyfika-
tów). Po kliknięciu tego folderu zobaczysz listę szablonów, które są obecnie wbudowane w nasz
serwer CA. Ponieważ nie chcemy korzystać z jednego z tych wcześniej zdefiniowanych szablo-
nów, moglibyśmy kliknąć ten folder prawym przyciskiem myszy i utworzyć nowy szablon,
ale nie jest to właściwe miejsce, w którym należałoby to zrobić. Jest to trochę bezsensowne, ale
być może istnieje jakiś mądry powód, dla którego nowe szablony certyfikatów nie mogą być
tworzone bezpośrednio z tego ekranu. Musimy przejść do innego okna, z którego można fak-
tycznie zarządzać swoimi certyfikatami i je modyfikować. W tym celu kliknij prawym przyci-
skiem myszy folder Certificate Templates, a następnie wybierz opcję Manage (Zarządzaj):
148
Teraz widzisz znacznie bardziej szczegółową listę szablonów, a na niej kilka, których nie wyświe-
tlono na pierwszym ekranie. Aby stworzyć nowy szablon, powinniśmy użyć wcześniej istnieją-
cego, który działa podobnie jak ten, którego funkcjonalność zaplanujemy. Szablony kompu-
terów są powszechnie wydawane w wielu organizacjach z powodu coraz większej liczby
technologii wymagających istnienia certyfikatów, ale jak stwierdziliśmy, nie chcemy korzy-
stać z wbudowanego szablonu, który nazywa się po prostu Computer, ponieważ wolelibyśmy,
aby nasz miał bardziej konkretną nazwę, i być może chcielibyśmy też, by okres ważności
certyfikatu był dłuższy, niż określono to w ustawieniach domyślnych. Kliknij prawym przyci-
skiem myszy wbudowany szablon Computer, a następnie wybierz opcję Duplicate Template
(Duplikuj szablon). Spowoduje to otwarcie okna Properties (Właściwości), w którym powinieneś
przejść do zakładki General (Ogólne) i nadać naszemu nowemu szablonowi unikatową nazwę.
W następnym rozdziale omówimy technologię zdalnego dostępu o nazwie DirectAccess,

która będzie używana w naszym środowisku. Poprawna implementacja tej technologii obej-
muje wydawanie certyfikatów dla wszystkich mobilnych stacji roboczych, dlatego będziemy
chcieli wykorzystać nowy szablon do tego celu. Zakładka General to także miejsce, w którym
możemy ustalić okres ważności certyfikatu. W polu Validity period (Okres ważności) wprowa-
dzimy więc wartość 2 (zobacz pierwszy rysunek na następnej stronie).
Jeśli certyfikaty, które chcesz wystawić, wymagają jakichkolwiek dodatkowych zmian usta-
wień, możesz wybrać dostępne zakładki zawarte w oknie Properties i dokonać niezbędnych
modyfikacji. W naszym przykładzie zmienię inne ustawienie, które znajduje się w zakładce
Subject Name (Nazwa podmiotu). Chciałbym, aby moje nowe certyfikaty miały nazwę pod-
miotu zgodną z nazwą komputera, dla którego będą wystawiane, dlatego z rozwijanej listy
wybrałem opcję Common name (Nazwa pospolita) (zobacz drugi rysunek na następnej stronie).
149
150
Mamy jeszcze jedną zakładkę do odwiedzenia. W każdym nowo tworzonym szablonie certyfi-
katu powinieneś zawsze skonfigurować zakładkę o nazwie Security (Zabezpieczenia). Chcemy się
tu upewnić, że uprawnienia zabezpieczeń dla tego szablonu są zdefiniowane w sposób, który
umożliwia wydawanie certyfikatu odpowiednim użytkownikom lub komputerom. Jednocześnie
musimy być pewni, że ustawienia zabezpieczeń szablonu nie są zbyt niskie, w przeciwnym
razie certyfikat mógłby otrzymać obiekt nieuprawniony. W naszym przykładzie planuję wydawać
certyfikaty DirectAccess wszystkim komputerom w domenie, ponieważ takie certyfikaty
mogą być również używane do ogólnych uwierzytelnień IPsec, które kiedyś chciałbym
skonfigurować.
Właśnie dlatego upewniam się, że w zakładce Security znajduje się pozycja o nazwie Domain
Computers (Komputery domeny), która powinna mieć uprawnienia do odczytu i rejestrowania.
Dzięki temu każdy komputer przyłączony do mojej domeny będzie miał możliwość zażądania
nowego certyfikatu utworzonego na podstawie tego szablonu:
Zdefiniowałem już wszystko, czego potrzebuję dla swojego certyfikatu, więc po prostu klikam
przycisk OK. Nowy szablon certyfikatu pojawia się teraz na liście szablonów w moim serwerze CA.
151
Wydawanie nowych certyfikatów

Teraz mamy do wykonania czynność, na której za pierwszym razem potyka się wiele osób.
Utworzyliśmy nowy szablon, a dodatkowo sprawdziliśmy, czy jego uprawnienia zostały odpo-
wiednio skonfigurowane, aby każdy komputer, który należy do domeny, mógł poprosić o certyfi-
kat. Tak więc następnym logicznym krokiem powinno być zalogowanie się na komputer
kliencki i zażądanie certyfikatu. Jest jednak dodatkowe zadanie, które należy wykonać, aby
to było możliwe.
Mimo że nowy szablon został utworzony, nie został jeszcze opublikowany. W obecnej chwili
serwer CA nie będzie oferował klientom nowego szablonu, nawet jeśli są mu przypisane od-
powiednie uprawnienia zabezpieczeń. Proces publikowania szablonu certyfikatu jest bardzo
szybki — to tylko kilka kliknięć myszą — ale jeśli nie wiesz, że należy go wykonać, może to
być dla Ciebie bardzo frustrujące, ponieważ w interfejsie nie znajdziesz żadnej wskazówki
dotyczącej tego wymagania.
Publikowanie szablonu
Jeśli konsola szablonów certyfikatów jest nadal otwarta (za pomocą niej zarządzaliśmy na-
szymi szablonami), zamknij ją, aby wrócić do głównej konsoli zarządzania urzędem certyfi-
kacji. Zauważyliśmy, że lista dostępnych szablonów certyfikatów, która się w niej wyświetla,
jest znacznie krótsza, pamiętasz? Dzieje się tak, ponieważ zawiera ona tylko te szablony certyfi-
katów, które zostały opublikowane i są dostępne do wydania. Aby dodać inne szablony do
opublikowanej listy, w tym nasz nowy, wystarczy kliknąć prawym przyciskiem myszy folder
Certificate Templates (Szablony certyfikatów), a następnie przejść do opcji New/Certificate
Template to Issue (Nowy/Szablon certyfikatu do wystawienia):
Pojawi się nowe okno dialogowe z listą dostępnych szablonów, które nie zostały jeszcze wydane.
Wszystko, co musisz zrobić, to wybrać swój szablon z tej listy i kliknąć przycisk OK. Nowy
szablon znajdzie się teraz na liście opublikowanych szablonów certyfikatów i komputer
kliencki może wystąpić z prośbą o zainstalowanie Twojego certyfikatu:
152
Jeśli przyjrzysz się liście i nie zauważysz na niej swojego nowo utworzonego szablonu, może
być konieczne wykonanie dodatkowego kroku. Czasami trzeba po prostu chwilę odczekać,
ponieważ musi się zakończyć proces replikacji pomiędzy kontrolerami domeny. Innym ra-
zem nowy szablon nie pojawi się na tej liście nawet po dłuższym czasie. W takim przypadku
prawdopodobnie wystarczy ponownie uruchomić usługę urzędu certyfikacji, aby zmusić ją
do pobrania informacji o nowym szablonie. Aby to zrobić, kliknij prawym przyciskiem myszy na-
zwę urzędu certyfikacji widniejącą w górnej części konsoli i przejdź do opcji All Tasks/Stop
Service (Wszystkie zadania/Zatrzymaj usługę). Zatrzymanie tej usługi zwykle zajmuje sekundę
lub dwie; następnie możesz natychmiast ponownie kliknąć prawym przyciskiem myszy nazwę
urzędu certyfikacji i tym razem wybrać opcję All Tasks | Start Service (Wszystkie zadania/
Uruchom usługę). Teraz spróbuj ponownie opublikować nowy szablon, a powinieneś zobaczyć
go na liście:
153
Żądanie wydania certyfikatu przy użyciu konsoli MMC

Nasz nowy szablon certyfikatu został utworzony i pomyślnie opublikowaliśmy go w konsoli
urzędu certyfikacji, dzięki czemu jest on formalnie gotowy do wydania. Nadszedł czas, by to
przetestować. Aby to zrobić, zaloguj się w sieci do zwykłego komputera klienckiego. Żądanie
wydania nowego certyfikatu można zrealizować na kilka sposobów. Pierwszy polega na uży-
ciu starej, dobrej konsoli MMC. Na komputerze klienckim uruchom konsolę MMC i dodaj
do niej przystawkę Certificates (Certyfikaty). Po wybraniu opcji Certificates z listy dostępnych
przystawek i kliknięciu przycisku Add (Dodaj) pojawi się okno dialogowe z kilkoma opcjami
do wyboru. Możesz zarządzać certyfikatami dla konta użytkownika, konta usługi lub konta kom-
putera. Ponieważ próbujemy wystawić certyfikat, który będzie używany przez sam komputer,
z listy powinienem wybrać opcję Computer account (Konto komputera), a następnie kliknąć
przycisk Next (Dalej):
Na następnej stronie kliknij przycisk Finish (Zakończ), aby wybrać opcję domyślną, czyli Local
computer (Komputer lokalny). Dzięki temu będziemy mogli zarządzać certyfikatami dostępnymi
w lokalnym magazynie certyfikatów komputera.
W nowszych systemach operacyjnych, takich jak Windows 8 i 10 oraz Windows Server

2012, 2012 R2, 2016 i 2019, istnieje skrót MSC służący do bezpośredniego otwierania
magazynu certyfikatów komputera lokalnego. W polu Run (Uruchom) wpisz po prostu
CERTLM.MSC, a konsola MMC automatycznie uruchomi i utworzy tę przystawkę.
Uruchomiliśmy aplikację, której powinieneś używać podczas instalowania certyfikatów na kom-

puterze lub serwerze. W magazynie certyfikatów istnieje wiele folderów, ale nas interesuje
jeden, o nazwie Personal (Osobisty), w którym będziemy chcieli zainstalować nasz certyfikat.
Wybierzemy go niezależnie od tego, czy zainstalujemy certyfikat maszyny (jak w naszym
przypadku) czy też certyfikat SSL na serwerze WWW. Osobisty folder certyfikatów komputera
lokalnego jest poprawną lokalizacją dla obu rodzajów certyfikatów. Jeśli klikniesz nazwę Personal,
zobaczysz, że obecnie na liście nie ma żadnych elementów (zobacz pierwszy rysunek na na-
stępnej stronie).
Aby poprosić o nowy certyfikat z naszego serwera CA, po prostu kliknij prawym przyciskiem myszy
folder Personal, a następnie wybierz opcję All Tasks/Request New Certificate... (Wszystkie
zadania/Żądaj nowego certyfikatu...). Spowoduje to otwarcie kreatora — kliknij od razu
przycisk Next (Dalej).
154
Teraz pojawi się ekran, który wygląda tak, jakby trzeba było coś na nim wykonać. Ponieważ jed-
nak żądamy certyfikatu na jednym z naszych firmowych komputerów przyłączonych do do-
meny, w rzeczywistości nie musimy nic robić (patrz poniższy zrzut ekranu). Po prostu kliknij
przycisk Next (Dalej), a kreator wyśle zapytanie do usługi Active Directory, aby wyświetlić
wszystkie szablony certyfikatów, które są możliwe do wydania:
Zostanie wyświetlony ekran Request Certificates (Żądaj certyfikatów), na którym pojawi się
lista dostępnych szablonów. Jest ona dynamiczna — jej zawartość zależy od tego, na jakim
komputerze jesteś zalogowany i jakie są uprawnienia konta użytkownika. Czy pamiętasz, jak
konfigurowaliśmy zakładkę związaną z zabezpieczeniami naszego nowego szablonu certyfikatu?
To tam określiliśmy, kto i co może pobierać nowe certyfikaty oparte na danym szablonie.
155
Gdybym zdefiniował bardziej szczegółową grupę niż komputery w domenie, możliwe, że mój
nowy szablon DirectAccess Machine nie pojawiłby się na tej liście. Ponieważ jednak stworzyłem
szablon w taki sposób, by mógł być dostępny dla dowolnego komputera z naszej domeny,
widzę go na ekranie:
Jeśli nie widzisz swojego szablonu na liście, zaznacz pole wyboru Show all templates
(Pokaż wszystkie szablony). Dzięki temu uzyskasz pełną listę wszystkich szablonów
znajdujących się na serwerze CA oraz odpowiednie wyjaśnienia, dlaczego nie są one
obecnie możliwe do wydania.
Zaznacz opcję wyboru znajdującą się obok żądanego certyfikatu i kliknij przycisk Enroll (Zareje-
struj). Cała operacja potrwa kilka sekund, podczas gdy serwer CA będzie przetwarzać Twoje
żądanie i wyda nowy certyfikat, który będzie przeznaczony dla Twojego komputera i będzie
zawierał ustawienia umieszczone przez nas w szablonie. Po zakończeniu operacji będziesz
mógł odnaleźć nasz nowy certyfikat maszyny w folderze Personal/Certificates (Osobisty/Certyfikaty)
konsoli MMC. Po dwukrotnym kliknięciu certyfikatu możesz sprawdzić jego właściwości,
aby się upewnić, że wszystkie ustawienia, które zdefiniowałeś w szablonie, pojawiły się
w certyfikacie (zobacz pierwszy rysunek na następnej stronie).
Żądanie wydania certyfikatu przy użyciu interfejsu WWW

Gdy tylko to możliwe, używam konsoli MMC w celu żądania wydania certyfikatów. Istnieje jed-
nakże inna platforma, za pomocą której w większości przypadków można żądać certyfikatów
i je wystawiać. Napisałem „w większości przypadków”, ponieważ istnienie tej opcji zależy
przede wszystkim od sposobu zdefiniowania serwera CA. Podczas instalowania roli AD CS
upewniłem się, że wybrałem opcje Certification Authority (Urząd certyfikacji) oraz Certification
Authority Web Enrollment (Obsługa urzędu certyfikacji przez serwer WWW). Właśnie tę drugą
opcję będziemy analizować w tym punkcie rozdziału. Bez składnika roli związanego z rejestracją
156
w sieci nie mielibyśmy witryny WWW działającej na naszym serwerze CA, więc nie mogli-
byśmy za jej pomocą zażądać certyfikatu. Jeśli serwer CA nie ma włączonej opcji rejestracji
przez serwer WWW, możesz ponownie odwiedzić stronę instalacji roli w Menedżerze ser-
wera i dodać tę opcję:
Po zainstalowaniu opcji obsługi urzędu certyfikacji przez serwer WWW, na naszym serwerze CA
działa obecnie witryna, do której można uzyskać dostęp za pośrednictwem przeglądarki inter-
netowej. Posiadanie tej witryny jest przydatne, jeśli z jakiegoś powodu użytkownicy muszą
mieć możliwość wydawania własnych certyfikatów. Znacznie prościej będzie przekazać im
dokumentację lub przeszkolić ich w zakresie żądania certyfikatu za pomocą strony internetowej,
niż zmuszać do sprawnego korzystania z konsoli MMC. Ponadto, jeśli spróbujesz zażądać
certyfikatów od komputerów, które nie znajdują się w tej samej sieci co serwer CA, użycie
MMC może być trudne. Na przykład, jeśli użytkownik, będąc w domu, będzie chciał poprosić
o nowy certyfikat, konsola MMC bez ustanowionego tunelu VPN najprawdopodobniej nie
będzie w stanie połączyć się z serwerem CA w celu pobrania tego certyfikatu. Ponieważ funk-
cjonuje nasza witryna do rejestracji certyfikatów, możesz (podobnie jak w przypadku każdej
157
innej witryny w sieci) uczynić ją dostępną z zewnątrz z użyciem odwrotnego proxy lub zapory
sieciowej, tak aby zapewnić bezpieczeństwo ruchu i możliwość żądania certyfikatów z dowolne-
go miejsca.
Aby uzyskać dostęp do tej witryny, skorzystajmy ponownie z naszego zwykłego komputera
klienckiego. Tym razem zamiast otwierać MMC, po prostu uruchomię przeglądarkę Internet
Explorer lub dowolną inną, a następnie zaloguję się na stronie WWW o adresie https://
<SERWER_CA>/certsrv. W moim konkretnym środowisku dokładny adres to https://CA1/certsrv:
Nasz adres URL rozpoczyna się od HTTPS. Aby możliwe było wysyłanie żądań, konfigu-
racja witryny musi pozwalać na wykorzystanie protokołu HTTPS zamiast zwykłego
HTTP. Wydawanie certyfikatów nie będzie funkcjonować poprzez protokół HTTP, po-
nieważ informacje do klienta byłyby wtedy przesyłane w postaci zwykłego, niezaszy-
frowanego tekstu. Umożliwienie korzystania na stronie serwera CA z protokołu HTTPS
zapewnia, że wydany certyfikat będzie przesyłany w postaci zaszyfrowanej.
Kliknięcie łącza Request a certificate (Poproś o certyfikat) przeniesie Cię do kreatora, w którym
będziesz mógł poprosić serwer CA o nowy certyfikat. Zazwyczaj ten interfejs WWW służy
do uzyskania certyfikatu użytkownika. W przypadku certyfikatów na poziomie komputera
istnieją dość proste sposoby ich automatycznej dystrybucji bez potrzeby interakcji ze strony
użytkowników. (Za chwilę dokładniej omówimy to zagadnienie). W naszym przykładzie
prosimy użytkowników o zalogowanie się na stronę i kliknięcie łącza User Certificate (Certyfikat
użytkownika) (zobacz pierwszy rysunek na następnej stronie).
Jeśli nie jesteś zainteresowany certyfikatem użytkownika i chcesz użyć interfejsu WWW
do zażądania certyfikatu komputera, serwera WWW lub jeszcze innego, możesz wy-
brać łącze advanced certificate request (zaawansowane żądanie certyfikatu) i postąpić
zgodnie z instrukcjami.
158
Następnie kliknij przycisk Submit (Prześlij), a po wygenerowaniu certyfikatu zobaczysz łącze

Install this certificate (Zainstaluj ten certyfikat), które pozwoli go zainstalować. Kliknij je, a nowo
utworzony certyfikat zostanie zainstalowany na Twoim komputerze. Na poniższym zrzucie
ekranu widzimy, że strona WWW potwierdziła pomyślną instalację. Oprócz tego w otwartej
konsoli MMC mogę sprawdzić bieżące certyfikaty użytkownika i dowiedzieć się, czy nowy
certyfikat rzeczywiście istnieje:
Określanie sposobu automatycznej

rejestracji certyfikatów
Nasz serwer urzędu certyfikacji został skonfigurowany i działa poprawnie. Możemy więc z po-
wodzeniem wydawać certyfikaty na komputery klienckie. Wspaniale! A teraz załóżmy, że prowa-
dzisz nowy projekt, a jednym z jego wymagań jest to, aby wszystkie komputery w Twojej sie-
ci otrzymywały kopię nowego certyfikatu maszyny, który właśnie stworzyliśmy. Och, brzmi to jak
dużo żmudnej pracy. Co prawda proces żądania certyfikatu jest prosty (trwa zaledwie kilka
159
sekund na każdej stacji roboczej), jeśli jednak musiałbyś go wykonać indywidualnie na kilku ty-
siącach komputerów, trzeba byłoby na to poświęcić bardzo dużo czasu. Ponadto w wielu przy-
padkach wydawane certyfikaty będą ważne tylko przez rok. Czy to oznacza, że każdego roku
będę miał do czynienia z ogromną ilością pracy administracyjnej związanej z ponownym
wydawaniem tych certyfikatów po ich wygaśnięciu? Zdecydowanie nie!
Zastanówmy się, jak można wykorzystać zasady grupy do utworzenia obiektu GPO, który
automatycznie zarejestruje nasze nowe certyfikaty na wszystkich komputerach w sieci, a oprócz
tego skonfiguruje je tak, aby w odpowiednich odstępach czasu, przed upływem terminu ważno-
ści, certyfikat mógł się automatycznie odnawiać.
Przejdźmy do konsoli zarządzania urzędem certyfikacji na naszym serwerze CA i zajrzyjmy do

folderu Issued Certificates (Wydane certyfikaty). Chciałbym tylko sprawdzić, ile certyfikatów wyda-
liśmy do tej pory w naszej sieci. Jak się okazuje, na razie niewiele, ale mam nadzieję, że będzie
ich więcej, gdy poprawnie skonfigurujemy swoją politykę i zacznie ona automatycznie działać:
Zaloguj się do serwera kontrolera domeny, a następnie otwórz konsolę Group Policy Management
(Zarządzanie zasadami grupy). Utworzyłem nowy obiekt zasad grupy o nazwie Enable Certificate
Auto-enrollment (Włącz automatyczne rejestrowanie certyfikatów), a teraz zamierzam poddać go
edycji i znaleźć ustawienia, które muszę odpowiednio skonfigurować, aby poprawnie działał
(zobacz pierwszy rysunek na następnej stronie).
Odpowiednie ustawienie obiektu GPO, które chcemy skonfigurować, znajduje się w folderze
Computer Configuration/Policies/Windows Settings/Security Settings/Public Key Policies/Certificate
Services Client — Auto-Enrollment (Konfiguracja komputera/Zasady/Ustawienia systemu
Windows/Ustawienia zabezpieczeń/Zasady kluczy publicznych/Klient usług certyfikatów —
automatyczna rejestracja).
Kliknij dwukrotnie to ustawienie, aby wyświetlić jego właściwości. Wszystko, co musimy zrobić,
to zmienić opcję Configuration Model (Model konfiguracji) na Enabled (Włączony), a następnie
zaznaczyć pola wyboru Renew expired certificates, update pending certificates, and remove
revoked certificates (Odnów wygasłe certyfikaty, aktualizuj oczekujące certyfikaty i usuń odwołane
160
certyfikaty) oraz Update certificates that use certificate templates (Aktualizuj certyfikaty, które
używają szablonów certyfikatów). Zmiana tych ustawień zagwarantuje, że automatyczne odno-
wienie zostanie wykonane automatycznie, gdy tylko zacznie się zbliżać termin ważności certyfikatów:
161
Co jeszcze musimy zdefiniować dla naszego obiektu GPO, aby go uruchomić? Utworzyć łącze,
aby można go było użyć! Jak pisałem w poprzednim rozdziale, we własnym środowisku zapewne
utworzysz łącze do określonej jednostki organizacyjnej. Ja jednak chciałbym, aby w moim labo-
ratorium certyfikaty były używane w każdej maszynie przyłączonej do domeny, dlatego podłączę
swój nowy obiekt zasad grupy do katalogu głównego domeny, aby dotyczył on wszystkich
klientów i serwerów.
Gdy obiekt GPO zostaje utworzony, skonfigurowany i połączony z domeną, mogłoby się wyda-
wać, że zostaną wydane nowe certyfikaty, a w folderze Issued Certificates będzie więcej pozycji.
Niczego nowego tam jednak nie ma. Chwileczkę, w naszym obiekcie GPO tak naprawdę nie
zdefiniowaliśmy niczego, co byłoby związane z szablonem DirectAccess Machine! Czy może
to być przyczyną problemu? Nie, w rzeczywistości nie ma żadnej dostępnej opcji, która po-
zwalałaby nam określić, jakiego rodzaju szablon chcielibyśmy wykorzystać do automatycznej
rejestracji.
Gdy w zasadach grupy umożliwiasz automatyczną rejestrację certyfikatu, staje się ona dostępna
dla każdego szablonu certyfikatu. Po zdefiniowaniu zasady automatycznej rejestracji i powiązaniu
jej z domeną, dzięki czemu stała się aktywna, działa ona teraz na każdym komputerze przy-
łączonym do domeny, dla każdego szablonu certyfikatu opublikowanego w naszym urzędzie
certyfikacji. Jednak na razie żaden certyfikat nie został wydany moim komputerom. Dzieje
się tak, ponieważ powinniśmy jeszcze dostosować ustawienia zabezpieczeń w nowym szablonie
DirectAccess Machine. Na razie skonfigurowaliśmy je w taki sposób, aby wszystkie komputery
domeny miały uprawnienia do rejestracji. Być może pamiętasz, że w zakładce Zabezpieczenia
znajdującej się we właściwościach szablonu certyfikatu było dodatkowe pole o nazwie Autoenroll
(Autorejestrowanie). Każdy szablon certyfikatu ma uprawnienie pozwalające na autoreje-
strowanie, lecz domyślnie nie jest ono włączone. Gdy umożliwiliśmy już wykonywanie automa-
tycznej rejestracji w naszej domenie, musimy również zezwolić na automatyczną rejestrację
w szablonie, który chcemy dystrybuować. Gdy tylko odblokujemy to uprawnienie, certyfikaty
zaczną się pojawiać w naszej sieci.
Przejdź do sekcji zarządzania certyfikatami na serwerze CA, a następnie dla nowego szablonu
otwórz opcję Properties (Właściwości). Wybierz zakładkę Security (Zabezpieczenia) i zezwól
na uprawnienie Autoenroll (Autorejestrowanie) dla grupy Domain Computers (Komputery
domeny). Dzięki temu urząd certyfikacji zacznie odpowiednio dystrybuować certyfikaty (zo-
bacz pierwszy rysunek na następnej stronie).
Jeśli dam swojemu środowisku chwilę, która pozwoli Active Directory zaktualizować zasady grupy
na wszystkich komputerach, zobaczę, że z serwera CA zostało wydanych więcej certyfikatów
(zobacz drugi rysunek na następnej stronie).
Aby automatycznie wystawiać certyfikaty na podstawie dowolnego szablonu, po prostu opu-

blikuj go i upewnij się, że nadałeś mu odpowiednie uprawnienia do autorejestrowania. Gdy
dla komputerów klienckich zostanie utworzony obiekt zasad grupy z automatyczną rejestra-
cją, skontaktują się one z serwerem urzędu certyfikacji i poproszą go o certyfikaty z szablo-
nów, do których mają dostęp. Gdy będzie się zbliżał termin wygaśnięcia certyfikatu, a komputer
będzie chciał go odnowić, zasady automatycznej rejestracji na podstawie znaczników czasu
zdefiniowane w obiekcie zasad grupy spowodują wydanie nowego certyfikatu przed datą wyga-
śnięcia obecnego.
162
163
Wdrożenie automatycznej rejestracji certyfikatów może bardzo usprawnić pracę administrato-

rom i przyczynić się do powstania całkowicie zautomatyzowanego procesu!
Uzyskanie certyfikatu SSL

organu publicznego
Umiesz już bez problemu pobierać certyfikaty z serwera CA znajdującego się w Twojej sieci.
W jaki sposób powinniśmy jednak w przypadku naszych serwerów sieciowych obsłużyć te
certyfikaty SSL, które powinny być uzyskane z publicznego urzędu certyfikacji? Dla wielu
czytelników będą to najczęściej wykonywane operacje związane z certyfikatami i dlatego
bardzo ważne jest, by zrozumieć również tę stronę medalu. Aby uzyskać certyfikat SSL od
wybranego urzędu publicznego, należy przeprowadzić proces składający się z trzech etapów:
utworzyć żądanie certyfikatu, przesłać to żądanie i zainstalować wynikowy certyfikat. Będziemy
korzystać z mojego serwera WEB1, na którym mam uruchomioną stronę internetową. Obecnie
witryna jest w stanie obsłużyć tylko ruch HTTP, ale gdy będziemy chcieli ją udostępnić w inter-
necie, będziemy musieli włączyć HTTPS, aby informacje przesyłane na stronę były szyfrowane.
Aby korzystać z HTTPS, musimy na serwerze WEB1 zainstalować certyfikat SSL. Na tym
serwerze działa platforma usług internetowych firmy Microsoft znana pod nazwą Internet
Information Services (Internetowe usługi informacyjne — IIS). Trójetapowy proces będzie
taki sam w przypadku każdego innego serwera WWW, takiego jak Apache. Określone działania,
które musisz wykonać, są jednak różne, ponieważ Apache i inne serwery WWW mają odmienne
od IIS interfejsy użytkownika. Ponieważ pracujemy na serwerze sieciowym Windows Server
2019, używamy IIS 10.
Para kluczy publiczny-prywatny

Zanim przejdziemy do wykonania trzech wspomnianych etapów, zastanówmy się, dlaczego
tak właśnie musi być. Prawdopodobnie słyszałeś o kluczu prywatnym, ale może nie do końca
rozumiesz, czym on jest. Gdy ze swojego komputera klienckiego łączysz się przez internet z wi-
tryną HTTPS, wiesz, że ruch jest szyfrowany. Oznacza to, że pakiety danych przed opusz-
czeniem mojego laptopa są umieszczane w ładnej, zgrabnej paczce, aby nikt ich nie widział
podczas podróży, a następnie, gdy dotrą do serwera WWW, są rozpakowywane. Mój laptop
używa klucza do szyfrowania ruchu, a do jego odszyfrowania serwer również wykorzystuje
klucz. Skąd jednak wiadomo, jakich kluczy należy użyć? Istnieją dwa rodzaje metod szyfrowania,
które można zastosować w naszym przypadku:
 Szyfrowanie symetryczne: jest to prostsza metoda szyfrowania. Oznacza ona,
że istnieje jeden klucz wykorzystywany przez obie strony. Dane są szyfrowane za
pomocą klucza, który służy również do ich rozpakowania po dotarciu do miejsca
docelowego. Ponieważ ten pojedynczy klucz ma potężną władzę, wolałbyś,
aby nie dostał się w niepowołane ręce, co oznacza, że nie chciałbyś go udostępnić
w internecie. Stąd wniosek, że szyfrowanie symetryczne nie jest zwykle używane
do ochrony ruchu na stronach internetowych.
164
 Szyfrowanie asymetryczne: jest ono używane w ruchu HTTPS. Szyfrowanie

asymetryczne wykorzystuje dwa klucze: publiczny i prywatny. Klucz publiczny
znajduje się w certyfikacie SSL, dzięki czemu każdy sprzęt podłączony do internetu
może się skontaktować z witryną i go uzyskać. Następnie laptop używa tego
klucza publicznego do szyfrowania ruchu i wysyłania go do serwera internetowego.
Dlaczego można bezpiecznie udostępnić klucz publiczny w całym internecie?
Ponieważ ruch można odszyfrować tylko przy użyciu odpowiedniego klucza
prywatnego, który odpowiednio zabezpieczony jest przechowywany na serwerze
WWW. Bardzo ważne jest zapewnienie bezpieczeństwa klucza prywatnego
i serwerów sieciowych oraz zagwarantowanie, że klucz ten nie zostanie odczytany
przez nieuprawnionego użytkownika.
Tworzenie żądania podpisania certyfikatu

Jeśli pierwszym Twoim krokiem do uzyskania certyfikatu SSL od publicznego urzędu certy-
fikacji było zalogowanie się na jego stronie internetowej, zakup certyfikatu i natychmiastowe
pobranie go — już popełniłeś błąd. Taki certyfikat oczywiście nie miałby żadnej wiedzy o kluczu
prywatnym, którego używałbyś na serwerze WWW, czyli byłby w praktyce bezużyteczny,
gdyby został gdziekolwiek zainstalowany.
Bardzo ważne jest, aby podczas instalowania na serwerze WWW certyfikatu SSL znał on
Twój klucz prywatny. Jak możemy się upewnić, że tak się stanie? Tu wchodzi w grę żądanie
podpisania certyfikatu (ang. Certificate Signing Request — CSR). Pierwszym krokiem do prawi-
dłowego uzyskania certyfikatu SSL jest wygenerowanie pliku CSR. Podczas jego generowa-
nia platforma serwera WWW tworzy i ukrywa niezbędny klucz prywatny. Ponieważ plik CSR
potrafi współpracować z tym kluczem prywatnym, po zalogowaniu się na stronie internetowej
urzędu certyfikacji używasz tego pliku w celu zażądania certyfikatu.
Klucz prywatny nie znajduje się wewnątrz pliku CSR. Urząd certyfikacji nigdy nie pozna
Twojego klucza prywatnego. Jest on bardzo ważny i przechowuje się go wyłącznie na
serwerze WWW Twojej organizacji.
Aby wygenerować plik CSR, w Menedżerze serwera otwórz IIS z menu Tools, a następnie
kliknij nazwę serwera WWW w drzewie nawigacyjnym znajdującym się po lewej stronie
okna. Spowoduje to wyświetlenie szeregu różnych apletów na głównym obszarze konsoli. Inte-
resujący nas element nazywa się Server Certificates (Certyfikaty serwera). Kliknij go dwukrotnie
W oknie Server Certificates możesz teraz zobaczyć wszystkie istniejące certyfikaty, które znajdują
się na danym serwerze. W tym miejscu pojawi się ostatecznie nasz nowy certyfikat SSL, którego
użyjemy we właściwościach witryny, gdy będziemy gotowi włączyć protokół HTTPS. Pierw-
szym krokiem do uzyskania nowego certyfikatu jest utworzenie żądania certyfikatu, którego
będzie można użyć w połączeniu z danym urzędem certyfikacji. Jeśli spojrzysz na prawą stronę
okna, zobaczysz sekcję Actions (Akcje), w której znajduje się łącze Create Certificate Request…
(Utwórz żądanie certyfikatu…). Kliknij je (zobacz drugi rysunek na następnej stronie).
165
Pojawi się nowe okno kreatora (zobacz pierwszy rysunek na następnej stronie). Musisz po-
dać w nim informacje, które będą przechowywane w certyfikacie SSL. Najważniejsze jest tu
pole Common name (Nazwa pospolita). Musi ono zawierać nazwę DNS serwera, który ma być
chroniony przez certyfikat. Zasadniczo podajesz tutaj nazwę swojej witryny. Następnie konty-
nuujesz wypełnianie informacji dotyczących Twojej firmy. Zwróć uwagę na pole Organizatio-
nal unit (Jednostka organizacyjna), które może zawierać dowolny ciąg znaków — zazwyczaj
po prostu wpisuję tu słowo Web. W przypadku pola State (Województwo) należy podać pełną
nazwę.
Na stronie Cryptographic Service Provider Properties (Właściwości dostawcy usług krypto-

graficznych) zazwyczaj pozostawisz pole Cryptographic service provider (Dostawca usług
kryptograficznych) z wartością domyślną, chyba że używasz specjalistycznej karty kryptograficz-
nej i planujesz jej użyć do szyfrowania swojej witryny. Na serwerze IIS prawie zawsze znaj-
dziesz tu dostawcę kryptograficznego Microsoft RSA SChannel. Powinieneś zmodyfikować
wartość pola Bit length (Długość w bitach). Przez wiele lat standardowa długość w bitach
wynosiła 1024 i ta wartość jest wciąż domyślna w systemie Windows Server 2019. Branża
166
szyfrowania SSL zdecydowała jednak, że wartość 1024 jest zbyt niska, a nowym standardem
powinno być 2048 bitów. Gdy wejdziesz na stronę swojego urzędu certyfikacji, aby poprosić
o certyfikat, jest bardzo prawdopodobne, że twoje żądanie będzie musiało mieć minimum
2048 bitów. Wybierz więc z rozwijanego menu wartość 2048:
Trzeba jeszcze wybrać lokalizację i nazwę pliku CSR. Należy zapisać ten plik w postaci teksto-
wej, ponieważ w momencie, gdy będziemy chcieli poprosić o certyfikat, będziemy musieli
otworzyć ten plik, a następnie skopiować i wkleić jego zawartość. Utworzyłeś właśnie plik CSR,
który można wykorzystać w celu żądania certyfikatu od publicznego urzędu certyfikacji.
Przesyłanie żądania certyfikatu

Teraz przejdź na stronę internetową publicznego urzędu certyfikacji. Każda ze wspomnia-
nych wcześniej firm, taka jak GoDaddy lub Verisign, będzie odpowiednia do tego celu.
Strony różnią się wyglądem i interfejsem, więc nie mogę podać dokładnych kroków, które
należy wykonać w tym procesie. Po założeniu konta i zalogowaniu się na stronie urzędu powi-
nieneś być w stanie znaleźć opcję zakupu certyfikatu SSL. Po zakupie tego certyfikatu będziesz
musiał wykonać procedurę jego żądania i wdrażania.
167
Zazwyczaj jedyną informacją, o którą poprosi urząd certyfikacji po przejściu do interfejsu

służącego do stworzenia nowego certyfikatu, będzie zawartość pliku CSR. Jeśli otworzysz
plik tekstowy, który wcześniej zapisałeś, zobaczysz bezsensowny zbiór znaków:
Te dziwnie wyglądające dane są jednak wymagane przez urząd certyfikacji w celu utworzenia
nowego certyfikatu SSL, który będzie poprawnie współpracować z kluczem prywatnym ser-
wera WWW. Tylko serwer, który wygenerował dany plik CSR, będzie mógł zaakceptować i pra-
widłowo wykorzystać oparty na nim certyfikat SSL. Zazwyczaj musisz jedynie skopiować całą
zawartość pliku CSR i wkleić ją na stronie internetowej urzędu certyfikacji.
Pobieranie i instalowanie certyfikatu

Teraz usiądź i cierpliwie poczekaj. W zależności od tego, z którego urzędu korzystasz i jak
często Twoja firma wykonuje w nim zakupy, certyfikat może być dostępny do pobrania prawie
natychmiast lub może upłynąć kilka godzin, zanim pojawi się na liście dostępnych pobrań.
Powodem jest to, że w wielu urzędach certyfikacji nowe certyfikaty zatwierdza realny pracownik ,
a Ty dosłownie czekasz, aż ktoś przyjrzy się Twojemu żądaniu certyfikatu i związanym z nim
informacjom, aby się upewnić, że faktycznie pracujesz dla firmy, która jest właścicielem danej
domeny. Pamiętaj: prawdziwą korzyścią z używania publicznego certyfikatu SSL jest gwarancja
urzędu certyfikacji, że użytkownik tego certyfikatu odpowiada zgłaszanej firmie. Należy się
więc upewnić, że certyfikat dla strony portal.contoso.com nie zostanie przez pomyłkę wysta-
wiony komuś z firmy Fabrikam.
Gdy będziesz już w stanie pobrać certyfikat ze strony urzędu certyfikacji, skopiuj go na serwer
WWW, na którym wygenerowaliśmy plik CSR. Bardzo ważne jest, aby zainstalować nowy
certyfikat właśnie na tym samym serwerze. Jeśli zainstalowałbyś go na innym serwerze WWW,
168
który nie wygenerował pliku CSR, certyfikat zostałby zaimportowany pomyślnie, ale nie byłby
w stanie funkcjonować. Taki problem pojawiłby się, ponieważ klucz prywatny, z którym certyfikat
powinien współpracować, nie byłby obecny na innym serwerze.
Po powrocie do konsoli zarządzania IIS możemy użyć następnej akcji z listy po prawej stronie,
Complete Certificate Request… (Ukończ żądanie certyfikatu...). Spowoduje to uruchomienie
niewielkiego kreatora, w którym podasz właśnie pobrany plik certyfikatu i zaimportujesz go
na nasz serwer. Gdy certyfikat znajdzie się na serwerze, będzie gotowy do użycia w Twojej
witrynie.
Jest jeszcze jeden dodatkowy element, który zawsze sprawdzam po zainstalowaniu lub za-
importowaniu certyfikatu SSL. W programie IIS możesz już zobaczyć swój nowy certyfikat
widniejący na liście. Po jego dwukrotnym kliknięciu zostanie wyświetlona strona właściwo-
ści certyfikatu. W dolnej części zakładki General (Ogólne) powinna się wyświetlić mała ikona
klucza, a obok niej komunikat You have a private key that corresponds to this certificate (Twój
klucz prywatny odpowiada temu certyfikatowi). Jeśli go widzisz, import się powiódł, a nowy plik
certyfikatu idealnie pasuje do pliku CSR. Serwer i certyfikat współdzielą teraz kluczowe infor-
macje o kluczu prywatnym. Certyfikat SSL może więc poprawnie działać i chronić stronę
WWW. Jeśli nie widzisz tego komunikatu, wystąpił błąd podczas żądania i pobierania naszego
certyfikatu. W takim przypadku musisz rozpocząć wszystko od nowa i wygenerować plik CSR,
ponieważ certyfikat, który otrzymałeś, nie mógł zostać odpowiednio utworzony na podstawie tego
pliku. Jeśli w dolnej części okna nie pojawi się komunikat o poprawnym zaimportowaniu
certyfikatu, nie będzie można zarządzać szyfrowanym ruchem.
Oto przykładowy wygląd zakładki w przypadku, gdy certyfikat został prawidłowo zaimportowany:
169
Eksportowanie i importowanie
certyfikatów
Często muszę używać tego samego certyfikatu SSL na wielu serwerach. Może się tak zdarzyć
w przypadku, gdy mam kilka serwerów IIS obsługujących tę samą stronę WWW, dla których
używam jakiejś formy równoważenia obciążenia, aby podzielić ruch między nimi. Potrzeba
ta może również się pojawić podczas używania sprzętowego modułu równoważenia obciążenia,
ponieważ czasami trzeba instalować certyfikaty nie tylko na samych serwerach WWW, ale
także we wspomnianym urządzeniu. Innym przykładem jest użycie certyfikatów wieloznacz-
nych. Tego typu certyfikaty zazwyczaj zamierzasz instalować na wielu serwerach.
Czy to oznacza, że muszę wygenerować plik CSR dla każdego serwera i wielokrotnie żądać
nowej kopii tego samego certyfikatu? Zdecydowanie nie; mogłoby to nawet spowodować
powstanie problemów. Gdy publiczny urząd certyfikacji ponownie generuje certyfikat (innymi
słowy, jeśli kiedyś zażądałeś certyfikatu o określonej nazwie, a po jakimś czasie ponownie
przyszedłeś poprosić o jego kopię), wówczas może unieważnić pierwszy z nich, a następnie
wydać drugi. Nie zawsze jest to od razu zauważalne, ponieważ zwykle mija jakiś czas, zanim
pierwszy certyfikat zostanie unieważniony. Jeśli ponownie zalogujesz się do urzędu certyfikacji
poprzez przeglądarkę i poprosisz o nową kopię tego samego certyfikatu z wykorzystaniem
nowego pliku CSR, wygenerowanego dla drugiego serwera WWW, może się zdarzyć, że przez
kilka dni wszystko będzie poprawnie działać, aż nagle główny serwer WWW przestanie zarzą-
dzać ruchem, ponieważ jego certyfikat SSL wygaśnie.
Co powinniśmy więc zrobić? Jeśli musisz ponownie użyć tego samego certyfikatu SSL na wielu
serwerach, możesz po prostu wyeksportować go z jednej maszyny i zaimportować w innej.
W ogóle nie ma potrzeby kontaktowania się z urzędem certyfikacji. Proces ten jest dość prosty
i możliwy do zrealizowania na dwa sposoby: w przystawce MMC dla certyfikatów lub w samym
narzędziu IIS. Należy jednak pamiętać, że proces ten różni się nieznacznie w zależności od wy-
branej metody, dlatego podczas klikania w kolejnych oknach kreatorów musisz być szczegól-
nie świadomy tego, co się dzieje z kluczem prywatnym.
Eksportowanie z przystawki MMC

Wróćmy do opcji Local Computer (Komputer lokalny) dostępnej w przystawce MMC dla certyfi-
katów, a następnie przejdźmy do pozycji Personal/Certificates (Osobisty/Certyfikaty), dzięki
czemu będziesz mógł zobaczyć na liście swój certyfikat SSL. Kliknij go prawym przyciskiem
myszy, a następnie przejdź do opcji All Tasks/Export… (Wszystkie zadania/Eksportuj...).
Podczas obsługi kreatora należy zwrócić uwagę na kilka ważnych spraw. Pierwszą decyzją, jaką
musisz podjąć, jest to, czy należy eksportować klucz prywatny. Jak pamiętasz, klucz prywatny jest
tajnym kodem, który pozwala certyfikatowi poprawnie współpracować z serwerem, na którym
jest zainstalowany. Jeśli eksportujesz certyfikat bez klucza prywatnego, nie będzie on działać
na innym serwerze. Ważne jest więc, aby w przypadku eksportowania certyfikatu z zamiarem
zainstalowania go na drugim serwerze WWW i używania do sprawdzania poprawności ruchu
SSL wybrać pierwszą opcję: Yes, export the private key (Tak, eksportuj klucz prywatny):
170
Ponieważ kreator ostrzeże Cię, gdy wybierzesz opcję eksportu certyfikatu z kluczem prywatnym,
musisz podać hasło, które będzie używane do ochrony wyeksportowanego pliku PFX. Waż-
ne jest, aby to hasło było poprawne. Jeśli go zapomnisz, wyeksportowany plik będzie całkowicie
bezużyteczny. Jeśli wpiszesz hasło, które jest bardzo proste lub łatwe do odgadnięcia, każdy, kto
uzyskałby dostęp do tego pliku PFX, być może byłby w stanie użyć Twojego certyfikatu
i klucza prywatnego na swoich serwerach WWW, co nie byłoby dobrą wiadomością.
Eksportowanie z konsoli IIS

W aplecie Server Certificates (Certyfikaty serwera) kliknij certyfikat prawym przyciskiem myszy
i wybierz opcję Eksportuj... (Export...). Spowoduje to uruchomienie prostego kreatora, który po-
prosi o podanie lokalizacji i hasła:
Podczas eksportowania certyfikatu przy użyciu przystawki MMC było o wiele więcej opcji
do wyboru, dlaczego więc ten kreator jest tak uproszczony? Konsola IIS przyjmuje niejawnie
określone założenia dotyczące pozostałych ustawień w celu przyspieszenia procesu eksportu.
Jest bardzo prawdopodobne, że podczas eksportowania certyfikatu SSL zamierzasz również
171
wyeksportować klucz prywatny, dlatego IIS po prostu przyjmuje to założenie i pomija resztę
opcji. Jesteś zmuszony wprowadzić hasło, ponieważ nie możesz pominąć dołączenia klucza pry-
watnego do certyfikatu. Jeśli więc zamierzałeś wyeksportować certyfikat bez informacji o kluczu
prywatnym, nie możesz do tego wykorzystać konsoli IIS. Musisz otworzyć przystawkę MMC
i użyć bardziej rozbudowanego kreatora, którego w niej znajdziesz.
Importowanie w innym serwerze

Niezależnie od tego, w jaki sposób wykonałeś eksport, zaimportowanie kompletnego pliku PFX
w innym serwerze jest bardzo łatwe. Będąc w konsoli MMC lub IIS, możesz kliknąć prawym
przyciskiem myszy i wybrać akcję Import (Importuj). W kolejnych etapach kreatora wystarczy
wybrać plik PFX, a następnie wprowadzić hasło użyte do jego ochrony, co spowoduje zaim-
portowanie certyfikatu. Jeśli otworzysz jego właściwości, zobaczysz, że ikona małego klucza
i komunikat o kluczu prywatnym są poprawnie wyświetlane w dolnej części okna właściwości
certyfikatu. Jeśli nie widzisz tego komunikatu, oznacza to, że coś się nie powiodło w trakcie
eksportu i musisz spróbować ponownie go przeprowadzić.
Znajdź więc serwer z certyfikatem SSL i przetestuj procedurę jego eksportu z kluczem
prywatnym oraz bez niego. Zobaczysz, że podczas importowania w innym serwerze pliku
certyfikatu bez klucza prywatnego w dolnej części okna nie pojawi się odpowiedni komunikat,
i odwrotnie — wyeksportowany plik zawierający klucz prywatny spowoduje wyświetlenie
tekstu. Dodatkowo spróbuj użyć obu certyfikatów w testowej witrynie i zobacz, co się stanie.
Przekonasz się, że certyfikat bez klucza prywatnego nie będzie umiał weryfikować ruchu SSL.
Jeśli spróbujesz wyeksportować certyfikat SSL, a opcja dołączenia klucza prywatnego

będzie nieaktywna, będzie to oznaczać, że podczas instalacji tego certyfikatu na serwerze
sieciowym zablokowano możliwość eksportu klucza prywatnego w przyszłości. W takim
przypadku nie będzie można wyeksportować certyfikatu z kluczem prywatnym.
Podsumowanie
Certyfikaty mają często złą reputację. Moim zdaniem to dlatego, że w przekonaniu użytkowni-
ków zarządzanie certyfikatami jest uciążliwe i powoduje ból głowy. Widzę w tym jakiś sens.
Bez posiadania wiedzy związanej z obsługą różnych konsoli administracyjnych zarządzają-
cych infrastrukturą certyfikatów trudno byłoby uruchomić nawet najprostsze funkcje. Mam
nadzieję, że wykonując najczęściej spotykane zadania związane z certyfikatami, osiągnąłeś
już pewien poziom pewności i komfortu, dzięki czemu możesz kontynuować prace nad projek-
tami, które są obecnie wstrzymane i czekają na stworzenie infrastruktury zarządzającej certyfi-
katami. W następnym rozdziale zajmiemy się obsługą sieci w systemie Windows Server 2019.
172
Pytania
1. Jak nazywa się rola w systemie Windows Server 2019, która umożliwia wydawanie
certyfikatów z serwera?
2. Jaki serwer urzędu certyfikacji jest zazwyczaj instalowany jako pierwszy
w środowisku domeny?
3. Czy powinno się zainstalować rolę urzędu certyfikacji na kontrolerze domeny?
4. Co należy zrobić po utworzeniu nowego szablonu certyfikatu, zanim na jego
podstawie będzie można wydawać certyfikaty komputerom lub użytkownikom?
5. Jaka jest ogólna nazwa ustawienia GPO, które wymusza automatyczne wydawanie
certyfikatów bez osobistej interwencji administratora?
6. Certyfikat SSL będzie mógł poprawnie zweryfikować ruch tylko wówczas,
jeśli udostępni informacje o kluczu _______ serwerowi WWW.
7. Jakich podstawowych informacji potrzebuje publiczny urząd certyfikacji,
aby wystawić nowy certyfikat SSL (wskazówka: generujesz je na swoim
serwerze WWW)?
173
174
5
Obsługa sieci
w Windows Server 2019
Jak wynika z informacji przedstawionych dotąd w tej książce, serwery są czymś w rodzaju
pni drzew w naszych sieciach. Stanowią one infrastrukturę szkieletową, która umożliwia
wykonywanie naszej pracy. Jeśli serwery są pniami, wówczas same sieci muszą być korze-
niami. Twoja sieć to platforma obsługująca infrastrukturę firmy. Tworzy kanały, z których korzy-
stają wszystkie urządzenia w firmie, aby się ze sobą komunikować.
Tradycyjnie w branży IT istnieli specjaliści od serwerów oraz specjaliści od sieci, a w wielu

firmach nadal tak jest. Administrator, który przede wszystkim obsługuje serwery, zazwyczaj
nie ma w ciągu dnia wystarczającej ilości czasu, aby zajmować się również infrastrukturą
sieciową. Odwrotna sytuacja także jest prawdziwa. Administratorzy sieci do zarządzania
używają zwykle specyficznego sprzętu i specyficznych narzędzi, więc nie byliby zaintereso-
wani zbyt głębokim zanurzeniem się w świat systemu Windows Server. Jednak wielu z nas
pracuje w mniejszych firmach, w których trzeba się zajmować różnymi zagadnieniami.
Czasami administratorzy serwerów i sieci muszą ściśle ze sobą współpracować, dlatego powinni-
śmy zrozumieć przynajmniej podstawowe zasady działania sieci i poznać narzędzia, których
możemy użyć do rozwiązywania problemów z niedziałającymi połączeniami. Ponadto system
Windows Server 2019 zmusza nas do innego sposobu myślenia o sieci — chodzi o wirtualizację.
Zawsze będzie istnieć warstwa fizyczna sieci, wykorzystująca realne przełączniki i routery do
przekazywania pakietów między różnymi pokojami i budynkami. Jednak w serwerach Windows
Server pojawiła się możliwość wykorzystania programowalnej sieci komputerowej (ang. software-
-defined networking — SDN), co pozwala na zwirtualizowanie niektórych konfiguracji siecio-
wych. Oprócz tego wirtualizujemy ruch sieciowy i budujemy sieci przy użyciu konsoli serwera,
zamiast, jak w przeszłości, używać interfejsu wiersza poleceń w celu podłączania się do routerów.
Stop, chyba się zagalopowałem. Najpierw porozmawiajmy o nowych przydatnych składnikach

w systemie Windows Server 2019, które współpracują z fizycznymi lub całkowicie dowolnymi
sieciami komputerowymi, ponieważ będą one ważne dla każdego administratora. Później po-
święcimy kilka chwil na bliższe zapoznanie Cię z wirtualizacją sieci.
Oto zagadnienia, które omówimy w tym rozdziale:

 Wprowadzenie do protokołu IPv6.
 Twoje narzędzia sieciowe.
 Tworzenie tablicy routingu.
 Grupowanie kart sieciowych.
 Programowalna sieć komputerowa.
Wprowadzenie do protokołu IPv6

Witamy po mrocznej stronie mocy! Niestety, tak właśnie wielu administratorów myśli o proto-
kole IPv6. Chociaż protokół IPv6 nie jest niczym nowym, z mojego doświadczenia wynika,
że prawie nikt nie wdrożył go w sieci lokalnej. Współpracując przez ostatnich kilka lat z setkami
różnych firm na całym świecie, natknąłem się tylko na jedną organizację, która korzystała
z protokołu IPv6 w całej sieci produkcyjnej, i nawet w tym przypadku nie była to jego prawdziwa,
natywna wersja. Zamiast tego firma korzystała z technologii tunelowania zwanej ISATAP,
aby wszystkie serwery i klienty porozumiewały się ze sobą za pomocą pakietów IPv6, które
jednak wciąż przemieszczały się po fizycznej sieci IPv4. Nie zrozum mnie źle — znam wiele
przypadków, w których firmy testują protokół IPv6 i nawet mają w tym celu odpowiednio
skonfigurowane odizolowane fragmenty sieci. Czy jednak używasz protokołu IPv6 w całej sieci
produkcyjnej? Większość z nas nie jest jeszcze gotowa na tak wielką zmianę. Dlaczego tak
trudno jest wdrożyć protokół IPv6? Ponieważ od samego początku używamy protokołu IPv4,
znamy go i rozumiemy, a poza tym naprawdę nie ma potrzeby przechodzenia w naszych sieciach
na wersję IPv6. Chwila — wydawało mi się, że pojawiły się obawy przed wyczerpaniem adre-
sów IPv4… Tak, dotyczy to adresów IP w publicznym internecie, ale nie ma nic wspólnego
z naszymi sieciami wewnętrznymi. Otóż nawet jeśli jutro zabraknie nam publicznych adre-
sów IPv4, nie wpłynie to wcale na sieci wewnętrzne w naszych firmach. Przez długi czas (a być
może bezterminowo) będziemy mogli nadal używać protokołu IPv4 w swoich sieciach, o ile bę-
dziemy się czuli komfortowo, korzystając z technologii NAT do tłumaczenia zewnętrznego
ruchu sieciowego na protokół IPv4. Wszyscy używamy translacji NAT w takiej czy innej formie
prawie tak długo, jak istnieje protokół IPv4, więc jest to coś, z czego ludzie są bardzo zadowoleni.
Powiem wprost: nie próbuję Cię przekonywać, że trzymanie się protokołu IPv4 to sposób na
przyszłość. Informuję tylko, że dla większości organizacji w ciągu najbliższych kilku lat będzie to
po prostu prawda. Powodem, dla którego w tej książce chciałbym omówić protokół IPv6,
jest to, że ostatecznie będziesz musiał sobie z nim poradzić. Ale kiedy to zrobisz, będziesz
naprawdę podekscytowany! Protokół IPv6 ma kilka olbrzymich zalet w porównaniu z IPv4,
w tym ogromną liczbę adresów IP, które można przechowywać w ramach jednej sieci. Zespoły
administratorów sieciowych w firmach na całym świecie zmagają się codziennie z potrzebą
budowania coraz większej liczby sieci IPv4 i ich łączenia. Pomyśl o tym: istnieje mnóstwo
firm, w których liczba pracowników przekracza 10 tysięcy. W niektórych jest ich nawet o wiele
176
Rozdział 5. • Obsługa sieci w Windows Server 2019
więcej. W dzisiejszym świecie każdy potrzebuje właściwie ciągłego dostępu do swoich danych.
Dane to nowa waluta. Większość użytkowników ma teraz co najmniej dwa fizyczne urządzenia,
z których korzysta w pracy. Często spotykane konfiguracje to laptop i tablet, laptop i smartfon lub
komputer stacjonarny, laptop, tablet i smartfon. W świecie IPv4, w którym masz do czynie-
nia ze stosunkowo małymi zakresami adresów IP, musisz bardzo kreatywnie tworzyć podsieci,
aby pomieścić te wszystkie fizyczne urządzenia, z których każde potrzebuje unikatowego ad-
resu IP do komunikacji. Największą zaletą protokołu IPv6 jest to, że natychmiast i z definicji
rozwiązuje on wszystkie te problemy, ponieważ zapewnia możliwość posiadania ogromnej
liczby adresów IP w jednej sieci. O jakiej liczbie adresów mówimy? Oto niektóre dane porów-
nawcze, które pozwolą uzyskać pewien pogląd na tę sprawę:
 Adres IPv4 to adres o długości 32 bitów, który wygląda tak:
192.168.1.5
 Adres IPv6 to adres o długości 128 bitów, który wygląda tak:
2001:AABB:CCDD:AB00:0123:4567:8901:ABCD
Jak widać, adres IPv4 jest znacznie krótszy, co oczywiście oznacza, że istnieje mniej możliwości
uzyskania unikatowych adresów IP. W rzeczywistości nie widzisz, jak długie są adresy IPv6.
W powyższych przykładach przedstawiono adresy IPv4 i IPv6 w takiej postaci, jaka została
przyjęta do ich wyświetlania. Naprawdę jednak adres IPv4 jest prezentowany w postaci dziesięt-
nej, a IPv6 w systemie szesnastkowym. Adresy IPv6 są wyświetlane przy użyciu systemu
szesnastkowego, dzięki czemu są maksymalnie skompresowane. Jeśli zajrzysz pod maskę,
adres IPv6 w swojej natywnej 128-bitowej formie może wyglądać mniej więcej tak, jak pokazano
poniżej (i właśnie tak wygląda wewnątrz pakietu danych):
0001000001000001000011011001100000000000000000010000000000000000
0001000000000000000000000000100000000000000000000000000000000001
To imponujący zestaw cyfr, ale nie jest on czymś bardzo użytecznym lub przyjaznym dla ludz-
kiego oka. Może więc zamiast w systemie dwójkowym zaprezentowalibyśmy adres IPv6
w formacie dziesiętnym — w taki sam sposób, w jaki są pokazywane adresy IPv4? W takim
przypadku adres IPv6 będzie wyglądać mniej więcej tak:
192.16.1.2.34.0.0.1.0.0.0.0.0.0.0.1
Teraz w pełni rozumiesz, dlaczego adres IPv6 jest zawsze używany i wyświetlany w systemie
szesnastkowym — jest on wystarczająco długi nawet w tym skompresowanym formacie!
Jak działają adresy IP w wersji IPv6?

Podczas tworzenia sieci w wersji IPv4 jej podsieci są niezwykle ważne, ponieważ umożli-
wiają nam posiadanie więcej niż jednego zbioru adresów IP. W przypadku najbardziej podsta-
wowej formy sieci, w której konfigurujesz adresy i używasz 24-bitowej podsieci (maska podsieci
równa 255.255.255.0), co jest bardzo powszechne na niewielkich obszarach, takich jak dom
lub małe biuro, jesteś ograniczony do 254 unikatowych adresów IP. Ojej! Niektóre firmy
mają tysiące różnych serwerów, a oprócz tego komputery klienckie i inne urządzenia, które rów-
nież muszą się łączyć z siecią. Na szczęście możemy zbudować wiele różnych podsieci w ramach
177
jednej sieci IPv4 w celu zwiększenia swojego użytecznego zakresu adresów IP, ale wymaga
to starannego planowania i obliczania przestrzeni adresowych. Jest to powód, dla którego pole-
gamy na doświadczonych administratorach sieci, którzy zarządzają tym fragmentem infrastruktury.
Jedna niepoprawna konfiguracja podsieci w tablicy routingu może zablokować cały ruch siecio-
wy. Administrowanie podsieciami w dużej sieci IPv4 nie jest zadaniem dla osób o słabym sercu.
Gdy myślimy o adresowaniu IPv6, możliwości są niemalże nieograniczone. Jeśli wyliczyłbyś

wszystkie unikatowe adresy IPv6 dostępne w 128-bitowej przestrzeni, odkryłbyś, że istnieje po-
nad 340 undecylionów adresów możliwych do utworzenia. Innymi słowy, byłoby to 340 trylio-
nów trylionów trylionów adresów. Jest to liczba dostępnych adresów w internecie obsługują-
cym protokół IPv6, ale co to oznacza dla naszych sieci wewnętrznych?
Aby przeanalizować liczbę adresów, których moglibyśmy używać w typowej sieci wewnętrznej
w wersji IPv6, przyjrzyjmy się jeszcze raz wcześniej zaprezentowanemu adresowi. Wymyśliłem
go na poczekaniu, ale postarajmy się go podzielić na części:
2001:AABB:CCDD:AB00:0123:4567:8901:ABCD
W porównaniu z prostym adresem 192.168.1.5 powyższy ciąg znaków wygląda jak potwór.
Wynika to z tego, że generalnie nie jesteśmy przyzwyczajeni do obsługi formatu szesnastko-
wego — to po prostu inny sposób patrzenia na dane. Jak wspomniałem, jest to adres 128-bitowy.
Został on podzielony na 8 różnych sekcji, a każda z nich jest oddzielona dwukropkiem i składa
się z 16 bitów. Pierwsze 64 bity (pierwsza połowa) adresu to informacje o routingu, a ostat-
nie 64 bity to unikatowy identyfikator urządzenia w sieci. W pierwszej części mamy dwa różne
komponenty. Pierwszych 48 bitów (3 grupy szesnastkowe) to prefiks organizacyjny, który
będzie taki sam dla wszystkich naszych urządzeń w sieci. Następnie czwarty zestaw informacji,
czyli dalszych 16 bitów, może być naszym identyfikatorem podsieci. Daje nam to możliwość
posiadania w przyszłości wielu różnych podsieci. Po użyciu pierwszej połowy adresu pozostaje
nam jeszcze druga część, czyli ostatnie 64 bity, które możemy wykorzystać do nadawania
identyfikatorów urządzeniom. Ta część adresu będzie odmienna dla każdego urządzenia w sieci
i pozwoli na nadawanie indywidualnych, statycznych adresów IPv6, które będą używane do
komunikacji. Pokażę to wszystko dokładniej. Weźmy poprzedni przykładowy adres i podzielmy
go na następujące części:
 prefiks organizacyjny: 2001:AABB:CCDD,
 identyfikator podsieci: AB00,
 identyfikatory urządzeń: 0123:4567:8901:ABCD.
Ile urządzeń możemy mieć w swojej sieci ze schematem IP takim jak powyższy? Cóż, nawet
w naszym przykładzie, w którym przydzieliliśmy tylko jedną 16-bitową sekcję dla podsieci
i 64 bity dla rzeczywistych adresów IP, uzyskalibyśmy możliwość posiadania ponad 65 000
podsieci i kwintylionów unikatowych identyfikatorów urządzeń w naszym zakresie IP. Impo-
nujące, prawda?
Jeśli zastosujemy powyższy schemat i użyjemy tylko jednej podsieci w celu zarządzania wszyst-
kimi urządzeniami, pierwsza połowa naszych adresów będzie zawsze taka sama, dzięki czemu
będą one łatwiejsze do zapamiętania i obsługi. Zaskakujące jest to, że szybko przyzwyczaisz
się w swoim środowisku do wyświetlania tych dużych liczb szesnastkowych. Nawet jeśli za-
178
czniesz je rozpoznawać, prawdopodobnie nadal nie będziesz chciał od razu logować się na ser-
wery lub komputery w sieci przy użyciu ich statycznych adresów IP. Wiem, że wciąż wielu z nas
ma w zwyczaju mówić: „Muszę szybko wskoczyć na mój serwer WWW, więc połączę się
z adresem 192.168.1.5 przez zdalny pulpit”. Sam czas potrzebny na wpisanie adresów IPv6,
nawet jeśli je pamiętasz, na ogół nie jest tego wart. Wdrożenie protokołu IPv6 pociągnie za sobą
większe uzależnienie od usług DHCP i DNS, co sprawi, że stanie się on bardziej użyteczny.
Gdy już wiemy, do jakich celów są wykorzystywane określone fragmenty adresu, musimy się za-
stanowić, w jaki sposób moglibyśmy przypisać numery identyfikacyjne wszystkim komputerom,
serwerom i innym urządzeniom w swojej sieci. Mógłbyś zacząć od cyfry 1 i po prostu za
każdym razem zwiększać liczbę o jeden. Innym pomysłem jest zamiana starych adresów IPv4 na
wartości szesnastkowe i użycie ich jako ostatnich 32 bitów adresu. Na swoim komputerze
otwórz aplikację kalkulatora, a następnie przejdź w tryb programisty. Dzięki temu otrzymasz
szybkie i łatwe w użyciu narzędzie, które można wykorzystać do konwersji liczb dziesiętnych na
szesnastkowe i odwrotnie. Weźmy przykład mojego serwera WWW, który działa pod adresem
192.168.1.5. W sieci zamierzam wdrożyć protokół IPv6 i dlatego chciałbym, aby adres IPv6
mojego serwera odzwierciedlał w sekcji identyfikatora urządzenia oryginalny adres IPv4. Jeśli
w kalkulatorze wprowadzisz wartość 192, wyświetli się odpowiednia liczba szesnastkowa, jak po-
kazano na poniższym zrzucie ekranu:
179
Jeśli postąpimy tak samo z każdym oktetem naszego adresu IPv4, otrzymamy następujące wyniki:
192 = C0
168 = A8
1 = 01
5 = 05
Zatem adresowi 192.168.1.5 odpowiada wartość C0A8:0105. Teraz mogę jej użyć w połączeniu
z prefiksem organizacyjnym i identyfikatorem podsieci, aby utworzyć statyczny adres IPv6
dla swojego serwera WWW:
2001:AABB:CCDD:0001:0000:0000:C0A8:0105
Być może zauważyłeś, że na końcu adresu IPv6 umieściłem szesnastkowy identyfikator urządze-
nia, a oprócz tego wprowadziłem kilka innych zmian. Założyliśmy, że ostatnie 64 bity będą prze-
znaczone dla identyfikatora urządzenia. Jednakże mój stary adres IPv4 zużywa tylko 32 bity,
więc w środku pozostały jeszcze 32 bity do wykorzystania. Byłoby dziwnie mieć w nich jakieś
losowe dane, więc po prostu wyzerowałem je, aby uprościć schemat adresowania. Oprócz
tej zmiany zainicjalizowałem swój identyfikator podsieci wartością 1, ponieważ jest to pierwsza
podsieć w mojej sieci.
Nowe adresowanie zaczyna wyglądać bardziej przejrzyście i ma więcej sensu. Gdy spoglą-
dam na ten nowy adres naszego serwera WWW, przychodzą mi do głowy kolejne pomysły
na wprowadzenie ulepszeń. W tej chwili adres jest w stu procentach poprawny. Mógłbym
wprowadzić go we właściwościach karty sieciowej swojego serwera i działałby bez problemu.
Jednak jest tam wiele zer i nie muszę ich wszystkich przechowywać. Za każdym razem, gdy
w 16-bitowym segmencie poprzedzającym rzeczywistą liczbę pojawiają się zbędne zera, można
je po prostu usunąć. Na przykład nasz identyfikator podsieci i pierwsze 32 bity naszego
identyfikatora urządzenia mają wiele niepotrzebnych zer, więc mogę skonsolidować adres w na-
stępujący sposób:
2001:AABB:CCDD:1:0:0:C0A8:0105
Idźmy dalej — za każdym razem, gdy 16-bitowe sekcje są złożone całkowicie z zer, można je
zamienić na podwójny dwukropek. Tak więc pierwsze 32 bity naszego identyfikatora urządzenia,
które są zerami, mogę zastąpić znakami ::. Poniżej zaprezentowałem adres pierwotny i po
konsolidacji. Te liczby wyglądają zupełnie inaczej. Mimo że skonsolidowany adres jest znacznie
łatwiejszy do odczytania, z technicznego punktu widzenia jest on dokładnie taki sam jak
oryginalny:
2001:AABB:CCDD:0001:0000:0000:C0A8:0105
2001:AABB:CCDD:1::C0A8:0105
Jeśli tworzysz strukturę laboratorium lub chcesz szybko przetestować protokół IPv6, możesz
użyć adresów tak prostych, jak podano w poniższym przykładzie. Dwa adresy, które tu przed-
stawię, są dokładnie takie same:
2001:0000:0000:0000:0000:0000:0000:0001
2001::1
180
Należy pamiętać, że podwójnego dwukropka można użyć tylko raz w obrębie adresu
IP. Jeśli w tym samym adresie są dwa miejsca, w których można go zastosować, możesz
wybrać tylko jedno z nich w celu uproszczenia zapisu. W drugim miejscu zapis musi
pozostać w standardowej postaci.
Dzięki podanym powyżej informacjom powinieneś być w stanie stworzyć własny wzorzec
adresów IPv6 i zacząć je przypisywać komputerom lub serwerom w sieci. Temu tematowi można
poświęcić całą książkę i faktycznie powstało ich dużo.
Twoje narzędzia sieciowe

Niezależnie od tego, czy jesteś administratorem serwera, administratorem sieci, czy też łączysz
ich obowiązki, w świecie systemu Windows Server możesz wykorzystać wiele narzędzi przydat-
nych do testowania i monitorowania połączeń sieciowych. Niektóre z tych narzędzi są zawarte
w samym systemie operacyjnym i mogą być wywoływane z wiersza poleceń lub z programu
PowerShell. Inne są bardziej rozbudowanymi interfejsami graficznymi, które wymagają insta-
lacji przed uruchomieniem. Oto narzędzia sieciowe, które zamierzam zaprezentować:
 ping,
 tracert,
 pathping,
 Test-Connection,
 telnet,
 Test-NetConnection.
Wszystkie te narzędzia są bezpłatne, więc nie masz żadnej wymówki, aby się z nimi nie zapoznać.
Polecenie ping
Nawet najbardziej nowocześni specjaliści IT są zwykle zaznajomieni z poleceniem ping.
Można je wywołać z wiersza polecenia lub z programu PowerShell. Służy ono do wysłania
zapytania o nazwę DNS i (lub) adres IP, po którym następuje oczekiwanie na odpowiedź na
to wywołanie. Polecenie ping zawsze było i wciąż jest naszym głównym narzędziem do testowa-
nia łączności między dwoma urządzeniami w sieci. W swoim kliencie Windows 10 podłączonym
do sieci LAN mogę uruchomić wiersz poleceń i wykonać instrukcję ping <ADRES_IP>. Po-
nieważ w środowisku używam usługi DNS, które zamienia nazwy na adresy IP, mogę również
użyć polecenia ping <NAZWA_SERWERA>, jak pokazano na poniższym przykładzie. Możesz zauwa-
żyć, że mój serwer odpowiada na polecenie ping, informując mnie, że jest w sieci i pracuje:
181
Ruch sieciowy generowany przez polecenie ping jest technicznie zwany ruchem ICMP. Jest to
ważna informacja, ponieważ protokół ICMP jest obecnie coraz częściej blokowany, a zapory
są domyślnie włączone w wielu naszych systemach i urządzeniach. ping był zawsze narzędziem,
na które mogliśmy liczyć, gdy chcieliśmy dość dokładnie ustalić, czy między dwoma urządze-
niami istnieje połączenie sieciowe. Niestety, już tak nie jest. Jeśli na komputerze zainstalujesz
system Windows i podłączysz go do sieci, może się on poprawnie komunikować z internetem
i wszystkimi serwerami. Jeśli jednak z innego urządzenia w sieci spróbujesz wysłać do tego
nowego komputera polecenie ping, prawdopodobnie nie zostanie wykonane. Dlaczego tak
się dzieje? Wynika to stąd, że system Windows ma wbudowane pewne zabezpieczenia, w tym
zdefiniowane w zaporze blokowanie ruchu ICMP. W takim przypadku musisz wyłączyć zaporę
albo dodać do niej regułę dostępu, która zezwoli na ruch ICMP. Po włączeniu takiej reguły
nowy komputer zacznie odpowiadać na polecenie ping. Pamiętaj, że w dzisiejszym świecie
podczas tworzenia nowych systemów lub serwerów w sieci polecenie ping nie zawsze jest
narzędziem, na którym można polegać.
Na odpowiedzi ICMP można łatwo zezwolić przez dodanie reguły do zapory Windows Defen-
der z zabezpieczeniami zaawansowanymi. Nadal jednak musiałbyś pamiętać, aby tę operację
wykonywać ręcznie na każdym nowym systemie, który podłączasz do sieci. Na szczęście już
wiesz, jak korzystać z zasad grupy w celu zbudowania obiektu GPO i umieszczenia go na wszyst-
kich komputerach. Jak się zapewne domyślasz, w obiekcie GPO możesz bez problemu umie-
ścić reguły zapory. Dodanie reguły zapory za pomocą zasad grupy to powszechny sposób na
dopuszczenie lub zablokowanie protokołu ICMP w całej organizacji.
Polecenie tracert
Polecenie tracert (skrót od słów Trace Route) służy do śledzenia pakietu sieciowego, który
przemieszcza się po Twojej sieci. Tak naprawdę to polecenie obserwuje wszystkie miejsca, które
napotyka pakiet, zanim dotrze do miejsca docelowego. Te „nierówności na drodze”, przez
które musi przejść pakiet sieciowy, nazywane są przeskokami (ang. hops). Trasa śledzenia poka-
zuje wszystkie przeskoki, które odwiedza Twój pakiet, gdy zbliża się do serwera docelowego
lub dowolnego innego urządzania, z którym próbuje się skontaktować. Moja sieć laboratoryjna
182
jest bardzo płaska i nudna, więc wykonanie polecenia tracert nie pokazałoby nam wiele. Jeśli
jednak otworzę program PowerShell w komputerze podłączonym do internetu i wykonam pole-
cenie tracert do serwera sieciowego takiego jak Bing, otrzymam kilka interesujących wyników:
Jeśli wykorzystujesz polecenie tracert, ale w danych wyjściowych nie chcesz widzieć
żadnych informacji z usługi DNS, użyj opcji tracert -d, aby zachować wyłącznie adresy IP.
Informacje te mogą być bardzo przydatne podczas diagnozowania niedziałającego połączenia.

Jeśli ruch, zanim dotrze do miejsca docelowego, przechodzi przez wiele przeskoków, takich
jak routery i zapory sieciowe, polecenie tracert może być niezbędne w ustaleniu, w którym
miejscu strumienia pojawia się problem. Biorąc pod uwagę, że powyższy zrzut ekranu pokazuje
udaną trasę śledzenia do serwera Bing, zobaczmy teraz, jak się sprawy mają, gdy coś się zepsuje.
Odłączę router internetowy i ponownie uruchomię to samo polecenie tracert www.bing.com.
Teraz widzimy, że nadal mogę się komunikować ze swoim lokalnym routerem, ale poza niego
pakiety już nie przechodzą:
183
Polecenie pathping
Polecenie tracert jest użyteczne i wydaje się faktycznie standardem przy śledzeniu pakietów
w sieci, jednak moim zdaniem pathping jest jeszcze potężniejsze. Polecenie pathping zasadniczo
wykonuje dokładnie to samo co tracert, z tym wyjątkiem, że zapewnia jeszcze jedną istotną
informację. Podczas używania zaprezentowanych narzędzi najczęściej chciałbyś się tylko do-
wiedzieć, w którym miejscu w łańcuchu przeskoków coś się psuje. Konfigurując serwery do
zastosowań sieciowych, często używam urządzeń, które mają wiele różnych kart sieciowych.
Gdy w systemie mamy do czynienia z wieloma kartami sieciowymi, lokalna tabela routingu
jest tak samo ważna jak zewnętrzne routery i przełączniki, więc często chciałbym sprawdzić
ścieżkę pakietu, aby zobaczyć, z której lokalnej karty jest wysyłany. W takiej sytuacji polecenie
pathping jest lepsze od tracert. Pierwszą informacją, którą prezentuje polecenie tracert,
jest przeskok na następne urządzenie sieciowe. Polecenie pathping pokazuje również, z którego
interfejsu sieciowego Twojego komputera są wysyłane pakiety.
Oto przykład: często konfiguruję serwery dostępu zdalnego z wieloma kartami sieciowymi. Pod-
czas tego procesu tworzę wiele tras na serwerze lokalnym, dzięki czemu wie on, jaki ruch należy
wysłać w danym kierunku — na przykład jaki ruch powinien wychodzić z wewnętrznej
karty sieciowej i jaki ruch musi wchodzić przez zewnętrzną kartę sieciową. Po wypełnieniu
wszystkich tabel routingu dla wewnętrznej karty sieciowej testuję je przez wysłanie polecenia
ping do serwera w sieci. Być może wykonanie tego polecenia nie powiedzie się, a ja nie będę
wiedział, jaki jest tego powód. Mogę spróbować użyć polecenia tracert, ale nie dowiem się
niczego nowego, ponieważ ono po prostu nie widzi pierwszego przeskoku, więc następuje
przekroczenie limitu czasu. Jeśli jednak spróbuję zastosować polecenie pathping, pierwszy prze-
skok co prawda nadal nie będzie dostępny, ale teraz dowiem się, że mój ruch próbuje się wydo-
stawać przez ZEWNĘTRZNĄ kartę sieciową. Ojej! Na serwerze musieliśmy nieprawidłowo
skonfigurować swoją statyczną trasę. Wiem więc, że muszę ją usunąć, a następnie utworzyć
ponownie, aby ruch odbywał się przez wewnętrzną kartę sieciową.
Poniżej przedstawiono wiersz poleceń programu PowerShell uruchomiony na tym samym kom-
puterze, którego użyłem do wykonania zrzutu ekranu dla polecenia tracert. Widzimy, że
pathping wyświetla adres IP lokalnej karty sieciowej mojego laptopa, przez którą odbywa się
ruch. Polecenie tracert nie wyświetlało tych informacji:
184
Polecenie Test-Connection
Instrukcje, które omówiliśmy do tej pory, można było uruchomić z wiersza poleceń lub progra-
mu PowerShell. Nadszedł jednak czas, aby zaprezentować nowsze narzędzie, które można
wywołać tylko w powłoce PowerShell. Mam na myśli polecenie o nazwie Test-Connection — jest
ono czymś w rodzaju polecenia ping na sterydach. Jeśli otworzymy wiersz poleceń PowerShell
w naszym środowisku laboratoryjnym, a następnie uruchomimy instrukcję Test-Connection
WEB1, otrzymamy wynik, który jest bardzo podobny do tego, jaki uzyskalibyśmy po użyciu zwy-
kłego polecenia ping. Informacje są jednak wyświetlone w sposób, który moim zdaniem jest
bardziej przyjazny dla użytkownika. Pojawiła się również nowa kolumna danych o nazwie Source
(Źródło):
Ciekawa sprawa. Gdy uruchomiłem to polecenie, byłem zalogowany na serwerze DC1, więc był
on moim urządzeniem źródłowym. Czy to oznacza, że w poleceniu Test-Connection mam
możliwość zmiany komputera źródłowego? Tak, jest to prawdą. Podobnie jak w przypadku
wszystkich innych elementów zarządzających systemem Windows Server 2019, nie ma potrzeby
logowania się na serwerze lokalnym. W przypadku polecenia Test-Connection oznacza to, że
możesz otworzyć wiersz poleceń programu PowerShell w dowolnym komputerze podłączonym
do sieci i przetestować połączenia między dwoma różnymi punktami końcowymi, nawet jeśli nie
jesteś zalogowany do żadnego z nich. Sprawdźmy to.
Nadal jestem zalogowany na serwerze DC1, ale zamierzam użyć polecenia Test-Connection,
aby przetestować połączenia między kilkoma serwerami w sieci. Nie tylko możesz określić
komputer źródłowy inny niż ten, na którym jesteś obecnie zalogowany, ale też możesz pójść
o krok dalej i za pomocą tego potężnego polecenia określić wiele źródeł i miejsc docelowych.
Jeśli więc chcę przetestować połączenia z kilku różnych maszyn źródłowych do kilku różnych
miejsc docelowych, mogę to łatwo zrobić za pomocą następującego polecenia:
Test-Connection -Source DC1, DC2 -ComputerName WEB1, BACK1
Na poniższym zrzucie ekranu widać, że otrzymałem odpowiednie statystyki dotyczące komuni-

kowania się źródłowych serwerów DC1 i DC2 z docelowymi maszynami WEB1 i BACK1.
Polecenie Test-Connection może więc być bardzo potężnym narzędziem do monitorowania:
185
Jeszcze jedną przydatną funkcjonalnością, na którą należy zwrócić uwagę, jest to, że za pomocą
przełącznika -Quiet można dość łatwo zmniejszyć ilość informacji wyjściowych. Przez dodanie
opcji -Quiet do polecenia Test-Connection likwidujesz prawie wszystkie dane wyjściowe
i otrzymujesz tylko proste potwierdzenia True lub False w zależności od tego, czy połączenie się
powiodło czy nie. Niestety, nie można łączyć przełączników -Source i -Quiet, ale jeśli używasz
polecenia Test-Connection z oryginalnego komputera źródłowego, na którym jesteś zalogowany
(jak większość z nas i tak robi), wówczas opcja -Quiet działa świetnie. W większości przypadków
tak naprawdę zależy nam na zwykłej odpowiedzi Tak lub Nie, by dowiedzieć się, czy połączenia
działają, a niekoniecznie chcielibyśmy oglądać na ekranie dokładne wyniki wszystkich prób.
Po użyciu opcji -Quiet otrzymujemy dokładnie to, o co nam chodzi:
Test-Connection -Quiet -ComputerName WEB1, BACK1, DC2, CA1
Gdybym użył polecenia Test-Connection w standardowy sposób, aby spróbować się połączyć ze
wszystkimi serwerami w swojej sieci, otrzymałbym bardzo dużą liczbę wyników. Dzięki wyko-
rzystaniu parametru -Quiet otrzymuję tylko krótkie odpowiedzi True (Prawda) lub False (Fałsz),
jednoznacznie informujące, czy można się skontaktować z danym serwerem:
186
Polecenie telnet
Polecenie telnet zapewnia sporo możliwości zdalnego zarządzania. Zasadniczo umożliwia
ono nawiązanie połączenia między dwoma komputerami w celu zarządzania maszyną zdalną
za pośrednictwem wirtualnego połączenia terminalowego. Nie będziemy jednakże omawiać tu
żadnej rzeczywistej funkcjonalności zapewnianej przez telnet, ponieważ w kontekście sieci
uważam, że jest to całkiem przydatne, proste narzędzie służące do testowania połączeń i nie
trzeba nic wiedzieć o tym, jakie ma zaawansowane opcje.
Gdy analizowaliśmy polecenie ping, wspominaliśmy o wadach protokołu ICMP. Można go łatwo
zablokować i przez to w obecnie tworzonych sieciach coraz częściej polecenie ping nie działa
prawidłowo. Jest to smutne, ponieważ było ono zawsze najczęstszą formą testowania połączenia
sieciowego. W rzeczywistości jednak, jeśli ułatwiało nam życie, ułatwiało też życie hakerom.
Skoro nie możemy już polegać na poleceniu ping, gdy chcemy uzyskać informację, czy istnieje
połączenie ze zdalnym systemem, czego powinniśmy używać w zamian? Innym często spotyka-
nym przypadkiem jest sytuacja, w której sam serwer może reagować poprawnie, ale określo-
na usługa działająca na nim ma problem i nie odpowiada. Proste polecenie ping może informo-
wać, że serwer jest co prawda w trybie online, ale nie może nam nic powiedzieć na temat
konkretnej usługi. Z wykorzystaniem poleceń klienta Telnetu możemy w prosty sposób wysłać
zapytania do serwera. Co ważniejsze, możemy sprawdzić pojedynczą usługę na tym serwerze,
aby upewnić się, że działa ona poprawnie.
Oto praktyczny przykład. Często konfiguruję serwery WWW wymagające dostępu do inter-
netu. Po uruchomieniu nowego serwera warto sprawdzić, czy można się do niego dostać
z internetu, i upewnić się, że odpowiada. Być może jednak sama witryna nie jest jeszcze dostępna,
więc nie mogę jej wczytać za pomocą przeglądarki Internet Explorer lub innej. Jest też całkiem
prawdopodobne, że na tym serwerze lub na poziomie firmowej zapory sieciowej wyłączyliśmy
odpowiadanie na polecenie ping, ponieważ w internecie często blokuje się protokół ICMP
w celu zmniejszenia podatności na ataki. Tak więc mój nowy serwer działa i wydaje się nam,
że sieć jest poprawnie skonfigurowana, ale nie mogę użyć polecenia ping, serwer bowiem
z założenia nie odpowie na nie. Czego mogę więc użyć do przeprowadzenia testów? Polecenia
telnet. Używając go, mogę nakazać komputerowi, aby sprawdził określony port na moim
nowym serwerze internetowym i dowiedział się, czy istnieje odpowiednie połączenie. W ten
sposób ustanawia się połączenie gniazda z portem na tym serwerze, co jest znacznie bardziej
zbliżone do rzeczywistego ruchu generowanego przez użytkownika niż użycie polecenia
ping. Jeśli polecenie telnet połączy się pomyślnie, będziesz już wiedział, że ruch dociera do
serwera, a usługa działająca na porcie, którego dotyczy zapytanie, wydaje się odpowiadać
poprawnie.
Możliwość korzystania z usługi Telnet nie jest domyślnie dostępna w systemie Windows Se-
rver 2019 ani w żadnym innym systemie operacyjnym Windows, dlatego najpierw musimy
przejść do Menedżera serwera i wybrać opcję Add Roles and Features (Dodaj role i funkcje),
aby zainstalować funkcję o nazwie Telnet Client (Klient Telnetu):
187
Klienta Telnetu powinieneś zainstalować tylko na komputerze, na którym użyjesz wiersza

poleceń. Nie musisz nic robić na zdalnym serwerze, z którym się łączysz.
Gdy funkcja klienta Telnetu zostanie już zainstalowana, będziemy mogli jej użyć z wiersza
poleceń lub programu PowerShell, dzięki czemu spróbujemy się połączyć ze swojego komputera
do usługi zdalnej. Wystarczy podać nazwę (lub adres IP) serwera docelowego i jego port.
Następnie telnet po prostu połączy się poprawnie lub przekroczy limit czasu, a my na podstawie
otrzymanego wyniku będziemy mogli stwierdzić, czy dana usługa na serwerze odpowiada.
Wypróbujmy to narzędzie na naszym serwerze WWW. Właśnie wyłączyłem stronę interne-
tową w konsoli IIS, więc mamy obecnie sytuację, w której co prawda serwer jest online, ale
sama strona nie działa. Jeśli spróbuję użyć polecenia ping z serwerem WEB1, uzyskam poprawną
odpowiedź. Jak widać, narzędzia do monitorowania serwera oparte na protokole ICMP mogłyby
przekazać fałszywe informacje, ponieważ stwierdziłyby, że serwer działa, nawet jeśli nasza
strona jest niedostępna. Na poniższym zrzucie ekranu widać, że po wykonaniu polecenia
ping próbowałem również wysłać zapytanie na port 80 serwera WEB1. W tym celu użyłem
polecenia telnet web1 80. Okazało się, że upłynął limit czasu. Dzięki temu możemy stwierdzić,
że strona internetowa działająca na porcie 80 nie odpowiada (zobacz pierwszy rysunek na
następnej stronie).
Po włączeniu strony możemy ponownie spróbować wykonać polecenie telnet web1 80 i teraz
już nie otrzymamy komunikatu o przekroczeniu limitu czasu. Tym razem wnętrze okna pro-
gramu PowerShell zostanie wyczyszczone, a pod jego górną krawędzią pojawi się migający
kursor. Chociaż nie otrzymałem jawnego komunikatu „Super, połączyłeś się!”, ten migający
kursor wskazuje, że połączenie z serwerem zostało pomyślnie nawiązane po porcie 80, co ozna-
cza, że witryna jest w trybie online i odpowiada (zobacz drugi rysunek na następnej stronie).
188
Po utworzeniu udanego połączenia za pomocą klienta Telnetu możesz się zastanawiać,

jak wrócić do zwykłego interfejsu programu PowerShell. Naciśnij jednocześnie klawisze
Ctrl+] (ten drugi to klawisz prawego nawiasu kwadratowego, znajdujący się zazwyczaj na
klawiaturze obok klawisza ukośnika odwrotnego), wpisz słowo quit, a następnie naciśnij
klawisz Enter. Powinieneś powrócić do wiersza poleceń programu PowerShell.
Polecenie Test-NetConnection
Jeśli poleceniu ping odpowiada ulepszone polecenie programu PowerShell o nazwie Test-
-Connection, moglibyśmy zapytać, czy istnieje również poprawione narzędzie, które działa
podobnie jak telnet i służy do testowania połączeń po określonych portach. Odpowiedź jest
twierdząca. Polecenie Test-NetConnection programu PowerShell to kolejny sposób na sprawdze-
nie określonych portów lub usług w systemie zdalnym, przy czym uzyskane dane wyjściowe
są bardziej przyjazne niż w przypadku usługi Telnet.
Wykonajmy te same testy co poprzednio, jeszcze raz sprawdzając port 80 na serwerze

WEB1. Na poniższym zrzucie ekranu widać, że polecenie zostało uruchomione dwukrotnie.
Za pierwszym razem witryna WWW serwera WEB1 została wyłączona, a moje połączenie
z portem 80 nie powiodło się. Za drugim razem włączyłem ponownie witrynę i uzyskałem
udane połączenie.
Test-NetConnection WEB1 -Port 80
189
Śledzenie pakietów za pomocą programów Wireshark

lub Message Analyzer
Może także zajść potrzeba głębszego przeanalizowania pakietów sieciowych. Teraz wkra-
czamy na terytorium, na którym dobrze się czuje zespół administratorów sieciowych. Jeśli jednak
poznasz odpowiednie narzędzia, być może przed wezwaniem pomocy zdołasz samodzielnie
rozwiązać problem. Korzystanie z narzędzi wiersza poleceń do sprawdzania stanu serwerów
i usług jest bardzo przydatne, ale czasami może nie wystarczyć. Na przykład masz aplikację
kliencką, która nie łączy się z serwerem, i nie wiesz, jaki jest tego powód. Narzędzia takie jak
ping, a nawet telnet, mogą być w stanie połączyć się pomyślnie, co wskazuje na poprawne
skonfigurowanie routingu sieciowego, ale sam program po uruchomieniu nie łączy się. Jeśli
dzienniki zdarzeń aplikacji nie pomagają w rozwiązaniu problemu, możesz się dokładniej
przyjrzeć pakietom sieciowym, które program próbuje wysyłać w kierunku serwera.
190
W takiej sytuacji przydają się narzędzia Wireshark i Message Analyzer. Oba są bezpłatne i oba
można łatwo pobrać. Mają także te same funkcje. Zostały zaprojektowane do przechwytywania
ruchu sieciowego opuszczającego system lub docierającego do niego, a także wyświetlania in-
formacji zawartych w samych pakietach, abyś mógł dokładniej zapoznać się z sytuacją. W przy-
padku naszej przykładowej aplikacji, która nie może się połączyć, mógłbyś uruchomić jedno
z tych narzędzi na komputerze klienckim, aby obserwować ruch wychodzący. Możesz je także
uruchomić na serwerze aplikacji, aby śledzić pakiety przychodzące od klienta.
Każde z narzędzi działa jednak trochę odmiennie, a ponieważ nie mamy tutaj miejsca, aby
je dokładnie omówić, poniżej podam jedynie odnośniki, za pomocą których możesz je pobrać
w celu przetestowania:
1. Wireshark: https://www.wireshark.org/download.html,
2. Microsoft Message Analyzer: https://www.microsoft.com/en-us/download/
details.aspx?id=44226.
Narzędzie TCPView
Narzędzia, które omówiliśmy do tej pory, są świetne i mogą być używane na co dzień do testo-
wania określonych zasobów, jednakże zdarzają się sytuacje, w których musisz się wycofać
i przede wszystkim dowiedzieć, czego w ogóle szukasz. Być może obsługujesz aplikację na
komputerze i nie masz pewności, z jakim serwerem się ona komunikuje. A może podejrzewasz,
że komputer „złapał” wirusa, który próbuje się połączyć z zarządzającym nim serwerem, a Ty
chciałbyś zidentyfikować jego lokalizację lub sam proces nawiązujący połączenie. W takich
sytuacjach pomocne byłoby narzędzie, które można by uruchomić na komputerze lokalnym
w celu zaprezentowania w jasny i zwięzły sposób wszystkich aktywnych strumieni ruchu
sieciowego. Właśnie taką funkcję ma narzędzie TCPView. Zostało ono pierwotnie stworzone
przez zespół programistów Sysinternals. Być może słyszałeś o innych stworzonych przez niego
narzędziach, takich jak ProcMon i FileMon. Program TCPView wyświetla w czasie rzeczywistym
wszystkie aktywne połączenia TCP i UDP używane na danym komputerze. Ważne jest również
to, że nie musisz go instalować. Jest to samodzielny plik wykonywalny, dzięki czemu można
go łatwo użyć, a przy tym po zakończeniu pracy sam usuwa swoje ślady z pamięci.
Program TCPView możesz pobrać z adresu https://docs.microsoft.com/en-us/sysinternals/

downloads/tcpview.
Po prostu skopiuj plik na komputer lub serwer, który chcesz monitorować, a następnie kliknij
go dwukrotnie. Poniżej zamieszczono zrzut ekranu z interfejsem programu TCPView, który
działał na moim lokalnym komputerze i wyświetlał wszystkie połączenia tworzone w danym
momencie przez system Windows i inne oprogramowanie. Możesz zatrzymać przewijanie ekranu,
aby przyjrzeć się bliżej wynikom, a także zdefiniować filtry, by ograniczyć ilość danych i znaleźć to,
czego naprawdę szukasz. Filtry pozwalają pozbyć się śmieci, dzięki czemu można się przyjrzeć
bliżej określonemu docelowemu miejscu lub identyfikatorowi procesu:
191
Tworzenie tablicy routingu

Gdy słyszysz termin „tablica routingu”, możesz łatwo wpaść w nawyk przyjmowania, że dotyczy
on czegoś, z czym muszą się zmagać jedynie administratorzy sieci i co jest konfigurowane w ro-
uterach i zaporach sieciowych. Przecież to zagadnienie nie dotyczy administratora serwera,
mam rację? Podłączanie serwerów do sieci stało się bardzo łatwe, ponieważ wymaga podania
jedynie adresu IP, maski podsieci i domyślnej bramy. Po spełnieniu tych warunków możemy
natychmiast komunikować się ze wszystkimi urządzeniami wewnątrz swojej sieci lokalnej.
Chociaż sprzęt sieciowy i administratorzy ukrywają wiele szczegółów związanych z magicznym
działaniem sieci, ważne jest, aby zrozumieć, w jaki sposób w środowisku Windows funkcjonuje
routing. Mogą pojawić się sytuacje, w których będziesz musiał zmodyfikować lub zbudować
tablicę routingu bezpośrednio w samym systemie Windows Server.
Serwery o wielu adresach

Uruchamianie serwerów z wieloma adresami to przypadek, dla którego z pewnością będziesz
musiał zrozumieć działanie lokalnej tablicy routingu i ją zmodyfikować. Jeśli uważasz, że to
zagadnienie Cię nie dotyczy, ponieważ nigdy wcześniej nie słyszałeś o wieloadresowości, za-
stanów się ponownie. To słowo po prostu oznacza, że Twój serwer ma więcej niż jedną kartę
sieciową. Z pewnością może się tak zdarzyć, nawet jeśli prowadzisz niewielki sklep, który nie
używa wielu serwerów. Często serwery Small Business lub Essentials mają wiele interfejsów sie-
ciowych oddzielających ruch wewnętrzny od ruchu internetowego. Innym przykładem urządze-
nia z wieloma adresami może być serwer dostępu zdalnego, który udostępnia funkcje pośrednika
(proxy), DirectAccess lub VPN. Kolejnym powodem, dla którego warto zrozumieć wielo-
192
adresowość, są serwery Hyper-V. Bardzo często mają one wiele kart sieciowych, ponieważ
działające na nich maszyny wirtualne mogą wymagać połączenia z różnymi sieciami fizycznymi
w organizacji.
Gdy już ustaliliśmy, czym jest serwer o wielu adresach, możesz nadal się zastanawiać, dlaczego
o tym wspominam. Jeśli mam więcej niż jedną kartę sieciową, czyż konfigurując każdą z nich
w systemie Windows, nie nadam im po prostu określonych adresów IP, tak jak zrobiłbym
w przypadku pojedynczej karty sieciowej na dowolnym serwerze? Tak i nie. Tak — konfigu-
rujesz adresy IP na każdej karcie sieciowej, ponieważ jest to niezbędne do odpowiedniej
identyfikacji i transportu pakietów w sieci. Nie — nie konfigurujesz wszystkich kart sieciowych
na swoim serwerze w ten sam sposób. Jest jeden kluczowy element, o którym należy pamiętać
i który należy uwzględnić, aby pakiety na serwerze wieloadresowym były poprawnie przesyłane.
Tylko jedna brama domyślna

Oto najważniejsza zasada. Gdy serwer zawiera wiele kart sieciowych, można mieć tylko jedną
bramę domyślną. Jedną dla całego serwera. Oznacza to, że będziesz mieć jedną kartę sieciową
z domyślną bramą, natomiast pozostałe karty NIE będą miały zdefiniowanej domyślnej bramy
w swoich ustawieniach TCP/IP. Jest to bardzo ważne. Celem istnienia domyślnej bramy jest
zdefiniowanie ścieżki ostatniej szansy. Gdy system Windows chce wysłać pakiet do miejsca
docelowego, przegląda lokalną tablicę routingu (tak, istnieje tablica routingu, nawet jeśli jej nie
skonfigurowałeś ani nie widziałeś) i sprawdza, czy dla docelowej podsieci, do której musi dotrzeć
ten pakiet, istnieje określona trasa statyczna. Jeśli tak, wysyła tą trasą pakiet do miejsca docelo-
wego. Gdy w tablicy routingu nie ma trasy statycznej, Windows próbuje skorzystać z bramy
domyślnej i przekierowuje ruch na jej adres. Na wszystkich serwerach z pojedynczą kartą sie-
ciową domyślną bramą jest router, który zawiera wszystkie informacje o routingu dla Twojej
sieci. Tak więc serwer po prostu przekazuje pakiet danych routerowi, który wykonuje resztę
pracy.
Gdy mamy wiele kart sieciowych w systemie Windows Server, nie możemy zdefiniować dla
każdej z nich bramy domyślnej, ponieważ zakłóci to przepływ ruchu z Twojego serwera. Nie
da się przewidzieć, która z kart zostanie wybrana podczas każdej transmisji sieciowej wykorzy-
stującej bramę domyślną. Pomogłem wielu osobom, które miały właśnie taki problem w swoich
serwerach. Musiały one używać serwera jako mostu między dwiema sieciami lub z jakiegoś
powodu podłączyły go do wielu różnych sieci, a teraz miały problem, ponieważ połączenie
czasami wydaje się działać, a czasem nie. Zaczynam więc przeglądać właściwości kart sieciowych
i odkrywam, że każda z nich ma wprowadzony domyślny adres bramy we właściwościach
protokołu TCP/IP. No i proszę, znaleźliśmy przyczynę. Gdy system próbuje wysyłać pakiety,
jest całkowicie zdezorientowany, ponieważ nie wie, z której bramy powinien skorzystać w danym
momencie.
Jeśli kiedykolwiek próbowałeś konfigurować domyślne bramy w większej liczbie kart sieciowych
na tym samym serwerze, prawdopodobnie znasz już komunikat ostrzegawczy wyświetlany
po wykonaniu tej czynności. Przeprowadźmy test. Dodałem kolejną kartę sieciową do jednego ze
swoich serwerów i skonfigurowałem ustawienia IP tylko na jednej z nich. Teraz dodam
193
nowy adres IP, maskę podsieci i domyślną bramę do swojej drugiej karty sieciowej. Aby zapisać
zmiany, klikam przycisk OK i pojawia się następujące okno:
Okno zawiera jedno z tych ostrzeżeń, które łatwo pominąć z powodu jego nieco tajemniczej
natury, ale i tak rozumiesz sedno: działasz na własne ryzyko! A co w tym momencie robi więk-
szość administratorów? Po prostu klika i zapisuje zmiany. Następnie zaczynają się pojawiać
problemy z routingiem. Może nie dzisiaj, ale następnym razem, gdy ponownie uruchamiasz
ten serwer, a być może dopiero 3 tygodnie później. Na pewno jednak w pewnym momencie
Twój serwer zacznie wysyłać pakiety do niewłaściwych miejsc i powodować problemy.
Definiowanie trasy
Co więc należy zrobić w takiej sytuacji? Zbudować statyczną tablicę routingu. Jeśli na serwerze
zainstalowano wiele kart sieciowych, co powoduje, że ma on wiele adresów IP, musisz w tablicy
routingu poinformować system Windows, której karty sieciowej należy używać do jakiego
rodzaju ruchu. Gdy pakiety będą musiały zostać wysłane do określonego miejsca docelowego,
tablica routingu będzie świadoma istnienia różnych ścieżek sieciowych i odpowiednio przekieruje
ruch. Nadal będziesz polegać na routerach, które zajmą się resztą ruchu, ale dostarczenie pakie-
tów do właściwego routera przez wysłanie ich przez odpowiednią fizyczną kartę sieciową jest
kluczem do tego, by cała operacja przebiegła poprawnie w Twoim serwerze wieloadresowym.
Gdy już rozumiesz, dlaczego tablica routingu jest ważna, i wiesz, w jaki sposób należy jej
używać, zabierzmy się do pracy i dodajmy kilka tras na serwerze z podwójną kartą sieciową.
Działania wykonamy za pomocą wiersza poleceń oraz programu PowerShell, jednakże zastoso-
wana składnia będzie odmienna w zależności od tego, jakiego narzędzia użyjesz.
Dodawanie trasy za pomocą wiersza poleceń

Zanim będziemy mogli zaplanować nową trasę, powinniśmy uzyskać więcej informacji o konfi-
guracji sieci na naszym serwerze. Ma on dwie karty sieciowe: jedna jest podłączona do sieci
wewnętrznej, a druga jest podłączona do strefy DMZ z dostępem do internetu. Ponieważ
mogę mieć tylko jeden domyślny adres bramy, został on zdefiniowany tylko w karcie sieciowej
DMZ, nie ma bowiem możliwości, abym dodał trasy dla każdej podsieci, z którą trzeba się
194
będzie połączyć przez internet. Przez umieszczenie domyślnej bramy w swojej karcie DMZ
sprawiam, że wewnętrzna karta sieciowa jest jej pozbawiona i przez to ma bardzo ograniczone
możliwości kontaktowania się z innymi sieciami. Wewnętrzna podsieć, do której jestem fizycz-
nie podłączony, ma adres 10.10.10.0/24, więc mogę się teraz kontaktować z dowolnym jej
elementem, poczynając od adresu 10.10.10.1, a kończąc na 10.10.10.254. Te adresy są dostępne
lokalnie i nie wymagają żadnej bramy (trasa typu on-link). Jestem podłączony bezpośrednio
do tej podsieci, dlatego mój serwer automatycznie wie, jak należy w niej kierować ruchem.
Jednakże za pośrednictwem swojej wewnętrznej karty sieciowej nie mogę się skontaktować
z niczym innym, gdyż tablica routingu nie wie nic o pozostałych podsieciach, które istnieją
w mojej sieci wewnętrznej. Na przykład mam dodatkową podsieć 192.168.16.0/24 zawierającą
urządzenia, z którymi muszę się łączyć ze swojego nowego serwera. Gdybym musiał się teraz
połączyć z jednym z tych urządzeń, pakiety zostałyby wysłane przez kartę sieciową DMZ.
Ponieważ tablica routingu na moim serwerze nie ma pojęcia, jak radzić sobie z ruchem o ad-
resach 192.168.16, wysłałaby go do bramy domyślnej. Poniżej zaprezentowałem ogólną składnię
instrukcji route, której musimy użyć, aby ruch został skierowany z naszego serwera do nowej
podsieci:
route add -p <ID_PODSIECI> mask <MASKA_PODSIECI> <BRAMA> IF <ID_INTERFEJSU>
Zanim będziemy mogli użyć unikatowej instrukcji route dotyczącej dodania sieci 192.168.16,
musimy wykonać trochę pracy detektywistycznej i dowiedzieć się, co oznaczają poszczególne
opcje. Poniżej przedstawiono opis poszczególnych elementów, które są wymagane do popraw-
nego uruchomienia instrukcji route:
 -p: ta opcja sprawi, że polecenie zdefiniuje trasę na czas niekreślony. Jeśli zapomnisz
wstawić opcję -p do instrukcji route add, nowa trasa zniknie przy następnym
uruchomieniu serwera. Niedobrze.
 ID_PODSIECI: jest to podsieć, którą dodajemy; w naszym przypadku jest równa
192.168.16.0.
 MASKA_PODSIECI: maska podsieci dla nowej trasy (255.255.255.0).
 BRAMA: ten parametr jest trochę mylący. Często zdaje się oznaczać, że należy
wprowadzić adres bramy dla nowej podsieci, jednakże nie jest to prawdą.
W rzeczywistości za pomocą tego parametru definiujesz pierwszy przeskok,
na który trafią wysyłane przez serwer dane. Jaki byłby domyślny adres bramy
w wewnętrznej karcie sieciowej? W przypadku naszej sieci jest to 10.10.10.1.
 ID_INTERFEJSU: podanie numeru interfejsu nie jest konieczne do utworzenia trasy,
ale jeśli tego nie zrobisz, jest szansa, że Twoja trasa zostanie powiązana z niewłaściwą
kartą sieciową i ruch zostanie wysłany w złym kierunku. Doświadczyłem już czegoś
takiego, więc od tego czasu zawsze podaję numer identyfikacyjny interfejsu karty
sieciowej. Zazwyczaj jest to jedno- lub dwucyfrowa liczba, która jest identyfikatorem
zdefiniowanym przez system Windows dla wewnętrznej karty sieciowej.
Odczytując wyniki polecenia route print, możemy się dowiedzieć, jaki jest numer
identyfikacyjny interfejsu:
195
Na samym początku listingu zawierającego wynik działania polecenia route print zostają wy-
świetlone wszystkie karty sieciowe dostępne w wymienionym systemie. W naszym przypadku
wewnętrzna karta sieciowa jest położona na najwyższym miejscu listy. Zidentyfikowałem ją przez
porównanie adresu MAC uzyskanego z danych wyjściowych polecenia ipconfig /all. Jak widać,
moja wewnętrzna karta interfejsu sieciowego ma numer 5, więc w instrukcji route add zamie-
rzam użyć parametru IF 5, aby upewnić się, że nowa trasa zostanie powiązana z tą kartą.
Oto nasza pełna instrukcja route add:

route add -p 192.168.16.0 mask 255.255.255.0 10.10.10.1 if 5
Jeśli teraz wykonasz polecenie route print, będziesz mógł zobaczyć nową trasę 192.168.16.0
wymienioną w sekcji Persistent Routes (Trasy statyczne) tablicy routingu. Z naszego serwera
możemy obecnie wysyłać pakiety danych do tej podsieci. Ilekroć w serwerze pojawi się pakiet,
który będzie musiał zostać skierowany do podsieci 192.168.16.x, będzie on przesyłany przez
wewnętrzną kartę sieciową w kierunku routera 10.10.10.1. Router następnie odbierze ten pakiet
i prześle do podsieci 192.168.16:
196
Usuwanie trasy
Czasami możesz błędnie wprowadzić instrukcję route. Najlepszym wyjściem jest wtedy po pro-
stu usunięcie złej trasy, a następnie ponowne użycie instrukcji route add z poprawną składnią.
Być może istnieją też inne powody, dla których od czasu do czasu konieczne będzie usuwanie
tras, dlatego warto zapoznać się z tym poleceniem. Usuwanie tras jest znacznie prostsze niż
ich dodawanie. Musisz tylko znać identyfikator podsieci dla trasy, którą chcesz usunąć, a następ-
nie po prostu wykonać polecenie route delete <ID_PODSIECI>. Na przykład, aby pozbyć się
naszej trasy 192.168.16.0, którą utworzyliśmy za pomocą wiersza poleceń, użyłbym takiej
instrukcji:
route delete 192.168.16.0
Dodawanie trasy za pomocą programu PowerShell

Ponieważ PowerShell króluje, jeśli chodzi o większość zadań wykorzystujących wiersz pole-
ceń w systemie Windows Server, powinniśmy mieć możliwość realizacji tej samej operacji
również za pomocą tego nowego interfejsu. Możesz oczywiście wprowadzić to samo polece-
nie add route w wierszu poleceń programu PowerShell i będzie ono poprawnie działać, jednak
istnieje specjalne polecenie cmdlet, którego również możemy użyć. Wykorzystajmy więc in-
strukcję New-NetRoute, aby dodać kolejną podsieć do naszej tablicy routingu — tym razem
dodamy 192.168.17.0. Oto polecenie, którego możemy użyć:
New-NetRoute -DestinationPrefix "192.168.17.0/24" -InterfaceIndex 5 -NextHop 10.10.10.1
Widzimy, że składnia polecenia jest podobna do składni poprzedniego, ale nieco bardziej przyja-
zna. Zamiast wprowadzać całą maskę i adres podsieci, możesz użyć metody z ukośnikiem,
aby określić podsieć i jej maskę w ramach tego samego identyfikatora. Ponadto nie znajdziemy tu
opcji zwanej bramą, która zawsze jest nieco myląca, ale zamiast niej mamy parametr o nazwie
NextHop (dosł. „następny przeskok”). Ma on dla mnie trochę więcej sensu.
Poprzednio korzystaliśmy z polecenia route print, aby wyświetlić całą tablicę routingu. Do wy-
świetlenia tej tablicy w programie PowerShell służy polecenie cmdlet o nazwie Get-NetRoute:
197
Grupowanie kart sieciowych

Przejdziemy teraz do innego zagadnienia związanego z siecią, które staje się coraz bardziej
popularne w przypadku sprzętu serwerowego, a mianowicie grupowania kart sieciowych
(ang. NIC Teaming). Grupowanie kart sieciowych polega zasadniczo na powiązaniu ze sobą
dwóch lub więcej fizycznych interfejsów sieciowych w taki sposób, jakby były pojedynczym
interfejsem sieciowym w systemie Windows. Umożliwia to podłączenie dwóch fizycznych
przewodów do dwóch różnych portów przełącznika przy użyciu tych samych ustawień. Jeśli je-
den port karty sieciowej, port przełącznika lub przewód połączeniowy ulegnie awarii, serwer
będzie kontynuować swoją pracę i łączyć się z siecią, ponieważ grupowanie pozwala karcie
sieciowej, która nadal działa, na obsługę ruchu sieciowego.
Samo grupowanie kart sieciowych nie jest niczym nowym, ponieważ istnieje w systemie
operacyjnym Windows Server już od ponad 10 lat. Jednak wczesne wersje tego rozwiąza-
nia były problematyczne, a na podstawie własnego doświadczenia uważam, że Windows
Server 2016 to najwcześniejszy system operacyjny, który większość pracowników IT uważa
za wystarczająco stabilny, by można było w nim korzystać z grupowania kart sieciowych
w środowisku produkcyjnym. W związku z tym to rozwiązanie jest wciąż stosunkowo
świeże.
198
Aby rozpocząć grupowanie kart sieciowych, musisz się upewnić, że istnieje ich więcej w serwe-
rze. W swoim komputerze mam obecnie cztery porty kart sieciowych. Chciałbym utworzyć
dwa zespoły: moja pierwsza i druga karta sieciowa zostaną zgrupowane, aby stać się zespołem
sieci wewnętrznej, a karta trzecia i czwarta staną się zespołem sieci DMZ. W ten sposób po obu
stronach swojej sieci zapewnię na tym serwerze redundancję kart sieciowych.
Pierwszym działaniem, które należy wykonać, jest usunięcie wszelkich ustawień związanych
z adresami IP, które mogą istnieć w kartach sieciowych. Gdy połączysz wiele kart sieciowych
w jeden zespół, skonfigurujesz dla niego parametry adresów IP. Nie będziesz już zajmował się
właściwościami poszczególnych kart w celu przypisania im adresów IP. Otwórz więc właściwości
każdej karty sieciowej i upewnij się, że nie zawierają informacji o statycznym adresie IP, tak
jak na poniższym zrzucie ekranu:
Teraz otwórz Menedżera serwera i kliknij łącze Local Server (Serwer lokalny). Przeglądając
informacje o właściwościach serwera, zobaczysz opis każdej karty sieciowej, a także opcję
o nazwie NIC Teaming (Zespół kart interfejsu sieciowego), która ma obecnie wartość Disabled
(Wyłączone):
199
Kliknij opcję Disabled, a następnie poszukaj sekcji zatytułowanej Teams (Zespoły). Kliknij
przycisk Tasks (Zadania) i wybierz opcję New Team (Nowy zespół).
Nadaj nowemu zespołowi odpowiednią nazwę i wybierz karty sieciowe, które mają być częścią
tego zespołu. Możesz wykonać te same kroki tyle razy, ile potrzebujesz, aby utworzyć dodatkowe
zespoły z pozostałymi kartami sieciowymi:
Gdy zakończysz działania, Twoje zespoły zostaną wyświetlone w Menedżerze serwera. Jeśli
w Panelu sterowania otworzysz okno Network Connections (Połączenia sieciowe), zobaczysz,
że oprócz czterech fizycznych kart sieciowych będziesz miał dwa nowe elementy, które odpo-
wiadają konfiguracjom naszych nowych zespołów. Mogę kliknąć prawym przyciskiem myszy
każdy z tych zespołów i skonfigurować parametry związane z adresem IP, podobnie jak zrobił-
bym to dla pojedynczej karty sieciowej. Właściwości związane z adresem IP będą obowiązywać
dla wszystkich kart sieciowych wchodzących w skład zespołu:
200
Programowalna sieć komputerowa

Nie można zaprzeczyć, że przetwarzanie w chmurze charakteryzuje się wysokim poziomem
uniwersalności i elastyczności i że większość technicznej kadry kierowniczej testuje obecnie
możliwości wykorzystania technologii chmurowych. Na przeszkodzie w ich szerszym użyciu stoi to,
że trzeba zapewnić odpowiedni poziom zaufania. Usługi w chmurze udostępniają ogromną moc
obliczeniową, a oprócz tego są osiągalne natychmiast po naciśnięciu jednego przycisku. Aby
firmy mogły przechowywać swoje dane w tych systemach, poziom zaufania organizacji do
dostawcy chmury musi być bardzo wysoki. Używając chmury, nie posiadasz przecież żadnej
infrastruktury sprzętowej ani sieciowej, w której są przechowywane Twoje dane, więc Twoja
kontrola nad tymi zasobami jest w najlepszym razie ograniczona. Widząc tę przeszkodę, firma
Microsoft dołożyła wielu starań, by wprowadzić najnowsze technologie chmurowe do lokalnego
centrum danych. Wysoki poziom uniwersalności serwerów w naszych centrach danych oznacza
wirtualizację. Wirtualizacja serwerów trwa już od wielu lat, a jej możliwości są ciągle ulepszane.
Teraz gdy mamy możliwość tak łatwego uruchamiania nowych serwerów przy użyciu tech-
nologii wirtualizacji, wygląda na to, że następną przeszkodą do pokonania będzie zdolność
do łatwego przenoszenia tych wirtualnych serwerów w dowolnym czasie do dowolnego
miejsca.
Czy masz serwer, który chciałbyś przenieść do innego centrum danych w Twoim kraju? A może
zastanawiasz się nad przeniesieniem całego centrum danych do nowej kolokacji w innym mie-
ście? Być może niedawno nabyłeś nową firmę i musisz umieścić jej infrastrukturę w swojej
sieci, ale okazuje się, że pewne konfiguracje nakładają się na siebie. Czy kupiłeś już miejsce
u dostawcy usług w chmurze, a teraz próbujesz uporządkować bałagan związany z planowa-
niem migracji wszystkich serwerów do tej chmury? Oto pytania wymagające odpowiedzi,
którą jest programowalna sieć komputerowa.
Programowalna sieć komputerowa (SDN) jest szerokim, ogólnym terminem, który oznacza
wiele technologii współpracujących ze sobą w celu uzyskania wymaganej funkcjonalności.
Celem tego rozwiązania jest rozszerzenie granic sieci, bez względu na to, gdzie się znajdu-
jesz i kiedy żądasz jakichś usług. Rzućmy okiem na niektóre składniki dostępne w systemie
Windows Server 2019, które działając wspólnie, tworzą wirtualne środowisko sieciowe — pierw-
szy krok w procesie realizacji sieci zdefiniowanej programowo.
201
Wirtualizacja sieci Hyper-V

Najważniejszy komponent, który pozwala na analizę sieci i przemieszczanie jej do warstwy
wirtualizacji, znajduje się w systemie Hyper-V. Ma to sens, ponieważ jest to ten sam element,
który służy do wirtualizacji serwerów. Dzięki wirtualizacji sieci Hyper-V separujemy sieci
wirtualne i fizyczne. Podczas definiowania nowych sieci wirtualnych nie trzeba już uwzględniać
ograniczeń schematu IP w sieci fizycznej, ponieważ mogą one działać poprawnie nawet wów-
czas, gdy konfiguracje dwóch różnych sieci byłyby w tradycyjnych warunkach niezgodne ze
sobą.
Ta koncepcja jest trochę trudna do zrozumienia, jeśli po raz pierwszy o niej słyszysz, więc za
chwilę omówimy kilka rzeczywistych sytuacji, w których można by skorzystać z tego rodzaju
separacji.
Chmury prywatne
Prywatne chmury pojawiają się w centrach danych na całym świecie, ponieważ ich tworze-
nie ma sens. Każdy administrator, który chciałby skorzystać z zalet chmury w swoim środo-
wisku, jednocześnie unikając jej wad, może zastosować to rozwiązanie. Utworzenie chmury
prywatnej daje możliwość dynamicznego powiększania i zmniejszania zasobów obliczeniowych
oraz obsługiwania wielu dzierżawców lub działów w ramach tej samej infrastruktury. Interfejsy
zarządzające mogą być obsługiwane bezpośrednio w tych działach, dzięki czemu sam dzierżawca
realizuje drobiazgowe prace konfiguracyjne, a administrator nie musi tracić czasu i zasobów
na wykonywanie na poziomie dostawcy infrastruktury niewielkich, ale złożonych zadań.
Chmury prywatne umożliwiają korzystanie ze wszystkich funkcji chmury publicznej, bez obawy
o poziom prywatności danych przechowywanych u zewnętrznego dostawcy usługi, nad którymi
nie można mieć wówczas realnej kontroli.
Gdy w lokalnej infrastrukturze należy wdrożyć prywatną chmurę, szczególnie taką, w której
chcesz zapewnić obsługę wielu dzierżawców, warto (a nawet trzeba) skorzystać z zalet wirtuali-
zacji sieci. Załóżmy, że udostępniasz zasoby komputerowe dwóm oddziałom firmy, a każdy
z nich ma własne potrzeby hostingu niektórych serwerów WWW. Nie wygląda to na wielkie
wyzwanie, ale problemem jest to, że te oddziały mają zespoły administracyjne, które chcą korzy-
stać ze schematów IP w zakresie 10.0.0.0. Oba muszą mieć możliwość korzystania z tych
samych adresów IP w tej samej sieci szkieletowej, którą udostępniasz, a cały ruch musi zostać
całkowicie rozdzielony i odseparowany. Wymagania te byłyby niemożliwe do spełnienia w trady-
cyjnej sieci fizycznej, ale wirtualizacja sieci pozwala w prosty sposób każdemu z działów
przydzielić podsieci IP i dowolne schematy adresowania. Dzięki temu można uruchamiać ser-
wery w dowolnych podsieciach i adresacjach IP, a cały ruch jest w pełni hermetyzowany,
dzięki czemu pozostaje odseparowany i całkowicie „nieświadomy” pozostałego ruchu w tej sa-
mej fizycznej sieci szkieletowej, która działa pod warstwą wirtualizacji. Ten scenariusz do-
brze się również sprawdza w przypadku przejęć korporacyjnych. Dwie firmy, które łączą
siły na poziomie IT, często mają konflikty dotyczące domen i podsieci. Dzięki wirtualizacji sieci
można zachować istniejącą konfigurację infrastruktury oraz serwerów, jednocześnie dodając je
do tej samej sieci fizycznej dzięki zastosowaniu wirtualizacji sieci Hyper-V.
202
Innym, prostszym przykładem jest sytuacja, w której po prostu chcesz przenieść serwer w sieci
korporacyjnej. Być może masz starszy serwer biznesowy, do którego wciąż wielu pracowników
potrzebuje dostępu, ponieważ musi używać aplikacji branżowej, która działa przez cały czas.
Problem z przenoszeniem serwera polega na tym, że aplikacja branżowa na komputerach klienc-
kich zawiera statyczny adres IPv4 skonfigurowany w celu komunikacji z serwerem. Gdy użyt-
kownik otwiera aplikację, powoduje nawiązanie łączności z serwerem o adresie 10.10.10.10.
Tradycyjnie mógłby się tu pojawić duży problem, gdyż przeniesienie tego serwera z obecnego
centrum danych do nowej lokalizacji oznaczałoby zmianę adresu IP, a to z kolei uniemożliwiłoby
wszystkim dostęp do niego. W przypadku sieci wirtualnych nie stanowi to żadnego kłopotu.
Dzięki możliwości kontrolowania ruchu sieciowego i podsieci IP w warstwie wirtualizacji
serwer ten można przenieść z Warszawy do Krakowa i zachować jego wszystkie ustawienia
dotyczące adresu IP, ponieważ działająca pod spodem sieć fizyczna nie ma żadnego znaczenia.
Zanim dane zostaną wysłane przez sieć fizyczną, nastąpi ich hermetyzacja, dzięki czemu
adres IP starszego serwera może pozostać niezmieniony, a on sam może być bez żadnych
problemów przenoszony do dowolnego miejsca w Twoim środowisku.
Chmury hybrydowe
Chociaż zwiększenie uniwersalności sieci korporacyjnych jest już ogromną korzyścią, możliwości
udostępniane przez wirtualizację sieci rosną wykładniczo, gdy decydujesz się skorzystać z praw-
dziwych zasobów chmurowych. Kiedy podejmiesz decyzję o przeniesieniu części zasobów,
która powinna być zarządzana przez dostawcę usług w chmurze publicznej, prawdopodobnie
uruchomisz środowisko chmury hybrydowej. Oznacza to, że zdefiniujesz niektóre usługi
w chmurze, ale zachowasz także niektóre serwery i usługi w lokalnej infrastrukturze. Przewi-
duję, że w przypadku większości firm scenariusz chmury hybrydowej będzie realizowany
bez końca, ponieważ stuprocentowe przejście do chmury publicznej jest po prostu niemożliwe,
biorąc pod uwagę sposoby, w jakie wiele przedsiębiorstw prowadzi działalność. Gdybyś chciał
skonfigurować chmurę hybrydową, ponownie należałoby przeanalizować wszelkie problemy
związane z przepływem zasobów między Twoimi sieciami fizycznymi i chmurowymi. Gdy chcę
przenieść lokalny serwer do chmury, muszę tak dostosować jego parametry, aby konfiguracja
sieci była zgodna z infrastrukturą chmury. Czy więc nie muszę ponownie konfigurować karty sie-
ciowej na swoim serwerze, aby pasowała do podsieci działającej w mojej sieci w chmurze? Nie,
jeśli masz uruchomioną infrastrukturę wirtualizacji sieci. Po raz kolejny użycie sieci definiowanej
programowo oszczędza czas dzięki temu, że daje nam możliwość zachowania informacji o adre-
sach IP na serwerach, które są przenoszone, ponieważ po prostu będą one używały tej samej
adresacji w chmurze. Jak już wspominałem, ze względu na hermetyzację ruchu fizyczna sieć
zapewniana przez chmurę nie musi być zgodna z naszą siecią wirtualną, a to daje nam możliwość
płynnego przenoszenia serwerów z infrastruktury lokalnej do chmury (i odwrotnie) bez koniecz-
ności spełnienia specjalnych wymagań dla sieci.
Jak działa programowalna sieć komputerowa?

Na razie brzmi to jak magia. Jak to wszystko faktycznie działa i jakie elementy muszą ze sobą
współpracować, aby wirtualizacja sieci stała się rzeczywistością w organizacji? Coś tak złożonego
z pewnością ma wiele składników i nie można tego włączyć po prostu przez naciśnięcie przyci-
sku. W sieci, która została zwirtualizowana, funkcjonują różne technologie i komponenty. Zapre-
203
zentuję je za chwilę, dzięki czemu lepiej zrozumiesz działanie odpowiednich elementów i termi-
nologię, z którą będziesz mieć do czynienia po rozpoczęciu pracy z sieciami programowalnymi.
System Center Virtual Machine Manager

Zestaw narzędzi Microsoft System Center (a w szczególności komponent Virtual Machine Ma-
nager — VMM) jest kluczowym elementem układanki tworzącej model sieci zdefiniowanej pro-
gramowo. Zdolność do pobierania adresów IP i przenoszenia ich do innych lokalizacji wymaga
pewnej koordynacji urządzeń sieciowych, a VMM jest w stanie w tym pomóc. Ten komponent
jest centralnym punktem zarządzania podczas definiowania i konfigurowania sieci wirtualnych.
Sam System Center to ogromne zagadnienie z wieloma opcjami, dlatego nie zostanie ono
omówione w tej książce. Podaję jednak odpowiednie łącze, które może służyć jako punkt wyjścia
do zapoznania się z komponentem VMM: https://docs.microsoft.com/en-us/previous-versions/
system-center/system-center-2012-R2/gg610610(v=sc.12).
Rola Network controller

Rola Network controller (Kontroler sieci) została początkowo wprowadzona w systemie Windows
Server 2016 i jak sama nazwa wskazuje, służy ona do kontroli zasobów sieciowych w organizacji.
W większości przypadków ta rola będzie współpracować z VMM, aby zarządzanie konfigura-
cjami sieci było jak najbardziej scentralizowane i bezproblemowe. Kontroler sieci to samodzielna
rola, którą można zainstalować w systemie Server 2016 lub 2019 i do której następnie można
uzyskać bezpośredni dostęp bez konieczności użycia VMM. Nie przewiduję jednak wielu wdro-
żeń, które by stosowały taką konfigurację. Korzystanie z roli Network controller jest możliwe
przez użycie odpowiednich interfejsów API PowerShell, ale jeszcze lepszy rezultat zapewni
dodanie interfejsu graficznego, z którego konfigurujesz nowe sieci, monitorujesz istniejące urzą-
dzenia lub rozwiązujesz problemy w modelu wirtualnym. Interfejs graficzny, którego można
użyć, to System Center VMM.
Kontroler sieci może służyć do konfigurowania wielu różnych aspektów sieci wirtualnych i fi-
zycznych. Dzięki niemu można skonfigurować podsieci i adresy IP, parametry sieci VLAN
na przełącznikach Hyper-V, a nawet użyć go do zdefiniowania kart sieciowych na maszynach
wirtualnych. Kontroler sieci pozwala także na tworzenie reguł związanych z listą kontroli
dostępu (ACL) w przełączniku Hyper-V i zarządzanie nimi, dzięki czemu na tym poziomie
można zdefiniować własne rozwiązanie zapory bez konieczności konfigurowania lokalnych za-
pór na samych maszynach wirtualnych lub posiadania specjalizowanego sprzętu. Kontroler sieci
może nawet służyć do konfigurowania równoważenia obciążenia i zapewnienia dostępu VPN za
pośrednictwem serwerów RRAS.
Protokół Generic Routing Encapsulation

Generic Routing Encapsulation (GRE) jest po prostu protokołem tunelowania, jednakże
niezbędnym, aby wirtualizacja sieci przebiegła pomyślnie. Gdy wcześniej omawialiśmy przeno-
szenie podsieci IP oraz definiowanie sieci wirtualnych ponad sieciami fizycznymi bez konieczno-
ści zapewniania kompatybilnych konfiguracji IP, powinienem był dodać, że cała ta funkcjonal-
ność jest zapewniana przez użycie protokołu GRE. Gdy Twoja sieć fizyczna ma adres
192.168.0.x, ale w centrum danych chciałbyś zarządzać niektórymi maszynami wirtualnymi
204
z innej podsieci, możesz bez problemu utworzyć sieć wirtualną 10.10.10.x, jednakże aby
wszystko działało, pakiety danych muszą być w stanie poruszać się po fizycznej sieci 192.168.
W tym momencie zaczyna odgrywać rolę hermetyzacja routingu. Wszystkie pakiety z sieci
10.10.10.x są hermetyzowane przed wysłaniem ich przez fizyczną sieć 192.168.0.x.
Istnieją dwa różne, specyficzne protokoły hermetyzacji routingu, które są obsługiwane w środo-
wisku wirtualizacji sieci Microsoft Hyper-V. We wcześniejszych wersjach środowiska Windows
Server mogliśmy się skoncentrować wyłącznie na standardzie Network Virtualization Generic
Routing Encapsulation (NVGRE), ponieważ był to jedyny protokół wykorzystywany przez
system Windows do wirtualizacji sieci. Od dłuższego czasu istnieje jednak inny protokół, zwany
Virtual Extensible Local Area Network (VXLAN), dlatego wiele przełączników sieciowych
(szczególnie firmy Cisco) częściej obsługuje VXLAN niż NVGRE. Tak więc w przypadku
nowych platform wirtualizacji sieci, poczynając od systemu Windows Server 2016, jesteśmy
w stanie obsługiwać protokoły NVGRE lub VXLAN w zależności od tego, co najlepiej odpo-
wiada potrzebom przedsiębiorstwa.
Nie musisz rozumieć, w jaki sposób działają protokoły GRE, aby sprawić, by wykonywały
swoją pracę, ponieważ zostaną one skonfigurowane za pomocą narzędzi istniejących w stosie
wirtualizacji sieci Hyper-V. Ważne jest jednak, aby biorąc pod uwagę koncepcję wirtualnego śro-
dowiska sieciowego, zrozumieć, że za sprawą protokołu GRE wszystkie elementy współpracują
ze sobą i poprawnie działają.
Usługa Microsoft Azure Virtual Network

Gdy w środowisku korporacyjnym uruchomisz już wirtualizację sieci Hyper-V i poczujesz
się komfortowo dzięki oddzieleniu sieci fizycznych od wirtualnych, najprawdopodobniej bę-
dziesz także chciał zbadać możliwości interakcji z sieciami dostawców usług w chmurze. Korzy-
stając z Microsoft Azure jako dostawcy usług w chmurze, możesz zbudować hybrydowe środo-
wisko chmurowe, które łączy lokalne sieci fizyczne ze zdalnymi sieciami wirtualnymi
umieszczonymi na platformie Azure. Sieć wirtualna platformy Azure to składnik, który
umożliwia wprowadzanie własnych adresów IP i podsieci do chmury. Oto miejsce, w którym
możesz uzyskać więcej informacji (a nawet dostać możliwość bezpłatnego przetestowania wirtu-
alnej sieci platformy Azure): https://azure.microsoft.com/en-us/services/virtual-network/.
Brama Windows Server Gateway (SDN Gateway)

Podczas pracy z sieciami fizycznymi, wirtualnymi i takimi, które są przechowywane w środowi-
skach chmurowych, potrzebujesz jakiegoś komponentu umożliwiającego sieciom interakcję
i komunikację między sobą. Tu właśnie wchodzi w grę brama Windows Server Gateway (zwana
również SDN Gateway). Windows Server Gateway to nowszy termin. Poprzednio używano
(i czasami nadal tak się robi) nazwy Hyper-V Network Virtualization Gateway, więc możesz
ją spotkać w niektórych dokumentacjach. Cel bramy Windows Server Gateway jest dość prosty:
ma łączyć sieci wirtualne i fizyczne. Sieci wirtualne mogą się znajdować w środowisku lokalnym
lub w chmurze. W każdym z tych przypadków, aby połączyć się z siecią, trzeba zastosować
bramę Windows Server Gateway. Podczas tworzenia pomostu między lokalną infrastrukturą
a chmurą dostawca usług w chmurze będzie po swojej stronie korzystał z bramy, do której
można się podłączyć z sieci fizycznej za pośrednictwem tunelu VPN.
205
Windows Server Gateway jest, ogólnie rzecz biorąc, maszyną wirtualną, zintegrowaną z wirtuali-
zacją sieci Hyper-V. Pojedynczej bramy można użyć do kierowania ruchem w przypadku
różnych klientów, dzierżawców lub oddziałów. Chociaż ci różni klienci mają oddzielne sieci, które
muszą być odseparowane od siebie, dostawca chmury (publicznej lub prywatnej) może nadal
wykorzystywać pojedynczą bramę do zarządzania całym ruchem, ponieważ bramy pozwalają
zapewnić całkowitą izolację między poszczególnymi strumieniami danych.
Brama Windows Server Gateway istniała już w systemie Server 2016, ale po jej wdrożeniu wy-
kryto pewne problemy związane z wydajnością, które ograniczają przepustowość ruchu siecio-
wego. Te ograniczenia zostały znacznie zmniejszone w systemie Windows Server 2019, co ozna-
cza, że jedna brama może teraz obsługiwać szerszy zakres ruchu i większą liczbę dzierżawców.
Szyfrowanie sieci wirtualnej

Zespoły zarządzania bezpieczeństwem nieustannie dbają o szyfrowanie danych. Niezależnie
od tego, czy dane są przechowywane czy przesyłane, należy się upewnić, że są odpowiednio
zabezpieczone i chronione przed nieuprawnioną modyfikacją. W czasach przed wersją Server
2019 szyfrowanie ruchu wewnątrz sieci podczas przesyłania danych było generalnie zadaniem
samej aplikacji, a nie sieci. Jeśli Twoje oprogramowanie ma możliwość szyfrowania danych
przepływających między klientem a serwerem lub między serwerem aplikacji a serwerem bazy
danych, to świetnie! Jeśli jednak aplikacja nie ma wbudowanych funkcji szyfrowania, prawdopo-
dobnie komunikacja między klientem a serwerem odbywa się w postaci jawnego tekstu. Na-
wet w przypadku aplikacji, które faktycznie szyfrują dane, algorytmy szyfrów są czasami łama-
ne i narażane na szwank. W przyszłości wraz z odkryciem nowych luk w zabezpieczeniach
można mieć tylko nadzieję, że sposób, w jaki aplikacja chroni ruch, może zostać zaktualizowany
w celu obsługi nowszych i lepszych metod szyfrowania.
Na szczęście Windows Server 2019 udostępnia nową funkcjonalność w ramach sieci definiowa-
nych programowo. Nazywa się ona szyfrowaniem sieci wirtualnej i realizuje dokładnie to,
co sugeruje jej nazwa. Gdy dane są przesyłane między maszynami wirtualnymi a serwerami
Hyper-V (w tej samej sieci), całe podsieci mogą zostać przeznaczone do zaszyfrowania, co ozna-
cza, że ruch w nich jest automatycznie szyfrowany na poziomie sieci wirtualnej. Aby można
było skorzystać z tego rozwiązania, serwery VM i aplikacje działające na nich nie muszą być
w żaden sposób konfigurowane ani zmieniane, ponieważ to sama sieć automatycznie szyfruje
cały odbywający się w niej ruch.
Za pomocą programowalnej sieci komputerowej systemu Server 2019 każda podsieć w sieci
wirtualnej może zostać oznakowana w celu szyfrowania, włącznie ze zdefiniowaniem odpowied-
niego certyfikatu. Jeśli kiedyś obecne standardy szyfrowania staną się nieaktualne lub niepewne,
programowalna sieć komputerowa będzie mogła zostać odpowiednio zaktualizowana, aby speł-
niała nowe wymagania. Odpowiednie podsieci nadal będą szyfrowane przy użyciu nowych
metod bez konieczności wprowadzania jakichkolwiek zmian w maszynach wirtualnych lub
aplikacjach. Jeśli w swoim środowisku używasz programowalnej sieci komputerowej i sieci wir-
tualnych, włączenie ich szyfrowania nie jest żadnym problemem!
206
Łączenie sieci lokalnej z usługą Azure

Większość firm, które zarządzają swoimi serwerami poprzez usługę Microsoft Azure, nadal ma
fizyczne, lokalne sieci. Jedno z podstawowych pytań, na które zawsze należy odpowiedzieć,
brzmi: „W jaki sposób będziemy mogli połączyć swoje fizyczne centrum danych z centrum da-
nych Azure?”. Zazwyczaj firmy wybierają w tym celu jedną z dwóch różnych metod. Możesz
wdrożyć serwery bramy na brzegu sieci lokalnej i platformy Azure oraz połączyć je za pomocą
sieci VPN typu lokacja-lokacja. Dzięki temu uzyskujemy stały tunel między dwiema sieciami.
Alternatywnie Microsoft zapewnia usługę o nazwie Azure Express Route, która wykonuje to
samo działanie — tworzy stały tunel między siecią fizyczną a siecią wirtualną platformy Azure.
Każde z tych rozwiązań po skonfigurowaniu działa świetnie, ale małe organizacje, mające
tylko kilka lokalnych serwerów, które muszą zostać podłączone do chmury Azure, mogą je uznać
za zbyt skomplikowane.
Azure Network Adapter

Jeśli masz lokalny serwer, który należy szybko połączyć ze środowiskiem platformy Azure (a nie
zdefiniowałeś jeszcze stałego połączenia między lokalizacją fizyczną a tym środowiskiem),
możesz w chmurze hybrydowej skorzystać z zupełnie nowej funkcji zwanej Azure Network
Adapter (karta sieciowa platformy Azure). Aby użyć takiej karty sieciowej, musisz wykorzystać
nową platformę Windows Admin Center, służącą do zarządzania serwerami.
Za pomocą aplikacji Windows Admin Center można szybko dodać kartę Azure Network Adapter
do lokalnego serwera, który połączy się bezpośrednio z siecią platformy Azure za pomocą
połączenia VPN typu punkt-lokacja. Super!
Co więcej, ta funkcjonalność została wdrożona również w starszych wersjach systemu Windows

Server, dzięki czemu możesz dodawać karty sieciowe nie tylko w komputerach z systemem
Server 2019, ale także tych, które mają zainstalowane wersje Server 2016 i Server 2012 R2.
Aby to było możliwe, należy spełnić kilka wymagań: musisz mieć aktywną subskrypcję platformy
Azure i skonfigurować co najmniej jedną sieć Azure Virtual Network.
Następnie musisz zarejestrować swoją aplikację Windows Admin Center na platformie Azure.
Aby to zrobić, możesz otworzyć Windows Admin Center, a następnie przejść do opcji Settings
(Ustawienia). W dalszej kolejności klikasz łącze Azure w grupie Gateway (Brama) i przechodzisz
przez proces rejestracji:
207
Gdy na platformie Azure zarejestrowałeś już swoją aplikację Windows Admin Center, za jej po-
mocą otwórz serwer, którym zarządzasz, a następnie przejdź do sekcji Network (Sieć). Pojawi się
lista wszystkich kart sieciowych, które są dostępne w Twoim serwerze, a w górnej części okna
będzie widnieć menu rozwijane Actions (Akcje). Wewnątrz tego menu wybierz opcję Add
Azure Network Adapter (Dodaj kartę sieciową Azure).
Przekonasz się, że wszystkie dane wymagane przez platformę Azure do nawiązania połączenia
zostały już automatycznie uzupełnione na podstawie parametrów Twojej sieci i subskrypcji.
Jeśli nie masz jeszcze sieci Azure Virtual Network, ten kreator może nawet ją utworzyć. Będziesz
miał również możliwość zdefiniowania własnego certyfikatu w celu uwierzytelnienia tworzonego
połączenia. Takie działanie będzie dobrym pomysłem, jeśli planujesz używać długoterminowego
połączenia z platformą Azure. W przeciwnym razie możesz pozwolić aplikacji Windows Ad-
min Center i platformie Azure na wygenerowanie certyfikatu z podpisem własnym i po prostu
kliknąć przycisk Create (Utwórz). Windows Admin Center uruchomi połączenie między ser-
werem lokalnym a wirtualną siecią platformy Azure. To tylko kilka kliknięć myszą! Oto wspaniała
metoda prostego i szybkiego tworzenia połączeń ad hoc między serwerami a platformą Azure.
208
Jeśli później będziesz musiał odłączyć serwer od sieci platformy Azure, możesz otworzyć
okno połączeń sieciowych, tak jak zrobiłeś podczas próby modyfikacji właściwości karty siecio-
wej, a przekonasz się, że aplikacja Windows Admin Center po prostu skonfigurowała połączenie
VPN typu punkt-lokacja, które pojawia się obecnie na liście Network Connections (Połączenia
sieciowe). Możesz kliknąć prawym przyciskiem myszy połączenie Azure VPN i rozłączyć je.
Podsumowanie
Zadania administrowania serwerami i sieciami były w większości organizacji dość wyraźnie
rozdzielone, ale z czasem te obszary zaczęły się pokrywać. Istnieje wiele konfiguracji i zadań
związanych z siecią, które muszą być teraz wykonywane przez administratorów systemu
Windows Server bez angażowania zespołu administratorów sieciowych, dlatego ważne jest, abyś
dobrze zrozumiał, jak działa Twoja infrastruktura. Znajomość narzędzi przedstawionych w tym
rozdziale umożliwi konfigurowanie, monitorowanie i rozwiązywanie problemów w przypadku
większości sieci zorientowanych na produkty firmy Microsoft.
Wprowadzenie do sieci definiowanej programowo może się okazać dość trudnym podroz-
działem, jeśli nigdy wcześniej nie spotkałeś się z takim rozwiązaniem. Mam jednak nadzieję,
że zachęci Cię to do zainteresowania się tym tematem, dzięki czemu będziesz mógł sobie
z nim poradzić w przyszłości. Przetwarzanie w chmurze będzie już cały czas dostępne niezależ-
nie od tego, czy jesteś na nie gotowy. Sieci lokalne firmy Microsoft potrafią w różny sposób
współpracować z usługą Microsoft Azure, dlatego wkrótce pracownicy działu IT będą musieli się
zapoznać z tymi koncepcjami. Idea programowalnej sieci komputerowej zyska na popularności
w nadchodzących latach. Obecnie może się ona wydawać trochę zniechęcająca, ale za kilka
lat będziemy się dziwić, w jaki sposób wszystko kiedyś mogło funkcjonować bez sieci wirtual-
nych. Znacznie więcej informacji o takich sieciach znajduje się zarówno w witrynie Microsoft
Docs, jak też w opublikowanych książkach na temat wirtualnej sieci Hyper-V oraz platformy
System Center Virtual Machine Manager. Warto, abyś dogłębniej zapoznał się z tymi materiała-
mi, jeśli jesteś zainteresowany przetestowaniem nowych rozwiązań. W następnym rozdziale
zajmiemy się użyciem opcji zdalnego dostępu.
Pytania
1. Ile bitów ma adres IPv6?
2. Zapisz następujący adres IPv6 w formie skróconej:
2001:ABCD:0001:0002:0000:0000:0000:0001.
3. Jak nazywa się polecenie podobne do trace route, ale wyświetlające lokalną kartę
sieciową, z której są wysyłane dane?
4. Na serwerze z wieloma kartami sieciowymi można wprowadzić adres bramy
domyślnej dla każdej z tych kart — prawda czy fałsz?
209
5. Jak nazywa się polecenie cmdlet programu PowerShell, którego można używać
do tworzenia nowych tras w systemie Windows Server?
6. Jakich wersji systemów operacyjnych Windows Server można używać z kartą Azure
Network Adapter w celu połączenia serwerów bezpośrednio z wirtualnymi
sieciami platformy Azure?
210
6
Użycie opcji
zdalnego dostępu
Umożliwienie pracownikom zdalnego dostępu do zasobów korporacyjnych było kiedyś dużą

korzyścią dla większości firm, ale niekoniecznie wymaganiem. Z pewnością zmieniło się to
w ciągu ostatnich kilku lat, ponieważ obecnie większość pracowników liczy na to, że będzie
mogła wykonywać swoją pracę z dowolnego miejsca. Telefony komórkowe odgrywają tu znaczą-
cą rolę, ale mają duże ograniczenia związane z małymi rozmiarami ekranów i niską wydajnością
systemów operacyjnych. Aby zapewnić pracownikom możliwość wykonywania pracy z domu,
kawiarni lub hotelu, tradycyjnie korzystamy z wirtualnych sieci prywatnych (VPN).
Większość sieci VPN w dzisiejszych firmach jest realizowana przez produkty firm innych niż
Microsoft. Rola dostępu zdalnego w systemie Windows Server 2019 ma na celu zmianę tego po-
dejścia. Po wprowadzeniu wielu ulepszeń w komponentach VPN bezpośrednio w systemie
Windows Server, stał się on realną i bezpieczną platformą zapewniającą dostęp do zasobów fir-
mowych ze zdalnych komputerów. W systemie Windows Server 2019 oprócz VPN zawarto
kilka nowszych technologii, które również mają na celu zapewnienie zdalnego dostępu do zaso-
bów korporacyjnych, jednakże przy użyciu innych sposobów.
Oto zagadnienia, które omówimy w tym rozdziale:

 Always On VPN.
 DirectAccess.
 Remote Access Management Console.
 DirectAccess, VPN czy AOVPN? Jakie rozwiązanie jest najlepsze?
 Web Application Proxy (WAP).
 Wymagania dla WAP.
 Najnowsze ulepszenia WAP.
Always On VPN
Zapewnienie użytkownikowi dostępu do połączenia VPN oznacza tradycyjnie udostępnienie
mu specjalnego łącza do połączenia sieciowego, w którym po uruchomieniu można wprowa-
dzić poświadczenia, aby wykonać poprawne uwierzytelnianie, a następnie połączyć się z sie-
cią swojego środowiska pracy w celu komunikacji z zasobami firmy. Po uruchomieniu VPN
użytkownicy mogą otwierać pocztę e-mail, wyszukiwać dokumenty, uruchamiać aplikacje bizne-
sowe lub w inny sposób pracować tak, jakby fizycznie znajdowali się w biurze. Ponadto w przy-
padku połączenia przez VPN możliwe jest zarządzanie ich laptopami, co umożliwia popraw-
ne działanie systemów takich, jak zasady grupy i SCCM. Usługa VPN zapewni doskonałe
połączenie z Twoją siecią, ale (pamiętaj, wspominamy tutaj o tradycyjnych, standardowych
połączeniach VPN) działa tylko wtedy, gdy użytkownik uruchomi ją ręcznie. Gdy użytkownicy
nie połączą się z siecią VPN, mogą jedynie przeglądać internet bez możliwości dostania się
do firmowego centrum danych. Oznacza to również, że tradycyjne połączenie VPN nie może
zostać ustanowione już na ekranie logowania Windows, ponieważ dopóki użytkownicy nie zalo-
gują się do komputera, nie będą mieli możliwości uruchomienia tunelu VPN. Wynika stąd,
że wszystko, co może nastąpić przed zalogowaniem lub w trakcie logowania, tak jak wyszuki-
wanie uwierzytelnienia na żywo, przetwarzanie zasad grupy lub uruchamianie skryptów logowa-
nia, nie będzie działać za pośrednictwem tradycyjnej sieci VPN.
Usługa Always On VPN (AOVPN) po prostu sprawia, że połączenie VPN jest stałe i automa-
tycznie nawiązywane. Innymi słowy, za każdym razem, gdy laptop użytkownika znajduje się
poza biurem i jest podłączony do internetu, tworzony jest automatycznie tunel VPN do sieci
korporacyjnej, w optymistycznym wariancie bez udziału pracownika w tym procesie. Pozwala
to użytkownikom całkowicie zapomnieć o VPN — urządzenie jest zawsze podłączone i gotowe
do użycia. Mogą się oni po prostu zalogować na swoich komputerach, uruchomić aplikacje i roz-
począć pracę. Oznacza to również, że składniki zarządzania środowiskiem informatycznym,
takie jak zasady bezpieczeństwa, aktualizacje i pakiety instalatora, mogą być przesyłane na kom-
putery klienckie przez większą część czasu ich działania, ponieważ nie czekamy, aż użytkownik
ponownie się połączy ze środowiskiem firmowym. Takie połączenie jest nawiązywane automa-
tycznie i właściwie przez cały czas.
Na komputerze klienckim istnieją faktycznie trzy różne sposoby uruchamiania usługi Always
On VPN. Żaden z nich nie wiąże się z koniecznością ręcznego ustanawiania połączenia VPN
przez użytkownika:
 Usługę AOVPN można skonfigurować tak, aby była zawsze włączona, co oznacza,
że gdy tylko komputer uzyska dostęp do internetu, od razu spróbuje się połączyć.
 Inną opcją jest uruchamianie przez aplikację, co oznacza, że możesz skonfigurować
usługę AOVPN w taki sposób, aby aktywowała się tylko wtedy, gdy na stacji roboczej
zostaje otwarta jedna z określonych aplikacji.
 Trzecią opcją jest uruchamianie oparte na nazwie DNS. Gdy zostaje użyta określona
nazwa DNS, nastąpi uruchomienie połączenia VPN, co zwykle ma miejsce wówczas,
gdy użytkownicy otwierają określone programy.
212
Rozdział 6. • Użycie opcji zdalnego dostępu
Ponieważ oczywiście nie potrzebujesz połączenia Always On VPN, gdy Twój laptop jest we-
wnątrz sieci korporacyjnej, powinienem również wspomnieć, że usługa AOVPN jest wystar-
czająco inteligentna, aby się wyłączyć, gdy użytkownik pojawi się w firmie. Komputery z włą-
czoną funkcją AOVPN automatycznie wykrywają, czy są wewnątrz sieci, a tym samym wyłączają
komponenty VPN. Jeśli są poza siecią, wówczas muszą uruchomić połączenie tunelowe
VPN. Ten proces jest znany pod nazwą wykrywania zaufanej sieci. Po właściwym skonfigu-
rowaniu składniki usługi Always On VPN uzyskują informacje na temat tego, jaki jest we-
wnętrzny sufiks DNS firmy, a następnie monitorują ustawienia karty sieciowej i zapory sieciowej
w celu ustalenia, czy do tych składników przypisano ten sam sufiks. Gdy pojawi się dopasowa-
nie, usługa będzie wiedziała, że jesteś w sieci wewnętrznej, a następnie się wyłączy.
Rodzaje tuneli AOVPN

Zanim zaprezentuję szczegółowe informacje o komponentach klienta i serwera wymaganych
do zrealizowania połączenia AOVPN, muszę poruszyć ważne zagadnienie. Powinieneś je
uwzględnić, jeśli masz podjąć odpowiednią decyzję dotyczącą tego, w jaki sposób chciałbyś
wykorzystywać AOVPN w swojej firmie. Istnieją dwa bardzo różniące się od siebie rodzaje
tuneli VPN, których można używać z Always On VPN: tunel użytkownika i tunel urządzenia.
Jak dowiesz się w dalszej części tego rozdziału, istnienie dwóch różnych rodzajów tuneli jest
opcją połączenia AOVPN pod względem funkcjonalności zbliżoną do rozwiązania DirectAccess,
które również ma podwójny tunel. Zastanówmy się przez chwilę nad celowością istnienia
tych dwóch tuneli.
Tunele użytkownika
Tunel użytkownika jest najczęściej stosowaną metodą nawiązywania połączenia w standardzie
AOVPN. Ten tunel jest uwierzytelniany na poziomie użytkownika. Certyfikaty użytkownika
są wydawane Twoim komputerom z wykorzystaniem wewnętrznej infrastruktury kluczy publicz-
nych. Następnie stanowią one część procesu uwierzytelniania podczas połączenia. Tunele
użytkownika obsługują cały ruch komputera i użytkowników, należy jednak pamiętać, że nie
można ich ustanowić, gdy komputer wyświetla ekran logowania, ponieważ nie nastąpiło jeszcze
uwierzytelnienie. Tak więc tunel użytkownika uruchomi się dopiero po tym, jak ten pomyśl-
nie zaloguje się na komputerze. Gdy dostępny jest tylko tunel użytkownika, komputer nie będzie
miał połączenia z siecią korporacyjną, dopóki ktoś nie zaloguje się na nim. Oznacza to również,
że w trakcie logowania będziesz musiał polegać na poświadczeniach buforowanych.
Tunele urządzenia
Tunel urządzenia nie ma wad, które byłyby widoczne podczas korzystania z tunelu użytkownika.
Jest on uwierzytelniany za pomocą certyfikatu maszyny, również wydawanego przy użyciu we-
wnętrznej infrastruktury PKI. Oznacza to, że tunel urządzenia można ustanowić nawet przed
uwierzytelnieniem użytkownika. Innymi słowy, działa on także wówczas, gdy komputer wyświetla
ekran logowania Windows. Umożliwia to działanie narzędzi zarządzających, takich jak zasady
grupy i SCCM, niezależnie od tego, czy użytkownik zalogował się na komputerze. Pozwala także
na uwierzytelnianie w czasie rzeczywistym na kontrolerach domeny, umożliwiając użytkownikowi
213
logowanie się do stacji roboczej, na której nigdy wcześniej nie pracował. Można również w cza-
sie rzeczywistym obsługiwać proces wygaśnięcia hasła.
Wymagania niezbędne do uruchomienia tunelu

urządzenia
Tunel użytkownika może być stosowany właściwie w każdej maszynie wyposażonej w system
Windows 10. Istnieją jednak pewne określone wymagania dotyczące jego uruchomienia.
Oto one:
1. Klient musi być dołączony do domeny.
2. Klient musi mieć certyfikat komputera.
3. Klient musi mieć zainstalowany system Windows 10 1709 lub nowszy w wersji
Enterprise lub Education.
4. Tunel urządzenia powinien wykorzystywać tylko protokół IKEv2. Ta opcja nie jest
bezwzględnie wymagana, jednakże ważne jest, abyś o niej wiedział, ponieważ
za chwilę będziemy analizować protokół IKEv2 i zastanawiać się, czy może być
on najlepszą metodą nawiązywania połączeń dla Twoich klientów.
Wymagania klienta AOVPN

Ważne jest, aby zrozumieć, że utrzymywanie stałego połączenia AOVPN jest tak naprawdę
funkcją realizowaną po stronie klienta. Możesz użyć AOVPN na komputerze klienckim, aby
połączyć się z wieloma różnymi rodzajami infrastruktury VPN. To zagadnienie omówimy
wkrótce w punkcie „Serwerowe komponenty AOVPN”.
Chociaż ręczne tworzenie regularnych połączeń VPN jest możliwe w systemach operacyjnych
klienta Windows już od ponad 15 lat, narzędzie Always On VPN jest całkiem nowe. Aby
można było z niego skorzystać, pracownicy muszą używać systemu Windows 10, i to w wersji
1607 lub nowszej.
Oto obsługiwane wersje Windows:

 Windows 10 1607 lub nowsza,
 Windows 10 1709 lub nowsza,
 Windows 10 1803 lub nowsza.
 Moment — to nie ma sensu. Po co wymieniać je oddzielnie, skoro i tak starsze
zawierają się w nowszych? Wprawdzie, technicznie rzecz biorąc, narzędzie Always
On VPN zostało oficjalnie wprowadzone w systemie Windows 10 1607, z czasem
uzyskało pewne usprawnienia. Oto krótka lista tych ulepszeń:
 Windows 10 1607: wprowadzenie możliwości automatycznego uruchamiania
połączenia VPN, a więc udostępnienie najprostszej wersji narzędzia Always On VPN.
214
 Windows 10 1709: aktualizacje i zmiany dotyczyły dodania tunelu urządzenia.

Jeśli zamierzasz uruchomić tunel urządzenia w celu zarządzania komputerem
(większość przedsiębiorstw tak robi), rozważ wersję 1709 jako minimalne wymaganie
systemowe.
 Windows 10 1803: zawiera niektóre poprawki dotyczące problemów, które zostały
odkryte w wersji 1709. W rzeczywistości oznacza to, że wszyscy wdrażają narzędzie
Always On VPN wyłącznie w wersji Windows 10 1803. Na szczęście platforma
aktualizacji Windows 10 została znacznie ulepszona, co oznacza, że wiele firm
na bieżąco wykonuje aktualizacje systemu operacyjnego. Aktualizacja do wersji 1803
jest na pewno o wiele mniej bolesna niż przykładowo migracja z Windows XP
do Windows 7.
Wybór określonej wersji systemu: 1607, 1709, 1803 czy 1809, nie ma znaczenia. Always On VPN
współpracuje z wersjami Windows 10 Home, Pro, Enterprise i każdą inną. Oznacza to, że
tunel użytkownika działa w tych wszystkich wersjach systemu Windows.
Warto podkreślić jeszcze raz: jeśli w narzędziu Always On VPN chcesz skorzystać z tunelu urzą-
dzenia, musisz użyć systemu Windows 10 Enterprise lub Education dołączonego do domeny.
Dołączenie do domeny
Ustaliliśmy już, że jeśli w AOVPN chcesz skorzystać z tunelu urządzenia, komputery klienckie
muszą zostać dołączone do domeny. Jeśli jednak wystarcza Ci korzystanie z tunelu użytkow-
nika, nie ma żadnych wymagań dotyczących członkostwa w domenie. Klienty nadal powinny
używać systemu Windows 10 1607 lub nowszego, jednakże o dowolnym typie — mogą być
nawet wykorzystywane komputery domowe dodane do prostych grup roboczych, ponieważ
domena nie jest wymagana.
Jest to wielokrotnie podkreślane w dokumentacji firmy Microsoft, ponieważ umożliwia korzysta-

nie z Always On VPN w przypadku własnych urządzeń użytkownika (ang. Bring Your Own
Device — BYOD). Chociaż jest to interesująca opcja, nie przewiduję, że firmy bardzo chętnie
zezwolą na łączenie komputerów osobistych pracowników z siecią VPN. Większość organizacji
stara się w tylko niewielkim stopniu zaspokoić rynek BYOD, przez zapewnienie dostępu do
niektórych zasobów za pośrednictwem chmury i usług takich jak Office 365, zorientowanych
na pocztę elektroniczną i dokumenty. Ale czy należałoby zezwolić na podłączanie komputerów
osobistych i urządzeń pracowników do sieci firmowej za pomocą pełnowymiarowego tunelu
VPN działającego w warstwie trzeciej? Nie wydaje mi się. Takie koszmary śnią się po nocach
administratorom bezpieczeństwa.
Wdrażanie ustawień
Załóżmy, że po stronie serwera masz już wszystkie składniki gotowe do wdrożenia w celu
ustanowienia połączenia VPN. W rzeczywistości udało Ci się ustalić, że możesz bez problemu
doraźnie tworzyć tradycyjne połączenia VPN do sieci firmowej. Wspaniale! Wygląda na to, że
infrastruktura została przygotowana. Co należy więc zrobić, aby klienci zaczęli nawiązywać
połączenia Always On VPN?
215
Część wymagań jest obecnie dość trudna do spełnienia dla niektórych firm. Sama konfiguracja
zasad dla połączenia Always On VPN nie jest zbyt skomplikowana. Musisz się jedynie zapoznać
z różnymi dostępnymi opcjami, zdecydować, które z nich są ważne w Twoim przypadku,
a następnie stworzyć odpowiedni plik konfiguracyjny lub skrypt. Chociaż nie ma tu miejsca,
aby szczegółowo omówić wszystkie te opcje, metoda pozwalająca na zdefiniowanie określonych
ustawień polega zazwyczaj na ręcznym wykonaniu połączenia VPN, dostosowaniu go do wyma-
gań bezpieczeństwa i uwierzytelniania, a następnie uruchomieniu narzędzia, które wyeks-
portuje parametry do plików konfiguracyjnych. Ustawienia profilu VPN można zapisywać
w plikach XML i PS1 (skrypt PowerShell). Być może oba te pliki będą potrzebne do przeniesie-
nia ustawień do komputerów pracowników. Aby dowiedzieć się więcej, odwiedź następującą
stronę: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/
deploy/vpn-deploy-client-vpn-connections.
Po utworzeniu plików konfiguracyjnych stajesz przed zadaniem umieszczenia konfiguracji

w komputerach klientów. Idealnie byłoby, gdybyś miał jakieś rozwiązanie służące do zarzą-
dzania urządzeniami mobilnymi (MDM). Istnieje wiele technologii, które mogą być uważane
za systemy MDM, jednakże firma Microsoft preferuje dwa z nich: System Center Configu-
ration Manager (SCCM) i Microsoft Intune.
Byłoby wspaniale, gdybyś miał zainstalowany program SCCM! Dzięki niemu możesz łatwo
skonfigurować i wdrożyć ustawienia oparte na skryptach PowerShell w komputerach klienckich,
a następnie umożliwić im używanie połączeń Always On VPN.
Być może nie masz programu SCCM, ale używasz chmury i wszystkie Twoje komputery są pod-
łączone do usługi Intune? Świetnie! Możesz użyć usługi Intune, aby wdrożyć ustawienia
AOVPN za pomocą plików XML. Jedną z zalet tej metody jest to, że usługa Intune może
zarządzać komputerami nieprzyłączonymi do domeny, dzięki czemu można teoretycznie
dodać komputery domowe i osobiste użytkowników do infrastruktury zarządzanej przez
usługę Intune i skonfigurować je do korzystania z połączeń Always On VPN.
Systemy SCCM i Intune są świetne, ale nie wszyscy ich używają. Istnieje trzecia opcja wdraża-
nia ustawień Always On VPN za pomocą skryptów PowerShell. Chociaż jest to plan B firmy
Microsoft (która naprawdę wolałaby, abyś wdrożył AOVPN za pośrednictwem MDM), obawiam
się, że PowerShell stanie się rzeczywistością dla wielu klientów z sektora małych i średnich
przedsiębiorstw, którzy chcą korzystać z połączeń AOVPN. Największą wadą używania progra-
mu PowerShell w celu wdrożenia ustawień AOVPN jest to, że musi on być uruchamiany
w trybie wysokich uprawnień, co oznacza, że trudno jest zautomatyzować cały proces, ponieważ
zalogowany użytkownik (za pomocą którego należy nawiązać połączenie VPN) powinien być
lokalnym administratorem, aby skrypt działał poprawnie.
Z nadzieją i niepokojem czekam na dzień, w którym zostanie zdefiniowany szablon zasad

grupy pozwalający na wprowadzenie ustawień Always On VPN, jednakże do tej pory nie wia-
domo, czy będzie to kiedykolwiek możliwe. Każdy ma wdrożone zasady grup, ale nie każdy
używa systemu MDM. Za chwilę przeczytasz, że wdrażanie ustawień połączenia Microsoft
DirectAccess (alternatywa dla AOVPN) odbywa się za pomocą zasad grupy, które są niezwykle
łatwe do zrozumienia i zarządzania. O ile mi wiadomo, w chwili gdy piszę te słowa, DirectAccess
ma dużą przewagę nad AOVPN, obsługuje bowiem zmiany ustawień po stronie klienta. Pamiętaj
216
jednak, aby odwiedzić witrynę Microsoft Docs w celu uzyskania najnowszych informacji na
ten temat, ponieważ narzędzie AOVPN jest stale ulepszane i prawdopodobnie nastąpią
pewne zmiany w tym obszarze technologii.
Serwerowe komponenty AOVPN

Gdy masz już wiedzę na temat tego, co jest potrzebne po stronie klienta, aby można było
uruchomić połączenie Always On VPN, chciałbyś się dowiedzieć, jakie składniki są wyma-
gane po stronie serwera i infrastruktury, aby możliwe było nawiązywanie takich połączeń.
Co ciekawe, zapewnienie stałego połączenia w usłudze AOVPN nie ma nic wspólnego z in-
frastrukturą serwerów — jest to składnik obsługiwany całkowicie po stronie klienta. Wszystko,
co musimy zrobić po stronie serwera, to upewnić się, że możemy odbierać przychodzące
połączenia VPN. Jeśli są pracownicy, którzy wykonują udane połączenia VPN, jest duża szansa,
że masz już infrastrukturę serwerową niezbędną do wprowadzenia usługi AOVPN do swojego
środowiska.
Serwer zdalnego dostępu

Oczywiście potrzebujesz serwera VPN, aby móc obsługiwać połączenia VPN? Cóż, nie jest to
takie oczywiste. W systemie Windows Server rola zarządzająca połączeniami VPN, AOVPN
i DirectAccess nazywa się Remote Access (dostęp zdalny), ale można uruchomić usługę Always
On VPN bez systemu Windows Server będącego serwerem dostępu zdalnego. Ponieważ utrzy-
manie stałego połączenia jest funkcją realizowaną po stronie klienta, możliwe jest zarządza-
nie infrastrukturą po stronie serwera VPN przez zewnętrznych dostawców. Mimo że jest to
technicznie wykonalne, nie jest tak naprawdę tym, czego oczekuje firma Microsoft. Również
moim zdaniem wdrożenie powinno zostać przeprowadzone w inny sposób. W rzeczywistości
osoby zainteresowane korzystaniem z usługi Microsoft Always On VPN będą używały systemu
Microsoft Windows Server w celu zarządzania rolą dostępu zdalnego będącą elementem, z któ-
rym łączą się zewnętrzni klienci.
Wiele osób automatycznie zakłada, że usługa AOVPN jest związana z systemem Windows
Server 2019, ponieważ jest ona nową technologią, która właśnie została udostępniona.
Wcale tak nie jest. Możesz zarządzać infrastrukturą VPN (rolą zdalnego dostępu) w systemach
Server 2019, Server 2016, a nawet Server 2012 R2. Działa ona wszędzie w taki sam sposób,
udostępniając klientom zasoby, z których mogą korzystać dzięki połączeniom VPN.
Po zainstalowaniu roli dostępu zdalnego w systemie Windows Server przekonasz się, że

większość działań konfiguracyjnych VPN można wykonywać przy użyciu konsoli Routing and
Remote Access (Routing i dostęp zdalny — RRAS). Podczas konfigurowania sieci VPN zoba-
czysz, że istnieje wiele protokołów, których można użyć w celu ustanowienia połączenia
VPN między klientem a serwerem. Powinieneś zdobyć przynajmniej ogólną wiedzę o tym,
jak one działają. Wymienię je tutaj w kolejności od najbardziej zaawansowanego i najbez-
pieczniejszego aż po „Nie dotykaj tego!”.
217
Protokół IKEv2
IKEv2 to najnowszy, najbardziej zaawansowany i najwszechstronniejszy sposób łączenia
komputerów klienckich za pośrednictwem sieci VPN lub AOVPN. Jest to jedyny sposób
umożliwiający podłączenie tunelu urządzenia w usłudze AOVPN. Protokół IKEv2 wymaga
w celu uwierzytelnienia wystawienia certyfikatów komputera dla maszyn klienckich. Ogólnie
oznacza to, że jeśli chciałbyś, aby klienty łączyły się za pomocą protokołu IKEv2, powinny
zostać dodane do domeny. Bardzo ważne jest, aby pamiętać, że IKEv2 używa do nawiązania
połączenia portów UDP 500 i 4500.
Protokół SSTP
Protokół SSTP wykorzystuje strumień SSL i jest uważany za zastępczą metodę nawiązywa-
nia połączeń AOVPN. Z tego powodu wymaga zainstalowania certyfikatu SSL na serwerze
dostępu zdalnego, ale nie potrzebuje certyfikatów maszyn na komputerach klienckich. Proto-
kół SSTP używa portu TCP 443, dzięki czemu pozwala na uzyskiwanie połączeń nawet z bardzo
restrykcyjnych sieci, w których protokół IKEv2 może nie zadziałać (z powodu jego zależności od
protokołu UDP).
Protokół L2TP
Ten protokół zwykle nie jest używany podczas wdrażania usługi AOVPN. Jest w stanie nawiązy-
wać połączenia VPN za pomocą certyfikatów lub klucza wstępnego. Ponieważ masz już do
dyspozycji dwa lepsze protokoły, nie powinieneś z niego korzystać.
Protokół PPTP
Mimo że ten protokół jest nadal poprawną opcją konfiguracji w konsoli RRAS, trzymaj się z dala
od niego! Protokół PPTP został zasadniczo złamany, więc jeśli nadal korzystasz z opartych na
nim połączeń VPN, musisz uznać strumienie danych za niezaszyfrowane i przyjąć, że przesyłają
czytelny tekst przez internet.
Urząd certyfikacji
Certyfikaty maszyn, certyfikaty użytkownika, certyfikaty SSL… coś strasznego! Oczywiste
jest, że aby korzystać z usługi Always On VPN, musisz wiedzieć, w jaki sposób działają certyfi-
katy i jak należy je wdrażać. Staje się to coraz bardziej powszechne w przypadku nowszych,
dobrze zabezpieczonych technologii. Głównym wymaganiem jest to, że w celu wydawania
certyfikatów musisz mieć w swoim środowisku wdrożoną infrastrukturę klucza publicznego
i co najmniej jeden serwer Windows będący urzędem certyfikacji. Poniżej zaprezentowano
listę obszarów, w których infrastruktura AOVPN może wykorzystywać certyfikaty:
 Certyfikaty użytkownika: są to certyfikaty wydawane użytkownikom VPN
z wewnętrznego urzędu certyfikacji i wykorzystywane do uwierzytelniania
tunelu użytkownika.
 Certyfikaty maszyny: są to certyfikaty wydawane dla stacji roboczych
(głównie laptopów) z wewnętrznego urzędu certyfikacji i używane do
uwierzytelniania tunelu urządzenia.
218
 Certyfikat SSL: zainstalowany na serwerze dostępu zdalnego w celu sprawdzenia

poprawności ruchu przychodzącego dla połączeń typu SSTP VPN.
 Certyfikaty maszyn VPN i NPS: Twój serwer dostępu zdalnego, a także serwery
NPS, które za chwilę omówimy, wymagają certyfikatów komputera wydanych
przez wewnętrzny urząd certyfikacji.
Network Policy Server (NPS)

Serwer Network Policy Server (serwer zarządzania zasadami sieciowymi — NPS) służy w zasa-
dzie do uwierzytelniania połączeń VPN. Gdy pojawia się żądanie połączenia VPN, serwer dostępu
zdalnego przekazuje je do serwera NPS w celu zweryfikowania, kim jest użytkownik, a także
sprawdzenia, czy ma on uprawnienia do zalogowania się za pośrednictwem sieci VPN.
Podczas obsługi połączeń VPN firmy Microsoft konfigurujemy serwer NPS najczęściej w taki
sposób, aby uprawnienia mieli użytkownicy należący do określonej grupy zabezpieczeń usługi
Active Directory. Na przykład, jeśli utworzysz grupę o nazwie Użytkownicy VPN, a następnie
przypiszesz ją do serwera NPS, połączenia VPN będą mogli realizować tylko ci użytkownicy,
których umieściłeś w tej grupie.
NPS jest kolejną rolą systemu Windows Server, która może być zainstalowana na jednym
serwerze lub na wielu maszynach w celu zapewnienia nadmiarowości. Podobnie jak w przypad-
ku roli dostępu zdalnego, usługa serwera NPS nie wymaga najnowszej wersji systemu Windows
Server, czyli Server 2019 — równie dobrze można ją wdrożyć we wcześniejszych.
W małych środowiskach, które używają tylko jednego serwera dostępu zdalnego, często umiesz-
cza się rolę NPS na tym samym serwerze, który zapewnia łączność VPN.
DirectAccess
Podczas omawiania usługi Always On VPN kilka razy wspominałem o produkcie Microsoft
DirectAccess. DirectAccess (w skrócie DA) to kolejna forma automatycznej łączności typu VPN,
jednakże działa ona odmiennie od Always On VPN. Podczas gdy usługa AOVPN po prostu
używa oczekiwanych, dobrze znanych protokołów VPN, a następnie stosuje sprytną magię,
aby automatycznie uruchamiać tradycyjne tunele VPN, tunele DirectAccess są unikatowe.
Są one chronione przez protokół IPsec i w zasadzie niedostępne oraz bezosobowe. Uważam,
że zespoły bezpieczeństwa uwielbiają zabezpieczenia i złożoność zawartą w tunelach usługi
DirectAccess, ponieważ jest to platforma połączeń, do której atakujący nie potrafią się wła-
mać ani jej skopiować.
Z mojego doświadczenia wynika, że obecnie Microsoft DirectAccess jest najczęstszym po-

wodem, dla którego administratorzy wdrażają rolę dostępu zdalnego w systemie Windows
Server. Jak wspomniałem, najłatwiejszym sposobem na zrozumienie usługi DirectAccess
jest potraktowanie jej jako automatycznej sieci VPN. Podobnie jak w przypadku VPN, celem
usługi DirectAccess jest połączenie komputerów użytkowników z siecią korporacyjną, gdy
219
znajdują się oni poza biurem. Jednak różni się ona od VPN metodą, której pracownicy uży-
wają, aby uzyskać to połączenie. DirectAccess nie jest komponentem oprogramowania: jest
to szereg składników, które są już wbudowane w systemie operacyjnym Windows i wspólnie
działają, aby zapewnić użytkownikowi bezproblemowy dostęp. Co mam na myśli pisząc
„bezproblemowy”? Podobnie jak usługa AOVPN łączy się bez interakcji użytkownika, tak nie
musi on nic robić w celu nawiązania połączenia DirectAccess. Połączenie tworzy się samo.
Gdy tylko komputer zdalny uzyskuje połączenie do internetu, czy to poprzez domową sieć
bezprzewodową, czy publicznie dostępny internet w kawiarni, czy też hotspot telefonu komór-
kowego, tunele DirectAccess są automatycznie ustanawiane.
Gdy komputer łączy się automatycznie, oszczędzasz czas i pieniądze niezależnie od tego,
czy korzystasz z usług Always On VPN czy DirectAccess. Oszczędzasz czas, ponieważ użyt-
kownik nie musi już uruchamiać połączenia VPN. Pieniądze są oszczędzane, ponieważ czas
to pieniądz, ale także dlatego, że stałe połączenie oznacza, iż poprawki są instalowane, zasady
bezpieczeństwa stosowane, a zdalne komputery zarządzane cały czas, nawet wówczas, gdy użyt-
kownik pracuje zdalnie. Nie musisz już czekać, aż użytkownicy wrócą do biura lub zdecydują się
ręcznie uruchomić połączenie VPN, aby móc przesłać nowe ustawienia i zasady do ich kom-
puterów. Wszystko to dzieje się niezależnie od tego, gdzie się znajdują — o ile mają dostęp do
internetu. Odkąd są dostępne dwie różne technologie zdalnego dostępu firmy Microsoft,
które mają na celu zrealizowanie automatycznego połączenia dla zdalnych użytkowników,
pracownicy mogą osiągać większą produktywność. Słowa „przyjazny dla użytkownika” i „VPN”
nigdy wcześniej nie były ze sobą powiązane, a w najnowszych wersjach systemów operacyj-
nych Windows — owszem, są.
Usługa DirectAccess w rzeczywistości istnieje od czasu wydania wersji Windows Server

2008 R2, a jednak regularnie spotykam osoby, które nigdy o niej nie słyszały. Na samym początku
jej wdrażanie było dość trudne i wiązało się z wieloma dziwnymi wymaganiami, ale w ciągu
ostatnich kilku lat wiele się zmieniło. Usługa DirectAccess jest obecnie o wiele prostsza niż
kiedykolwiek i pozwala na uzyskanie większych niż dotąd korzyści.
Cała prawda o usłudze DirectAccess i protokole IPv6

Jednym z dziwnych wymagań, o których wspomniałem, była potrzeba wdrożenia w Twojej
sieci protokołu IPv6. W przypadku pierwszej wersji usługi DirectAccess było to wymaganie
faktycznie niefortunne. Piszę „niefortunne”, ponieważ nawet dzisiaj, w 2019 roku, prawie nikt
nie korzysta z protokołu IPv6 w swojej sieci korporacyjnej, już nie wspominając o tym, że
wiele lat temu, gdy ta usługa została udostępniona, wielu administratorów nawet nie wiedziało,
czym jest IPv6. Na szczęście nie musisz już wdrażać protokołu IPv6 w swoich sieciach. Na wy-
padek gdyby ktoś nie zwracał uwagi na moje słowa lub studiował stare, nieaktualne dokumenty
TechNet, powtarzam: nie potrzebujesz protokołu IPv6, aby korzystać z DirectAccess! Znam
zbyt wiele przypadków, w których firma rozważała wdrożenie tej usługi, ale zrezygnowała,
ponieważ administratorzy po analizie dokumentacji TechNet uwierzyli, że użycie protokołu
IPv6 jest wymaganiem, i odrzucili projekt, który według nich w tej sytuacji nie mógłby funkcjo-
nować. Absolutnie nie musisz korzystać z protokołu IPv6 w swojej sieci, aby usługa DirectAccess
działała. Ważne jednak jest, aby zrozumieć, w jaki sposób DirectAccess korzysta z IPv6, ze-
tkniesz się bowiem z tym zagadnieniem zaraz po rozpoczęciu jej wdrażania.
220
Kiedy jestem w domu i pracuję na firmowym laptopie, DirectAccess łączy mnie z siecią
korporacyjną. Moja wewnętrzna sieć w pracy nie używa protokołu IPv6 — obecnie jest ona
całkowicie siecią IPv4. Dotyczy to w dzisiejszych czasach większości firm. Jednak gdy otwieram
wiersz poleceń i w swoim laptopie używającym usługi DirectAccess wykonuję polecenie
ping, które wysyła zapytanie do jednego z serwerów, otrzymuję następujące wyniki (przepraszam
za usunięte fragmenty nazwy serwera i adresu):
O co chodzi? Dla mnie wygląda to jak protokół IPv6. To oczywiste, że usługa DirectAccess
współpracuje z protokołem IPv6. Cały ruch przesyłany w internecie w ramach połączenia
między moim laptopem a serwerem DirectAccess, który znajduje się w centrum danych, jest
ruchem typu IPv6. Moja sieć wewnętrzna używa adresów IPv4, również mój serwer
DirectAccess ma tylko adresy IPv4, a jednak utworzony tunel przesyła dane przy użyciu
protokołu IPv6. Jest to sedno działania usługi DirectAccess i nie można tego zmienić. Twój
laptop za pośrednictwem internetu wysyła do serwera DirectAccess pakiety IPv6 zaszyfro-
wane protokołem IPsec. Gdy serwer DA odbierze te pakiety, może je przekształcić w wersję
IPv4 w celu przesłania ich na serwer docelowy w sieci korporacyjnej. Na przykład, gdy
otwieram program Outlook i próbuję połączyć się z serwerem Exchange, moje pakiety pro-
gramu Outlook przepływają przez tunel DirectAccess z użyciem protokołu IPv6. Gdy pa-
kiety te trafiają na serwer DirectAccess, sięga on do wewnętrznej usługi DNS, aby się dowie-
dzieć, czy mój serwer Exchange używa protokołu IPv4 czy IPv6. Jeśli faktycznie korzystasz
w sieci z wersji IPv6, a serwer Exchange ma adres typu IPv6, serwer DA po prostu wyśle
pakiety IPv6 do serwera Exchange. Połączenie zakończone! Jeśli natomiast używasz w swo-
jej sieci protokołu IPv4, serwer DA zobaczy tylko jeden rekord hosta w DNS, co oznacza, że
serwer Exchange jest dostępny pod adresem IPv4. Serwer DirectAccess zmieni pakiet IPv6
na IPv4, a następnie wyśle go do serwera Exchange. Dwie technologie, które obsługują mo-
dyfikacje pakietów, zwane są DNS64 i NAT64. Prawdopodobnie widziałeś ich nazwy w nie-
których dostępnych w sieci dokumentach związanych z usługą DirectAccess. Celem tych
technologii jest zamiana przychodzącego strumienia pakietów IPv6 na IPv4 dla sieci, w któ-
rych jest to wymagane (czyli obecnie dla prawie każdej sieci), a następnie, dla ruchu po-
wrotnego, zamiana z IPv4 z powrotem na IPv6, aby dane mogły się przedostać z powrotem
do komputera zdalnego klienta przez tunel IPsec oparty na protokole IPv6 i łączący klienta
z serwerem DA poprzez internet.
Ważne jest, aby pamiętać, że DirectAccess korzysta z IPv6, ponieważ wszelkie zasady bez-
pieczeństwa, które domyślnie blokują IPv6 na komputerach klienckich, nie pozwalają działać
usłudze DirectAccess również w Twoim środowisku. Trzeba będzie odpowiednio zmodyfikować
te zasady, aby umożliwić klientom przesyłanie pakietów IPv6 do internetu. Jednak powinieneś
także wiedzieć, że nie musisz wdrażać protokołu IPv6 wewnątrz sieci korporacyjnej, ponieważ
sam serwer DirectAccess potrafi przekształcić cały ruch do protokołu IPv4, zanim trafi on do tej
sieci. Większość implementacji DirectAccess, które obecnie działają na świecie, funkcjonuje
właśnie w ten sposób.
221
Wymagania wstępne dotyczące usługi DirectAccess

Usługa DirectAccess zawiera wiele składników, dlatego istnieją różne sposoby jej konfigurowa-
nia, jednak nie wszystkie z nich są zalecane. W tym punkcie przeanalizujemy część waż-
nych decyzji, które będziesz musiał podjąć podczas projektowania własnego środowiska
DirectAccess.
Dołączenie do domeny
Pierwszym znaczącym wymaganiem jest dodanie systemów z usługą DirectAccess do domeny.
Twój serwer (lub serwery) DA muszą być dołączone do domeny, i to samo dotyczy wszystkich
komputerów klienckich, z których chcesz się łączyć do sieci wewnętrznej. Członkostwo w do-
menie jest wymagane przede wszystkim do celów uwierzytelniania, a także dlatego, że ustawie-
nia klienta DirectAccess, które należy zastosować w komputerach przenośnych, są do nich
przesyłane za pomocą zasad grupy. Na wczesnym etapie procesu planowania zawsze lubię
zwracać uwagę na to wymaganie, oznacza ono bowiem, że użytkownicy, którzy kupują sobie
laptopy w sklepie, zazwyczaj nie będą mogli skorzystać z usługi DirectAccess, chyba że nie masz
nic przeciwko dodaniu komputerów domowych do Twojej domeny. Wygląda na to, że DA
jest tak naprawdę technologią przeznaczoną do łączenia zasobów firmowych, które są dodane do
domeny, i zarządzania nimi. Ważne jest też, aby zrozumieć to wymaganie z punktu widzenia
bezpieczeństwa, ponieważ serwer DirectAccess zwykle będzie się znajdować na brzegu sieci.
Zewnętrzna karta sieciowa w serwerze DA często jest umieszczana w strefie DMZ, ale musi
ona również należeć do domeny, co być może nie jest standardowym rozwiązaniem dla syste-
mów z sieci granicznej.
Obsługiwane systemy operacyjne klienta

Nie wszystkie systemy operacyjne klienta Windows zawierają składniki niezbędne do działania
połączenia DirectAccess. Jest ono obsługiwane w wersji Enterprise, której używa znaczna
liczba większych firm wykorzystujących systemy operacyjne firmy Microsoft. Z pewnością
jednak zdarzają się wyjątki. Nadal dużo niewielkich przedsiębiorstw korzysta z wersji Professio-
nal, lub nawet Home, które nie zawierają komponentów DirectAccess. Poniżej przedstawiono
listę systemów operacyjnych obsługujących usługę DirectAccess. Podczas planowania musisz się
upewnić, że Twoje komputery zdalne zawierają jeden z nich:
 Windows 10 Enterprise,
 Windows 10 Education,
 Windows 8.0 lub 8.1 Enterprise,
 Windows 7 Enterprise,
 Windows 7 Ultimate.
Serwery DirectAccess z jedną lub dwiema kartami sieciowymi

Jedno ważne pytanie, na które należy odpowiedzieć nawet przed zainstalowaniem roli dostępu
zdalnego na nowym serwerze, brzmi: Ile kart sieciowych jest potrzebnych w tej maszynie?
Istnieją dwie obsługiwane metody implementacji usługi DirectAccess.
222
Tryb z jedną kartą sieciową

Twój serwer DirectAccess może mieć tylko jedną kartę sieciową. W takim przypadku zazwyczaj
podłącza się ją bezpośrednio do sieci wewnętrznej, aby miała dostęp do wszystkich zasobów,
z którymi komputery klienckie będą się musiały kontaktować podczas sesji DirectAccess.
Aby przepuścić ruch z internetu do serwera DirectAccess, musisz ustanowić translację ad-
resów sieciowych (NAT) z publicznego adresu IP na dowolny wewnętrzny adres IP przypisany
do serwera DA. Wielu administratorom bezpieczeństwa sieci nie podoba się ta metoda, ponie-
waż oznacza ona utworzenie translatora NAT, który przenosi ruch bezpośrednio do sieci korpo-
racyjnej z pominięciem strefy DMZ.
Na podstawie swojego doświadczenia mogę również stwierdzić, że tryb z pojedynczą kartą

sieciową nie zawsze działa poprawnie. Radzi sobie świetnie w przypadku szybko utworzonego
laboratorium testowego lub weryfikowania koncepcji, jednakże w wielu firmach byłem
świadkiem problemów, gdy administratorzy próbowali uruchomić środowisko produkcyjne
DirectAccess na jednej karcie sieciowej. Możliwość użycia tylko jednej karty sieciowej została
dodana do usługi DirectAccess w jej nowszych wersjach, więc pierwotnie ten system nie został
zaprojektowany do działania w takich warunkach. Zdecydowanie zalecam, aby do produkcyj-
nej instalacji DA użyć innej opcji, o której napiszę poniżej.
Dwie karty sieciowe

W serwerze DirectAccess mamy zainstalowane dwie karty sieciowe. Wewnętrzna karta sieciowa
jest zazwyczaj podłączana bezpośrednio do sieci korporacyjnej, natomiast fizyczne umiejsco-
wienie zewnętrznej karty może się różnić w zależności od organizacji. Zaraz po tym punkcie
przeanalizujemy różne lokalizacje zewnętrznej karty sieciowej. Tryb z dwoma kartami jest
zalecanym sposobem implementacji usługi DirectAccess. Jak już wspomniałem, wdrożenie sys-
temu Windows Server z wieloma kartami sieciowymi oznacza, że będziesz korzystał z niego
w trybie wieloadresowości, więc musisz odpowiednio skonfigurować ich ustawienia. W przy-
padku serwera dostępu zdalnego zewnętrzna karta sieciowa jest zawsze tą, która zawiera
domyślne ustawienia bramy, dlatego musisz się upewnić, że przestrzegasz tej reguły i nie
konfigurujesz bramy domyślnej w karcie wewnętrznej. Z drugiej strony chcesz skonfiguro-
wać adresy serwerów DNS we właściwościach wewnętrznej karty sieciowej, ale nie chciałbyś
tego robić dla karty zewnętrznej. Ponieważ serwer jest wieloadresowy, prawdopodobnie bę-
dziesz musiał utworzyć pewne trasy, aby dodać podsieci korporacyjne do tablicy routingu
systemu Windows, zanim będzie on w stanie pomyślnie wysyłać i odbierać ruch. Jedynymi
sieciami, które nie musiałyby być brane pod uwagę podczas dodawania tras statycznych,
byłyby niewielkie sieci, w których wszystkie urządzenia wewnętrzne znajdują się w jednej
podsieci. W takim przypadku nie trzeba wprowadzać tras statycznych. Większość sieci korpora-
cyjnych zawiera jednak wiele podsieci, więc w takim przypadku wróć do rozdziału 5.,
„Obsługa sieci w Windows Server 2019”, w którym omówiliśmy wieloadresowość i sposoby
tworzenia tras.
Więcej niż dwie karty sieciowe

Nie myśl o tej opcji. Jeśli umiesz konfigurować routery lub zapory sieciowe, wiesz, że możesz
zainstalować wiele kart sieciowych na serwerze i podłączyć je do różnych podsieci. Chociaż
223
jest wiele powodów, dla których podział dostępu do sieci na serwerze zdalnego dostępu może
być korzystny, nie będzie to działać tak, jak oczekujesz. Usługa DirectAccess może zarządzać
tylko dwoma różnymi interfejsami sieciowymi.
Jak widać na poniższym zrzucie ekranu, podczas obsługi kreatora instalacji będziesz musiał
ustawić jedną kartę sieciową jako External (Zewnętrzna), a drugą jako Internal (Wewnętrzna).
Niestety, żadne inne karty sieciowe, które istnieją w tym serwerze, nie będą używane przez
usługę DirectAccess. Być może w przyszłych wersjach to się zmieni!
NAT-ować czy nie NAT-ować?

Gdy zdecydowałeś się umieścić dwie karty sieciowe w serwerze DirectAccess, musisz podjąć
decyzję, gdzie podłączysz kartę zewnętrzną. Są dwa typowe miejsca, do których można podłą-
czyć zewnętrzny interfejs sieciowy. W zależności od tego, które z nich wybierzesz, działanie
środowiska DirectAccess może się znacznie różnić. Zanim omówimy rzeczywiste umiejscowie-
nie karty sieciowej, chciałbym zaprezentować kilka protokołów, o których należy pamiętać,
ponieważ są one związane z odpowiedzią na pytanie dotyczące lokalizacji tej karty. Gdy
laptop nawiąże połączenie z serwerem DirectAccess, użyje do tego celu jednego z trzech proto-
kołów tunelowania IPv6. Tymi protokołami są: 6to4, Teredo i IP-HTTPS. Gdy klient ustanowi
tunele DirectAccess, w zależności od obecnego połączenia internetowego automatycznie
zdecyduje, którego z tych protokołów powinien użyć. Wszystkie trzy protokoły pełnią tę samą
funkcję dla połączenia DirectAccess: ich zadaniem jest pobieranie strumienia pakietów IPv6
wychodzącego z laptopa i hermetyzowanie go w postaci IPv4, aby ruch mógł zostać pomyślnie
przesłany internetem obsługującym adresy IPv4. Gdy pakiety docierają do serwera DirectAccess,
są z powrotem zamieniane na wersję IPv6, aby można je było przetworzyć.
Protokół 6to4
Klienty DirectAccess będą próbować połączyć się przy użyciu protokołu 6to4 tylko wtedy,
gdy zdalny laptop ma prawdziwy publiczny adres IP. W dzisiejszych czasach z powodu braku
dostępnych internetowych adresów IPv4 taka sytuacja jest rzadka, dlatego protokół 6to4 za-
zwyczaj nie jest używany przez komputery klienckie DirectAccess. W rzeczywistości może on
sprawiać problemy, gdy użytkownicy łączą się z internetem przy użyciu kart telefonów komór-
224
kowych zainstalowanych w laptopach, dlatego powszechnie stosowaną praktyką jest wyłączanie

interfejsu 6to4 w komputerach klienckich.
Protokół Teredo
Gdy klienci DA są podłączeni do internetu za pomocą prywatnego adresu IP, schowani na
przykład za routerem domowym lub publicznym routerem Wi-Fi, podejmą próbę połączenia
z wykorzystaniem protokołu Teredo. Teredo używa strumienia UDP do hermetyzacji pakie-
tów DirectAccess, więc dopóki połączenie internetowe użytkownika zezwala na wychodzący
ruch typu UDP po porcie 3544, dopóty protokół zazwyczaj funkcjonuje poprawnie i jest uży-
wany przez połączenie DirectAccess.
Protokół IP-HTTPS
Jeśli protokół Teredo nie nawiąże połączenia, na przykład w przypadku, gdy użytkownik jest
podłączony do sieci, która blokuje wychodzące pakiety UDP, połączenie DirectAccess spró-
buje skorzystać z protokołu IP-HTTPS (ang. IP over HTTPS). Protokół ten hermetyzuje pa-
kiety IPv6 w nagłówkach IPv4, a następnie opakowuje je w nagłówkach HTTP i przed wy-
słaniem do internetu szyfruje za pomocą protokołów TLS i SSL. Dzięki temu połączenie
DirectAccess staje się strumieniem SSL, podobnie jak ma to miejsce podczas przeglądania
witryny HTTPS.
Instalacja ekstremalna — w internecie

Podłączając zewnętrzną kartę sieciową serwera DirectAccess bezpośrednio do internetu,
możesz przydzielić jej prawdziwy publiczny adres IP. Włączasz wtedy wszystkie trzy poprzednio
omówione protokoły tunelowania pakietów, dzięki czemu komputery klienckie będą mogły
wybierać między nimi w celu uzyskania najlepszej formy połączenia. Podczas instalacji eks-
tremalnej przydzieliłbyś nie tylko jeden, ale dwa publiczne adresy IP dla zewnętrznej karty
sieciowej. Upewnij się, że te adresy są równoległe, ponieważ wymaga tego protokół Teredo.
Gdy Twój serwer DirectAccess będzie miał dwa równoległe publiczne adresy IP przypisane
do zewnętrznej karty sieciowej, umożliwi połączeniom dostęp do protokołu Teredo.
Aby połączenie działało, karta sieciowa nie musi być podłączona bezpośrednio do internetu.
W zależności od możliwości zapory może być dostępna opcja ustanowienia zmostko-
wanej strefy DMZ (ang. Bridged DMZ), w której nie zachodzi translacja NAT. Powinieneś się
skontaktować ze sprzedawcą zapory, aby się dowiedzieć, czy jest to możliwe. W tym
scenariuszu nadal będzie można konfigurować prawdziwe publiczne adresy IP w ze-
wnętrznej karcie sieciowej, ale ruch zostanie najpierw przepuszczony przez zaporę, aby
można go było chronić i nim zarządzać.
Instalacja przy wykorzystaniu translacji NAT

Administratorzy sieciowi znacznie częściej chcą umieścić zewnętrzną kartę sieciową serwe-
ra DirectAccess za zaporą, w strefie DMZ. Zazwyczaj oznacza to utworzenie translacji NAT
w celu umożliwienia ruchu pakietów do serwera. Chociaż takie rozwiązanie jest całkowicie
225
możliwe i lepiej chroni sam serwer DirectAccess przed atakiem z internetu, ma ono dużą
wadę. Po zainstalowaniu serwera DirectAccess przy użyciu translacji NAT protokół Teredo
przestanie działać. W rzeczywistości kreator konfiguracji DirectAccess rozpozna, że prywatny
adres IP został umieszczony na zewnętrznej karcie sieciowej, i po prostu nie włączy tego
protokołu.
Gdy protokół Teredo nie będzie dostępny, wszystkie klienty DirectAccess będą się łączyć
przy użyciu protokołu IP-HTTPS. Dlaczego więc powinniśmy się przejmować sytuacją, w której
protokół Teredo jest niedostępny? Ponieważ jest on bardziej wydajny niż IP-HTTPS. Gdy
Teredo tuneluje pakiety, po prostu hermetyzuje IPv6 wewnątrz IPv4. Strumień ruchu DirectAc-
cess jest przez cały czas szyfrowany protokołem IPsec, więc tunel Teredo nie musi wykony-
wać żadnego dodatkowego szyfrowania. Z drugiej strony, gdy IP-HTTPS tuneluje pakiety,
pobiera już zaszyfrowany strumień ruchu IPsec i szyfruje go po raz drugi za pomocą SSL.
Oznacza to, że wszystkie przychodzące i wychodzące pakiety podlegają podwójnemu szyfrowa-
niu, co powoduje dodatkowe przetwarzanie, zużywa cykle procesora oraz spowalnia połą-
czenie. Powoduje to także nadmiarowe obciążenie sprzętowe na samym serwerze DirectAccess,
obsługuje on bowiem dwa razy więcej procesów szyfrujących.
Ten problem jest szczególnie widoczny, gdy na komputerach klienckich używasz systemu
Windows 7, ponieważ podwójne przetwarzanie szyfrowania zauważalnie spowalnia połączenie.
DirectAccess nadal działa dobrze, ale jeśli umieścisz laptopa podłączonego przez protokół
Teredo obok laptopa podłączonego przez IP-HTTPS, zauważysz różnicę prędkości.
Na szczęście w systemach Windows 8 i Windows 10 wprowadzono pewne środki zaradcze,

które pomagają zniwelować te różnice w prędkości. Nowsze systemy operacyjne klienta są obec-
nie na tyle inteligentne, że mogą modyfikować część SSL tunelu IP-HTTPS za pomocą algoryt-
mu szyfrowania NULL, co oznacza, że protokół IP-HTTPS nie wykonuje drugiego szyfro-
wania, a jego wydajność jest taka sama jak Teredo.
To rozwiązanie działa jednak zadowalająco tylko w przypadku nowszych systemów operacyjnych

klienta (Windows 7 zawsze będzie podwójnie szyfrować za pomocą protokołu IP-HTTPS),
a niekiedy i tak sprawia problemy. Na przykład, jeśli umożliwisz serwerowi DirectAccess
również zapewnianie łączności VPN lub jeśli zdecydujesz się jednocześnie zastosować sys-
tem jednorazowych haseł (OTP), algorytm NULL zostanie wyłączony, ponieważ w takich sytu-
acjach spowoduje on zagrożenie bezpieczeństwa, więc nawet komputery z systemem Windows 8
i Windows 10 będą wykonywać podwójne szyfrowanie podczas łączenia się za pośrednic-
twem protokołu IP-HTTPS. Musiałbyś się zastanowić, w jakiej sytuacji korzystne byłoby
włączenie protokołu Teredo, aby komputery mogły się łączyć za jego pośrednictwem.
Podsumowując, z pewnością możesz zainstalować zewnętrzną kartę sieciową serwera DirectAccess

przy użyciu translacji NAT, ale pamiętaj, że wszystkie komputery klienckie będą się wówczas łą-
czyć za pomocą protokołu IP-HTTPS. Ważne jest także, aby zrozumieć potencjalny efekt uboczny
takiej implementacji.
226
Network Location Server

Ten główny składnik infrastruktury DirectAccess jest elementem, który nie istnieje nawet na
samym serwerze DirectAccess, a przynajmniej nie powinien, jeśli wszystko zostanie poprawnie
skonfigurowane. Network Location Server (NLS) to po prostu strona WWW działająca
w sieci korporacyjnej. Ta strona nie musi być dostępna z internetu — w rzeczywistości nawet nie
powinna. Serwer NLS jest używany jako część mechanizmu wykrywania obecności wewnątrz
sieci firmowej w komputerach klienckich DirectAccess i działa podobnie jak funkcja Trusted
Network Detection w usłudze Always On VPN. Za każdym razem, gdy klient DA uzyskuje
połączenie sieciowe, zaczyna wyszukiwać stronę WWW serwera NLS. Jeśli może się z nią
połączyć, oznacza to, że znajduje się w sieci korporacyjnej, a usługa DirectAccess nie jest
wymagana, więc ją wyłącza. Jeśli jednak nie można się połączyć z witryną NLS, znaczy to,
że znajdujesz się poza siecią firmową, a komponenty DirectAccess zaczną się uruchamiać.
Warunek wstępny uruchomienia serwera NLS jest łatwy do spełnienia. Wszystko, co musisz
zrobić, to uruchomić maszynę wirtualną i zainstalować na niej usługę IIS, która będzie obsługi-
wać nową stronę intranetową, lub nawet dodać tę stronę do istniejącego serwera WWW
w sieci. Są tylko dwa czynniki, na które należy zwrócić uwagę podczas konfigurowania
witryny NLS. Po pierwsze, musi to być witryna HTTPS, a zatem wymaga certyfikatu SSL.
W dalszej części tego rozdziału omówimy ten certyfikat, a także inne, które są wykorzystywane
przez usługę DirectAccess. Musisz nie tylko się upewnić, że witryna jest dostępna za pośred-
nictwem protokołu HTTPS, ale również zadbać o unikatowość nazwy DNS, której używasz
do łączenia się z tą witryną. Ten warunek trzeba spełnić, bez względu bowiem na to, jaką nazwę
wybierzesz dla witryny NLS, nie da się jej rozwiązać, gdy komputery klienckie znajdują się
poza siecią korporacyjną. Taka funkcjonalność jest zaplanowana, ponieważ oczywiście nie chciał-
byś, aby klienci mogli z powodzeniem skontaktować się z witryną NLS, gdy pracują zdalnie,
gdyż spowodowałoby to przerwanie połączenia DirectAccess.
Powodem, dla którego nalegam na unikatową nazwę DNS, jest to, że często mam do czynie-
nia z niedoświadczonymi administratorami DirectAccess wykorzystującymi istniejącą, we-
wnętrzną witrynę internetową jako stronę NLS. Na przykład, jeśli Twoja strona intranetowa
https://intranet działa jako witryna SharePoint, mógłbyś po prostu użyć jej w konfiguracji
DA jako definicji serwera NLS. Jednak po wprowadzeniu takiej modyfikacji zdasz sobie
wkrótce sprawę, że żaden pracownik podłączony zdalnie nie będzie mógł uzyskać dostępu
do strony https://intranet. Jest to zamierzone, ponieważ środowisko DirectAccess traktuje
teraz witrynę intranetową jako serwer NLS i jest ona nieosiągalna dla użytkownika, który
znajduje się poza firmą. Jakie jest rozwiązanie tego problemu? Upewnij się, że zdefiniowałeś
nową nazwę DNS, która będzie używana dla witryny NLS. Może to być coś podobnego do adresu
https://nls.contoso.local.
Chciałbym podkreślić, że najważniejsze we wdrożeniu serwera NLS jest umieszczenie jego

witryny na maszynie, która nie jest serwerem DirectAccess. Podczas korzystania z kreatorów
konfiguracji DA zobaczysz, że na ekranie, za pomocą którego definiujemy serwer NLS, pojawi
się zalecenie wdrożenia go na zdalnym serwerze WWW. Będzie także dostępna opcja hostowania
witryny NLS bezpośrednio na samym serwerze DirectAccess. Nie rób tego! Gdy strona
NLS zostanie umieszczona na serwerze DA, może wystąpić wiele różnych problemów. Uru-
chamianie NLS na serwerze DirectAccess ogranicza też Twoje przyszłe możliwości, ponie-
227
waż niektóre zaawansowane konfiguracje DA wymagają usunięcia witryny NLS z serwera

DA, więc równie dobrze możesz wszystko poprawnie skonfigurować na samym początku.
Zmiana strony NLS już po produkcyjnym uruchomieniu usługi DirectAccess może być bardzo
trudna i często rodzi problemy. Pomagałem wielu firmom w przenoszeniu witryny NLS po tym,
gdy zdały sobie sprawę, że nie mogą współdzielić środowiska NLS na serwerze DA po dodaniu
drugiego serwera w celu rozbudowy środowiska lub uzyskania redundancji. Poniżej zamiesz-
czam zrzut ekranu kreatora konfiguracji DirectAccess, w którym wybierasz lokalizację NLS.
Pamiętaj, aby zaznaczyć górną opcję!
Certyfikaty używane w usłudze DirectAccess

Obok nieporozumień związanych z dokumentacją dotyczącą sposobu korzystania z proto-
kołu IPv6 przez usługę DirectAccess certyfikaty są kolejnym wielkim „odstraszaczem” dla
administratorów, którzy byliby zainteresowani jej wypróbowaniem. Gdy zaczniesz analizo-
wać działanie DA, szybko zdasz sobie sprawę z tego, że wymagane jest użycie kilku certyfikatów.
Podczas gdy sieci VPN na ogół również zmuszają do korzystania z certyfikatów, na podsta-
wie informacji dostępnych w witrynie Microsoft Docs trudno jest zrozumieć, jakie certyfikaty
należałoby wdrożyć w przypadku DirectAccess, więc w tym punkcie wyjaśnimy wszelkie
nieporozumienia, które się mogą pojawić. To naprawdę nie jest zbyt skomplikowane, gdy
wiesz, co należy, a czego nie powinno się robić.
Podstawowym warunkiem jest posiadanie w sieci serwera Windows z urzędem certyfikacji.

Poziom implementacji PKI nie jest tak ważny dla usługi DirectAccess. Po prostu musimy mieć
możliwość wystawiania certyfikatów swojemu serwerowi DA i klientom. Usługa DirectAccess
wykorzystuje tylko trzy rodzaje certyfikatów, z których dwa są certyfikatami SSL.
Certyfikat SSL na serwerze NLS

Jak wspomniałem, witryna NLS musi obsługiwać protokół HTTPS. Oznacza to, że będziesz
musiał zainstalować certyfikat SSL na serwerze, na którym znajduje się strona NLS. Zakładając,
że masz wewnętrzny serwer urzędu certyfikacji, ten certyfikat można łatwo uzyskać i nie
228
będziesz ponosić żadnych związanych z nim kosztów. Nie musisz kupować go z publicznego
urzędu certyfikacji, gdyż dostęp do niego będzie możliwy tylko z komputerów przyłączonych do
domeny i będących klientami DirectAccess. Ponieważ komputery przyłączone do domeny
automatycznie ufają lokalnym serwerom urzędu certyfikacji, wymagany certyfikat można po
prostu uzyskać z takiego urzędu i będzie on poprawnie wykonywał swoje zadanie.
Certyfikat SSL na serwerze DirectAccess

Wymagany jest także certyfikat SSL, który zostanie zainstalowany na serwerze DirectAccess.
Taki certyfikat należy jednak kupić od publicznego urzędu certyfikacji. Będzie on używany
do sprawdzania poprawności strumieni ruchu IP-HTTPS przychodzących z komputerów
klienckich, zawierają one bowiem dane szyfrowane protokołem SSL. Potrzebujemy więc
certyfikatu SSL, aby je weryfikować. Ponieważ komponent odbierający ruch IP-HTTPS jest
podłączony do publicznego internetu, zdecydowanie zaleca się korzystanie z certyfikatu po-
chodzącego z publicznego ośrodka certyfikacji zamiast z certyfikatu wydanego przez we-
wnętrzną infrastrukturę PKI.
Jeśli Twoja firma posiada wieloznaczny certyfikat SSL, użyj go w tym przypadku, aby
obniżyć koszty!
Certyfikaty maszyn na serwerze DirectAccess i wszystkich klientach

Ostatnią i najbardziej skomplikowaną częścią układanki certyfikatów DirectAccess są certy-
fikaty maszyn. Gdy jednak wiesz, co jest wymagane, wcale nie jest to trudne zagadnienie. Po
prostu wymagane jest zainstalowanie certyfikatu komputera lub maszyny na serwerze
DirectAccess, a także na każdym komputerze klienckim. Certyfikat maszyny jest częścią procesu
uwierzytelniania dla tuneli IPsec. Jest to element algorytmu używanego przez usługę DirectAccess
podczas nawiązywania połączenia w celu sprawdzenia, czy naprawdę jesteś tym, za kogo się
podajesz.
Najlepszą metodą uzyskania certyfikatów maszyny jest zalogowanie się na serwerze urzędu
certyfikacji i zdefiniowanie nowego szablonu certyfikatu, który zostanie utworzony na podstawie
wbudowanego szablonu komputera. Podczas konfigurowania nowego szablonu certyfikatu
upewnij się, że spełnia on następujące wymagania:
 Pole Common Name (Nazwa pospolita; podmiot) certyfikatu powinno być zgodne
z nazwą FQDN komputera.
 Pole Subject Alternative Name (Alternatywna nazwa podmiotu — SAN)
certyfikatu powinno być równe nazwie DNS komputera.
 Certyfikat powinien służyć zamierzonym celom (rozszerzone użycie klucza)
zarówno w przypadku uwierzytelnienia klienta, jak i serwera.
Powinienem tutaj wspomnieć (choć tak naprawdę nie chcę), że wydanie tych certyfikatów
nie jest absolutnie konieczne, aby usługa DirectAccess mogła działać. Jeśli po stronie klienta
korzystasz z systemu Windows 8 lub nowszego, możliwe jest, że usługa DA będzie działać
bez certyfikatów komputera. Komputery będące w sieci mogą podczas tworzenia tuneli IPsec
229
używać w celu uwierzytelniania komponentu o nazwie Kerberos Proxy zamiast certyfikatu.

Zdecydowanie jednak zalecam stosowanie certyfikatów. Korzystanie z certyfikatów w ramach
procesu uwierzytelniania sprawia, że połączenie jest bardziej stabilne i bezpieczne. Ponad-
to, podobnie jak w przypadku lokalizacji serwera NLS, jeśli chciałbyś wdrożyć w usłudze
DirectAccess jakiekolwiek zaawansowane funkcje, takie jak równoważenie obciążenia lub wie-
lowitrynowość, a nawet gdy po prostu chcesz, aby komputery klienckie z systemem Win-
dows 7 łączyły się do sieci lokalnej, i tak będziesz musiał wygenerować certyfikaty. Więc po
prostu zastosuj się do najlepszych wzorców postępowania i utwórz te certyfikaty, zanim
jeszcze zaczniesz testować usługę DirectAccess.
Nie używaj kreatora Getting Started Wizard (GSW)!

Po podjęciu niezbędnych decyzji projektowych i wdrożeniu wymagań, o których wspomi-
nałem do tej pory, nadszedł czas, aby zainstalować rolę Remote Access na nowym serwerze
DirectAccess! Po zakończeniu instalowania roli, podobnie jak wielu innych ról w systemie
Windows Server 2019, zostanie wyświetlony komunikat informujący, że aby można było z niej
skorzystać, trzeba przeprowadzić dodatkową konfigurację. W rzeczywistości gdybyś chciał
podążyć za żółtym wykrzyknikiem w Menedżerze serwera, jedynym dostępnym działaniem
byłaby opcja Open the Getting Started Wizard (Otwórz kreatora Wprowadzenie). Hmm, nie
jest to opcja, którą chciałbyś kliknąć:
Właściwym narzędziem służącym do konfiguracji usługi DirectAccess jest konsola Remote

Access Management Console (Zarządzanie dostępem zdalnym), dostępna z menu Tools w Mene-
dżerze serwera po zainstalowaniu roli Remote Access. Uruchom ją, a dostaniesz kilka opcji
do wyboru:
Nie klikaj łącza Open the Getting Started Wizard! Ten kreator to skrótowa metoda implementacji
usługi DirectAccess, zaprojektowana wyłącznie w celu jak najszybszego jej uruchomienia —
być może do prostej weryfikacji koncepcji. Pod żadnym pozorem nie należy ufać kreatorowi
230
GSW w produkcyjnym środowisku DA, ponieważ szybka i łatwa konfiguracja zawiera mnóstwo
kompromisów, które nie są najlepszymi wzorcami postępowania.
Ponieważ jesteś świadomym administratorem, powinieneś w konsoli kliknąć łącze Run the
Remote Access Setup Wizard (Uruchom kreatora konfiguracji dostępu zdalnego). Spowoduje
to wywołanie pełnowymiarowego kreatora konfiguracji DirectAccess. Konfiguracja DA składa
się z czterech różnych etapów, przy czym każdy zawiera kilka okien, w których będziesz mu-
siał wybrać odpowiednie opcje konfiguracji. Na tych ekranach znajduje się dużo informacji obja-
śniających, co oznacza każda z opcji, więc nie obawiaj się i określ poprawnie wszystkie para-
metry. Jeśli podczas konfiguracji usługi DirectAccess skorzystałeś z kreatora Getting Started
Wizard, może ona działać, ale nie będzie tak wydajna ani bezpieczna, jak mogłaby być. Poniżej
znajduje się krótka lista z powodami, dla których użycie kreatora Getting Started Wizard nie
leży w Twoim interesie. Oto działania wykonywane przez tego kreatora, które są sprzeczne
z najlepszymi wzorcami postępowania podczas konfiguracji usługi DirectAccess, wraz z towarzy-
szącymi im komentarzami z loży szyderców:
 Kreator GSW umieszcza witrynę NLS na serwerze DirectAccess — źle!
 Kreator GSW stosuje ustawienia zasad grupy klienta DirectAccess
do komputerów domeny — to okropny pomysł!
 Kreator GSW korzysta z certyfikatów z podpisem własnym — „poziom
zabezpieczeń minus jeden”, bez sensu!
 Kreator GSW automatycznie wyłącza protokół Teredo — nieefektywne!
 Kreator GSW nie udostępni Ci żadnej zaawansowanej opcji DirectAccess,
prawdopodobnie dlatego, że sposób, w jaki wszystko zostaje skonfigurowane,
nie pozwala skorzystać z takich funkcji — kiepska sprawa!
Remote Access Management Console

Jesteś na dobrej drodze do zapewnienia użytkownikom możliwości zdalnego dostępu do Twojego
nowego serwera. Podobnie jak w przypadku wielu innych urządzeń sieciowych, również po
wykonaniu wszelkich zadań konfiguracyjnych na serwerze dostępu zdalnego administratorzy
często zostawiają go i pozwalają mu działać. Nie ma potrzeby ciągłej konserwacji ani zmian
konfiguracji, jeśli będzie działać poprawnie. Jednak konsola Remote Access Management
Console (Konsola zarządzania dostępem zdalnym) w systemie Windows Server 2019 jest przy-
datna nie tylko do konfigurowania składników usługi dostępu zdalnego, ale także do jej monito-
rowania i tworzenia raportów. Jest ona dla usługi DirectAccess centrum zarządzającym pra-
wie wszystkimi jej elementami: konfiguracją, monitorowaniem i raportowaniem. W przypadku
usług typu VPN lub AOVPN będziesz w konsoli Routing and Remote Access podejmować
wiele decyzji dotyczących konfiguracji sieci VPN, jednakże to konsola RAMC jest właściwym
miejscem służącym do monitorowania aktywności po stronie serwera, połączeń z klientem
i tworzenia raportów statystycznych. Bez względu na to, czy korzystasz z DirectAccess,
VPN, czy też z kombinacji tych dwóch elementów, konsola RAMC jest narzędziem, w którym
musisz się czuć komfortowo.
231
Rzućmy okiem na tę konsolę, abyś zapoznał się z różnymi oknami, których będziesz używać
podczas interakcji z systemem:
Configuration
Ekran Configuration (Konfiguracja) jest dość intuicyjny; w tym miejscu tworzysz początkową
konfigurację dostępu zdalnego, a w przyszłości aktualizujesz jego ustawienia. Jak widać na zrzu-
cie ekranu, bezpośrednio z tej konsoli możesz skonfigurować opcje DirectAccess and VPN
(DirectAccess i VPN), a nawet Web Application Proxy (Serwer proxy aplikacji sieci Web).
Nie rób tego, co wykonałem na powyższym zrzucie ekranu. Zainstalowałem rolę zdal-
nego dostępu z opcjami DA i VPN, a także z usługą serwera proxy aplikacji sieci Web,
jednakże nie zaleca się jednoczesnego uruchamiania tych dwóch elementów na tym
samym serwerze. Zrobiłem to po prostu w celu stworzenia zrzutów ekranu w moim
laboratorium testowym.
Jeśli chodzi o VPN, nie ma tu wiele do skonfigurowania. Tak naprawdę masz tylko jedno
okno z opcjami, w którym określasz, jaki rodzaj adresu IP ma być przekazywany łączącym
się klientom VPN i jak obsługiwać uwierzytelnianie VPN. Od razu chciałbym podkreślić, że
dostęp do tego ekranu nie jest oczywisty. W sekcji konfiguracyjnej usług DirectAccess i VPN
232
powinieneś w drugim kroku kliknąć przycisk Edit… (Edytuj…), co spowoduje uruchomienie

minikreatora. Jego ostatnie okno nazywa się VPN Configuration (Konfiguracja VPN). Jest to
ekran, na którym możesz skonfigurować adresy IP i ustawienia uwierzytelniania dla połą-
czeń VPN. Pozostałe zadania związane z konfiguracją VPN będą należeć do tradycyjnej konsoli
Routing and Remote Access (RRAS). Wszystkie parametry połączeń DirectAccess są jednak
konfigurowane bezpośrednio z poziomu konsoli zarządzania dostępem zdalnym i czterech
minikreatorów:
Dashboard
Ekran Remote Access Dashboard (Pulpit nawigacyjny dostępu zdalnego) udostępnia znakomity
punkt widokowy pozwalający na obserwowanie statusu serwera dostępu zdalnego. Możesz
szybko wyświetlić stan komponentów działających na serwerze, niezależnie od tego, czy najnow-
sze zmiany konfiguracji zostały wprowadzone. W dolnej części okna będziesz także mógł
dostrzec niektóre statystyki dotyczące trwających połączeń DirectAccess i VPN (zobacz
zrzut na następnej stronie).
Operations Status
Jeśli chciałbyś dokładniej zbadać, co dzieje się po stronie serwera połączeń, wiedz, że do
tego właśnie służy ekran Operations Status (Status operacji). Możesz na nim zobaczyć więcej
szczegółów dotyczących każdego z komponentów, które działają w tle i umożliwiają wykonywa-
nie połączeń DA oraz VPN. Jeśli któryś z nich nie działa poprawnie, możesz go kliknąć, aby
uzyskać nieco więcej informacji. W ramach testu wyłączyłem serwer webowy NLS w swojej
sieci laboratoryjnej, dlatego na stronie Operations Status mogę zauważyć, że usługa NLS zawiera
znacznik błędu (zobacz kolejny zrzut na kolejnej stronie).
233
Remote Client Status

Następnie mamy ekran Remote Client Status (Status klienta zdalnego). Jak widać, jest to ekran,
na którym możemy monitorować podłączone komputery klienckie. Zostaną tutaj wyświetlone
zarówno połączenia DirectAccess, jak i VPN. Będziemy mogli zobaczyć nazwy komputerów,
nazwy użytkowników, a nawet zasoby, z których korzystają oni podczas połączeń. Informacje
na tym ekranie można filtrować przez umieszczenie dowolnych kryteriów na pasku Search
(Wyszukiwanie) w górnej części okna.
Ważne jest, aby pamiętać, że ekran Remote Client Status pokazuje tylko aktywne połączenia,
trwające „na żywo”. Nie są tutaj wyświetlane żadne informacje historyczne.
234
Reporting
Zgadłeś: Reporting (Raportowanie) to ekran, który musisz odwiedzić, jeśli chciałbyś się zapoznać
z historycznymi informacjami o zdalnym dostępie. To okno wygląda prawie tak samo jak
ekran Remote Client Status, z tą różnicą, że masz możliwość generowania raportów z danymi
historycznymi pobranymi dla wybranych zakresów dat. W raporcie masz takie same możliwości
wyszukiwania i filtrowania, jakie miałeś na ekranie Remote Client Status.
Raportowanie jest domyślnie wyłączone, ale wystarczy przejść do strony Reporting i kliknąć
odnośnik Configure Accounting (Konfiguruj raportowanie). Wówczas pojawi się opcja przecho-
wywania informacji historycznych. Możesz przechowywać dane w lokalnej bazie lub na zdalnym
serwerze RADIUS.
Dostępne są również opcje określające czas przechowywania rejestrowanych danych oraz

mechanizm, za pomocą którego można usunąć starsze informacje:
235
Tasks
Ostatnim obszarem okna w konsoli zarządzania dostępem zdalnym, na który chcę zwrócić
uwagę, jest pasek Tasks (Zadania) po prawej stronie ekranu. Działania i opcje wyświetlane
na tym pasku zadań zmieniają się w zależności od tego, na którym fragmencie konsoli się znaj-
dujesz. Upewnij się, że pamiętasz o tym obszarze ekranu podczas konfigurowania co bardziej
zaawansowanych funkcji. Oto niektóre przykłady dostępnych zadań na pasku Tasks: tworzenie
raportów użytkowania, odświeżanie ekranu, włączanie lub wyłączanie sieci VPN oraz konfigu-
rowanie równoważenia obciążenia sieciowego lub wielowitrynowości, jeśli używasz wielu
serwerów dostępu zdalnego.
236
DirectAccess, VPN czy AOVPN?

Jakie rozwiązanie jest najlepsze?
Usługa VPN istnieje od bardzo dawna, co powoduje, że jest ona dość dobrze znana osobom pra-
cującym w branży IT. Rozwiązanie Always On VPN z pewnością zawiera nowe interesujące
możliwości, ale w rzeczywistości jego niskopoziomowe mechanizmy opierają się na tradycyjnie
skonfigurowanym połączeniu VPN, więc sposób działania jest podobny do tego, co do tej
pory znaliśmy. W tym rozdziale omawialiśmy dość szczegółowo również usługę DirectAccess,
aby przybliżyć Ci alternatywną metodę automatycznego łączenia zdalnych klientów z centrum
danych. Gdy już wiesz, że istnieją dwie świetne platformy połączeń wbudowane w system
Windows Server 2019 w celu umożliwienia zdalnej pracy, czy zadajesz sobie pytanie, która
z nich jest lepsza?
Nie musisz wcale wybierać między nimi! Obie technologie można uruchomić jednocześnie,
nawet na tym samym serwerze dostępu zdalnego. Każda z nich ma swoje zalety i wady, a sposób,
w jaki je wykorzystasz, będzie zależał od wielu zmiennych. W procesie decyzyjnym będą
musieli zostać uwzględnieni użytkownicy, komputery klienckie i indywidualne potrzeby organi-
zacji. Omówmy pewne różnice istniejące między usługami DirectAccess i VPN, abyś mógł pod-
jąć inteligentną decyzję, które platformy łączności będą najlepiej odpowiadać Twojej organizacji.
Dołączenie do domeny?
Jednym z najważniejszych wymagań dotyczących komputera klienckiego używającego usługi
DirectAccess jest to, że musi on zostać przyłączony do domeny. Chociaż ten wymóg sam
w sobie nie wydaje się tak istotny, jego konsekwencje mogą być ogromne. Ufanie kompute-
rowi w stopniu umożliwiającym przyłączenie go do domeny oznacza najprawdopodobniej, że
jest on własnością firmy. Zapewne znaczy to również, że taka maszyna została zainstalowana
i przygotowana przez zespół IT. Firmy, które mają zwyczaj zezwalania pracownikom na używanie
własnych komputerów w pracy, mogą stwierdzić, że usługa DirectAccess niezbyt dobrze pa-
suje do ich modelu biznesowego. Nie jest ona także idealna w sytuacji, w której pracownicy
używają istniejących komputerów domowych do zdalnego łączenia się z siecią firmową.
W sytuacjach, w których wykorzystuje się komputery domowe i przenośne, lepszym rozwiąza-

niem jest zastosowanie usługi VPN. Do sieci firmowej możesz połączyć się przy użyciu VPN
(włącznie z Always On VPN) z komputera z systemem Windows 10 niedołączonym do domeny,
a nawet ręcznie z wielu urządzeń innych niż te, które zawierają oprogramowanie firmy
Microsoft. Platformy iOS, Android, telefony z systemem Windows i komputery Mac mają wbu-
dowanego klienta VPN, którego można użyć do połączenia się z serwerem dostępu zdalnego
zawierającym system Windows Server 2019. Jeśli jedynym dostępnym rozwiązaniem byłaby
usługa DirectAccess, z platformą dostępu zdalnego nie mógłbyś używać sprzętu niedołączonego
do domeny.
237
Pamiętaj, że chociaż tunel użytkownika w usłudze Always On VPN jest pod tym względem bar-
dziej uniwersalny niż połączenie DirectAccess, to jeśli zamierzasz korzystać z tunelu urządzeń
AOVPN, Twoje komputery nadal będą musiały zostać dołączone do domeny.
Uruchamianie automatyczne czy ręczne?

Istnieje wiele różnych sposobów podejścia do tego tematu. Odpowiedź na pytanie o to, która
z dwóch opcji: DirectAccess czy tradycyjna sieć VPN, jest lepsza, jest jasna: ta pierwsza,
czyli DirectAccess. Nie ma sensu, by użytkownicy otwierali połączenie, a następnie uruchamiali
je ręcznie w celu ustanowienia kanału VPN, gdy dostępna jest platforma zautomatyzowana.
Always On VPN zapewnia jednak automatyczną i bezproblemową łączność ze światem VPN.

Pod tym względem usługa AOVPN jest niemal tak samo wydajna jak DirectAccess. Używam
słowa „niemal” dlatego, że w czasie, gdy ta książka powstaje, dość trudno jest sprawić, by tunel
urządzeń działał poprawnie. Oznacza to, że większość firm wdrażających AOVPN korzysta
tylko z tunelu użytkownika. W scenariuszu z takim tunelem sieć VPN uruchamia się automa-
tycznie, ale dopiero wtedy, gdy użytkownik już się zaloguje do komputera. Oznacza to, że
w takich sytuacjach DirectAccess nadal ma przewagę nad AOVPN, ponieważ łączy się już
w trakcie wyświetlania ekranu logowania. Umożliwia to resetowanie hasła i logowanie nowych
użytkowników domeny na komputerach korzystających z usługi DirectAccess. Mam nadzieję,
że przyszłe ulepszenia umożliwią koegzystencję urządzeń AOVPN i tuneli użytkownika, co
zapewni prawdziwą stałą łączność z klientami zdalnymi.
Oprogramowanie zewnętrzne czy wbudowane?

Lubię meble firmy Ikea. Producent ten świetnie sobie radzi — dostarcza produkty wysokiej
jakości przy niskich kosztach, a dodatkowo pakuje je w niewiarygodnie małe pudełka. Po zapła-
ceniu za produkt rozpakuj go, złóż, a następnie przetestuj, aby upewnić się, czy działa —
świetna rzecz. Jeśli nie rozumiesz, dlaczego to piszę, dam Ci wskazówkę: jest to analogia do
tradycyjnych sieci VPN innych firm. Zazwyczaj płacisz dostawcy za jego produkt VPN, rozpako-
wujesz go, wdrażasz go po dodatkowych kosztach, a następnie testujesz. To oprogramowanie
może następnie ulec uszkodzeniu i wymagać ponownej instalacji lub rekonfiguracji, a na pewno
będzie zawierało aktualizacje, które należy wdrożyć w późniejszym okresie. Konserwacja,
konserwacja, konserwacja.
Może ostatnio oglądałem zbyt wiele programów typu „zrób to sam”, ale jestem miłośnikiem
domów z wbudowanymi składnikami. Takie elementy są zasadniczo meblami trwale zintegrowa-
nymi ze ścianami, narożnikami lub innymi miejscami. Wnoszą wartość dodaną i znacznie
lepiej łączą się z całym domem niż te, które zostały złożone oddzielnie, a następnie przymo-
cowane do ściany w narożniku pokoju.
DirectAccess i Always On VPN są takimi wbudowanymi meblami. Znajdują się w systemie

operacyjnym. Gdy aplikacja ulegnie awarii, nie trzeba instalować żadnego oprogramowania,
w tym dodatkowego programu aktualizacyjnego lub instalacyjnego. Wszystko, czego potrzebują
DA i AOVPN, znajduje się już dziś w systemie Windows — Ty po prostu tego nie używasz.
238
Och, i są darmowe! W każdym razie wliczone w koszt licencji systemu Windows. Nie istnieje
żadna licencja CAL dla użytkownika ani bieżące koszty licencyjne związane z wdrażaniem
rozwiązań firmy Microsoft zarządzających zdalnym dostępem.
Jeśli używasz maszyn z systemem Windows 10, usługi Microsoft DirectAccess i Microsoft Al-
ways On VPN wyraźnie wygrywają w porównaniu z jakimkolwiek rozwiązaniem innych firm
służącym do połączeń VPN.
Problemy z hasłem i logowaniem w tradycyjnych

sieciach VPN
Jeśli kiedykolwiek pracowałeś w dziale pomocy technicznej w firmie korzystającej z połączeń VPN,
wiesz, co mam na myśli. Można wyróżnić szereg typowych rozmów telefonicznych związanych
z hasłami i dotyczących problemów, które zdarzają się w świecie VPN. Czasami użytkownik
zapomina hasła. Być może jego hasło wygasło i musi zostać zmienione. VPN nie radzi sobie
dobrze z tym scenariuszem. A może pracownik, będąc zalogowanym, zmienił przed wyjściem
z pracy hasło, które wcześniej wygasło, a teraz próbuje się zdalnie zalogować z laptopa, ale
komputer go nie uwierzytelnia.
Jakie jest rozwiązanie problemów z hasłem podczas połączenia VPN? Zresetuj hasło użyt-
kownika, a następnie każ mu się pojawić w biurze, aby mógł się zalogować na swoim laptopie.
Tak, tego rodzaju rozmowy telefoniczne wciąż odbywają się każdego dnia. Jest to przykry,
ale prawdziwy problem występujący w staromodnych sieciach VPN.
Czy mam jakieś dobre wieści? Nowe rozwiązania firmy Microsoft obsługujące zdalny dostęp nie
mają tego rodzaju problemów! Ponieważ usługi DA i AOVPN są częścią systemu operacyjnego,
obie mogą się uruchamiać za każdym razem, gdy Windows uzyskuje połączenie z siecią kom-
puterową. Dotyczy to także ekranu logowania! Nawet jeśli komputer wyświetla ekran logowania
lub ekran blokady pulpitu, a system oczekuje na podanie nazwy mojego użytkownika i hasła,
to w przypadku, gdy jestem podłączony do internetu, mam również działający tunel
DirectAccess lub tunel urządzeń Always On VPN. Oznacza to, że mogę aktywnie wykonywać
zadania związane z zarządzaniem hasłami. Jeśli moje hasło wygasa i muszę je zaktualizować,
taka operacja się powiedzie. Jeśli zapomniałem hasła i nie mogę się dostać do laptopa,
dzwonię do działu pomocy technicznej i proszę o zresetowanie hasła. Następnie poprzez
usługę DA lub AOVPN mogę, będąc w domu, natychmiast zalogować się do swojego laptopa
przy użyciu nowego hasła.
Ta funkcjonalność pozwala też na bezproblemowe logowanie się na komputerze za pomocą

nowych kont użytkowników. Czy kiedykolwiek logowałeś się do swojego laptopa przy użyciu
konta innego użytkownika w celu wykonania jakichś testów? Tak, również jest to możliwe
w przypadku usług DA i AOVPN. Na przykład siedzę sobie teraz w domu i muszę pomóc
jednemu ze sprzedawców rozwiązać problem z uprawnieniami do plików. Podejrzewam, że
ma to coś wspólnego z jego kontem użytkownika, dlatego chcę się nim zalogować na swoim
laptopie, aby wykonać testy. Problem polega na tym, że jego konto użytkownika nigdy wcześniej
nie było używane na moim laptopie. Gdybym użył usługi VPN, nie miałbym żadnych szans
239
— to nigdy nie zadziała. Dzięki usłudze DirectAccess jest to bułka z masłem! Po prostu się
wylogowuję, wpisuję nazwę innego użytkownika, jego hasło, i to wszystko. Jestem zalogowany,
siedząc w piżamie przed komputerem.
Należy pamiętać, że połączenia DirectAccess i VPN można uruchamiać na tym samym

serwerze dostępu zdalnego z systemem Windows Server 2019. Umożliwia to zarzą-
dzanie klientami połączonymi za pośrednictwem usług DA, AOVPN, a także tradycyj-
nych sieci VPN (jeśli masz urządzenia z systemem innym niż Windows 10, które muszą
uzyskać połączenie). Jeśli którakolwiek z tych technologii łączności udostępnia możliwości,
z których możesz skorzystać, użyj ich wszystkich!
Zapory z ograniczeniami portów

Oto jeden z innych typowych tematów związanych z siecią VPN i zgłaszanych pracownikom
pomocy technicznej: Nie mogę uzyskać połączenia do sieci VPN z tego hotelu. Niestety, więk-
szość protokołów używanych przez VPN do ustanawiania połączenia nie jest przyjazna dla
zapory sieciowej. Być może router w domu zezwala na cały ruch wychodzący, dlatego w przy-
padku połączenia internetowego wszystko jest w porządku i protokół VPN bardzo dobrze spełnia
swoją funkcję. Użyj jednak tego samego laptopa w kawiarni, hotelu lub na lotnisku, a VPN
nagle przestanie się łączyć i wyświetli dziwny błąd. Jest to zwykle spowodowane tym, że pu-
bliczne połączenia internetowe wykorzystują zaporę z ograniczeniami portów. Takie zapory
ograniczają dostęp wychodzący, często blokując takie protokoły, jak ICMP i UDP, co może prze-
szkadzać w nawiązywaniu połączeń VPN. W najtrudniejszych przypadkach udostępniają tylko
dwa porty wychodzące: TCP 80 dla ruchu HTTP i TCP 443 dla HTTPS. Wszystko inne jest
blokowane.
Czy nowsze technologie dostępu zdalnego będą umiały poprawnie nawiązać połączenie, gdy
znajdziesz się za zaporą sieciową ograniczającą porty?
Usługa DirectAccess została stworzona, aby z definicji obsłużyć taki scenariusz. Czy pamiętasz
trzy różne protokoły, których DA może użyć w celu uzyskania połączenia? Opcja rezerwowa
nosi nazwę IP-HTTPS i wykorzystuje ruch po porcie TCP 443. Tak więc DirectAccess, nawet
będąc za najpoważniejszymi zaporami sieciowymi, zazwyczaj łączy się automatycznie i bez
żadnego wahania.
Usługę Always On VPN zwykle się wdraża, mając na uwadze najlepsze wzorce postępowania
(tak właśnie powinno być), w tym priorytetyzację IKEv2 jako protokołu łączności VPN. Jednak
niektóre firmy wdrażają AOVPN tylko z protokołem IKEv2. W tym przypadku zapora sieciowa
ograniczająca porty przeszkadza w wykonywaniu połączeń VPN, ponieważ IKEv2 używa do
łączności portów UDP. Usługa AOVPN nie zadziała więc. Rozumiesz już, mam nadzieję, że
konfigurując usługę AOVPN, powinieneś się upewnić, czy podjąłeś niezbędne kroki, aby
uwzględnić również opcję SSTP VPN jako metodę awaryjną? Protokół SSTP używa także
portu TCP 443, dzięki czemu pakiety mogą zostać wysłane na zewnątrz nawet przez najbardziej
restrykcyjne zapory sieciowe.
240
Nadzwyczaj ważne!
Tunel urządzeń w przypadku usługi AOVPN może używać tylko protokołu IKEv2. Jeśli
znajdujesz się za zaporą ograniczającą porty i korzystasz z tunelu urządzeń, połączenie
nie zostanie nawiązane. Tunel użytkownika AOVPN jest jedynym, który może zadziałać
w trybie awaryjnym SSTP.
Niedawno analizowałem ten scenariusz, współpracując z firmą, która stała przed konieczno-
ścią wybrania usługi DirectAccess lub Always On VPN dla swoich zdalnych komputerów.
Było to przedsiębiorstwo zarządzające komputerami w wielu szpitalach i gabinetach lekar-
skich, które nie miały łączy WAN. Biura miały jednak dostęp do internetu, dlatego chcieli-
śmy automatycznie łączyć komputery z głównym centrum danych. Na początku analizy mieli-
śmy do wyboru usługi DirectAccess i Always On VPN. Podczas testów jednak odkryliśmy, że
wiele sieci szpitalnych ogranicza wychodzący ruch do internetu. Jedyną metodą, dzięki której
usługa DA mogła się połączyć, było wykorzystanie protokołu IP-HTTPS. W przypadku
AOVPN był to wyłącznie protokół SSTP. To nie problem, prawda? Otóż jednak problem istniał.
Okazuje się, że te zdalne stacje robocze są często traktowane jako kioski lub maszyny typu
walk-up, do których wielu różnych pracowników może w każdej chwili podejść i się zalogować.
Często oznacza to, że użytkownicy logują się na komputerach, których nigdy wcześniej nie
używali, więc system nie buforuje ich danych uwierzytelniających.
Być może podejrzewasz, że nie mieliśmy wyboru i w tym scenariuszu musieliśmy skorzystać
z DirectAccess. Usługa ta pozwala na uzyskanie połączenia już na etapie ekranu logowania,
nawet jeśli korzysta z awaryjnej metody IP-HTTPS. Z drugiej strony połączenie Always On VPN
może działać na ekranie logowania jedynie przy zastosowaniu protokołu IKEv2, wymaga go
bowiem tunel urządzeń. Ponieważ IKEv2 korzysta z protokołu UDP, który został zablokowany
przez zaporę, jedynym sposobem na uzyskanie połączenia AOVPN było użycie SSTP. Połą-
czenie nie mogło jednak zostać nawiązane aż do momentu uruchomienia tunelu użytkownika,
co nastąpiło dopiero po zalogowaniu się użytkownika na maszynie. Ten niezwykle interesujący
przypadek użycia usług łączności w świecie rzeczywistym rzucił nieco światła na proces de-
cyzyjny, który będziesz musiał wziąć pod uwagę we własnym środowisku.
Ręczne rozłączanie
Jeśli wciąż nie jesteś przekonany, że tradycyjne sieci VPN są już przestarzałe, weźmy pod
uwagę jeszcze jedną kwestię. Gdy korzystasz z sieci VPN, które wymagają ręcznego uruchomie-
nia połączenia, to od samego użytkownika zależy, czy jego komputer będzie właściwie zarządza-
ny i aktualizowany. Możesz oczywiście mieć zautomatyzowane systemy takie, jak WSUS,
SCCM i zasady grupy, które wykonują odpowiednie działania za Ciebie. Gdy jednak laptop
znajduje się poza firmą i jej siecią LAN, te systemy zarządzania mogą wykonywać swoje zadania
tylko wtedy, gdy użytkownik zdecyduje się na ustanowienie połączenia VPN. Laptop pracownika
może spędzić tygodnie poza siecią korporacyjną, łącząc się z dziesiątkami niepewnych
punktów dostępowych, na przykład w trakcie podróży statkiem wycieczkowym po Karaibach.
Po tygodniach spędzonych na zabawach i korzystaniu z usług Netflix użytkownik połączy się
241
ponownie z siecią LAN lub VPN, aby trochę popracować. Okaże się wówczas, że jego maszyna
bardzo długo nie korzystała z firmowych zasad bezpieczeństwa i w międzyczasie nagroma-
dziła wiele różnego rodzaju zabawnych i kreatywnych programów, z którymi teraz musisz
walczyć.
Nie jest tak w przypadku narzędzi zdalnego dostępu firmy Microsoft! Zapewnienie opcji auto-
matycznego połączenia, takiej jak Always On VPN lub DirectAccess, oznacza, że laptop byłby
podłączony i odbierał wszystkie zasady bezpieczeństwa i poprawki również podczas długiego
urlopu pracownika.
Co więcej, na komputerze z usługą DirectAccess użytkownik nie może zablokować swoich

tuneli połączeń, nawet jeśli tego chce. Masz co prawda możliwość udostępnienia mu przycisku
Disconnect (Rozłącz), ale jest to niejako oszukiwanie użytkownika, któremu może się wydawać,
że połączenie DirectAccess zostanie zupełnie przerwane. W rzeczywistości tunel IPsec
nadal działa w tle, umożliwiając wykonywanie zadań zarządzających.
Natywne funkcje równoważenia obciążenia

Mówiąc krótko, zwycięzcą w tym przypadku jest usługa DirectAccess. Konsola zarządzania
dostępem zdalnym w systemie Windows Server 2019 ma wbudowane możliwości zarządzania
wieloma serwerami DA i ich konfigurowania. Bezpośrednio z jej poziomu możesz zainstalować
wiele serwerów DirectAccess, umieścić je w grupach obsługujących równoważenie obcią-
żenia oraz zapewnić odpowiedni poziom redundancji i uniwersalności. Nie potrzebujesz do
tego dodatkowego sprzętu lub tradycyjnych systemów równoważenia obciążenia. Możesz nawet
skonfigurować funkcję o nazwie DirectAccess multisite, w której użyjesz serwerów DirectAccess
znajdujących się w różnych lokalizacjach geograficznych, co umożliwi uzyskanie globalnej
ochrony. Prawie każda firma, która korzysta z DirectAccess, konfiguruje redundantne środowi-
sko, co zapewnia równoważenie obciążenia wewnątrz lokacji lub wielowitrynowość, a czasem
pozwalając na jednoczesne użycie obu tych funkcji, ponieważ są one wbudowane i łatwe do
skonfigurowania.
Niestety, te możliwości nie zostały (w każdym razie do tej pory) przeniesione do świata Micro-
soft VPN. Bez względu na to, czy umożliwiasz łączenie systemów Windows 7 za pomocą trady-
cyjnej sieci VPN, czy też nakazujesz klientom systemu Windows 10 wykonywanie połączeń
za pomocą Always On VPN, infrastruktura zaplecza RRAS VPN jest taka sama i nie ma wbudo-
wanej opcji obsługi wielu serwerów lub witryn. Taka funkcjonalność jest oczywiście możliwa
po uczynieniu danego systemu VPN redundantnym. Wymagałoby to jednak samodzielnego
skonfigurowania go za pomocą zewnętrznych mechanizmów równoważenia obciążenia,
a często użycia globalnych mechanizmów równoważenia obciążenia witryny lub serwera w celu
umożliwienia poprawnego przesyłania ruchu sieciowego.
To dobrze, że każdy administrator, który w przeszłości konfigurował sieci VPN z dowolnym

typem równoważeniem obciążenia, zna odpowiedni proces i jest w stanie łatwo zdefiniować
oczekiwaną funkcjonalność. Czynnikiem hamującym wdrażanie takiej funkcjonalności w przy-
padku niewielkich firm jest jednak to, że dysponują one ograniczoną liczbą serwerów oraz
242
sprzętu sieciowego i niewystarczającym doświadczeniem z dziedziny IT. Podsumowując —

dodatkowe możliwości dostępne w konsoli usługi DirectAccess sprawiają, że może być najlep-
szym rozwiązaniem VPN pod względem budowania infrastruktury dostępu zdalnego odpor-
nej na awarie.
Dystrybucja konfiguracji klienta

Ostatnią ważną kwestią, którą należy wziąć pod uwagę podczas podejmowania decyzji, jaki
system wybrać w celu uzyskania dostępu zdalnego, jest metoda, za pomocą której ustawie-
nia klienta są przekazywane do odpowiednich komputerów.
 Sieci VPN innych firm: omówiliśmy już wady stosowania aplikacji stworzonych
przez zewnętrznych dostawców VPN. Jeśli zamiast nich możesz użyć czegoś już
wbudowanego w system operacyjny Windows, wybór wydaje się oczywisty.
 Always On VPN: zalecanym sposobem wdrażania ustawień AOVPN na
komputerach klienckich jest zastosowanie rozwiązania MDM, a mianowicie
systemów SCCM lub Intune. Jeśli używasz jednego z nich, wdrożenie ustawień
AOVPN wśród pracowników będzie bardzo proste. Jeśli nie, nadal jest to możliwe,
ale nie jest to prosty proces.
 DirectAccess: myślę, że metoda zastosowana w usłudze DA do dystrybucji ustawień
klienta jest zdecydowanie najłatwiejsza w obsłudze i najbardziej uniwersalna.
Należy pamiętać, że DirectAccess dotyczy tylko systemów wykorzystujących
domenę. Ponieważ należy oczekiwać, że wszyscy klienci zostaną dołączeni
do domeny, możesz dystrybuować ustawienia usługi DirectAccess za pośrednictwem
zasad grupy, które istnieją w każdej infrastrukturze opartej na produktach
firmy Microsoft.
Mam szczerą nadzieję, że w przyszłości podczas wdrażania konfiguracji Always On VPN

będzie również dostępna opcja dystrybucji poprzez zasady grupy. Jestem całkowicie pewien,
że gdyby taka opcja została dodana, od razu stałaby się najpopularniejszym sposobem defi-
niowania ustawień AOVPN.
Oto podsumowanie całego podrozdziału. Jeśli porównuje się usługę DirectAccess z tradycyjny-
mi, ręcznie uruchamianymi sieciami VPN, ta pierwsza bez problemu wygrywa. Naprawdę nie
ma żadnej wątpliwości. Gdy jednak mamy też do dyspozycji drugą usługę, Always On VPN,
możemy stwierdzić, że każda z nich ma swoje zalety i wady. Obie zapewniają te same wyniki
przy użyciu różnych metod. Jak dotąd wydaje się, że w przypadku większości klientów de-
cydującym czynnikiem są przede wszystkim możliwości wdrażania po stronie użytkownika nie-
zależne od dostępu do systemu MDM, a także wymagania dotyczące użycia tunelu urządze-
nia. Celem firmy Microsoft jest to, by usługa AOVPN udostępniała te same funkcje, co
DirectAccess. Taka funkcjonalność coraz bardziej staje się rzeczywistością. Always On VPN
ma również niektóre zaawansowane funkcje uwierzytelniania, których nie ma DirectAccess,
takie jak integracja z systemami Windows Hello for Business lub Azure MFA.
243
Web Application Proxy (WAP)

DirectAccess i VPN są świetnymi technologiami zdalnego dostępu, a połączenie ich obu może
zapewnić kompletne rozwiązanie dla Twojej organizacji, bez żadnych kosztów lub użycia
produktu innej firmy. Co więcej, w systemie Windows Server 2019 dostępny jest jeszcze je-
den składnik roli dostępu zdalnego. Ten trzeci element to Web Application Proxy (Serwer
proxy aplikacji sieci Web — WAP). Zasadniczo jest to mechanizm odwrotnego proxy, który
umożliwia używanie niektórych aplikacji HTTP i HTTPS dostępnych w sieci firmowej oraz bez-
pieczne publikowanie ich w internecie. Jeśli w ciągu ostatnich kilku lat używałeś technologii
firmy Microsoft w przestrzeni sieci granicznej, prawdopodobnie rozpoznasz produkt o na-
zwie Forefront Unified Access Gateway (UAG), który ma podobną funkcjonalność. System
UAG był kompleksowym rozwiązaniem typu SSLVPN, również zaprojektowanym do publi-
kowania wewnętrznych aplikacji w internecie za pośrednictwem protokołu SSL. Był znacznie
potężniejszy niż zwykły serwer odwrotnego proxy i zawierał takie elementy, jak wstępne uwie-
rzytelnianie, SSTP VPN i bramę RDS. Sama usługa DirectAccess mogła nawet działać po-
przez UAG.
Jeśli wszyscy Twoi pracownicy mobilni mają dostęp do sieci DirectAccess lub VPN, praw-
dopodobnie nie używasz systemu WAP. Jednak wraz z rosnącym wykorzystaniem chmury
użytkownicy często oczekują, że będą mogli otworzyć przeglądarkę internetową z dowolnego
komputera i miejsca oraz uzyskać dostęp do niektórych swoich aplikacji. Dostęp do dokumentów
jest obecnie często zapewniany przez usługi sieciowe, takie jak SharePoint. Dostęp do poczty
e-mail można uzyskać zdalnie z dowolnego komputera przy użyciu systemu Outlook Web Access.
Użycie tylu aplikacji i danych jest możliwe tylko za pośrednictwem przeglądarki internetowej,
która pozwala pracownikom na dostęp do nich bez konieczności tworzenia pełnego tunelu
korporacyjnego, takiego jak VPN. Więc jaki jest rzeczywisty powód stosowania systemu WAP?
To komputery domowe, których nie chcesz podłączać do sieci VPN. W ten sposób nie musisz się
martwić tak bardzo o poziom bezpieczeństwa i stan komputerów domowych lub innych,
które należą do użytkowników, ponieważ jedynym programem, który wchodzi w interakcje
z Twoją firmą, jest przeglądarka internetowa. Ogranicza to potencjał ataków na Twoją sieć pro-
wadzonych z tych komputerów. Jak widać, technologia taka jak WAP z pewnością ma swoje
miejsce na rynku systemów dostępu zdalnego.
Mam nadzieję, że z czasem usługa WAP będzie coraz lepsza, co pozwoli na faktyczne zastąpienie
systemu UAG, który działał w środowisku Windows Server 2008 R2 i został oficjalnie wycofany
jako produkt firmy Microsoft. Rozwiązaniem najbardziej podobnym do UAG jest rola WAP.
Nie jest jeszcze tak uniwersalna, ale programiści firmy Microsoft pracują nad jej ulepszeniem.
Obecnie usługa WAP pozwala uzyskać dostęp do prostych aplikacji internetowych. Możesz także
zapewnić dostęp do zaawansowanych klientów korzystających z podstawowego uwierzytelniania
HTTP, takich jak Exchange ActiveSync. Uwzględniono również możliwość publikowania
danych na klientach korzystających z protokołu MSOFBA, na przykład w sytuacji, gdy użytkow-
nicy próbują pobrać dane firmowe z aplikacji Word lub Excel uruchomionych na kompute-
rze lokalnym.
244
Usługa WAP może działać jak odwrotne proxy i umożliwiać zdalny dostęp do takich systemów
jak środowiska Exchange i SharePoint. Nie jest to drobiazg, ponieważ są to technologie, z któ-
rych korzysta prawie każdy. Z pewnością więc wdrożenie usługi WAP może być korzystne,
gdy celem jest uzyskanie bezpiecznego dostępu do tych zasobów. Jest to z pewnością lepsze
niż skonfigurowanie translacji NAT bezpośrednio do serwera Exchange.
WAP jako serwer proxy AD FS

Innym przydatnym sposobem korzystania z serwera WAP jest konfigurowanie usług Active
Directory Federation Services (Usługi federacyjne Active Directory — AD FS) w sieci (prawdo-
podobnie jest to najpopularniejszy obecnie przykład użycia WAP). AD FS jest technologią
zaprojektowaną w celu umożliwienia jednokrotnego logowania użytkownikom i wykonywa-
nia operacji federacji z innymi firmami, a więc zarządza ona ruchem przychodzącym z in-
ternetu do sieci wewnętrznej. W przeszłości w systemie Windows Server istniał komponent
roli, który towarzyszył AD FS i był zwany AD FS Proxy. W najnowszych wersjach usług
AD FS ta osobna rola już nie istnieje i została zastąpiona składnikiem Web Application
Proxy zawartym w roli dostępu zdalnego. Dzięki temu rozwiązanie dostępu zdalnego jest bar-
dziej jednorodne i umożliwia przekazywanie ruchu przychodzącego dotyczącego AD FS przez
oficjalny serwer dostępu zdalnego zamiast użycia oddzielnego serwera AD FS Proxy. Każdy, kto
w swoim środowisku chce wdrożyć rolę AD FS skierowaną na zewnątrz, prawdopodobnie
będzie musiał w pewnym momencie zainstalować również usługę WAP.
Wymagania dla WAP

Niestety, możliwość korzystania z serwera proxy aplikacji sieci Web wiąże się z dość kłopotliwym
wymogiem: w środowisku (nawet w celach testowych) musi zostać zainstalowana rola AD FS,
ponieważ jest w niej przechowywana konfiguracja WAP. Żadna z informacji konfiguracyjnych
WAP nie jest przechowywana na samym serwerze dostępu zdalnego, co sprawia, że jest on lekki
i można go łatwo przenosić, zmieniać lub rozbudowywać. Minusem tego rozwiązania jest to,
że w środowisku musi zostać uruchomiony system AD FS, by usługa WAP uzyskała miejsce
do przechowywania określonych informacji konfiguracyjnych.
Chociaż ścisła integracja z rolą AD FS oznacza, że uzyskujemy lepsze opcje uwierzytelniania,

a użytkownicy mogą korzystać z jednokrotnego logowania AD FS do swoich aplikacji publi-
kowanych za pośrednictwem usługi WAP, jak dotąd w mniejszych przedsiębiorstwach wdrożenie
tej roli przebiegało opornie. Wiele firm jeszcze z niej nie korzysta, więc jeśli jedynym powodem,
dla którego należałoby ją wdrożyć, jest potrzeba opublikowania kilku aplikacji w internecie,
może się okazać, że nie będzie wystarczającej chęci do zainwestowania odpowiedniego czasu
i wysiłku, aby się to stało możliwe.
Jeśli jesteś zainteresowany korzystaniem z usługi WAP, a zatem uwzględniasz wymagania do-
tyczące roli AD FS, musisz pamiętać o tym, że można ją wykorzystać do innych celów. W rze-
czywistości jedną z najczęściej obecnie wykorzystywanych nowości jest integracja ze środowi-
245
skiem Office 365. Jeśli planujesz użyć systemu Office 365 w swoim środowisku, AD FS będzie
doskonałym narzędziem, które może w tym przypadku ulepszyć możliwości uwierzytelniania.
Najnowsze ulepszenia WAP

Serwer proxy aplikacji sieci Web został wprowadzony w systemie Server 2012 R2, a w Win-
dows Server 2016 został znacząco ulepszony. Od tamtej pory nie nastąpiły w nim żadne
większe modyfikacje, ale mimo to zaprezentuję zmiany, które mają wpływ na podstawowe
funkcje, aby udowodnić, że rozwój tego narzędzia wciąż trwa. Oto niektóre z ulepszeń, któ-
re z czasem w nim wprowadzono.
Uwierzytelnienie wstępne dla autoryzacji HTTP Basic

Istnieją dwa różne sposoby uwierzytelniania użytkowników w aplikacjach publikowanych
przez serwer proxy aplikacji sieci Web. Są nimi uwierzytelnianie wstępne i uwierzytelnianie
przekazywane. Publikowanie aplikacji z uwierzytelnieniem wstępnym oznacza, że użytkow-
nicy będą musieli się zatrzymać na interfejsie usług AD FS, aby się uwierzytelnić, zanim
zostaną dopuszczeni do samej aplikacji internetowej. Moim zdaniem uwierzytelnianie
wstępne jest kluczowym elementem każdego odwrotnego proxy i musiałbym być naprawdę
zdesperowany, aby podjąć decyzję o opublikowaniu aplikacji, która nie wymaga takiego uwie-
rzytelnienia. Jednak mamy drugą możliwość, czyli uwierzytelnianie przekazywane, które
działa w następujący sposób. Gdy udostępniasz aplikację i wybierasz uwierzytelnianie prze-
kazywane, usługa WAP po prostu przesyła pakiety z internetu do serwera aplikacji. Użytkownicy
mogą uzyskać dostęp do aplikacji WWW bez potrzeby uwierzytelnienia, więc teoretycznie
każdy może wyświetlić jej główną stronę. Na tej stronie aplikacja będzie najprawdopodobniej
wymagać uwierzytelnienia użytkownika, jednakże w tym przypadku nie będzie istnieć żadna
ochrona przed atakiem typu man-in-the-middle, ponieważ aplikacja jest dostępna publicznie.
Ja nie zalecam używania takiej opcji.
Wiesz już, że obecnie usługa WAP może wstępnie uwierzytelniać aplikacje internetowe,
jednak jej pierwotna wersja nie mogła wykonywać żadnych wstępnych uwierzytelnień w aplika-
cjach typu HTTP Basic, na przykład gdy firma chciała opublikować dostęp do systemu
Exchange ActiveSync. Ta niezdolność powodowała, że usługa ActiveSync była zbyt narażona
na ataki z zewnątrz i stanowiła zagrożenie dla bezpieczeństwa. Na szczęście w systemie Win-
dows Server 2016 zaszły pozytywne zmiany — możesz teraz wstępnie uwierzytelniać stru-
mienie ruchu, które używają autoryzacji HTTP Basic.
Przekierowanie HTTP na HTTPS

Użytkownicy nie lubią tracić czasu z powodu tego, że podczas uzyskiwania dostępu do aplikacji
należy przed adresem URL wpisać ciąg znaków HTTPS://. Woleliby raczej pamiętać tylko
sam adres email.contoso.com. Niezdolność usługi WAP do przekierowania ruchu HTTP na
246
HTTPS była uciążliwa i utrudniała jej wdrażanie, ale sytuacja już się zmieniła. Serwer proxy
aplikacji sieci Web umożliwia usłudze WAP przekierowanie ruchu HTTP na HTTPS, co
oznacza, że użytkownicy nie muszą już wpisywać słowa HTTPS w pasku adresu przeglądarki.
Mogą po prostu podać nazwę DNS witryny i pozwolić usłudze WAP obsługiwać translację
danych.
Adresy IP klientów przekazywane do aplikacji

W świecie odwrotnego proxy i usługi SSLVPN uruchamiamy czasami aplikacje, które wymagają
znajomości lokalnego adresu IP klienta. Chociaż to wymaganie nie zdarza się zbyt często i zwy-
kle dotyczy starszych aplikacji, nadal istnieje. Gdy aplikacja po stronie serwera musi wiedzieć,
jaki jest adres IP klienta, stanowi to duże wyzwanie dla rozwiązań używających odwrotnego
proxy. Gdy informacje od użytkownika są przesyłane przez system WAP lub inny serwer typu
odwrotne proxy, rozwiązanie działa jak translacja NAT, która zmienia informację o źródłowym
adresie IP w pakietach danych. Serwer aplikacji nie może więc określić lokalnego adresu IP
klienta i pojawiają się kłopoty. Serwer proxy aplikacji sieci Web ma obecnie możliwość propago-
wania adresu IP po stronie klienta do serwera aplikacji, co łagodzi ten problem.
Dostęp do serwera Remote Desktop Gateway

Produkt UAG był powszechnie wykorzystywany między innymi do uzyskiwania dostępu do
usług pulpitu zdalnego. Był on zasadniczo bramą pulpitu zdalnego, która pozwalała na do-
stęp do serwerów RDSH, wykonywanie indywidualnych połączeń RDP z komputerami stacjo-
narnymi, na przykład podczas implementacji VDI, a nawet używanie aplikacji RemoteApp.
Niestety, usługa WAP nie ma jeszcze takiej funkcjonalności nawet w najnowszej wersji, jednakże
pewne zmiany zostały wprowadzone, co na pewno oznacza ruch we właściwym kierunku.
Ulepszenia usługi WAP i pulpitu zdalnego pozwalają obecnie na uzyskiwanie dostępu do samego
serwera Remote Desktop Gateway. Tradycyjnie brama pulpitu zdalnego jest umieszczana na
brzegu sieci i łączy użytkowników zewnętrznych z wewnętrznymi serwerami pulpitu zdal-
nego. Umieszczenie systemu WAP przed bramą pulpitu zdalnego umożliwia uzyskanie lepszego
uwierzytelniania wstępnego dla usług pulpitu zdalnego i zwiększa separację między sieciami
wewnętrznymi a zewnętrznymi.
Trzymam kciuki za tym, aby te systemy wciąż były rozwijane, a usługa WAP mogła w przyszłości
standardowo obsługiwać protokoły takie jak pulpit zdalny nawet bez potrzeby korzystania z bramy
Remote Desktop Gateway.
Ulepszona konsola administracyjna

Pierwotną wersją usługi WAP w systemie Windows Server 2012 R2 najlepiej zarządzać za
pomocą programu PowerShell. Jeślibyś chciał, z pewnością nadal mógłbyś używać powłoki
PowerShell do tworzenia reguł publikowania. Konsola zarządzania dostępem zdalnym została
jednak w międzyczasie ulepszona, ponieważ bierze teraz pod uwagę serwer proxy aplikacji
247
sieci Web. Zanim otworzysz samą konsolę, upewnij się, że odpowiednie pole wyboru zostało
zaznaczone podczas instalacji roli dostępu zdalnego. Jeśli nie wybrałeś opcji Web Application
Proxy (Serwer proxy aplikacji sieci Web) w trakcie instalacji tej roli, wróć do funkcji dodawania
i usuwania ról w Menedżerze serwera, aby dodać usługę WAP do serwera:
Należy pamiętać, że chociaż serwer proxy aplikacji sieci Web jest składnikiem tej samej
roli dostępu zdalnego, która zawiera połączenia DirectAccess i VPN, nie zaleca się urucha-
miania usługi WAP jednocześnie z DA i VPN na tym samym serwerze. Jak już wiesz, możesz
zarządzać połączeniami DA i VPN na jednym serwerze dostępu zdalnego. W przypadku
usługi WAP powinien to być jednak samodzielny komponent. Nie uruchamiaj jej na serwe-
rze DA lub VPN, a także nie instaluj połączeń DA i VPN na serwerze WAP.
Gdy do naszego systemu dodaliśmy już serwer proxy aplikacji sieci Web, możesz otworzyć
konsolę zarządzania dostępem zdalnym i zobaczyć go na liście w sekcji Configuration (Konfigu-
racja). W tym miejscu uruchomisz kreatora Web Application Proxy Configuration Wizard
(Kreator konfiguracji serwera proxy aplikacji sieci Web) i będziesz konfigurować serwer AD FS,
certyfikaty, których zamierzasz użyć, a także inne parametry wymagane dla roli:
248
Podsumowanie
Obecna technologia pozwala na to, by firma umożliwiała swoim pracownikom dostęp do ich za-
sobów z dowolnego miejsca. Coraz więcej organizacji zatrudnia pracowników zdalnych i dlatego
wymaga bezpiecznego, stabilnego i wydajnego sposobu na zapewnienie im dostępu do danych
i aplikacji firmowych. Rola dostępu zdalnego w systemie Windows Server 2019 została za-
projektowana właśnie w tym celu. Dzięki niej możemy skorzystać z trzech różnych sposobów
zdalnego dostępu do zasobów korporacyjnych. Działy IT nigdy wcześniej nie miały tak wielu
technologii zdalnego dostępu zawartych w systemie operacyjnym Windows i dostępnych na
wyciągnięcie ręki. Jeśli nadal używasz systemu VPN innej firmy lub starszego typu, zdecydowa-
nie powinieneś zapoznać się z nowymi możliwościami i dowiedzieć, w jaki sposób mogą one
wesprzeć Twoją firmę.
DirectAccess i Always On VPN to szczególnie imponujące i ważne opcje nawiązywania połączeń

— nowy sposób podejścia do zdalnego dostępu. Automatyczne połączenia umożliwiają pracę
maszynom działającym bez przerw, które mogą być naprawiane i aktualizowane, ponieważ są
zawsze podłączone do serwerów zarządzających. Możesz jednocześnie zwiększyć wydajność
pracy użytkowników i poprawić bezpieczeństwo sieci. Te dwie frazy są zwykle oksymoronami
w świecie IT, jednakże obecnie dzięki usłudze zdalnego dostępu firmy Microsoft trzymają
się za ręce i wspólnie śpiewają piosenki.
W następnym rozdziale przyjrzymy się niektórym funkcjom zabezpieczeń wbudowanym w sys-

temy operacyjne Windows Server 2019 oraz sposobom hardeningu serwerów w celu zapewnie-
nia jeszcze większego poziomu bezpieczeństwa niż ten, który zapewnia domyślna konfiguracja.
Pytania
1. Co oznacza skrót AOVPN?
2. Jakie są dwa podstawowe protokoły używane podczas łączenia klientów za pomocą
usługi AOVPN?
3. W której wersji systemu Windows 10 udostępniono usługę AOVPN?
4. W jakim szczególnym przypadku klient AOVPN musiałby zostać dołączony
do Twojej domeny?
5. Czy usługa DirectAccess wymaga, aby wewnętrzna sieć firmowa działała
w wersji IPv6?
6. Jak nazywa się wewnętrzna strona internetowa, z którą łączą się klienci
DirectAccess w celu ustalenia, czy znajdują się w sieci korporacyjnej?
7. Jaką rolę odgrywa serwer WAP w środowisku federacyjnym?
249
250
7
Hardening
i bezpieczeństwo
Trzy i osiem dziesiątych miliona dolarów. Szacunek dla każdego, kto przeczytał to zdanie
głosem Doktora Zło. Jeśli nie masz pojęcia, o czym piszę, być może miałeś beztroskie dzie-
ciństwo. Żarty na bok — ta liczba ma duże znaczenie dla bezpieczeństwa IT. Dlaczego? Ponie-
waż 3,8 miliona dolarów to średni koszt naruszenia bezpieczeństwa danych w amerykańskiej
firmie. Tego rodzaju przerażające informacje usłyszałem na konferencji firmy Microsoft
w Redmond kilka lat temu, a z roku na rok koszty rosną. A może chciałbyś się zapoznać się
z innym rodzajem statystyki, której można by użyć, aby uzyskać zgodę na zwiększenie budżetu
bezpieczeństwa? Istnieją różne analizy, ale ogólnie rzecz biorąc, średnia liczba dni, w których
osoba atakująca przebywa w Twojej sieci (czas spędzony na przeglądaniu plików i infrastruktury
przed wykryciem i wyeliminowaniem intruza), wynosi około 200. Pomyśl o tym — 200 dni!
To większa część roku, spędzona ciekawie w Twoim środowisku, zanim się zorientujesz! Co
zazwyczaj atakujący robią w ciągu tych 200 dni? Krok po kroku wysyłają wszystkie dane tylnymi
drzwiami. Następna liczba to 76% — procent włamań do sieci, które mają miejsce w wyniku
naruszenia danych uwierzytelniających użytkownika. Co więcej, identyfikacja tych ataków
staje się coraz trudniejsza, ponieważ osoby atakujące korzystają z legalnych narzędzi infor-
matycznych, aby zdobyć to, czego chcą. Na przykład mogą używać inżynierii społecznej, aby
zdobyć zaufanie któregoś z pracowników i następnie wykorzystać je w celu zainstalowania na-
rzędzia zdalnego dostępu na jego komputerze roboczym. Po co stosować złośliwe oprogramo-
wanie, skoro można użyć osoby, do której wszyscy mają zaufanie i która nie będzie alarmować
systemów wykrywania włamań? Dla mnie ma to sens.
Bezpieczeństwo danych, bezpieczeństwo sieci, bezpieczeństwo danych uwierzytelniających

— wszystko to coraz trudniej osiągnąć, ale zawsze pojawiają się nowe narzędzia i technologie,
które mogą pomóc w walce ze złymi ludźmi. Windows Server 2019 to najbezpieczniejszy
system operacyjny wyprodukowany przez firmę Microsoft. W tym rozdziale omówimy niektóre
zawarte w nim funkcje, dzięki którym to stwierdzenie jest prawdziwe:
 Windows Defender Advanced Threat Protection.

 Zapora systemu Windows Defender — bez żartów.
 Technologie szyfrowania.
 Hasła zabronione.
 Zaawansowana analiza zagrożeń.
 Najważniejsze wskazówki dotyczące ogólnego bezpieczeństwa.
Windows Defender Advanced

Threat Protection
Program Windows Defender działa od wielu lat, ale jego terminologia i możliwości rozwi-
nęły się w ostatnich kilku wydaniach systemu operacyjnego. Początkowo działał w systemie
Windows 8 jako darmowy, wbudowany produkt antywirusowy i nie był wtedy traktowany
zbyt poważnie. Jednak szybko rozwinął się i obecnie rzadko spotyka się komputer z systemem
Windows 10, na którym wyłączono usługę Defender Antivirus (AV) lub zaporę sieciową.
Narzędzia te są zawarte w systemie operacyjnym i są domyślnie włączone, w wyniku czego
poziom integracji i czas reakcji są znacznie lepsze, niż zapewniają aplikacje dostawców ze-
wnętrznych. Nie pamiętam już, ile razy analizowałem wycieki pamięci i losowe restarty serwe-
rów z powodu źle działającego oprogramowania antywirusowego innej firmy, co w dzisiejszym
świecie jest niedopuszczalne. Niektórzy nadal uważają, że funkcje antywirusowe aplikacji
Defender są niewystarczające — prawdopodobnie tylko dlatego, że są bezpłatne. Ja jednak
twierdzę, że ten program jest solidny i dobrze zintegrowany z samym systemem Windows.
Chciałbym jeszcze wziąć udział w spotkaniu społeczności związanej z produktem Windows
Defender.
Nawet nowszy, bardziej zaawansowany program Windows Defender Advanced Threat Protec-
tion (ATP) to tak naprawdę cała rodzina produktów i systemów, które współpracują ze sobą
w celu ochrony Twoich maszyn ze środowiskiem Windows. Ochrona przed wirusami i atakami
typu malware to tylko jedna z możliwości. Wbudowany program antywirusowy nadal jest
całkiem nowym pomysłem, jeśli chodzi o rodzinę systemów Windows Server. Pierwszym serwe-
rowym systemem operacyjnym, który miał wbudowany antywirusowy program Defender,
był Server 2016. Podejrzewam, że obecnie większość produkcyjnych serwerów działających
w firmach na całym świecie wciąż zawiera system Server 2012 R2, dlatego ulepszenie programu
Defender w wersji Server 2019 to kolejny powód, aby już dziś rozpocząć planowanie migracji.
W tej książce nie mamy wystarczającej ilości miejsca, aby przeanalizować każdy aspekt produktu
Windows Defender ATP, który jest wciąż udoskonalany. Omówimy niektóre jego interfejsy,
a także pokażę, jak należy korzystać z najczęściej używanych składników, które nie wymagają
stosowania zasad grupy. Zaprezentuję również niektóre bardziej zaawansowane funkcje, dzięki
czemu będziesz mógł je dokładniej przeanalizować w wolnej chwili.
252
Rozdział 7. • Hardening i bezpieczeństwo
Instalacja programu Windows Defender AV

Okazuje się, że wszystko zostało już zrobione! Program Windows Defender jest domyślnie
instalowany w systemie Windows Server 2019. Ponadto (chyba że to zmieniłeś) automatycznie
chroni Twój system natychmiast po uruchomieniu systemu operacyjnego. Sprawdź sam —
jeśli otworzysz Menedżera serwera i wybierzesz opcję Add roles and features (Dodaj role i funkcje),
będziesz mógł kliknąć odnośnik Funkcje (Features) i zobaczyć, że pole wyboru obok produktu
Windows Defender Antivirus jest już zaznaczone:
Jeśli z jakiegoś powodu to pole nie zostało zaznaczone, należy to zrobić, aby zainstalować
produkt Windows Defender Antivirus.
Wykorzystanie interfejsu użytkownika

Interfejs zestawu narzędzi Windows Defender jest taki sam jak w najnowszych wersjach sys-
temu Windows 10. Jeśli jednak się z nim jeszcze nie zapoznałeś, zaraz to zrobisz. Uruchom
opcję Settings (Ustawienia) z menu Start, a następnie kliknij łącze Update & Security (Aktualizacja
i zabezpieczenia). Po wejściu do nowej sekcji po lewej stronie okna zobaczysz opcję Windows
Security (Zabezpieczenia Windows). W tym miejscu możesz mieć dostęp do ogólnego widoku
różnych komponentów systemu Defender, które współpracują ze sobą w celu ochrony Twojego
systemu.
Pamiętaj, że nie musiałeś nic robić, aby włączyć którąkolwiek z tych funkcji — są one gotowe
do użycia (zobacz na zrzucie ekranu na następnej stronie).
Kliknięcie któregokolwiek z odnośników w grupie Protection areas (Obszary ochrony) spowoduje

wyświetlenie bardziej szczegółowych informacji, a także wielu opcji włączania i wyłączania
poszczególnych zabezpieczeń. Na przykład, jeśli klikniesz opcję Virus & threat protection
(Ochrona przed wirusami i zagrożeniami), zobaczysz podsumowanie informacji o aplikacji De-
fender AV, datę aktualizacji plików definicji wirusów, nazwę obecnie skanowanego pliku itd. Klik-
nięcie łącza o nazwie Manage settings (Zarządzaj ustawieniami) pozwala na wyłączenie usługi
Defender AV, jeśli kiedykolwiek zajdzie taka potrzeba, a także umożliwia wyświetlenie
253
wielu innych opcji, które można włączyć lub wyłączyć. Na następnej stronie zaprezentowano zrzut
ekranu z kilkoma ustawieniami dostępnymi w aplikacji Defender AV. Zdecydowałem się po-
kazać właśnie te trzy ustawienia, ponieważ są one związane z innym zagadnieniem, które
wkrótce omówimy, gdy będziemy analizować zaawansowaną ochronę przed zagrożeniami
w programie Windows Defender.
Wyłączanie usługi Windows Defender

Wiesz już, że usługa Defender AV jest domyślnie włączona, podobnie jak wiele innych składni-
ków, które tworzą rodzinę produktów Windows Defender. Usunięcie zaznaczenia pierwszej opcji
pokazanej na powyższym zrzucie ekranu tymczasowo wyłącza oprogramowanie antywirusowe.
Oprócz tego masz dwie możliwości, jeśli jesteś absolutnie pewien, że nie chcesz używać
usługi Defender AV, ponieważ stosujesz własne oprogramowanie antywirusowe, za które już
zapłaciłeś.
Po pierwsze, aplikacja Defender AV została zaprojektowana w taki sposób, aby się automa-
tycznie wyłączała w przypadku zainstalowania innego programu antywirusowego. Najprawdo-
podobniej wystarczy zainstalować narzędzie antywirusowe firmy zewnętrznej, a po restarcie
serwera program Defender AV przestanie działać i zezwoli na uruchomienie tego innego
produktu, aby nie powodować konfliktów. Jest to ważne, ponieważ wielu informatyków nie
zdaje sobie sprawy z tego, że kilka programów antywirusowych działających w jednym systemie
to, ogólnie rzecz biorąc, okropny pomysł. Często powodują one konflikty; występują również
błędy alokacji pamięci, a sam system działa wolno i nieprzewidywalnie.
254
Jeśli planujesz korzystać z własnego programu antywirusowego i chcesz mieć pewność, że apli-
kacja Defender zostanie całkowicie usunięta, możesz odinstalować tę funkcję z serwera. Najła-
twiej to wykonać za pomocą powłoki PowerShell przy użyciu następującego polecenia:
Uninstall-WindowsFeature -Name Windows-Defender
255
Czym w ogóle jest ATP?

Trudno określić, co dokładnie oznacza zaawansowana ochrona przed zagrożeniami (ang. Advanced
Threat Protection — ATP), ponieważ jest to zestaw składników i mechanizmów bezpieczeństwa
systemu Windows Defender współpracujących ze sobą w celu ochrony klientów i serwerów
przed zagrożeniami. W tym celu wykorzystywane jest oprogramowanie antywirusowe, zapora
sieciowa, zabezpieczenia sprzętowe, a nawet specyficzna ochrona przed programami wymusza-
jącymi okup (ransomware). Połączenie i współpraca tych wszystkich opcji w obszarze zabezpie-
czeń systemu Windows Server 2019 tworzy zaawansowaną ochronę przed zagrożeniami.
Niezwykle intrygujące dla nas może być to, że firma Microsoft w sprytny sposób wykorzystuje
połączenie z chmurą i przetwarzanie w niej danych w celu ciągłego ulepszania usługi Defender
AV. Być może nie wiesz o tym, ale większość komputerów z systemem Windows podłączonych
do internetu nieustannie sobie pomaga, zgłaszając do firmy Microsoft nowo odkryte luki
w zabezpieczeniach i złośliwe działania. Informacje te są następnie analizowane przy użyciu
algorytmów uczenia maszynowego, a uzyskane informacje mogą być natychmiast wykorzystane
na całym świecie przez pozostałe maszyny z systemem Windows.
Choć brzmi to trochę jak jakaś odmiana Wielkiego Brata i zapewne wiele osób obawia się
zagrożenia prywatności, wierzę, że wkrótce pokonamy ten strach i uświadomimy sobie, że
korzyści przeważają nad potencjalnymi obawami. Miliony użytkowników przesyłają obecnie
wiadomości e-mail za pośrednictwem usługi Office 365. Możesz nawet nie zdawać sobie z tego
sprawy, ale system Office 365 również zajmuje się tego rodzaju analizą danych w celu identyfi-
kowania i blokowania exploitów. Na przykład, jeśli duża grupa osób otrzymuje nagle maila
z załącznikiem będącym dokumentem Word z włączoną obsługą makr, co zazwyczaj nie jest
typową opcją, środowisko Office 365 może bardzo szybko przenieść ten dokument do bezpiecz-
nej strefy, otworzyć go (lub uruchomić, jeśli załącznik jest plikiem wykonywalnym) i sprawdzić,
czy dany plik jest rzeczywiście złośliwym oprogramowaniem. Jeśli tak, Office 365 natychmiast
rozpocznie jego blokowanie i w ten sposób zatrzyma potencjalnie katastrofalne w skutkach
rozprzestrzenianie się tego składnika. Wszystko to dzieje się bez udziału użytkownika lub perso-
nelu IT firmy. Nie jest to nawet działanie związane z danym nadawcą wiadomości. Jeśli jakiś
z moich użytkowników jako pierwszy otrzyma w poczcie elektronicznej dziwne oprogramowa-
nie, które zostanie następnie zidentyfikowane jako wirus, to odkrycie pozwoli je zablokować
również u innych klientów przechowujących swoje wiadomości w chmurze Microsoft. To coś
niesamowitego!
Ta sama zasada będzie obowiązywać w przypadku antywirusa Defender AV, jeśli zdecydujesz
się zezwolić mu na komunikację i przesyłanie informacji do zasobów chmurowych firmy
Microsoft. Wcześniej wkleiłem zrzut ekranu z funkcjami aplikacji Defender AV zwanymi
Cloud-delivered protection (Ochrona dostarczana z chmury) i Automatic sample submission
(Automatyczne przesyłanie próbek). To właśnie te elementy pozwalają na działanie magii opartej
na chmurze i przynoszą korzyści wszystkim komputerom.
256
Windows Defender ATP Exploit Guard

Po raz kolejny widzimy w tytule skomplikowaną nazwę rozwiązania technologicznego, które
musi mieć bardzo określone zastosowanie, nieprawdaż? Nie. Exploit Guard nie jest poje-
dynczą funkcją, ale raczej zestawem nowych funkcji wprowadzonych do rodziny Windows
Defender. W szczególności te nowe zabezpieczenia mają na celu wykrywanie niektórych
typowych zachowań stosowanych w obecnych atakach złośliwego oprogramowania oraz zapo-
bieganie im. Oto cztery podstawowe elementy rozwiązania Defender ATP Exploit Guard:
 Redukcja powierzchni ataku (ang. Attack Surface Reduction — ASR): ASR jest
zestawem elementów sterujących, które można włączyć, aby nie pozwolić na
uruchamianie niektórych typów plików. Może to pomóc w złagodzeniu skutków
działania złośliwego oprogramowania zainstalowanego przez użytkowników
klikających załączniki e-mail lub otwierających określone rodzaje plików
Microsoft Office. Jako specjaliści IT, wiemy bardzo dobrze, że nigdy nie
powinniśmy otwierać plików zawartych w wiadomościach e-mail, które wydają się
plikami wykonywalnymi. Często jednak typowy użytkownik komputera nie
zauważy różnicy między szkodliwym plikiem wykonywalnym a zwykłym plikiem
innego typu. Składnik ASR może zablokować działanie dowolnego pliku
wykonywalnego lub skryptowego uruchamianego z wiadomości e-mail.
 Ochrona sieci: włącza filtr Windows Defender SmartScreen, który może
blokować potencjalnie złośliwe oprogramowanie i nie pozwalać mu na łączenie
się z serwerami atakującego w celu przesyłania danych firmowych poza sieć
korporacyjną. Witryny internetowe mają określone poziomy reputacji, które
sprawiają, że strona lub adres stają się zaufane lub podejrzane. Taka ocena zależy
od rodzaju ruchu, który był obsługiwany przez te strony w przeszłości.
SmartScreen wykorzystuje bazy danych reputacji, aby zablokować ruch
wychodzący przed jego dotarciem do niewłaściwych miejsc docelowych.
 Kontrolowany dostęp do folderu: ochrona przed oprogramowaniem typu
ransomware! Jest to ciekawy temat, ponieważ programy wymuszające okup
stanowią główny problem każdego specjalisty ds. bezpieczeństwa IT. Jeśli
nie słyszałeś jeszcze o ransomware, wyjaśniam, że jest to rodzaj złośliwego
oprogramowania, które instaluje aplikację na Twoim komputerze, a następnie
szyfruje pliki na dyskach1. Po zaszyfrowaniu nie można otworzyć ani naprawić
tych plików bez dostępu do klucza szyfrowania, który osoby atakujące chętnie
przekażą ofierze w zamian za wysoką opłatę (niestety, nie zawsze tak bywa).
Każdego roku wiele firm płaci ten okup (i przez to same angażują się w bierne
zachowania przestępcze), ponieważ nie wdrożyło odpowiednio dobrej ochrony
danych ani nie wykonuje kopii zapasowych, z których można przywrócić
wymagane informacje. Kontrolowany dostęp do folderu pozwala zabezpieczyć
się przed oprogramowaniem typu ransomware, ponieważ nie dopuszcza
niezaufanych procesów do tych obszarów dysku twardego, które zostały uznane
za chronione.
1
Również na zamontowanych dyskach sieciowych, jeśli użytkownik ma na nich uprawnienia do zapisu
— przyp. tłum.
257
 Ochrona przed exploitami: uogólniona ochrona przed wieloma rodzajami

programów wykorzystujących błędy w oprogramowaniu. Funkcja ochrony przed
atakami w programie Defender ATP zawiera składniki, które były kiedyś
zestawem narzędzi rozszerzonego środowiska ograniczającego ryzyko
(ang. Enhanced Mitigation Experience Toolkit — EMET). Ten zbiór narzędzi był
oddzielną aplikacją aż do połowy 2018 roku, a następnie został dołączony do
usługi Defender ATP. Dzięki niemu możliwa jest ochrona procesów
systemowych, a także wykonywalnych programów aplikacyjnych.
Zapora systemu Windows Defender —

bez żartów
Zagrajmy w grę polegającą na kojarzeniu słów. Rzucę jakimś hasłem, a Ty odpowiesz pierwszym
słowem, które przyjdzie Ci na myśl.
Bezpieczeństwo sieci.
Czy powiedziałeś „zapora sieciowa”? Ja odpowiedziałbym w taki sposób. Gdy myślimy o zabez-
pieczeniu swoich urządzeń na poziomie sieci, bierzemy pod uwagę sieci graniczne. Są one
zdefiniowane i chronione przez zapory sieciowe, głównie na poziomie sprzętowym. Wyko-
rzystują specjalistyczne urządzenia w celu zapewnienia wysokiego poziomu bezpieczeństwa.
W tym podrozdziale chcę omówić kolejny element zabezpieczeń sieci, którego możesz i powi-
nieneś używać w swoich środowiskach. Tak, mam na myśli zaporę systemu Windows. Przestań
się śmiać, to niegrzeczne!
Biorąc pod uwagę przeszłość, łatwo wyśmiewać zaporę systemu Windows. W czasach systemów
Windows XP i Server 2003 była ona dość bezużyteczna i powodowała znacznie więcej proble-
mów, niż rozwiązywała. W rzeczywistości to wrażenie było tak powszechne, że wciąż istnieje
wiele firm, które w domyślnych zasadach grupy całkowicie wyłączają zaporę systemu Windows
we wszystkich swoich systemach przyłączonych do domeny. Gdy zadajesz im pytanie, dlaczego
tak robią, zwykle okazuje się, że nie mają określonego powodu. Standardowymi odpowiedziami
są: „Po prostu zawsze tak było” lub „Tak mamy zapisane w naszej formalnej polityce bezpieczeń-
stwa”. Jest to problem, ponieważ zapora Windows Defender z zaawansowanymi zabezpie-
czeniami (ang. Windows Defender Firewall with Advanced Security — WFAS) dostępna w naj-
nowszych systemach operacyjnych Windows jest znacznie bardziej niezawodna i zaawansowana
niż jakakolwiek jej wcześniejsza wersja. Można ją więc bez problemu wykorzystać w celu
poprawy architektury bezpieczeństwa. Chciałbym nawet oświadczyć, że wyłączenie zapory
WFAS w jednym z tych najnowszych systemów operacyjnych będzie niemądrym zachowaniem,
chyba że masz bardzo dobry konkretny powód.
258
Trzy konsole administracyjne zapory systemu Windows

Przede wszystkim ważne jest, aby wiedzieć, że istnieją trzy różne konsole, za pomocą których
można konfigurować ustawienia zapory systemu Windows. Funkcjonalność dwóch z nich się po-
krywa, a trzecia jest znacznie bardziej przydatna niż pozostałe. Przyjrzyjmy się każdej z nich.
Zapora Windows Defender (Panel sterowania)

Aby w systemie Windows Server 2019 uruchomić dowolną aplikację lub uzyskać dostęp do
określonych ustawień, zazwyczaj wystarczy po prostu kliknąć przycisk Start, a następnie wpisać
słowo odnoszące się do zadania, które próbuje się wykonać. Ja kliknąłem Start i wprowadziłem
słowo zapora. Najlepszą opcją dopasowania, która pojawiła się jako pierwsza w moich wynikach
wyszukiwania, była Zapora Windows Defender, tak więc wybrałem ją i uruchomiłem.
Co ciekawe, łącze prowadzi do konsoli konfiguracji zapory systemu Windows w panelu sterowa-
nia, który jest przestarzałym programem służącym do wprowadzania ustawień systemowych.
Konsola jednak wciąż działa i jest w pełni zdolna do wprowadzania zmian w podstawowych
funkcjach zapory, takich jak jej włączanie lub wyłączanie. Ponieważ narzędzie znajduje się
w panelu sterowania, musimy założyć, że tak naprawdę nie jest ono zalecane przez firmę Microsoft.
Pamiętaj, że wszystkie nowe parametry konfiguracyjne zostały przeniesione do programu
Windows Settings, którego należy używać zamiast starego panelu sterowania:
259
Zapora i ochrona sieci (Ustawienia zabezpieczeń Windows)

Chociaż narzędzia korzystające z panelu sterowania zawsze były w poprzednich wersjach
systemu operacyjnego właściwym sposobem na modyfikowanie parametrów zapory, wiesz
już, że w panelu Windows Settings jest obecnie przechowywanych wiele opcji związanych
z aplikacją Windows Defender. Czy to możliwe, że w sekcji Windows Security (Zabezpieczenia
Windows) znajdują się również ustawienia konfiguracji zapory Windows Defender?
Zgadza się. Otwórz panel Windows Settings i kliknij opcję Update & Security (Aktualizacja
i zabezpieczenia), a następnie Windows Security (Zabezpieczenia Windows). Byłeś tu już
wcześniej — jest to ekran, który zawiera krótkie podsumowanie składników środowiska Win-
dows Defender. Jednym z nich jest Firewall & network protection (Zapora i ochrona sieci).
Kliknij tę opcję, aby otworzyć nową platformę, której nie było we wcześniejszych wersjach
systemu Windows, a która obecnie służy do konfigurowania funkcji zapory Windows:
Kliknięcie dowolnego z pokazanych na rysunku odnośników umożliwi dostęp do dodatko-

wych opcji konfiguracyjnych. Na przykład, jeśli chciałbyś szybko włączyć lub wyłączyć
określone profile zapory (wkrótce je omówimy), możesz kliknąć ten, który zamierzasz skonfigu-
rować, taki jak Domain network (Sieć z domeną), a następnie w prosty sposób wyłączyć dla
niego zaporę. Wiele firm wyłącza profil sieci z domeną na swoich komputerach, aby zapora
sieciowa nie chroniła ruchu w korporacyjnej sieci LAN.
260
Chociaż wyłączenie zapory jest ogólnie złym pomysłem, czasami należy to zrobić, aby dopaso-
wać się do modelu biznesowego:
Okno konfiguracji zapory dostępne w ustawieniach Windows jest dobrym miejscem do podej-
mowania prostych, ogólnych decyzji dotyczących zapory Windows Defender, ale możliwości
tego interfejsu są ograniczone. Aby móc w jak najszerszym zakresie wykorzystać funkcje zapory
lub ją skonfigurować, należy użyć innego narzędzia, które omówimy poniżej.
Zapora Windows z zaawansowanymi zabezpieczeniami (WFAS)

Jeśli jesteś podobny do mnie, nie będziesz w pełni usatysfakcjonowany omówionymi powyżej
konsolami. Jeśli chcesz się zapoznać z bardziej szczegółowymi informacjami dotyczącymi
zapory Windows, będziesz potrzebować czegoś innego niż jej podstawowe narzędzia. Możesz
więc kliknąć jedno z łączy ustawień zaawansowanych pokazanych na wcześniejszych zrzutach
ekranu albo po prostu otworzyć wiersz poleceń lub kliknąć prawym przyciskiem myszy opcję
Start/Run (Start/Uruchom) i wprowadzić nazwę wf.msc. Każde z tych działań uruchomi pełną
konsolę administracyjną WFAS:
261
W tej konsoli możesz się zapoznać z o wiele bardziej szczegółowymi informacjami na temat
aktywności zapory Windows, a także dokonać bardziej precyzyjnych korekt w regułach zezwala-
jących i blokujących. Istnieje również sekcja Monitoring (Monitorowanie), za pomocą której
można wyświetlić aktywne reguły, w tym reguły zabezpieczeń połączeń. Jest to ważne miej-
sce, ponieważ potwierdza ono, że zapora WFAS wykonuje znacznie więcej działań niż samo
blokowanie ruchu sieciowego. Ta aplikacja jest nie tylko zaporą sieciową, ale także platformą
połączeń. Jeśli planujesz użyć protokołu IPsec do szyfrowania ruchu sieciowego, bez względu
na to, czy będzie to natywny protokół IPsec w sieci, czy też realizowany w ramach dostępu
zdalnego DirectAccess, w sekcji monitorowania zostaną wyświetlone reguły, które są defini-
cjami tuneli IPsec. Zapora systemu Windows jest faktycznie odpowiedzialna za tworzenie
zaszyfrowanych połączeń i tuneli, dzięki czemu jest o wiele bardziej zaawansowana niż poprzed-
nio używany produkt.
Trzy różne profile zapory

Gdy dowolna karta sieciowa znajdująca się w komputerze lub serwerze zostanie podłączona
do sieci, zapora Windows przypisze połączeniu jeden z trzech różnych profili. Prawdopodobnie
już wcześniej miałeś styczność z tym procesem decyzyjnym, nawet o tym nie wiedząc. Czy
podczas podłączania laptopa do sieci Wi-Fi w kawiarni system Windows zapytał Cię, czy łączysz
się z siecią domową, służbową czy publiczną? To właśnie zapora Windows zwróciła się do
Ciebie z zapytaniem, który profil chcesz przypisać do nowego połączenia sieciowego. Dzięki
przypisywaniu kart i połączeń sieciowych do różnych profili zapory możesz używać odmiennych
reguł dostępu i określać to, co powinno być dozwolone, a co zabronione. W rzeczywistości
zapora chce wiedzieć, jak bardzo ufasz danej sieci. Na przykład, gdy laptop jest podłączony
262
do sieci korporacyjnej, możesz pracować swobodniej niż wówczas, gdy ten sam komputer
jest podłączony do sieci hotelowej. Przypisanie bardziej restrykcyjnych reguł zapory do profilu,
który staje się aktywny, gdy jesteś podłączony do publicznego internetu, na przykład w hotelu,
lepiej zabezpiecza Cię przed atakującymi. Przeanalizujmy te trzy różne typy dostępnych profili:
 Domain Profile (Profil domeny): to jedyny profil, którego nie możesz przypisać.
Profil domeny jest aktywny tylko wtedy, gdy jesteś zalogowany na komputerze
przyłączonym do domeny i podłączonym do sieci, w której jest dostępny kontroler
domeny. Tak więc w przypadku każdej maszyny firmowej w sieci korporacyjnej
można oczekiwać, że jej profil domeny będzie aktywny.
 Private Profile (Profil prywatny): gdy łączysz się z nową siecią i jesteś proszony
o wybranie lokalizacji, połączenie zostanie przypisane do profilu prywatnego,
jeśli wybierzesz Home (Dom) lub Work (Praca).
 Public Profile (Profil publiczny): jeśli wybierzesz opcję Public Profile, wtedy
oczywiście zostanie Ci przypisany publiczny profil zapory. Ponadto stanie się
on domyślny, jeśli z jakiegoś powodu nie pojawi się pytanie ze strony zapory lub
w ogóle nie wybierzesz określonej opcji i po prostu zamkniesz okno z pytaniem
o przypisanie nowego połączenia. W nowszych wersjach systemu Windows
(szczególnie w Windows 10) zazwyczaj nie pojawia się pytanie o wybór sieci.
Zamiast tego pojawia się okno z pytaniem, czy chcesz zezwolić komputerowi na
komunikowanie się z innymi urządzeniami w nowej sieci. W rzeczywistości jest to
nadal pytanie o profil publiczny, a odpowiedź twierdząca spowoduje przypisanie
połączenia do prywatnego profilu zapory (ponieważ łączność z innymi urządzeniami
powinna być dopuszczona tylko w przypadku sieci zaufanych).
Każda karta sieciowa ma przypisaną własną definicję profilu. W tym samym systemie może być
aktywny więcej niż jeden profil zapory. Na przykład mój serwer RA1 jest podłączony zarówno do
sieci korporacyjnej, jak i publicznego internetu. W zaporze WFAS widać, że aktywne są
zarówno profil domeny, jak i profil publiczny (zobacz na pierwszym zrzucie ekranu na na-
stępnej stronie).
Alternatywnie możesz na serwerze otworzyć panel Network and Sharing Center (Centrum
sieci i udostępniania) i w prosty sposób stwierdzić, która karta sieciowa używa danego profilu
(zobacz na drugim zrzucie ekranu na następnej stronie).
Tworzenie w zaporze nowej reguły przychodzącej

Wiesz już, że najważniejsze składniki zapory Windows znajdują się w konsoli WFAS, więc użyjmy
jej w celu stworzenia nowej reguły. Na serwerze RA1 włączyłem protokół RDP, dzięki czemu
mogę łatwiej wykonywać prace administracyjne, po prostu siedząc przy biurku. Jednak po
włączeniu tego protokołu zezwoliłem także na dostęp do niego ze wszystkich sieci zdefiniowa-
nych w serwerze. Oznacza to, że po protokole RDP mogę się połączyć z maszyną nie tylko
z wnętrza sieci, ale także z internetu, jest to bowiem serwer dostępu zdalnego i zdarza mu się
263
być podłączonym bezpośrednio do sieci zewnętrznej. Jest to duży problem, ponieważ teraz
każdy mądrala może znaleźć mój serwer w internecie, użyć protokołu RDP i spróbować zalogo-
wać się na maszynę przy użyciu ataku brute force.
Aby zlikwidować ten problem, chciałbym zablokować protokół RDP tylko w swojej zewnętrz-
nej karcie sieciowej. Jednocześnie powinien on pozostać aktywny wewnątrz sieci, aby nadal
pozwalać mi na łączenie się z serwerem z własnego biurka. Czy jednak konsola WFAS pozwala
w prosty sposób utworzyć regułę zapory sieciowej, która zablokuje dostęp do protokołu RDP
tylko z zewnątrz? Oczywiście, że tak.
Uruchom plik wf.msc, aby wyświetlić okno zapory Windows Defender z zaawansowanymi
zabezpieczeniami, a następnie przejdź do sekcji Inbound Rules (Reguły przychodzące), dzięki
czemu zobaczysz wszystkie istniejące reguły zapory dla ruchu przychodzącego w tym serwerze
264
(znajdziesz tu wiele gotowych reguł, nawet jeśli nigdy wcześniej nie odwiedzałeś tej konsoli
— zostały one zainstalowane wraz z systemem operacyjnym). Kliknij prawym przyciskiem my-
szy pozycję Inbound Rules, a następnie z menu podręcznego wybierz opcję New Rule… (Nowa
reguła…). Spowoduje to uruchomienie kreatora, za pomocą którego utworzymy naszą nową
regułę zapory. Pierwszy ekran to miejsce, w którym określamy rodzaj nowo tworzonej reguły.
Możesz utworzyć regułę modyfikującą ruch dla określonego programu lub przejrzeć listę
uprzednio zdefiniowanych protokołów. Chciałbym jednak dokładnie wiedzieć, w jaki sposób
działa moja reguła, więc wolałbym sam ją zaprojektować, a nie polegać na wcześniej istniejącej
definicji protokołu. Wiem też, że protokół RDP działa na porcie TCP 3389. Na tym ekranie
wybiorę więc opcję Port, a po kliknięciu przycisku Next (Dalej) wprowadzę numer portu 3389:
Następnym etapem będzie podjęcie decyzji o tym, czy chcemy zezwolić na ruch po wybranym
porcie, czy też go zablokować. Istnieje też trzecia opcja, zezwalająca na połączenie tylko
wtedy, gdy zostało ono uwierzytelnione przez protokół IPsec. Ta opcja ma duże możliwości, ale
wymaga zdefiniowania protokołu IPsec w naszej sieci. Ze względu na to wymaganie nie może
ona być wybierana zbyt często. W naszym przykładzie mamy już działający protokół RDP,
ale chcemy go zablokować na jednej z kart sieciowych, dlatego wybiorę działanie Block the
connection (Zablokuj połączenie):
265
Nie chcemy jednak blokować protokołu RDP dla wszystkich kart sieciowych, więc musimy się
dobrze zastanowić przy wyborze opcji na następnym ekranie. W tym miejscu powinieneś sobie
przypomnieć niedawno zdobytą wiedzę o profilach zapory. Pamiętaj, że wewnętrzne karty sie-
ciowe podłączone do naszej sieci domenowej będą miały przypisany profil domeny. Z drugiej
strony wszystkie karty sieciowe, które nie są podłączone do sieci wewnętrznej z kontrolerem
domeny, będą miały aktywne profile publiczne lub prywatne. Tę wiedzę musimy wykorzystać na
obecnym ekranie. Jeśli chcemy wyłączyć protokół RDP tylko na zewnętrznej karcie sieciowej,
nasza reguła powinna być aktywna wyłącznie dla profilu prywatnego i publicznego. Przyglądając
się wcześniejszym zrzutom ekranu, widzimy jednak, że zewnętrzna karta sieciowa ma już
przypisany profil publiczny, więc możemy w tym miejscu zaznaczyć tylko pole wyboru Public
(Publiczny), co spowoduje, że protokół RDP zostanie dla niej zablokowany. Na wypadek gdyby-
śmy w przyszłości dodali do serwera więcej kart sieciowych, dla których chcielibyśmy zabloko-
wać dostęp po protokole RDP, pozostawimy zaznaczone oba pola Public i Private (Prywatny),
aby zapewnić wyższy poziom bezpieczeństwa. Upewnij się, że usunąłeś zaznaczenie profilu
Domain (Domena)! W przeciwnym razie całkowicie zablokujesz dostęp po protokole RDP.
Jeśli w tym momencie używasz tego protokołu w celu łączenia się z serwerem, na którym pra-
cujesz, zostaniesz w nim zablokowany i nie będziesz mógł się ponownie połączyć:
Wymyślmy jeszcze nazwę nowej reguły, i będziemy mieli wszystko gotowe! Możliwość nawią-
zywania połączeń z internetu po protokole RDP do naszego serwera została wyłączona i mo-
żemy być już bardziej spokojni.
Tworzenie reguły zezwalającej na wysyłanie pingów (ICMP)

Bardzo często muszę tworzyć reguły zezwalające na działanie protokołu ICMP lub jego blo-
kowanie. Innymi słowy, często muszę dostosowywać zaporę sieciową na serwerach, aby włączać
lub wyłączać ich zdolność do odpowiadania na polecenie ping. Prawdopodobnie zauważyłeś,
że w nowszych systemach operacyjnych przeznaczonych do serwerów zapora z definicji
automatycznie blokuje działanie polecenia ping (czyli protokołu ICMP). Jest to problemem
w środowiskach, w których instrukcja ping jest standardową metodą testowania, czy adres
IP jest używany lub dostępny. Być może będziesz się śmiać, ale uwierz mi, że wciąż wielu
administratorów IT nie wie, jakie adresy IP są już zajęte w ich sieciach. Gdy stoją oni w obliczu
potrzeby skonfigurowania nowego serwera i podjęcia decyzji, jaki adres IP należy mu nadać,
po prostu zaczynają używać polecenia ping z kolejnymi adresami IP w swojej sieci, dopóki
nie znajdą takiego, który nie odpowie! Widziałem to wiele razy. Chociaż nie jest to oczywiście
dobry sposób na zarządzanie adresami IP, czasem jest wykorzystywany. Niestety, ta metoda
266
nie działa dobrze, ponieważ większość nowo zainstalowanych systemów Windows od razu
blokuje odpowiedzi na pakiety ICMP. Oznacza to, że możesz próbować kontaktować się
z jakimś adresem IP i nie doczekać się odpowiedzi. Okaże się, że w rzeczywistości pod tym adre-
sem będzie jednak istnieć działający serwer.
Wróćmy do naszego problemu. Być może konieczne będzie włączenie protokołu ICMP na
nowym serwerze, aby mógł odpowiedzieć, gdy ktoś spróbuje się z nim skontaktować za pomocą
polecenia ping. Gdy musimy stworzyć regułę włączającą protokół ICMP, definiujemy ją podob-
nie jak w przypadku protokołu RDP, jednakże pojawia się jeden problem. Gdy rozpoczniesz
tworzenie nowej reguły i będziesz chciał wybrać jej rodzaj, na pierwszym ekranie, Rule Type
(Typ reguły), nie znajdziesz żadnych opcji ani wstępnych definicji związanych z protokołem
ICMP. Uważam, że jest to trochę dziwne, ponieważ reguły związane z protokołem ICMP są
często definiowane. Okazuje się jednak, że wybranie opcji ICMP z rozwijanej listy byłoby po
prostu zbyt łatwe. Zamiast tego utworzysz nową regułę ruchu przychodzącego, tak jak w przy-
padku RDP, a na pierwszym ekranie wybierzesz opcję Custom (Niestandardowa).
Na następnym ekranie pozostaw zaznaczoną opcję All programs (Wszystkie programy). Ponownie
kliknij przycisk Next (Dalej), a pojawi się rozwijana lista o nazwie Protocol type (Typ protokołu).
Z niej właśnie możesz wybrać protokół ICMP. Jak widać na poniższym zrzucie ekranu, dostępne
są opcje ICMPv4 lub ICMPv6, w zależności od tego, jakiego typu jest ruch sieciowy. Moje la-
boratorium testowe jest przeznaczone tylko dla ruchu IPv4, więc wybiorę ICMPv4:
W pozostałej części kreatora postępuj zgodnie z tą samą procedurą, którą przedstawiłem

podczas tworzenia reguły RDP: wybierz opcję zezwalania lub blokowania ruchu, a także rodzaj
profilu. Po zakończeniu pracy Twoja nowa reguła ICMPv4 zostanie natychmiast wprowadzona
w życie. Jeśli zezwoliłeś na połączenie, serwer będzie teraz pomyślnie odpowiadał na po-
lecenie ping:
267
Jeśli kiedykolwiek będziesz musiał zmodyfikować jakąś regułę lub zagłębić się w jej bardziej
zaawansowane właściwości, możesz na ekranie Inbound Rules (Reguły przychodzące) kliknąć
prawym przyciskiem myszy określony wiersz i przejść do opcji Properties (Właściwości). Zosta-
nie otwarte nowe okno z zakładkami, w których będziesz mógł zmodyfikować dowolne kryteria
dotyczące danej reguły. Na przykład możesz dodać kolejne porty, zmienić powiązanie z określo-
nym profilem, a przy wykorzystaniu zakładki Scope (Zakres) nawet określić, jakich adresów IP
dotyczy ta reguła.
Pozwala to stosować regułę zapory tylko dla ruchu przychodzącego lub wychodzącego
z określonej części sieci lub podzbioru maszyn. Na poniższym zrzucie ekranu zmodyfikowałem
ustawienia zakładki Scope w taki sposób, aby reguła zapory miała zastosowanie tylko do ruchu
przychodzącego z podsieci 192.168.0.0/16:
268
Zarządzanie zaporą WFAS przy użyciu zasad grupy

Zarządzanie regułami zapory na serwerach i klientach może być znaczącym krokiem w kierunku
utworzenia bardziej bezpiecznego środowiska w Twojej firmie. Co jest w tym najlepsze? To,
że ta technologia klasy korporacyjnej jest całkowicie bezpłatna, ponieważ została już wbudowana
w systemy operacyjne, których używasz. Jedynym kosztem związanym z zaporą sieciową
jest czas potrzebny na wdrożenie wszystkich reguł. Koszmarem administratora byłaby sytuacja,
w której musiałby wdrożyć całą listę różnych zezwoleń i blokad indywidualnie na każdej z maszyn.
Na szczęście mamy obiekty zasad grupy (GPO). Podobnie jak w przypadku większości ustawień
i funkcji systemu Microsoft Windows, skonfigurowanie zasad dla zapory sieciowej, które będą
dotyczyć wszystkich, jest w komputerach przyłączonych do domeny bardzo proste. Jeśli chcesz,
możesz nawet stworzyć więcej zestawów zasad, przykładowo zdefiniować obiekt zasad grupy,
który będzie stosować reguły zapory dla klientów, a także oddzielny obiekt GPO stosujący
reguły zapory dla serwerów. Chodzi o to, że możesz przydzielić komputery do określonych
kategorii, utworzyć reguły GPO dla każdej z nich, a następnie automatycznie zastosować je
w każdej maszynie z wykorzystaniem potężnych możliwości dystrybucji obiektów zasad grupy.
Ponieważ już wiesz, jak tworzy się obiekty GPO, zdefiniuj teraz taki, który będzie zawierał
pewne ustawienia związane z zaporą sieciową. Następnie odpowiednio podłącz ten
obiekt i przefiltruj, aby otrzymały go tylko te maszyny, które powinny. Być może przed wdroże-
niem produkcyjnym dobrym pomysłem będzie użycie testowej jednostki organizacyjnej, abyś
mógł się upewnić, że wszystkie reguły, które zamierzasz umieścić w obiekcie zasad grupy,
działają poprawnie i dobrze współpracują ze wszystkimi innymi istniejącymi politykami.
Po utworzeniu nowego obiektu GPO kliknij go w konsoli zarządzania zasadami grup prawym
przyciskiem myszy, a następnie wybierz opcję Edit… (Edytuj…):
269
Gdy mamy już otwarty nowy obiekt zasad grupy, musimy się dowiedzieć, w którym miejscu
znajdują się parametry związane z regułami zapory. Gdy jesteś zalogowany na komputerze
lokalnym, możesz je znaleźć w ścieżce Computer Configuration/Policies/Windows Settings/Security
Settings/Windows Defender Firewall with Advanced Security (Konfiguracja komputera/Zasady/
Ustawienia systemu Windows/Ustawienia zabezpieczeń/Zapora Windows Defender z zabezpiecze
niami zaawansowanymi):
Jak widać, w tym miejscu będziesz mógł także włączyć (lub wyłączyć) określone profile zapory
lub ją całą. Tutaj również możesz wyłączyć zaporę Windows dla wszystkich użytkowników.
Kliknąwszy prawym przyciskiem myszy opcję Windows Defender Firewall with Advanced Secu-
rity (Zapora Windows Defender z zabezpieczeniami zaawansowanym), a następnie wybrawszy
opcję Properties (Właściwości), możesz oddzielnie zdefiniować status każdego z profili (zobacz
na pierwszym zrzucie ekranu na następnej stronie).
Po zakończeniu definiowania profili zgodnie z Twoimi wymaganiami kliknij przycisk OK, a znaj-
dziesz się ponownie w części WFAS obiektu zasad grupy. Podobnie jak w przypadku lokalnej
konsoli zapory WFAS, znajdują się tu opcje Inbound Rules (Reguły przychodzące) i Outbound
Rules (Reguły wychodzące). Po prostu kliknij prawym przyciskiem myszy łącze Inbound Rules,
a następnie wybierz opcję New Rule… (Nowa reguła…), aby rozpocząć tworzenie reguły
bezpośrednio w obiekcie zasad grupy. Pojawi się ten sam kreator, który poznałeś, tworząc
regułę w lokalnej konsoli WFAS. Gdy zakończysz pracę, nowa reguła przychodząca zostanie
wyświetlona w obiekcie zasad grupy.
270
Zacznie ona od razu działać w usłudze Active Directory i zainstaluje się na komputerach
oraz serwerach zdefiniowanych w łączach do zasad, a także kryteriach filtrowania:
271
Technologie szyfrowania
Kiedyś zajmowały się nim wyłącznie wielkie organizacje. Obecnie każdy ich potrzebuje.
Chodzi o szyfrowanie. Większość z nas, korzystając z witryn internetowych, używa ruchu
szyfrowanego za pomocą stron HTTPS, jednakże nawet w tej dziedzinie istnieją zaskakujące
wyjątki, a wiele tanich firm hostingowych nadal udostępnia strony logowania, które przesyłają
dane w sposób nieszyfrowany. Jest to straszne, ponieważ w przypadku danych, które przesyłasz
przez internet za pomocą zwykłego protokołu HTTP lub niezaszyfrowanego maila, musisz
założyć, że będą one odczytane przez nieuprawnione osoby. Możliwe, że jesteś paranoikiem
i nikt tak naprawdę nie przechwytuje i nie odczytuje Twoich danych. Musisz jednak wiedzieć,
że jeśli otwierasz stronę internetową o adresie rozpoczynającym się od znaków HTTP lub
wysyłasz wiadomość e-mail przy użyciu jakiejś bezpłatnej usługi poczty elektronicznej, wszelkie
dane wprowadzane na tej stronie lub przesyłane w mailu mogą zostać łatwo odczytane przez
osoby z całego świata. Szyfrowanie danych jest obecnie absolutnym wymogiem dla firm, które
korzystają z internetu. Mimo tych słów zdaję sobie sprawę, że ogromna większość firm nadal
nie używa żadnej technologii szyfrowania w swoich systemach mailowych, a więc po prostu
czeka na katastrofę.
Chociaż coraz lepiej chronimy ruch w przeglądarce internetowej, tradycyjnie nadal nie przywią-
zujemy dużej wagi do danych, które wydają się bezpieczne w naszej sieci firmowej. Źli ludzie nie
są jednak głupi i mają do wyboru bardzo duży zestaw sztuczek, aby za pomocą inżynierii
społecznej dobrać się do tych danych. Co się stanie, gdy znajdą się już wewnątrz naszej sieci?
W większości przypadków będą mieli wszystko podane na talerzu. Zdobądź dostęp do jednego
konta użytkownika lub komputera, a otrzymasz klucze do dużej części królestwa. Na szczęście
istnieje kilka technologii wbudowanych w system Windows Server 2019, które zostały zaprojek-
towane do zwalczania tego typu włamań, a także do ochrony informacji, nawet wówczas, gdy
znajdują się one w naszym centrum danych. Zapoznajmy się ze sposobem działania tych tech-
nologii, abyśmy mogli ich ewentualnie użyć w celu lepszej ochrony swoich danych.
BitLocker i wirtualny układ TPM

BitLocker to technologia, która jest już dość dobrze znana w systemach klienckich używanych
w sieciach korporacyjnych. Jest to metoda szyfrowania całych dysków, pozwalająca w pełni
chronić dane na laptopach lub komputerach stacjonarnych, które mogłyby zostać skradzione.
Jeśli złodziej ukradnie firmowego laptopa, wyciągnie jego dysk twardy i włączy go do swojego
komputera… przykro mi, brak dostępu. Zaszyfrowany został cały wolumin. Ma to sens w przy-
padku urządzeń mobilnych, które można łatwo zgubić lub ukraść. Na początku nie rozważano
jednak użycia BitLockera do ochrony serwerów.
Wraz z coraz szerszym użyciem chmury do przetwarzania danych coraz bardziej sensowny
staje się pomysł, aby technologię BitLocker wykorzystać również na serwerach. Gdy myślimy
o chmurze, tak naprawdę chcemy, by BitLocker był zainstalowany na maszynach wirtualnych,
niezależnie od tego, czy są to systemy klienckie czy serwerowe. Bez względu na to, czy prze-
chowujesz swoje maszyny wirtualne (VM) w prawdziwym środowisku chmurowym zapew-
nianym przez publicznego dostawcę usług w chmurze, czy też zarządzasz własną chmurą pry-
272
watną, w której użytkownicy tworzą własne maszyny wirtualne i zarządzają nimi, Twoje dane nie
będą w pełni bezpieczne, jeśli pliki VHD i VHDX wirtualnych dysków twardych nie zostaną za-
szyfrowane. Dlaczego? Ponieważ każdy, kto ma uprawnienia administracyjne na platformie
hosta wirtualizacji, może łatwo uzyskać dostęp do dowolnych danych znajdujących się na dys-
kach twardych serwera, nawet nie mając jakiegokolwiek dostępu do sieci lub konta użytkownika
w domenie. Wystarczy, że ktoś skopiuje plik VHDX (dysk twardy Twojego serwera) na pamięć
USB, przyniesie do domu, zamontuje ten wirtualny dysk we własnym systemie, i już ma dostęp
do wszystkich danych z serwera. Mamy tu duży problem ze spełnieniem wymogów ochrony
danych.
Dlaczego w przeszłości szyfrowanie maszyn wirtualnych było niewykonalne? Ponieważ

funkcja BitLocker ma interesujące wymagania. Dysk twardy jest szyfrowany, co oznacza, że nie
można go użyć bez odblokowania szyfrowania. Jak odblokować dysk twardy, aby nasza maszyna
mogła się uruchomić? Istnieją dwa sposoby. Najlepszą metodą jest przechowywanie kluczy
odblokowujących w układzie Trusted Platform Module (TPM). Jest to fizyczny mikroukład
istniejący w większości komputerów, które można dziś kupić. Przechowywanie klucza odbloko-
wującego w tym układzie oznacza, że nie musisz fizycznie podłączać żadnego zewnętrznego
urządzenia do komputera w celu jego uruchomienia. Wystarczy wprowadzić kod PIN, aby
uzyskać dostęp do modułu TPM, a następnie moduł TPM odblokuje funkcję BitLockera.
Z drugiej strony, jeśli zdecydujesz się wdrożyć technologię BitLocker w urządzeniu bez
układu TPM, wówczas aby odblokować zaszyfrowany wolumin i umożliwić jego uruchomie-
nie, musisz podłączyć fizyczną pamięć USB zawierającą klucze odblokowujące BitLockera.
Czy widzisz jakieś problemy związane z tymi dwoma wersjami scenariusza w przypadku
maszyn wirtualnych? Maszyny wirtualne nie mogą zawierać fizycznego układu TPM, a także
nie można im w prosty sposób podłączyć pamięci USB! Jak więc mogę zaszyfrować serwer
wirtualny, aby co sprytniejsi administratorzy dostawcy usług w chmurze nie odczytali wszystkich
moich tajnych dokumentów?
Użyj wirtualnego modułu TPM. Ta opcja pojawiła się w systemie Windows Server 2016. Mamy
obecnie możliwość przydzielania swoim wirtualnym serwerom wirtualnego modułu TPM,
którego można użyć do przechowywania kluczy odblokowujących! Te niesamowite wieści
oznaczają, że możemy w końcu zaszyfrować wirtualne maszyny niezależnie od tego, czy są one
umieszczone na fizycznych serwerach Hyper-V w naszym centrum danych czy w chmurze Azure.
Chronione maszyny wirtualne

Korzystanie z funkcji BitLocker i wirtualnych modułów TPM w celu szyfrowania i ochrony
plików wirtualnych dysków twardych tworzy konstrukcję, która zwana jest chronionymi maszy-
nami wirtualnymi (ang. Shielded VMs). Chronione maszyny wirtualne zostały po raz pierwszy
wprowadzone w systemie Windows Server 2016, a następnie ulepszone w wersji Server 2019.
Na razie to tyle, jeśli chodzi o tę nową i wyjątkową technologię, ale chciałem o niej wspomnieć
już w tym rozdziale, ponieważ zdecydowanie dotyczy ona bezpieczeństwa w naszych środowi-
skach serwerowych.
Znacznie więcej szczegółów na temat chronionych maszyn wirtualnych podam w rozdziale 12.,
„Wirtualizacja centrum danych za pomocą hiperwizora Hyper-V”.
273
Szyfrowane sieci wirtualne

Czy nie byłoby wspaniale, gdybyśmy mogli zarządzać swoimi sieciami i je konfigurować za po-
mocą graficznego interfejsu administracyjnego, zamiast przez cały dzień męczyć się z interfejsem
wiersza poleceń w routerach? Czy nie skorzystalibyśmy ze zwiększonej uniwersalności sieci
w celu przenoszenia serwerów i obciążeń z jednej podsieci do drugiej bez konieczności zmiany
adresu IP lub routingu na urządzeniach? Czy nie moglibyśmy automatycznie szyfrować całego
ruchu przepływającego między naszymi serwerami bez konieczności konfigurowania parame-
trów szyfrowania na samych maszynach?
Tak! Wszystkie te funkcje możemy uzyskać dzięki wykorzystaniu programowalnej sieci kompu-
terowej (SDN) i nowej opcji zwanej szyfrowanymi sieciami wirtualnymi. Ten punkt tak na-
prawdę jest tylko odnośnikiem, który kieruje Cię z powrotem do rozdziału 5., „Obsługa sieci
w Windows Server 2019”, na wypadek gdybyś pominął go podczas czytania tej książki. Omówili-
śmy już programowalne sieci komputerowe i ich nowe możliwości tworzenia oraz automatycz-
nego szyfrowania sieci wirtualnych, które łączą maszyny wirtualne oraz serwery hostów Hyper-V.
Jeśli więc ten pomysł jest dla Ciebie intrygujący, wróć do rozdziału 5.
Encrypting File System

System szyfrowania plików (ang. Encrypting File System — EFS) to składnik środowiska Micro-
soft Windows istniejący w systemach operacyjnych klienta i serwera od wielu lat. Podczas gdy
BitLocker jest odpowiedzialny za ogólne zabezpieczenie całego woluminu lub dysku, EFS
działa w sposób bardziej szczegółowy. Możesz go zastosować, jeśli chciałbyś zaszyfrować tylko
określone dokumenty lub foldery. Gdy zdecydujesz się na szyfrowanie plików przy użyciu sys-
temu EFS, powinieneś wiedzieć, że Windows musi wykorzystywać certyfikat użytkownika
jako część procesu szyfrowania i deszyfrowania, dlatego też kluczem do udanego wdrożenia
jest dostępność wewnętrznej infrastruktury PKI. Należy również zauważyć, że klucze uwierzy-
telniające są powiązane z hasłem użytkownika, więc w pełni przejęte konto użytkownika może
zniweczyć korzyści płynące z użycia systemu EFS.
Myślę, że wiele firm nie stosuje jednak systemu EFS, ponieważ to użytkownik musi podjąć
decyzję o tym, jakie dokumenty należy przeznaczyć do zaszyfrowania. Oznacza to w takim
razie, że użytkownicy powinni pamiętać o szyfrowaniu, czyli najpierw muszą zrozumieć, jak
ważne ono jest, aby mogli mu później poświęcić swój czas. Chciałem tu wspomnieć o systemie
EFS, jest bowiem wciąż obsługiwaną i działającą platformą, za pomocą której możesz szyfrować
dane, jednakże większość administratorów wybiera BitLockera jako lepsze rozwiązanie.
Brak odpowiedzialności ze strony użytkownika i scentralizowana platforma zarządzania spra-
wiają, że BitLocker znacząco wyprzedza system EFS. Mimo to obie technologie mogą
z pewnością współistnieć, zapewniając bezpieczeństwo danych na dwóch różnych poziomach,
co jest pewną zaletą, ponieważ nie musisz polegać tylko na jednej z dostępnych technologii
szyfrowania danych.
274
Protokoły IPsec
Wiele technologii szyfrowania wbudowanych w systemy operacyjne dotyczy danych, które zo-
stały zapisane i nie są już przenoszone. Ale co możemy zrobić ze swoimi danymi, które się prze-
mieszczają? Omawialiśmy już użycie protokołu SSL w witrynach HTTPS jako sposobu szyfro-
wania danych docierających do przeglądarki internetowej. Jak jednak chronić inne dane,
które nie są związane z przeglądarką?
Co mógłbym zrobić, jeśli nawet nie przejmuję się danymi wysyłanymi przez internet, ale jestem
zainteresowany ochroną ruchu, który może istnieć w mojej wewnętrznej sieci korporacyjnej?
Czy jest coś, co może mi pomóc w zwiększeniu bezpieczeństwa danych? Oczywiście.
IPsec to zestaw protokołów, którego można używać do uwierzytelniania i szyfrowania pakietów

wysyłanych podczas komunikacji sieciowej. IPsec nie jest technologią specyficzną dla świata fir-
my Microsoft, jednakże w systemie Windows Server 2019 są dostępne różne sposoby wykorzy-
stania tego protokołu w celu zabezpieczenia danych przesyłanych między komputerami.
Najczęstszym miejscem w systemie Windows Server, w którym napotykamy protokół IPsec,

jest korzystanie z roli dostępu zdalnego. Podczas konfigurowania połączenia VPN na serwerze
zdalnego dostępu będziesz mieć możliwość wybrania spośród różnych protokołów połączeń,
których klienty VPN mogłyby użyć do łączenia się z serwerem VPN. Na liście możliwych
platform połączeniowych znajdują się także tunele IPsec (IKEv2). Drugą technologią zdalnego
dostępu wykorzystującą protokół IPsec jest DirectAccess. Za każdym razem, gdy komputer
kliencki w internecie tworzy do serwera DirectAccess tunel, jest on chroniony przez protokół
IPsec. Na szczęście konsola zarządzania dostępem zdalnym, której używasz do wdrażania za-
równo połączeń VPN, jak i DirectAccess, jest wystarczająco inteligentna i potrafi spowodo-
wać, by uwierzytelnianie i szyfrowanie za pomocą protokołu IPsec mogło poprawnie działać.
Nie musisz więc go znać, aby wykorzystywać technologie dostępu zdalnego!
Rola dostępu zdalnego nie koncentruje się niestety na obsłudze ruchu wewnątrz sieci. Gdy
masz na myśli VPN lub DirectAccess, bierzesz pod uwagę dane, które są przesyłane w interne-
cie. Co mógłbyś jednak zrobić, gdybyś po prostu chciał szyfrować ruch, który powstaje między
dwoma różnymi serwerami w tej samej sieci, a także taki, który pojawia się między komputerami
klienckimi w biurze a lokalnymi serwerami? W tej sytuacji staje się przydatna pewna znajomość
ustawień zasad IPsec, ponieważ dzięki nim możemy sprawić, by ruch w naszych sieciach
korporacyjnych był szyfrowany przy użyciu tego protokołu. Aby tak się stało, należy użyć
odpowiednich zasad.
Konfigurowanie protokołu IPsec

W środowisku Microsoft Windows są dwa różne miejsca, w których można konfigurować usta-
wienia IPsec. Zarówno starsze, jak i nowe systemy mogą zarządzać konfiguracją protokołu
IPsec poprzez tradycyjną przystawkę IP Security Policy (Zasady zabezpieczeń IP). Jeśli używasz
nowszych systemów, co najmniej takich, jak Windows 7 i Server 2008, alternatywnie do
skonfigurowania zasad IPsec możesz użyć zapory Windows Defender z zaawansowanymi
275
zabezpieczeniami. Zapora WFAS jest najbardziej uniwersalnym rozwiązaniem, ale nie zaw-
sze można jej użyć w starszych systemach dostępnych w Twoim środowisku.
Najpierw rzućmy okiem na starszą konsolę zasad IPsec. Zaczniemy od niej, ponieważ różne
dostępne opcje pomogą Ci zdobyć podstawową wiedzę pozwalającą na zrozumienie działania
protokołu IPsec wykorzystywanego między dwoma punktami końcowymi. W konsoli istnieją trzy
różne klasyfikacje zasad IPsec, które można przypisać do komputerów. Poświęćmy chwilę na wyja-
śnienie każdej z nich, ponieważ nazwy tych zasad mogą być nieco mylące. Przeanalizowanie zapre-
zentowanych opcji pomoże Ci zrozumieć, jak działają odpowiednie ustawienia w zaporze WFAS.
Zasada serwera
Nazwę „zasada serwera” należałoby prawdopodobnie zmienić na „zasada żądającego”, ponieważ
tak właśnie ona działa. Gdy komputer lub serwer wysyła żądanie sieciowe skierowane do innej
maszyny, żąda nawiązania połączenia sieciowego. Na komputerach żądających — tych które
inicjują ruch — właśnie w tym miejscu informujemy, że ma zastosowanie zasada serwera IPsec.
Zasada ta nakazuje danemu komputerowi lub serwerowi zażądać szyfrowania protokołem
IPsec sesji komunikacyjnej ustanowionej między maszyną inicjującą a komputerem zdalnym.
Jeśli zdalny system obsługuje protokół IPsec, tworzony jest tunel IPsec w celu ochrony ruchu
pojawiającego się między dwoma urządzeniami. Zasada serwera nie jest jednak bezkompromi-
sowa, więc jeśli komputer zdalny nie obsługuje protokołu IPsec, połączenie sieciowe nadal działa,
ale pozostaje niezaszyfrowane.
Zasada serwera bezpiecznego

Różnica w porównaniu z poprzednią opcją polega na tym, że zasada serwera bezpiecznego
wymaga szyfrowania IPsec w celu umożliwienia komunikacji sieciowej. Zwykła zasada serwera,
o której wspomniałem powyżej, spowoduje, jeśli będzie to możliwe, zaszyfrowanie ruchu za
pomocą protokołu IPsec. Jeśli jednak nie będzie można zaszyfrować danych, ruch wciąż będzie
się odbywać w postaci niezaszyfrowanej. W przeciwieństwie do tego rozwiązania zasada
serwera bezpiecznego nie nawiąże połączenia, jeśli protokół IPsec nie będzie mógł zostać
użyty między dwoma komputerami.
Zasada klienta
Nazwę „zasada klienta” należałoby zmienić na „zasada odpowiadającego”, ponieważ ma ona
zastosowanie na drugim końcu połączenia. Zasady klienta nie interesuje żądanie nawiązania
sesji IPsec — zależy jej tylko na odbiorze. Gdy komputer wysyła żądanie sieciowe do drugiej
maszyny i używa zasady serwera lub serwera bezpiecznego, a więc żąda nawiązania połączenia
IPsec, to drugie urządzenie musi mieć przypisaną zasadę klienta, aby zaakceptować i ustanowić
tunel IPsec. Zasada klienta odpowiada, zezwalając na szyfrowanie danych w sesji połączenia.
Przystawka IP Security Policy

Dostęp do klasycznej konsoli pozwalającej na modyfikowanie ustawień IPsec można uzyskać
za pośrednictwem programu MMC. Otwórz go, a następnie dodaj do niego przystawkę IP
Security Policy Management (Zarządzanie zasadami zabezpieczeń IP). Co ciekawe, dodawszy
276
tę przystawkę, zauważysz, że możesz wyświetlić lokalną zasadę IPsec komputera, na którym

jesteś zalogowany, a także wyświetlić zasadę IPsec dla domeny. Jeśli chciałbyś więc skonfiguro-
wać protokół IPsec dla całej domeny, będzie to Twoje miejsce docelowe, w którym zmodyfi-
kujesz odpowiednie ustawienia. Aby jednak po prostu zapoznać się ze sposobem działania
konsoli i ją przetestować, możesz wybrać opcję Local computer (Komputer lokalny):
Po uruchomieniu przystawki możesz w niej zauważyć istniejące zasady IPsec, które zostały już
wcześniej utworzone. Możesz także rozpocząć tworzenie własnych zasad z użyciem opcji Create
IP Security Policy… (Utwórz zasadę zabezpieczeń IP…), dostępnej po kliknięciu prawym
przyciskiem myszy wiersza IP Security Policies (Zasady zabezpieczeń IP), znajdującego się
po lewej stronie okna. Spowoduje to uruchomienie kreatora, który skonfiguruje określone
zasady IPsec:
Użycie zapory WFAS

Nowszą platformą używaną do definiowania reguł połączeń IPsec jest zapora systemu Win-
dows Defender z zaawansowanymi zabezpieczeniami. Otwórz ją, ponieważ już wiesz, jak to
zrobić. Następnie przejdź do sekcji Connection Security Rules (Reguły zabezpieczeń połączeń),
która znajduje się bezpośrednio pod opcjami Inbound Rules (Reguły przychodzące) i Outbound
Rules (Reguły wychodzące). W tym miejscu ustalisz reguły połączenia IPsec. Jeśli klikniesz
prawym przyciskiem myszy pole Connection Security Rules, a następnie wybierzesz opcję
New Rule… (Nowa reguła…), uruchomisz kreatora podobnego do tego, który służy do tworzenia
reguły zapory:
277
Gdy pojawi się okno kreatora, będziesz mógł zauważyć, że dostępne opcje są zupełnie inne
niż te, które zostają wyświetlone podczas tworzenia nowej reguły zapory. W tym miejscu
ustanawiasz reguły bezpieczeństwa połączeń IPsec definiujące formę tuneli IPsec oraz okre-
ślające urządzenia lub adresy IP, które muszą być aktywne:
W tej książce nie możemy co prawda omówić szczegółowo wszystkich dostępnych opcji tego
kreatora, ale zdecydowanie zalecam zdobycie dodatkowej wiedzy na ten temat przez zapoznanie
się z artykułem opublikowanym w witrynie TechNet i dostępnym pod następującym adresem:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-
-and-2012/hh831807(v=ws.11).
Hasła zabronione
Jeśli jesteś klientem usługi Azure Active Directory, masz już dostęp do tej nowej funkcji
zwanej hasłami zabronionymi. Pomysł jest następujący: firma Microsoft utrzymuje globalną
i wciąż aktualizowaną listę złych haseł (takich jak słowo hasło) i automatycznie blokuje
278
wszystkie ich warianty: H@sło, Hasło123 itd. Każde z tych potencjalnych haseł zostanie
całkowicie zablokowane, jeśli użytkownik kiedykolwiek spróbuje ich użyć. W interfejsie
usługi Azure Active Directory masz również możliwość dodawania własnych niestandardowych
haseł zabronionych. Po uruchomieniu funkcji blokowania haseł na platformie Azure można
ją następnie przenieść do lokalnego środowiska Active Directory, wdrażając usługę pośrednika
do ochrony haseł w Azure Active Directory (co to za nazwa!). Interfejs pośrednika między
lokalnymi kontrolerami domeny a usługą Azure Active Directory zapewnia, że hasła, które
użytkownicy próbują zapisać na lokalnych kontrolerach domeny, są zgodne z regułami określo-
nymi przez algorytmy haseł zabronionych na platformie Azure.
Aby skorzystać z tej technologii, musisz oczywiście być klientem usługi Azure Active Directory,
więc nie każdy może się nią cieszyć. Jeśli jednak używasz usługi Azure Active Directory
i synchronizujesz z nią swoje środowisko, ta technologia może nawet zostać zaimportowana
do starszych wersji lokalnych kontrolerów domeny, takich jak Windows Server 2012.
Oto odnośnik do bardziej szczegółowych informacji dotyczących haseł zabronionych:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-
-bad-on-premises.
Zaawansowana analiza zagrożeń

Moim zdaniem jedną z najciekawszych funkcji bezpieczeństwa, które zostały stworzone
przez firmę Microsoft w ciągu ostatnich kilku lat, jest zaawansowana analiza zagrożeń (ang.
Advanced Threat Analytics — ATA), a jednak prawie nikt się tą usługą nie interesuje. Nie jest to
jeszcze funkcja wbudowana w system operacyjny Windows Server, ale lokalne oprogramowanie,
które ma bardzo ciekawą funkcjonalność. Zasadniczo usługa ATA monitoruje cały ruch
w środowisku Active Directory. W czasie rzeczywistym ostrzega przed niebezpiecznymi lub
nietypowymi zachowaniami, natychmiast po ich wystąpieniu.
Zasada działania usługi ATA jest dość prosta do zrozumienia i tak logiczna, że wszyscy zastana-
wiają się, dlaczego tak długo zajęło jej wdrożenie. Powodem jest to, że uczenie się usługi ATA
i przetwarzanie przez nią danych jest bardzo zaawansowane. Tak — napisałem „uczenie
się”. Jest to najciekawsza funkcjonalność usługi ATA. Swoją sieć powinieneś skonfigurować
tak, aby cały ruch wychodzący z kontrolerów domeny oraz do nich wchodzący trafiał rów-
nież do systemu ATA. Najbezpieczniejszym sposobem spełnienia tego wymagania na poziomie
sieci jest uruchomienie klonowania portów (ang. port mirroring), aby wszystkie pakiety uży-
wane przez kontroler domeny też trafiły do usługi ATA, ale na poziomie, którego atakujący nie
byłby w stanie zobaczyć. Dzięki temu, nawet jeśli w Twojej sieci znajduje się włamywacz
i sprawdza, czy jakieś zabezpieczenia są aktywne, usługa ATA pozostaje niewidoczna dla je-
go wścibskich oczu. Jednak mniejsze firmy mogą nie być w stanie wykonać klonowania por-
tów lub jego wstępna konfiguracja może być dla nich zbyt skomplikowana. Dlatego istnieje dru-
ga opcja, polegająca na zainstalowaniu niewielkiego agenta ATA bezpośrednio na samych
kontrolerach domeny. Agent ten wysyła następnie niezbędne informacje do serwerów przetwa-
rzania usługi ATA.
279
W każdym z tych dwóch przypadków serwery przetwarzania usługi ATA otrzymują wszystkie
dane i zaczynają wyszukiwać wzorce. Jeśli Beata korzysta z komputera stacjonarnego o nazwie
BEATA-PC i tabletu o nazwie BEATA-TABLET, usługa ATA rozpozna ten wzorzec działania
i powiąże konto użytkownika Beaty z tymi urządzeniami. Usługa zauważa również jej standar-
dowy styl pracy. Beata zwykle loguje się do komputera w przybliżeniu o 8 rano, a wychodzi
do domu około godziny 17. Zwykle korzysta z kilku serwerów plików i serwera SharePoint.
Po mniej więcej tygodniu gromadzenia i monitorowania danych usługa ATA ma całkiem
niezłe pojęcie o standardowym dniu pracy Beaty.
Pewnej nocy coś się dzieje. Usługa ATA zauważa kilka błędów podczas używania hasła do
konta Beaty. To samo w sobie może nie być zbyt ekscytujące, ale za chwilę Beata loguje się
do serwera terminali, którego zazwyczaj nie używa. Następnie jej dane uwierzytelniające są
używane do uzyskania dostępu w kontrolerze domeny. To wygląda na atak! Co możemy zrobić za
pomocą zwykłych narzędzi istniejących w usłudze Active Directory? Niewiele. Jeśli przejrzymy
dzienniki zdarzeń, możemy zauważyć wpisy o próbach wprowadzenia błędnego hasła. Na
tej podstawie moglibyśmy spróbować przeszukać dzienniki zdarzeń innych serwerów, aby
dowiedzieć się, do jakich systemów miało dostęp dane konto, ale tak naprawdę nie mieliby-
śmy powodu, aby podejrzewać coś poważniejszego. To mógłby jednak być początek bardzo
niebezpiecznego ataku, którego nigdy byśmy nie wykryli. Na szczęście usługa ATA wie lepiej,
co się dzieje.
Interfejs zarządzania usługą ATA przypomina kanał społecznościowy, aktualizowany niemal

w czasie rzeczywistym. Gdybyśmy śledzili wyświetlanie informacji przez usługę ATA pod-
czas wydarzeń, które powyżej przedstawiłem, zobaczylibyśmy po kolei wszystkie mające
miejsce zdarzenia i od razu stałoby się oczywiste, że ktoś włamał się do konta Beaty i wyko-
rzystał je do uzyskania dostępu do kontrolera domeny. Do tej pory nie było jeszcze techno-
logii, która by tak intensywnie obserwowała ruch w usłudze Active Directory, a na pewno
takiej, która uczyłaby się wzorców i określonych zachowań. To naprawdę niesamowita usługa
i nie piszę tego tylko dlatego, że znam osoby, które ją zaprojektowały. Mogę zapewnić, że są
one genialne, co jest dość oczywiste, ponieważ zostały przejęte przez firmę Microsoft.
Usługa ATA wciąż jest na tyle nowa, że większość społeczności IT nie miała jeszcze z nią do
czynienia, więc gorąco zachęcam, by to zmienić. Któregoś dnia może Ci pomóc ocalić własną
skórę. Poniżej przedstawiam zrzut ekranu interfejsu sieciowego usługi ATA, dzięki czemu
możesz zobaczyć, jak wygląda w nim wysyłanie informacji w stylu kanału społecznościowe-
go. Ten zrzut ekranu został wykonany podczas działania wersji demo produktu. W tym przy-
padku użytkownikowi na potrzeby prezentacji skradziono token protokołu Kerberos, a następnie
wykorzystano go na innym komputerze w celu uzyskania dostępu do niektórych poufnych
plików, do których powinien mieć dostęp tylko użytkownik Demi Albuz. Chociaż usługa
ATA nie zatrzymała tej aktywności, natychmiast (mam na myśli: w ciągu kilku sekund), zaalar-
mowała na kanale, że właśnie odbywa się atak Pass-the-Ticket:
280
Oto następny przykład, w którym użytkownik o nazwie Almeta Whitfield nagle uzyskał dostęp
do 16 komputerów, których zazwyczaj nie używa. To kolejne poważne ostrzeżenie, że coś
dzieje się z kontem użytkownika:
Aby uzyskać więcej informacji na temat usługi ATA lub rozpocząć korzystanie z niej, zapoznaj się
z następującym odnośnikiem: https://docs.microsoft.com/en-us/advanced-threat-analytics/what-is-ata.
281
Najważniejsze wskazówki dotyczące

ogólnego bezpieczeństwa
Aby zabezpieczyć swoje środowisko, czasami musimy polegać tylko na sobie, a niekoniecz-
nie na funkcjonalności zapewnianej przez system operacyjny. Istnieje wiele zdroworozsądko-
wych metod administrowania, które są łatwe do wdrożenia, ale rzadko stosowane w prakty-
ce. Oto kilka wskazówek i sztuczek, których nauczyłem się przez lata i które pomogłem
stosować w firmach. Mam nadzieję, że jako czytelnik tej książki, uzupełnisz tę listę o pozy-
cje, które sam sprawdziłeś. Bez względu na to ten rozdział powinien Cię zachęcić do opra-
cowania twórczych sposobów, dzięki którym będziesz mógł ograniczyć prace administracyjne,
a dodatkowo zwiększyć bezpieczeństwo sieci.
Pozbycie się wiecznych administratorów

Czy wszyscy pracownicy IT otrzymują uprawnienia administratora domeny w dniu ich zatrud-
nienia? Czy któryś z Twoich pracowników IT może odczytać hasło do wbudowanego konta
administratora domeny? Czy zwykli użytkownicy mają uprawnienia administracyjne na
swoich komputerach? Wiesz, co mam na myśli — tego typu rozwiązania są nie do przyjęcia!
Niestety, takie praktyki były stosowane przez wiele lat w prawie każdej organizacji i do tej pory
nie zniknęły całkowicie. Nadal regularnie obserwuję, jak inżynierowie podczas konfigurowania
nowo tworzonych serwerów wykorzystują do wielu zadań ogólne konto administratora domeny.
Tak, mają oni dostęp do potencjalnie najważniejszego konta w sieci i używają go do codziennych
zadań. Co gorsza, każda czynność wykonywana za pomocą tego konta użytkownika staje się
anonimowa. Co mam na myśli? Gdy przy użyciu ogólnego konta administratora konfiguruję
nowy serwer lub wprowadzam zmiany w istniejącej maszynie, powoduje to powstanie poważne-
go problemu, ponieważ nikt nie może udowodnić, że to ja wykonałem te działania. Korzystanie
z ogólnych kont użytkowników to bardzo dobry sposób na uniknięcie odpowiedzialności
w przypadku, gdy coś się nie powiedzie. Nie zamierzam oczywiście sugerować, że zawsze
szukasz winnego, ale jeśli popsułbym coś na serwerze aplikacji, którym zazwyczaj nie admini-
struję, byłoby miło, gdyby osoby próbujące go naprawić mogłyby szybko znaleźć sprawcę
i dowiedzieć się, co takiego zrobił, a to na pewno pomogłoby w rozwiązaniu problemu. Istnieje
wiele powodów, dla których korzystanie z wbudowanego konta administratora powinno być
zabronione.
Jeśli chodzi o stronę klienta: czy Twoi użytkownicy naprawdę potrzebują praw administracyjnych
na swoich komputerach? Jesteś pewien? Prawdopodobnie znalazłbyś inne rozwiązanie. Obniże-
nie uprawnień użytkowników na ich komputerach do poziomu standardowego, lub nawet roz-
szerzonego, ale poniżej administratora lokalnego, może mieć ogromny wpływ na bezpie-
czeństwo systemów. Jeśli przed kontynuowaniem procedury instalowania oprogramowania
użytkownik musi jawnie wydać zgodę na użycie uprawnień administratora, zmniejsza się
prawdopodobieństwo zainfekowania systemu przez wirusy. Taki sposób pracy pozwala również
zachować wszystkie komputery w znacznie spójniejszym stanie, ponieważ nie będą one zawierać
282
żadnych niedozwolonych w firmie ani nieznanych aplikacji, a także ustawień wprowadza-

nych przez użytkownika.
Korzystanie z odrębnych kont w celu uzyskania dostępu

administracyjnego
Ten pomysł jest związany z powyżej wspomnianym problemem i obecnie staram się go realizo-
wać nawet w komputerach domowych, które instaluję dla przyjaciół i członków rodziny. Jest
on prosty i w rzeczywistości sprowadza się do następującej zasady: używaj dwóch różnych kont
użytkowników — jednego z dostępem administracyjnym, a drugiego zwykłego. Gdy wykorzy-
stujesz system do codziennych zadań, upewnij się, że jesteś zalogowany za pomocą zwykłego
konta użytkownika, które nie ma uprawnień administracyjnych ani na komputerze lokalnym,
ani w domenie. Jeśli wówczas spróbujesz coś zainstalować (lub coś spróbuje się samo zainstalo-
wać), za pomocą okna kontroli konta użytkownika (UAC) zostaniesz poproszony o podanie
nazwy i hasła użytkownika administracyjnego, zanim instalator zacznie cokolwiek robić.
Mogę stwierdzić, że ten sposób działa, ponieważ dzięki niemu podczas przeglądania internetu
w celu prowadzenia badań nad pewnym projektem uchroniłem swój komputer przed zainstalo-
waniem na nim wielu wirusów. Jeśli mimo tego, że nie kliknąłem żadnego pliku instalacyjnego,
pojawi się okno UAC z prośbą o podanie hasła administratora, będę wiedział, że jest to coś,
czego nie chciałbym mieć w swoim komputerze. Wystarczy wówczas kliknąć przycisk Nie,
a program na pewno się nie zainstaluje. Z drugiej strony, jeśli rzeczywiście mam zamiar coś
zainstalować, to wprowadzenie hasła do konta administracyjnego, by umożliwić instalatorowi
kontynuowania działania, jest naprawdę niewielką niedogodnością.
Utrzymanie dwóch oddzielnych kont pozwala na wykonywanie większości codziennych zadań.

Jednocześnie będziesz pewien, że nie masz odpowiednich uprawnień, by coś uszkodzić
w systemie. Ten sposób pracy ogranicza również wykorzystanie kont administracyjnych do
zarządzania komputerem w sieci, a także ułatwia monitorowanie ich aktywności, gdy są używane
do wprowadzania zmian w środowisku.
Używanie innego komputera do wykonywania zadań

administracyjnych
Gdybyś chciał zwiększyć poziom bezpieczeństwa i jeszcze bardziej rozwinąć pomysł polegający
na stosowaniu odrębnych kont użytkowników, mógłbyś korzystać z innego komputera pod-
czas wykonywania zadań na poziomie administracyjnym. Stosuj jeden komputer do wykonywa-
nia zwykłych zadań, a drugi do administrowania systemami. Z pewnością pomogłoby to zwięk-
szyć bezpieczeństwo Twojego komputera, a także zdalnych systemów, do których ma on dostęp.
Chociaż wydaje się, że posiadanie dwóch fizycznych komputerów na biurku jest uciążliwe,
pamiętaj, że w przypadku większości wersji systemu Windows 10 mamy możliwość uruchamia-
nia funkcji Hyper-V bezpośrednio na swoich komputerach stacjonarnych. Tak właśnie robię.
Mam komputer z systemem Windows 10. Uruchamiam w nim za pośrednictwem funkcji
Hyper-V maszynę wirtualną, z której wykonuję wszystkie zadania administracyjne dotyczące
283
szczególnie ważnych serwerów. Zgadzając się na kompromis podczas korzystania ze swojego

systemu operacyjnego, nie stosuję żadnych ustępstw dotyczących całego środowiska.
Bez względu na to, czy zdecydujesz się rozdzielić dostęp administracyjny na poziomie konta
użytkownika czy komputera, pamiętaj o następującej prostej zasadzie: nigdy nie zarządzaj usługą
Active Directory z tego samego miejsca, z którego przeglądasz Facebooka. Myślę, że jest to cał-
kiem dobre podsumowanie powyższej analizy.
Nigdy nie przeglądaj internetu, będąc zalogowanym

na serwerze
Wydaje się, że jest to oczywista zasada, ale niestety właściwie każdy administrator ją łamie. Przez
cały dzień zarządzamy serwerami i bardzo często musimy korzystać z przeglądarki internetowej.
Ponieważ program Internet Explorer jest domyślnie zainstalowany na serwerach Windows,
czasami po prostu szybciej i łatwiej można coś sprawdzić z konsoli maszyny, na której jest się
zalogowanym, zamiast wrócić do biura. Oprzyj się pokusie! Bardzo łatwo można pobrać niebez-
pieczne treści z internetu, szczególnie w przypadku serwerów, jeśli bowiem jakiekolwiek maszyny
w danej sieci działają bez ochrony antywirusowej, prawdopodobnie są nimi właśnie serwery.
To samo dotyczy filtrowania treści internetowych. Zawsze staramy się, by komputery użytkowni-
ków wykorzystywały korporacyjną bramę pośredniczącą (jeśli jest), ale nie zawsze dbamy o to,
by ruch sieciowy wychodzący z serwerów również przez nią przechodził.
Nie loguj się w taki sposób nawet w witrynach, którym ufasz. Atak typu man-in-the-middle
lub przejęcie strony internetowej może łatwo uszkodzić system serwerowy. Pamiętaj, że o wiele
łatwiej jest odtworzyć komputer użytkownika niż sam serwer.
Kontrola dostępu oparta na rolach

Mechanizm kontroli dostępu opartej na rolach (ang. Role-Based Access Control — RBAC)
nie ogranicza się do środowisk firmy Microsoft. Nie jest to również określona technologia,
którą można wykorzystać w systemie Windows Server 2019, ale jest to metoda polegająca na
oddzieleniu ról i obowiązków. Gdy zamierzamy oddzielić role pracowników od zagadnień
związanych z IT, tradycyjnie chcemy to rozwiązać za pomocą grup w usłudze Active
Directory. Chociaż dodawanie kont użytkowników do grup rozwiązuje wiele problemów związa-
nych z podziałem poziomów uprawnień i dostępu, rozwijanie tej metody może być skompli-
kowane, a ostatecznie administratorzy nadal mają pełny dostęp do samych grup. Technologie
RBAC dzielą role na innym poziomie, dbając o coś więcej niż tylko o poziom uprawnień.
Mechanizm RBAC koncentruje się bardziej na opisach stanowisk pracowników niż na ograni-
czeniach dostępu. Istnieje wiele różnych technologii, które wykorzystują narzędzia RBAC.
Są nawet dostępne zewnętrzne rozwiązania RBAC, które obsługują całą istniejąca infrastrukturę,
dzięki czemu są szeroko dostępne w całej organizacji i nie ograniczają się do jednej domeny
lub jednego lasu.
284
Just Enough Administration

Doskonałym przykładem technologii RBAC zawartej w systemie Windows Server 2019 jest
opcja Just Enough Administration (JEA), która jest elementem środowiska PowerShell.
JEA umożliwia przyznanie użytkownikom szczególnego, uprzywilejowanego dostępu, bez
konieczności nadawania im uprawnień administracyjnych, które były wymagane w przeszłości
do wykonywania tych samych obowiązków. Dodawanie użytkownika do serwerowej grupy
administratorów, aby mógł poprawnie wykonać swoją pracę, jest dość powszechnie stosowanym
rozwiązaniem, jednakże opcja JEA pozwala uniknąć tego kroku.
Myśląc „po staremu”, moglibyśmy łatwo potraktować JEA jako działanie polegające na umożli-
wieniu użytkownikom uzyskania dostępu administracyjnego w programie PowerShell, nawet
jeśli nie mają oni takiego pełnego dostępu do samego systemu operacyjnego. Jednak opcja
JEA jest czymś więcej. Pozwala ona uzyskać użytkownikom dostęp administracyjny tylko do
określonych instrukcji i poleceń cmdlet programu PowerShell. Uprawnienia do pozostałych
składników PowerShell pozostają na standardowym poziomie.
W rzeczywistości, jeśli użytkownik wykorzystuje opcję JEA w środowisku PowerShell i próbuje

wywołać polecenie cmdlet, do którego nie ma odpowiednich uprawnień, PowerShell udaje,
że go nie rozpoznaje. Nie informuje użytkownika „przepraszam, nie możesz tego zrobić” —
po prostu ignoruje polecenie! To zdecydowanie pomaga trzymać głodnego misia z dala od słoika
z miodem, chyba że chcesz go świadomie dla niego otworzyć.
Pójdźmy o krok dalej. Być może jesteś administratorem serwera DNS i wiesz, że czasami
trzeba restartować usługi DNS. Ponieważ przyjmujemy sposób pracy typowy dla zasad JEA
i RBAC, nie powinieneś mieć uprawnień administracyjnych w systemie operacyjnym serwera
DNS, ale będziesz mieć uprawnienia oparte na JEA w programie PowerShell, co pozwoli Ci na
uruchamianie narzędzi, których potrzebujesz w swojej pracy. Ponowne uruchomienie usługi
DNS wymaga dostępu do polecenia cmdlet Restart-Service, zgoda? Ale czy to nie oznacza, że
będę mógł zrestartować dowolną usługę na serwerze i przez to potencjalnie będę mógł wykonać
różne działania, które nie należą do moich obowiązków? Opcja JEA jest tak sprytna, że może sobie
poradzić także z takim scenariuszem. Podczas konfigurowania poziomu dostępu, jaki musi uzy-
skać użytkownik, możesz definiować szczegółowe uprawnienia dotyczące poszczególnych
poleceń cmdlet. W przypadku naszego przykładu możesz co prawda zapewnić użytkownikowi
dostęp do polecenia cmdlet Restart-Service, ale dać mu tylko uprawnienia do restartowania
określonych usług, takich jak te, które są związane z DNS. Jeśli użytkownik spróbuje użyć pole-
cenia Restart-Service dla innej usługi, choćby WINrm, zakończy działanie niepowodzeniem.
Podsumowanie
Najważniejszym zadaniem w tym roku dla wielu szefów działów IT jest zapewnienie bezpie-
czeństwa. Bezpieczeństwa komputerów klienckich, bezpieczeństwa sieci, bezpieczeństwa
zasobów w chmurze i, co najważniejsze, bezpieczeństwa danych. Nie ma jednego uniwersalnego
rozwiązania, które zabezpieczy całą Twoją infrastrukturę. Zapewnienie odpowiedniego poziomu
285
bezpieczeństwa zasobów wymaga użycia wielu składników i różnych technologii, które współ-
pracują ze sobą. Celem tego rozdziału było przedstawienie przykładowych środków bezpieczeń-
stwa i technologii, które można wykorzystać w dowolnym środowisku, a także wskazanie na wy-
sokie znaczenie bezpieczeństwa w dzisiejszym świecie IT. Zagadnienia dotyczące prywatności
i bezpieczeństwa należy analizować w przypadku każdego rozwiązania technologicznego, które
instalujemy. Zbyt często zdarza się, że w organizacjach są wdrażane nowe aplikacje bez brania
pod uwagę ich poziomu bezpieczeństwa. Aplikacje, które przesyłają lub przechowują dane nie-
zaszyfrowane, wymagają modyfikacji lub odinstalowania. Ochrona informacji ma zasadnicze
znaczenie dla trwałości naszych firm.
Nie możemy zakończyć dyskusji o bezpieczeństwie w systemie Windows Server 2019 bez
omówienia domyślnej opcji instalacji systemu operacyjnego, którą w tej książce do tej pory
ignorowaliśmy. Przejdź więc do następnej strony, aby mieć możliwość zapoznania się z bezob-
sługową i bardziej odporną na ataki wersją systemu Windows Server zwaną Server Core.
Pytania
1. Jak nazywa się produkt chroniący przed atakami typu malware dostępny w systemie
Windows Server 2019?
2. Który profil zapory Windows Defender powinien być aktywny, gdy komputer
przyłączony do domeny znajduje się w korporacyjnej sieci LAN?
3. Jakie są, oprócz profilu domeny, dwa możliwe do wykorzystania profile zapory
Windows Defender?
4. Jaki typ protokołu należy określić w regule wejściowej podczas tworzenia reguły
zapory, która zezwala na komunikację z poleceniem ping dla protokołu IPv4?
5. Jaki jest najłatwiejszy sposób na przekazanie wszystkim pracownikom
znormalizowanych reguł zapory Windows Defender?
6. Jak nazywamy maszyny wirtualne, których pliki wirtualnego dysku twardego
zostały zaszyfrowane?
7. Jak nazywa się technologia firmy Microsoft, która analizuje dane przesyłane
do kontrolera domeny w celu identyfikacji ataków typu pass-the-hash i pass-the-ticket?
286
8
Server Core
Kochanie, zmniejszyłem serwer! Kolejny rozdział, kolejne odwołanie do starego filmu. Przez
ostatnie 20 lat przyglądaliśmy się rozwojowi systemów operacyjnych firmy Microsoft. Taki roz-
wój może mieć dobry skutek — nowe funkcje i ulepszenia ułatwiają nam życie. Przynosi on jed-
nak także niedogodności, na przykład zbyt duże struktury plików i interfejsy graficzne powodu-
jące nadmierne zużycie pamięci. Jeśli porównałbyś systemy operacyjne Windows oraz Windows
Server i wyznaczył ich wielkość na podstawie takich czynników, jak zużycie miejsca na dysku
i wymagania dotyczące pamięci, okazałoby się, że każda nowa wersja jest obszerniejsza od
poprzedniej — wymagałaby nieco więcej mocy obliczeniowej i miejsca na dysku twardym.
Tak było prawdopodobnie do momentu wydania wersji Windows 8 i Server 2012. W celu ob-
niżenia wymagań związanych z zasobami zostały podjęte pewne działania, co było mile widzianą
zmianą. Ale zmiana ta nie była zbyt dramatyczna. Mam na myśli choćby to, że nowa wersja
Windows Server 2019 wciąż zawiera w katalogu C:\Windows\System32 wszystkie podstawowe
pliki. Nie chcę nawet wspominać o tym, co znajduje się w rejestrze. Oczywiście, nadal można
coś usunąć, ale na pewnym poziomie nowe systemy operacyjne wciąż są tworzone na podstawie
ich starszych wersji.
Teraz coś się być może zmieniło. W tym rozdziale omówimy alternatywny sposób korzysta-
nia z systemu Windows Server 2019, na znacznie mniejszą skalę. Opcja Server Core istnieje
już od dłuższego czasu, ale nie znam wielu osób, które faktycznie z niej korzystają. Ta zminiatu-
ryzowana wersja systemu Server 2019 została stworzona, aby udostępnić mniej wymagającą,
wydajniejszą i bezpieczniejszą platformę serwerową.
W tym rozdziale zaprezentuję następujące zagadnienia:

 Dlaczego warto korzystać z wersji Server Core?
 Używanie systemu Server Core.
 Wykorzystanie aplikacji Windows Admin Center do zarządzania systemem Server Core.
 Narzędzie Sconfig.
 Role dostępne w wersji Server Core.
 Co się stało z systemem Nano Server?
Dlaczego warto korzystać

z wersji Server Core?
Dlaczego w ogóle wspominam o wersji Server Core? Czy nie istnieje już od około 2008 roku?
Tak, właśnie dlatego chcę o niej napisać. Wersja Server Core systemu operacyjnego Windows
Server jest dostępna już od dłuższego czasu, ale wygląda na to, że wielu administratorów boi
się jej użyć. Współpracuję z wieloma firmami z różnych branż. Wszystkie mają jedną wspólną
cechę: używają serwerów Windows, które zawierają w pełni graficzny interfejs użytkownika
(wersja Desktop Experience). Czy administratorzy w tych firmach słyszeli o wersji Server
Core? Oczywiście. Czy testowali ją kiedyś w laboratorium? Czasami. Wydaje się, że każdy
ma nieco inny poziom doświadczenia z wersją Core, jednak rzadko jest wykorzystywana w roli
środowiska produkcyjnego. Może po prostu spotykam się z niewłaściwymi ludźmi, ale muszę
stwierdzić, że większość z nas, w tym ja, powinna zacząć korzystać z wersji Server Core w bardziej
regularny sposób.
Dlaczego powinniśmy zacząć korzystać z wersji Server Core? Ponieważ firma Microsoft uważa,
że serwery bez graficznego interfejsu użytkownika to przyszłość. Czy uwierzysz, że we wcze-
snych wersjach systemu Windows Server 2016 w ogóle nie istniała opcja Desktop Experience?
W takich wersjach nie mogłeś uruchomić w pełni graficznego interfejsu, z wyjątkiem niewielkiej
pseudopowłoki, którą można było zainstalować na serwerze Core. Firma Microsoft otrzymała
z tego powodu tyle słów krytyki, że opcja pełnego, graficznego pulpitu została dodana już
w jednej z wersji Technical Preview. Mimo to prawdopodobnie zauważyłeś, że Server Core
stał się domyślną opcją instalacji każdego systemu operacyjnego Windows Server. Pamiętasz, że
w jednym z początkowych rozdziałów tej książki analizowaliśmy faktyczną instalację systemu Se-
rver 2019? Domyślną opcją instalacji nie jest już Desktop Experience. Zamiast niej najważniej-
szą opcją na poniższym zrzucie ekranu jest wersja Server Core z wierszem poleceń:
288
Rozdział 8. • Server Core
Jednym z powodów odejścia od interfejsu graficznego są zwiększone możliwości automaty-

zacji i skalowalności. Gdy wszystkie nasze serwery mają podobną do siebie budowę, oznacza
to, że możemy wykonywać za ich pomocą więcej funkcji zbliżonych do przetwarzania
w chmurze. Przydzielanie w razie potrzeby większej lub mniejszej ilości zasobów, wdrażanie
dziesiątek serwerów jednym kliknięciem przycisku — tego rodzaju automatyzacje i dopasowy-
wanie rozmiarów są możliwe w chmurze tylko dlatego, że jej infrastruktura jest bardzo
znormalizowana. Zasoby sprzętowe w chmurze powinny być tak zoptymalizowane, aby narzę-
dzia operacyjne i automatyzacyjne mogły wykonać to, co jest od nich wymagane, bez potrzeby
zarządzania wszystkimi parametrami, które byłyby obecne w zmodyfikowanym przez użyt-
kownika interfejsie graficznym.
Istnieją też inne oczywiste zalety korzystania z tej uproszczonej, ograniczonej wersji systemu
operacyjnego. Server Core zajmuje mniej miejsca na dysku twardym, a oprócz tego charaktery-
zuje się mniejszym zużyciem pamięci oraz mniejszą podatnością na ataki od tradycyjnego,
pełnowymiarowego serwera. Teraz już wiesz, dlaczego przed chwilą tak kategorycznie stwier-
dziłem, że wszyscy powinniśmy zacząć używać systemu Server Core! Weźmy pod uwagę wiel-
kość serwera. Podstawowa wersja systemu Server 2019 Standard z uruchomioną opcją Desktop
Experience zajmuje około 10 GB na dysku twardym. Przed chwilą to sprawdziłem — odczyta-
łem właściwości swojego wirtualnego pliku dysku twardego używanego przez serwer CA1.
Ma on zainstalowany standardowy system Windows Server 2019 z pełną opcją Desktop
Experience. Po jakimś czasie ukończyłem instalację swojego pierwszego systemu operacyjnego
Server Core i okazało się, że plik VHDX używany przez nową maszynę wirtualną ma wielkość
tylko 5,8 GB, co oznacza 40% mniej miejsca w porównaniu z poprzednim rozmiarem. Przedsta-
wia to poniższy zrzut ekranu:
Zmiana wersji w locie jest już niemożliwa

Chciałbym zamieścić bardzo ważną uwagę: te osoby, którzy używały wersji Server Core w sys-
temie Windows Server 2012 R2, wiedzą, że istniała możliwość zmiany wersji serwera w locie.
Mam na myśli to, że jeśli zainstalowałeś nowy serwer z pełną wersją Desktop Experience,
mogłeś go później zmienić na Server Core. Odwrotne działanie również było możliwe — mogłeś
użyć wersji Server Core i zmienić ją na Desktop Experience.
289
Teraz nie jest to już dopuszczalne! Możliwość zmiany wersji serwera została zlikwidowana.
Powtarzam, taka operacja nie jest dostępna. Obecnie musisz się dokładnie zastanowić, jaką wer-
sję systemu operacyjnego chciałbyś zainstalować. Jeśli wdrożysz nowy serwer w wersji Server
Core, będzie on musiał pozostać w tej odmianie przez cały okres jego użytkowania.
Używanie systemu Server Core

Po zainstalowaniu systemu Server Core zostanie wyświetlony następujący ekran blokady:
Czy naprawdę widać tu okno wiersza poleceń z komunikatem Press Ctrl-Alt-Del to unlock
(Naciśnij Ctrl+Alt+Del, aby odblokować)? Tak, zgadza się. Gdy administrator widzi je po
raz pierwszy, wywołuje to zwykle u niego stłumiony śmiech. W każdym razie ja tak zarea-
gowałem. Ten ekran przypomniał mi trochę kodowanie prostych gier na kalkulatorach TI-83
w liceum matematycznym. Naciśnij klawisze Ctrl+Alt+Del, a zostaniesz poproszony o zmianę
hasła administratora, co jest tym samym zadaniem, które zawsze musi zostać wykonane na sa-
mym początku w wersjach graficznych systemu Windows Server. Wyjątkiem oczywiście jest
to, że wszystko wykonujesz z poziomu okna wiersza poleceń, wyłącznie z użyciem klawiatury.
Po formalnym zalogowaniu się do serwera zostanie uruchomiony klasyczny wiersz poleceń
C:\Windows\system32\cmd.exe, a migający kursor będzie oczekiwać na instrukcje:
Co ciekawe, okno wiersza poleceń nie zajmuje całego ekranu. Oczywiście, za okno z czar-
nym tłem odpowiada program cmd.exe. Jest to ważna uwaga, ponieważ można stwierdzić, że
sam system operacyjny Core jest czymś więcej niż tylko wierszem poleceń, a cmd.exe jest wy-
290
łącznie aplikacją, która uruchamia się automatycznie po zalogowaniu. Możesz nawet użyć myszy
i zmienić rozmiar okna wiersza poleceń lub go przesunąć. Zastanawiam się, czy (i kiedy) w jego
miejsce pojawi się okno programu PowerShell, które stanie się domyślnym interfejsem.
Jeszcze bardziej interesujące jest odkrycie, że z okna wiersza poleceń można uruchamiać
niektóre aplikacje używające interfejsu graficznego. Na przykład mógłbyś otworzyć Notatnik
i korzystać z niego zarówno przy użyciu klawiatury, jak i myszy — tak jak w przypadku dowolnej
innej wersji systemu Windows. Jeśli więc masz otwarty Notatnik, stwórz notatkę, a następnie
zapisz ją. Widzimy, że na dysku istnieje prawdziwa struktura plików i zestaw względnie normal-
nie wyglądających folderów systemowych. Tak więc Server Core nie jest niczym magicznym,
lecz faktycznie prawdziwym systemem operacyjnym Windows Server, umieszczonym w mniej-
szym i bezpieczniejszym pudełku:
PowerShell
Jeśli więc chodzi o zarządzanie systemem Server Core, możesz oczywiście pracować bezpośred-
nio z konsoli i używać wiersza poleceń, który wydaje się domyślnym interfejsem prezentowanym
przez system operacyjny. W rzeczywistości jednak polecenia i funkcje dostępne z poziomu
tego programu będą ograniczone. Jeśli jesteś zalogowany do konsoli systemu Windows Server
Core, o wiele bardziej sensowne będzie zastosowanie wiersza poleceń tylko w jednym celu,
a mianowicie do wywołania programu PowerShell, którego następnie możesz użyć do wykony-
wania wszelkich koniecznych zadań na tym serwerze. Najszybszym znanym mi sposobem,
aby przejść do okna programu PowerShell z podstawowego wiersza poleceń, jest po prostu
napisanie powershell i naciśnięcie klawisza Enter. Spowoduje to przeniesienie możliwości pro-
gramu PowerShell bezpośrednio do istniejącego okna wiersza poleceń, dzięki czemu będzie
291
można rozpocząć używanie nowych instrukcji i poleceń cmdlet, które są wymagane, by rzeczy-
wiście można było zarządzać serwerem:
Co zazwyczaj wykonujemy na nowo utworzonych serwerach? Oczywiście przypisujemy im

adresy IP. Bez połączenia sieciowego mamy z serwera niewiele pożytku. W przypadku każdego
nowszego systemu operacyjnego Windows Server informacje o adresie IP możesz przypisać
do kart sieciowych za pomocą programu PowerShell, ale większość z nas nie ma zwyczaju
tak czynić. Ponieważ nie możemy po prostu otworzyć panelu sterowania i wejść do centrum
sieci i udostępniania, tak jak zwykliśmy to robić za pomocą graficznego interfejsu użytkownika,
należy się zastanowić, od czego powinniśmy zacząć, aby skonfigurować połączenie sieciowe
w nowym serwerze Core.
Użycie poleceń cmdlet do zarządzania adresami IP

Oto polecenia cmdlet, których można używać z poziomu programu PowerShell do wyświetlania
i modyfikowania ustawień związanych z adresacją IP. Można je oczywiście także wykorzystywać
w systemie Windows Server wyposażonym w pełną wersję interfejsu graficznego.
W przypadku wersji Server Core, w której jest dostępny jedynie interfejs wiersza poleceń,
poniższe polecenia cmdlet są niezbędne do zdefiniowania połączenia sieciowego na nowym
serwerze:
 Get-NetIPConfiguration: wyświetla bieżącą konfigurację sieci.
 Get-NetIPAddress: wyświetla bieżące adresy IP.
 Get-NetIPInterface: wyświetla listę z informacjami o kartach sieciowych i ich
numerycznych identyfikatorach interfejsów. Identyfikator będzie przydatny podczas
definiowania adresu IP, ponieważ musimy być pewni, że PowerShell przypisze
go do właściwej karty sieciowej.
 New-NetIPAddress: służy do konfigurowania nowego adresu IP.
 Set-DNSClientServerAddress: polecenie jest używane do konfigurowania ustawień
serwera DNS we właściwościach karty sieciowej.
Przyjrzyjmy się procedurze konfigurowania statycznego adresu IP w nowej instancji systemu

Server Core, aby się upewnić, że powyższe polecenia mają sens. Do serwera chciałbym przypi-
sać adres IP 10.10.10.12, ale najpierw musiałbym się dowiedzieć, którego numeru identyfika-
cyjnego interfejsu karty sieciowej powinienem użyć. Informacje uzyskane po uruchomieniu
polecenia Get-NetIPInterface sugerują, że interesujący mnie numer ifIndex ma wartość 4:
292
Gdy znamy już numer interfejsu, użyjmy dwóch poleceń, które skonfigurują ustawienia ad-
resu IP w karcie sieciowej. Pierwsze polecenie przypisze karcie adres IP, prefiks maski podsieci
i bramę domyślną, drugie zaś przypisze jej adresy serwerów DNS:
New-NetIPAddress -InterfaceIndex 4 -IPAddress 10.10.10.12 -PrefixLength
24 -DefaultGateway 10.10.10.1
Set-DNSClientServerAddress -InterfaceIndex 4 -ServerAddresses
10.10.10.10,10.10.10.11
Moment, moment! W jaki sposób otworzyłem jednocześnie dwa okna programu

PowerShell w interfejsie Server Core? Zapoznaj się z punktem „Przypadkowe zamknięcie
okna z wierszem poleceń” w dalszej części tego rozdziału, aby się dowiedzieć, jak można
uruchomić wiele okien i narzędzi w konsoli Server Core.
293
Wszystkie ustawienia IP powinny być już zapisane w karcie sieciowej. Sprawdźmy to za pomocą
polecenia Get-NetIPConfiguration, jak pokazano na poniższym zrzucie ekranu. Alternatywnie
możesz użyć starego, dobrego polecenia ipconfig, ale czy jest w tym jakaś frajda?
Pamiętaj, że konfigurowanie karty sieciowej zawsze można uprościć przez użycie rezerwa-
cji DHCP. Gdybyś w systemie Server Core uruchomił proste polecenie ipconfig /all,
a następnie zanotował adres MAC karty sieciowej, mógłbyś go użyć do utworzenia rezer-
wacji w usłudze DHCP i w ten sposób przypisać określony adres IP nowemu serwerowi.
Definiowanie nazwy serwera

Gdy już ustaliliśmy połączenie sieciowe, następnym krokiem powinno być zdefiniowanie
nazwy naszego serwera i dołączenie go do domeny. Po pierwsze sprawdźmy, jaka jest obecna
nazwa serwera, a następnie zmieńmy ją na coś, co odpowiada naszym standardom. System
Windows po zainstalowaniu sam przypisuje serwerowi losową nazwę. Możesz wyświetlić bieżącą
nazwę serwera poleceniem hostname.
Aby zmienić nazwę serwera, musimy użyć polecenia PowerShell. Przejdź do okna z programem
PowerShell, a następnie po prostu wykonaj polecenie cmdlet Rename-Computer, aby ustalić
nową nazwę serwera. Zdecydowałem się przypisać swojemu nowemu serwerowi nazwę
WEB4, ponieważ później zainstalujemy na nim rolę Web Services, aby można było zarządzać
witryną internetową. Pamiętaj, że po zmianie nazwy komputera (podobnie jak w wersji graficznej
294
systemu Windows Server) konieczne będzie ponowne uruchomienie systemu, aby modyfikacje
zostały wprowadzone. Po wykonaniu polecenia Rename-Computer możesz więc wydać następne,
Restart-Computer, aby ponownie uruchomić maszynę:
Rename-Computer WEB4
Restart-Computer
Dołączanie do domeny
Kolejnym logicznym krokiem jest oczywiście dołączenie do domeny. Są to standardowe
funkcje, które wykonałbyś w swoim środowisku na każdym nowym serwerze. Obecnie uży-
wamy ich jednak w sposób, z którym być może nigdy wcześniej się nie spotkałeś, ponieważ
wszystko jest wykonywane wyłącznie z poziomu wiersza poleceń i interfejsów PowerShell.
Aby dołączyć do domeny maszynę z systemem Server Core, przejdź do okna programu Po-
werShell, a następnie użyj polecenia cmdlet Add-Computer. Zostaniesz poproszony o podanie
nazwy domeny i poświadczeń pozwalających na dołączenie do niej. Są to te same informa-
cje, które musisz podać, jeśli dołączasz do domeny serwer zawierający graficzną wersję
systemu Windows Server 2019. Najpierw musisz podać poświadczenia potrzebne do przyłą-
czenia do domeny:
295
Następnie musisz wskazać, do jakiej domeny chcesz dołączyć maszynę:
Alternatywnie w celu określenia nazwy domeny można użyć parametru -DomainName w połącze-
niu z oryginalnym poleceniem cmdlet Add-Computer. Oczywiście po dołączeniu do domeny
musisz ponownie uruchomić komputer, aby sfinalizować tę zmianę.
Zdalna sesja PowerShell

Gdy nowa maszyna z systemem Server Core uzyska adres IP oraz nazwę, a także zostanie
dołączona do domeny, będziemy mogli zacząć nią rzeczywiście administrować. Z pewnością
nadal mógłbyś się logować do konsoli i korzystać z niej bezpośrednio, ale podobnie jak w przy-
padku zarządzania dowolnym innym serwerem w Twoim środowisku powinny istnieć sposoby,
aby poradzić sobie z tym zdalnie, prawda? Jednym ze sposobów zarządzania serwerem Core
bez konieczności siedzenia przed nim jest użycie zdalnego połączenia PowerShell.
Proces korzystania ze zdalnego połączenia PowerShell w celu zarządzania serwerami (zarówno

w wersji graficznej, jak i bezobsługowej) omówimy bardziej szczegółowo w rozdziale 10.,
„PowerShell”. Teraz w skrócie przedstawię niezbędne polecenia i dostępne możliwości, które
pozwolą na nawiązanie zdalnej sesji z programu PowerShell używanego na stacji roboczej w śro-
dowisku dołączonym do domeny.
Otwórz okno programu PowerShell, będąc zalogowanym w innym systemie — może to być
serwer, a nawet system operacyjny klienta. PowerShell został oczywiście uruchomiony w kontek-
ście komputera, na którym obecnie jesteś zalogowany, więc wszelkie polecenia dotyczące
naszego serwera i wydawane za pomocą tego programu będą powodowały wyświetlenie błęd-
nych odpowiedzi z systemu lokalnego. Aby rzeczywiście podłączyć program PowerShell do
instancji systemu Server Core o nazwie WEB4, wydam odpowiednie polecenie. Po jego uru-
chomieniu pojawi się monit o podanie hasła do konta administratora. Następnie będę mógł
wykonywać zdalne polecenia PowerShell w naszym systemie Server Core:
Enter-PSSession -ComputerName WEB4 -Credential administrator
296
Obecnie używamy programu PowerShell zdalnie połączonego z maszyną WEB4 w wersji

Server Core. Możesz to potwierdzić, ponieważ po lewej stronie wiersza zachęty występuje
nazwa []. Być może jednak nie ufasz takiemu niewielkiemu dowodowi i chciałbyś się upewnić,
że okno programu PowerShell ma teraz dostęp do zdalnego serwera WEB4 i może nim zarzą-
dzać. Wydajmy więc kilka prostych poleceń, takich jak hostname i ipconfig, aby udowodnić,
że informacje wyświetlane w sesji PowerShell naprawdę pochodzą z nowego serwera WEB4:
Gdy z naszym systemem Server Core nawiązaliśmy już połączenie poprzez program PowerShell,
możemy bezpośrednio z niego wykonywać niemalże wszystkie działania na zdalnym serwerze.
297
Menedżer serwera
Chociaż początkowo konfiguracja serwera będzie modyfikowana za pomocą interfejsu wiersza
poleceń dostępnego w konsoli, po podłączeniu go do sieci bardziej korzystne będzie użycie
innych narzędzi. Prawdopodobnie istnieją polecenia cmdlet programu PowerShell, które
pozwalają zarządzać dowolnym składnikiem nowego serwera, ale dla większości z nas to rozwią-
zanie nie jest zbyt przyjazne. Jesteśmy jednak przyzwyczajeni do korzystania z narzędzi gra-
ficznych, takich jak Menedżer serwera. Wiesz już, że Server Manager może być używany do
administrowania wieloma systemami, zarówno lokalnymi, jak i zdalnymi, ponieważ jest czę-
ścią scentralizowanego mechanizmu zarządzania stworzonego przez firmę Microsoft. Funkcja
zdalnego zarządzania dostępna w Menedżerze serwera, którą zaprezentowaliśmy wcześniej
w tej książce, pozwala korzystać nie tylko z serwerów Windows opartych na graficznym interfej-
sie użytkownika, ale także z instancji Server Core.
Chcę zainstalować rolę na nowym serwerze WEB4. Mógłbym to zrobić bezpośrednio z konsoli
za pomocą poleceń PowerShell, ale zamiast tego spróbuję dodać maszynę WEB4 do Menedżera
serwera, który jest uruchomiony na innym moim serwerze. Mam zatem zamiar zalogować
się do serwera WEB3 i z tego miejsca użyć aplikacji Server Manager. Jak już wiesz, mogę
dodać nowy serwer do Menedżera serwera za pomocą menu Manage/Add Servers (Zarzą-
dzaj/Dodaj serwery):
Po dodaniu nowego serwera WEB4 do listy zarządzanych komputerów będzie można nim
zarządzać z poziomu Menedżera serwera. Chciałbym jednak wrócić do swoich pierwotnych
zamiarów i zainstalować rolę serwera WWW (IIS) na serwerze WEB4. Jeśli w Menedżerze
serwera użyję teraz funkcji Add roles and features (Dodaj role i funkcje), będę mógł wybrać
serwer WEB4 (zobacz pierwszy rysunek na następnej stronie).
Podobnie jak w przypadku każdego innego serwera wyposażonego w pełną wersję Desktop
Experience systemu Windows Server, możemy przejść do kreatora instalacji roli, a rola serwera
WWW zostanie zainstalowana na maszynie WEB4.
Narzędzia administracji zdalnej serwera

Prawdą jest również stwierdzenie, że można zarządzać instancjami Server Core za pomocą na-
rzędzi administracji zdalnej serwera (RSAT) dostępnych w systemie Windows 10. RSAT jest
w zasadzie po prostu kopią programu Server Manager, zaprojektowaną do działania w systemie
298
operacyjnym klienta. W naszym przypadku mamy już maszynę z systemem Windows 10, na któ-
rej wcześniej zainstalowałem RSAT, więc zaloguję się na nią i dodam serwer WEB4 do interfejsu.
Właśnie zakończyło się poprzednie zadanie, polegające na zainstalowaniu roli IIS na naszym
serwerze, więc powinienem być w stanie zobaczyć ją dostępną w programie RSAT po podłącze-
niu się do WEB4.
Jeśli nie korzystałeś wcześniej z narzędzi RSAT i nie zapoznałeś się z odpowiednimi informa-
cjami zamieszczonymi w rozdziale 2., powinieneś wiedzieć, że nie istnieje aplikacja o nazwie
„Narzędzia administracji zdalnej serwera”. Po zakończeniu instalacji RSAT otwórz menu
Start, a zobaczysz program o nazwie Server Manager (Menedżer serwera). W taki właśnie
sposób można wykorzystać klienta Windows 10 do zdalnego zarządzania instancjami Windows
Server 2019:
Wykonaj dokładnie taką samą operację jak w przypadku interfejsu Menedżera serwera dla
systemu Windows Server 2019 — użyj kreatora, aby dodać inne serwery w celu zarządzania
nimi. Po dodaniu w systemie Windows 10 serwera WEB4 do Menedżera serwera mogę zoba-
czyć usługę IIS na pulpicie nawigacyjnym. Oznacza to, że usługa, która działa na serwerze
WEB4, jest widoczna, dostępna i konfigurowalna bezpośrednio z mojego komputera stacjonar-
nego z systemem Windows 10. W przypadku większości zadań, które powinienem wykonać
na serwerze WEB4, nigdy nie będę musiał się logować do jego konsoli.
299
Jeśli kliknę prawym przyciskiem myszy nazwę serwera WEB4 w konsoli RSAT, zauważę, że ist-
nieje wiele dostępnych funkcji, których mogę użyć do zarządzania zdalną instancją Server Core:
Okazuje się, że istnieją sposoby pozwalające na korzystanie z narzędzi GUI w celu zarządzania
instancjami Windows Server bez interfejsu graficznego. To tylko kwestia potraktowania serwerów
jako bezobsługowych, ponieważ narzędziom takim, jak PowerShell lub Server Manager,
w rzeczywistości jest wszystko jedno, czy maszyna, którą obsługują, jest lokalna czy zdalna.
Procesy i narzędzia są takie same w obu przypadkach. Na poprzednim zrzucie ekranu widać, że
mógłbym nawet kliknąć opcję menu, aby uruchomić zdalne połączenie PowerShell z serwerem
WEB4. Spowodowałoby to natychmiastowe wyświetlenie okna programu PowerShell, który
jest zdalnie połączony z serwerem WEB4, mimo że obecnie jestem zalogowany tylko na
stacji roboczej z systemem Windows 10. Jest to nawet prostsze niż wydanie polecenia cmdlet
Enter-PSSession z poziomu programu PowerShell.
Przypadkowe zamknięcie okna z wierszem poleceń

Jest jeszcze jeden problem, który pojawia się na konsoli systemu Server Core. Jest on często
doświadczany przez administratorów, którzy nie używali regularnie serwerów z takim sys-
temem. Ponieważ mamy tendencję do zamykania nieużywanych okien i aplikacji, możemy
nieświadomie zamknąć także okno wiersza poleceń, które obsługuje cały proces administra-
cyjny w sesji konsoli systemu Server Core. W takim przypadku znajdziesz się przed dużym,
pustym ekranem, pozornie bez interfejsu, z którego niczego nie możesz uruchomić.
300
Jak można przywrócić normalną pracę tego serwera? Czy musimy go koniecznie zrestarto-
wać? To przerwałoby działanie wszystkich uruchomionych ról i zatrzymało ruch sieciowy, za
pomocą którego ten serwer obsługuje zdalnych użytkowników, więc oczywiście nie jest to
idealne rozwiązanie.
Dzięki użyciu narzędzia Task Manager (Menedżer zadań) można w prosty sposób uruchomić
nową instancję. Po omyłkowym zamknięciu bieżącego okna wiersza poleceń, mając przed
oczami pusty, czarny ekran konsoli Server Core, możesz nacisnąć sekwencję klawiszy
Ctrl+Alt+Del, a zostaną wyświetlone opcje zaprezentowane na poniższym zrzucie ekranu:
Wyświetlona zostanie lista kilku funkcji, które możesz wykonać, co jest całkiem miłym pomy-
słem. Jeśli jednak chcesz przywrócić okno wiersza poleceń, użyj klawiszy strzałek, aby podświe-
tlić wiersz Task Manager, a następnie naciśnij klawisz Enter. Spowoduje to uruchomienie
menedżera zadań, którego wszyscy znamy. Kliknij łącze More details (Więcej szczegółów),
aby udostępnić więcej szczegółów, a następnie z menu File (Plik) wybierz opcję Run new task
(Uruchom nowe zadanie):
W oknie dialogowym Create new task (Utwórz nowe zadanie) wprowadź nazwę cmd i naciśnij
przycisk OK:
301
Za pomocą tego okna dialogowego możesz także uruchomić dowolną inną aplikację. Jeśli
zamiast otwierać wiersz poleceń, chciałbyś przejść bezpośrednio do okna PowerShell, mógłbyś
po prostu w polu edycji wpisać powershell, a zostałoby ono otwarte:
Wykorzystanie aplikacji Windows Admin

Center do zarządzania systemem
Server Core
Wiersz poleceń uruchamiany z konsoli, zdalne połączenie PowerShell, zdalne administrowanie
Menedżerem serwera, a nawet narzędzia RSAT działające na stacji roboczej z systemem Win-
dows 10 są znaczącymi i potężnymi narzędziami do administrowania instancjami Server Core.
302
Zostały one jednak zepchnięte na dalszy plan przez nowo wprowadzoną aplikację Windows
Admin Center. Wiesz już, jakie są jej możliwości związane z centralnym zarządzaniem całą in-
frastrukturą serwera. Powinienem jednak podkreślić, że aplikacja WAC może obsługiwać
serwery zarówno z interfejsami graficznymi, jak i bez nich.
O wersji Server Core rozmawiałem z wieloma administratorami systemu Windows Server.

Jednym z największych problemów utrudniających wdrażanie tych bardziej wydajnych i bez-
piecznych platform serwerowych jest obawa, że po stosunkowo prostym procesie konfigura-
cji maszyny administrowanie nią i jej konserwacja będą znacznie bardziej uciążliwe. Admi-
nistratorzy mający doświadczenie z wersją Windows Server Desktop Experience doskonale
wiedzą, co należy zrobić w celu wykonywania codziennych zadań. Usuń jednak interfejs typu
„wskaż i kliknij”, a nagle dzień pracy administratora stanie się znacznie bardziej skomplikowany.
Na szczęście nie trzeba się uczyć na pamięć całego podręcznika z poleceniami PowerShell,
aby skorzystać z wersji Server Core! Aplikacja Windows Admin Center traktuje instancje
Server Core tak samo jak serwery używające graficznego interfejsu. Po prostu działa!
W naszym laboratorium testowym mamy już na jednym z serwerów zainstalowaną aplikację

WAC, więc otwórzmy ją i dodajmy nowy serwer WEB4 do administrowania. Zobaczymy, jakie
opcje można wykorzystać w celu bieżącej konserwacji tego serwera.
Gdy po raz pierwszy będziemy się łączyć z serwerem WEB4 za pośrednictwem konsoli
WAC, w rzeczywistości nic nie będzie wskazywać na to, że mamy do czynienia z instancją
Server Core, ponieważ dostępne są wszystkie graficzne narzędzia i programy użytkowe (zo-
bacz pierwszy rysunek na następnej stronie).
Wypróbujmy kilka opcji dostępnych w aplikacji Windows Admin Center. W górnej części
ekranu znajdują się kontrolki, za pomocą których możesz w prosty sposób wyłączyć lub zrestar-
tować serwer. Jest to o wiele łatwiejsze i szybsze niż ustanowienie zdalnego połączenia Po-
werShell w celu wydawania poleceń, by uzyskać ten sam wynik. Na ekranie głównym (po
przewinięciu go w dół) są również wyświetlane wskaźniki wydajności, pokazujące użycie
takich zasobów, jak CPU (Procesor), Memory (Pamięć) i Networking (Sieć). Aby mieć możliwość
zobaczenia tych statystyk bez zainstalowanej aplikacji WAC, musiałbyś się zalogować bez-
pośrednio do serwera WEB4 i uruchomić Menedżera zadań (zobacz drugi rysunek na na-
stępnej stronie).
Opuśćmy teraz ten jakże przydatny ekran główny i spróbujmy kliknąć jedno z narzędzi
znajdujących po lewej stronie ekranu, na przykład Events (Zdarzenia). Gdybyś chciał roz-
wiązać problem, nie mając aplikacji WAC, musiałbyś się zalogować na maszynę Server Core
i przejrzeć jej dzienniki zdarzeń. W jaki jednak sposób wykonałbyś to z poziomu interfejsu
wiersza poleceń? Przypuszczam, że po zalogowaniu się do konsoli Server Core użyłbyś Mene-
dżera zadań w celu uruchomienia programu EventVwr. Wykorzystanie aplikacji WAC i kliknię-
cie opcji Events jest jednakże znacznie łatwiejsze (zobacz kolejny zrzut na kolejnej stronie).
303
304
Innym przykładem przydatnej (szczególnie podczas pracy z instancją Server Core) funkcji
udostępnianej w aplikacji WAC jest opcja Files (Pliki), która służy do poruszania się po strukturze
plików i folderów dysku twardego. Istnieje również inna funkcja, o nazwie Firewall (Zapora),
pozwalająca na tworzenie lub usuwanie reguł zapory Windows, a także narzędzie Network
(Sieć), za pomocą którego można konfigurować adresy IP.
W aplikacji Windows Admin Center jest dostępnych jeszcze wiele innych narzędzi, a ostatnim,
na które chciałbym zwrócić uwagę, jest kolejne powtórzenie opcji PowerShell (podobnej do
tej, którą możemy napotkać w Menedżerze serwera). Przycisk PowerShell wywoła i wyświetli
zdalne połączenie programu PowerShell z instancją Server Core. Będzie on przydatny, jeśli
w aplikacji WAC nie będziesz mógł znaleźć potrzebnej Ci funkcji i trzeba będzie wykonać
z wiersza poleceń bardziej niskopoziomowe instrukcje. Najlepsze jest jednak to, że nie będziesz
wcale musiał uruchamiać samego programu PowerShell! Wszystko odbędzie się wyłącznie
w oknie przeglądarki internetowej (zobacz pierwszy rysunek na następnej stronie).
Istnieje jeszcze wiele innych funkcji dostępnych z poziomu aplikacji Windows Admin Center,
na przykład edycja rejestru, dodawanie ról i funkcji, sprawdzanie stanu usług, a nawet łączenie
z usługą Windows Update. Najwyższy czas zacząć używać aplikacji WAC!
Narzędzie Sconfig
A teraz cofnijmy się o krok i przetestujmy narzędzie dostępne w środowisku Server Core,
które jest jednak na ogół przydatne jedynie podczas pracy w konsoli serwera. Jak już wiesz,
za każdym razem, gdy uruchamiasz środowisko Server Core, trafiasz do okna wiersza poleceń,
z którego następnie możesz uruchomić program PowerShell i użyć tradycyjnych poleceń
cmdlet systemu Windows w celu wykonania czynności konfiguracyjnych.
305
Alternatywnie mógłbyś jednak wykorzystać program użytkowy o nazwie Sconfig. Jest to zestaw
narzędzi (coś w rodzaju skrótów w wierszu poleceń) służących do implementacji podstawowych
składników potrzebnych do przełączenia nowego serwera w tryb online i podłączenia go do
sieci. Program Sconfig został tak zaprojektowany, by można go było uruchamiać zaraz po
zainstalowaniu systemu operacyjnego. Umożliwia on przeprowadzenie wstępnej konfigura-
cji nowo utworzonego serwera, dzięki czemu można następnie rozpocząć korzystanie z jednego
z bardziej niezawodnych interfejsów administracyjnych, takich jak Menedżer serwera lub
Windows Admin Center.
Po uruchomieniu nowej instancji Server Core znajdziesz się w oknie wiersza poleceń, które
oczekuje na instrukcje. Wprowadź nazwę sconfig i naciśnij klawisz Enter; ekran powinien
szybko zmienić kolor z czarnego na niebieski i wyświetlić następujące informacje (zobacz
pierwszy rysunek na następnej stronie).
Opcje zawarte w narzędziu Sconfig są dość oczywiste, jednak postaram się przeanalizować
dostępne w nim typowe zadania. Oczywiście każde z nich można zrealizować za pomocą
poleceń cmdlet programu PowerShell, ale uważam, że łatwiej do tego celu wykorzystać
aplikację Sconfig. Najczęstsze zastosowania tego interfejsu to konfiguracja początkowych
ustawień sieciowych przez naciśnięcie klawisza 8 lub skonfigurowanie nazwy serwera i dodanie
go do domeny za pomocą opcji 2 i 1.
Naciskam więc klawisz 2, a następnie Enter, co powoduje pojawienie się monitu z prośbą
o podanie nazwy nowego komputera. Jest to niezwykle szybki sposób pozwalający na skonfi-
gurowanie nazwy serwera w nowo utworzonej maszynie Server Core. Ponieważ tak naprawdę
nie chcę zmieniać nazwy WEB4, nic nie wprowadzę i po prostu nacisnę klawisz Enter, aby
powrócić do ekranu głównego.
306
A teraz chciałbym sprawdzić ustawienia sieciowe. Naciśnięcie klawisza 8, a następnie Enter

powoduje przejście do opcji Network Settings (Ustawienia sieciowe), która wyświetla informację,
że karta sieciowa WEB4 ma adres 10.10.10.12. Jest to prawda, jednakże zmieńmy ten adres,
aby wykonać realną procedurę zmiany ustawień w programie Sconfig.
Najpierw wybrałem indeks karty sieciowej, który wynosi 1. Zostały wyświetlone dodatkowe
ustawienia tej karty, a także opcje pozwalające na zmianę konfiguracji. Ponowne wybranie
opcji 1, o nazwie Set Network Adapter Address (Ustaw adres karty sieciowej), umożliwi ustawie-
nie adresu karty sieciowej (zobacz pierwszy rysunek na następnej stronie).
Wprowadź literę S, oznaczającą, że chcesz wprowadzić statyczny adres IP, a następnie podaj
jego wartość, którą chcesz przypisać do danej karty sieciowej. Przypiszę serwerowi WEB4
adres 10.10.10.30, aby po prostu udowodnić, że cała procedura działa. Po wprowadzeniu
adresu IP muszę również ustawić nową maskę podsieci i adres bramy (zobacz drugi rysunek
na następnej stronie).
Jak widać, karcie sieciowej serwera WEB4 został natychmiast przypisany nowy adres IP,
10.10.10.30. Wykorzystywanie narzędzia Sconfig po przeprowadzeniu wstępnej konfiguracji
instancji Server Core może nie być częstym zjawiskiem. Jednak to narzędzie rzeczywiście po-
zwala zaoszczędzić czas, gdy jest używane do początkowej modyfikacji ustawień związanych
z siecią i nazwą tworzonego serwera.
307
308
Role dostępne w wersji Server Core

Ponieważ wersja Server Core jest oczywiście uproszczoną formą systemu operacyjnego, niektóre
role systemu Windows Server po prostu nie zostały zaprojektowane tak, by prawidłowo
funkcjonować w tym ograniczonym kontekście. Na szczęście dla nas przeważająca część z tych,
które działają, pozwala administratorom systemu Windows Server 2019 wdrożyć większość
krytycznych składników infrastruktury za pośrednictwem bezpieczniejszej platformy Server
Core. Oto lista ról, które są obecnie obsługiwane w instancji Server Core systemu Windows
Server 2019:
 Active Directory Certificate Services (Usługi certyfikatów Active Directory),
 Active Directory Domain Services (Usługi domenowe Active Directory),
 Active Directory Federation Services (Usługi federacyjne Active Directory),
 Active Directory Lightweight Directory Services (Ograniczone usługi katalogowe
Active Directory),
 Active Directory Rights Management Services (Usługi zarządzania prawami
Active Directory),
 Device Health Attestation (Poświadczenie o stanie urządzenia),
 DHCP Server (Serwer DHCP),
 DNS Server (Serwer DNS),
 File Services (Usługi plikowe),
 Host Guardian Service (Usługa ochrony hosta),
 Hyper-V (Usługa Hyper-V),
 Print and Document Services (Usługi drukowania i zarządzania dokumentami),
 Remote Access (Dostęp zdalny),
 Volume Activation Services (Usługi aktywacji zbiorowej),
 Web Server (IIS) (Serwer WWW — IIS),
 Windows Server Update Services (Usługi aktualizacji systemu Windows Server).
Co się stało z systemem Nano Server?

Sprawa dotycząca niewielkich platform Windows Server nie zakończyła się na wydaniu wer-
sji Server Core. Każdy, kto interesował się nowymi funkcjami systemu Server 2016, jest
świadomy tego, że istniała jeszcze jedna opcja instalacji, o nazwie Nano Server. Miał to być
jeszcze mniejszy, bezpieczniejszy, wydajniejszy, wyjątkowo kompaktowy system operacyjny,
który mógł obsługiwać ograniczony zestaw ról. Mimo to nadal można go było zainstalować
na fizycznej lub wirtualnej platformie serwerowej, uruchomić jako prawdziwy system operacyjny
serwera i używać do typowych celów obliczeniowych.
309
Jednak nieszczęśliwie dla entuzjastów systemu Nano Server, a szczególnie dla każdego, kto już
wykonał prace związane z jego instalacją i wdrożeniem do użytkowania, w ciągu ostatnich
kilku lat historia potoczyła się w zupełnie innym kierunku. Krótko mówiąc, nie można już
stosować systemu Nano Server do żadnych typowych zadań serwerowych. Nie można go
zainstalować na fizycznym sprzęcie, a nawet na maszynie wirtualnej. Ponadto funkcje zarządza-
nia, takie jak PowerShell i WinRM, zostały z niego usunięte i nie można na nim instalować
żadnych ról infrastrukturalnych firmy Microsoft.
Co więc pozostało po usunięciu wszystkich tych opcji z obszaru funkcjonalności systemu

Nano Server? Czy zakończył on swoje istnienie? Czy Nano Server może obecnie cokolwiek
zrobić?
Odpowiedzią na te pytania są kontenery. Obecnie domeną zastosowań serwera Nano jest wyko-
rzystanie kontenerów do wdrażania skalowalnych aplikacji gotowych do pracy w chmurze i za-
rządzania nimi. Więcej informacji na temat kontenerów i całkowitego powiązania z nimi
systemu Nano Server podam w rozdziale 11., „Kontenery i Nano Server”. Na razie wystar-
czy stwierdzić, że obrazy kontenerów na stronie internetowej firmy Microsoft będą jedynym
miejscem, w którym znajdziesz system Nano Server.
Podsumowanie
Muszę być z Tobą szczery — napisanie tego rozdziału było dodatkowym impulsem, którego
potrzebowałem, aby zacząć myśleć o zmniejszeniu własnych serwerów. Jadę na tym samym
wózku co wielu czytelników: wiem, czym jest Server Core, i nawet testowałem go, ale nigdy
nie podjąłem kroków, aby naprawdę wdrożyć go w środowisku produkcyjnym, które obsłu-
guję. Gdy dostępne stały się narzędzia takie, jak Sconfig i nowa aplikacja Windows Admin
Center, oficjalnie zabrakło mi wymówek, aby nie wdrażać nowych ról w maszynach wyposa-
żonych w Server Core. Chociaż zdobywanie nowej wiedzy nie jest bolesne, korzystanie z wersji
systemu Server Core nie wymaga już płynnej znajomości poleceń powłoki PowerShell. Począt-
kowo środowisko Server Core faktycznie wymagało naprawdę dobrego zrozumienia progra-
mu PowerShell, ponieważ był on jedynym niezawodnym sposobem konfigurowania tych
niewielkich serwerów i łączenia się z nimi. Nowe narzędzia pozwalają nam jednak korzystać
z prostszej platformy i administrować nią bez konieczności zapamiętywania wielu poleceń
cmdlet powłoki PowerShell.
Bezpieczeństwo jest głównym powodem, dla którego wszyscy powinniśmy uważać wersję
Server Core za swój nowy standard. Interfejs graficzny systemu Windows zawiera dużo kodu
i udostępnia wiele możliwości osobom zalogowanym na serwerach, na przykład umożliwia
przeglądanie internetu. Pozwala to na dotarcie do luk w zabezpieczeniach, które po prostu
nie istnieją w wersji Server Core. W następnym rozdziale zajmiemy się zagadnieniem redun-
dancji w systemie Windows Server 2019.
310
Pytania
1. Server Core jest domyślną opcją instalacji dla systemu Windows Server 2019 —
prawda czy fałsz?
2. Programu PowerShell można użyć do zmiany wersji systemu Server 2019 z Server
Core na Desktop Experience — prawda czy fałsz?
3. Jaka aplikacja pojawia się na konsoli świeżo uruchomionej instancji serwera
Windows Server 2019 Server Core?
4. Jakiego polecenia cmdlet można użyć do wyświetlenia bieżącej konfiguracji sieci
w systemie Server Core?
5. Jakiego polecenia cmdlet programu PowerShell można użyć do skonfigurowania
nazwy serwera w systemie Server Core?
6. Wymień niektóre narzędzia zarządzające, których można użyć do zdalnego
łączenia się z systemem Server Core.
7. Jak nazywa się narzędzie wbudowane w system Server Core, które można uruchomić
w celu uzyskania dostępu do czynności związanych z konfiguracją adresów IP,
nazwą serwera i członkostwem w domenie?
311
312
9
Redundancja
w systemie Windows
Server 2019
Pomnóż to przez dwa. To zdanie słyszę cały czas podczas planowania projektów. Jestem pe-
wien, że Ty też je znasz. Za każdym razem, gdy wdrażasz nową technologię, chcesz bardzo
dokładnie zaplanować cały proces. Dowiedz się, jakich serwerów będziesz potrzebować,
gdzie należy je umieścić i jak należy dla nich skonfigurować sieć. Po zakończeniu planowania
zamów wszystko podwójnie — na wypadek gdyby jeden z elementów się zepsuł. Żyjemy
w świecie permanentnie działających technologii. Awarie usług są niedopuszczalne, szcze-
gólnie jeśli zarządzamy chmurami publicznymi lub prywatnymi. Prawdą jest, że każda apli-
kacja lub usługa, od której zależy wykonanie pracy przez naszych użytkowników, ma kry-
tyczne znaczenie dla całego procesu i wymaga w zasadzie stuprocentowo bezawaryjnego
działania. Problem z redundancją polega na tym, że znacznie łatwiej jest mówić, niż coś zrobić.
Być może któregoś dnia otrzymamy magiczny przycisk o nazwie Naciśnij tutaj, aby uczynić
ten serwer redundantnym. Ten dzień jednak jeszcze nie nadszedł. Musimy zrozumieć techno-
logie, które są dostępne i umożliwiają zapewnienie redundancji w naszych systemach. W tym
rozdziale poznasz niektóre z tych rozwiązań. Ponieważ w niniejszej książce prezentujemy
system Server 2019 używany w lokalnej sieci, technologie, które za chwilę omówimy, będziesz
mógł wykorzystać we własnych centrach danych, na prawdziwych (fizycznych lub wirtualnych)
serwerach, które tworzysz, konfigurujesz i utrzymujesz. Chmura oczywiście może zapewnić
nam magiczne opcje skalowalności i redundancji, ale są one proste w użyciu i często nawet
nie musimy rozumieć, jak działają. W jaki więc sposób możemy zwiększyć niezawodność
systemów, które są zainstalowane na serwerach w naszych lokalnych centrach danych?

 Równoważenie obciążenia sieciowego.
 Konfigurowanie strony WWW z równoważeniem obciążenia.
 Klaster pracy awaryjnej.
 Poziomy klastrowania.
 Konfigurowanie klastra pracy awaryjnej.
 Najnowsze ulepszenia dotyczące klastrowania w systemie Windows Server.
 Bezpośrednie miejsce do magazynowania.
Równoważenie obciążenia sieciowego

Gdy słucham rozmów dotyczących zarządzania redundancją na serwerach, często występuje
w nich słowo klaster, na przykład: „Jeśli skonfigurujemy klaster w celu zapewnienia redundancji
dla tych serwerów…” lub „Nasza główna strona internetowa funkcjonuje w klastrze…”.
Świetnie, że w systemach, których dotyczą te rozmowy, stosowana jest pewna forma równowa-
żenia, jednak często zdarza się, że w ogóle nie wykorzystuje się w nich techniki klastrowania.
Gdy zaczynamy omawiać szczegóły konfiguracji takich systemów, odkrywamy, że funkcjonuje
w nich mechanizm znany pod nazwą równoważenia obciążenia sieciowego (ang. Network
Load Balancing — NLB). Prawdziwe klastrowanie omówimy w dalszej części tego rozdziału,
jednakże najpierw chciałbym zaprezentować częściej stosowaną metodę pozwalającą na uzy-
skanie redundancji dla wielu usług. Równoważenie obciążenia sieciowego rozprasza ruch na
poziomie protokołu TCP/IP, co oznacza, że sam system operacyjny serwera nie jest w ogóle
świadomy istnienia innych systemów ani nie polega na nich, a zamiast tego redundancja zo-
staje zapewniona w warstwie sieciowej. Te dwie metody (NLB i klastrowanie) mogą być błęd-
nie interpretowane, ponieważ czasami dokumentacja firmy Microsoft nazywa coś klastrem,
podczas gdy w rzeczywistości do nawiązywania połączeń używany jest mechanizm równowa-
żenia obciążenia sieciowego. Doskonałym przykładem tego jest usługa DirectAccess. W doku-
mentach biblioteki TechNet, a nawet w pewnych komunikatach konsoli, dwa połączone ze sobą
serwery DA określa się jako klaster. W tym przypadku nie mamy jednak do czynienia z klastrem
pracy awaryjnej. Niskopoziomowym mechanizmem, który umożliwia wykonywanie połączeń
z oboma węzłami, jest w rzeczywistości równoważenie obciążenia sieciowego systemu Windows.
Prawdopodobnie znasz niektóre firmy obecne na rynku sprzętu do równoważenia obciążenia.

Są to między innymi F5, Cisco, Kemp, Barracuda. Przedsiębiorstwa te produkują wyspecjali-
zowane urządzenia, które mogą kierować ruch do określonego miejsca docelowego i rozdzielać
go pomiędzy dwa lub więcej serwerów aplikacji. Chociaż jest to na ogół najbardziej nieza-
wodny sposób pozwalający na ustanawianie równoważenia obciążenia sieciowego, jest on tak-
że najdroższy i sprawia, że ogólnie samo środowisko staje się bardziej złożone. Jedną z ofero-
wanych przez te firmy funkcji, których nie może zapewnić wbudowane równoważenie
obciążenia sieciowego systemu Windows, jest zakończenie połączenia SSL (ang. SSL termina-
tion lub SSL offloading). Wyspecjalizowane urządzenia są w stanie odbierać ruch sieciowy
szyfrowany protokołem SSL, a następnie deszyfrować pakiety przed wysłaniem ich na odpo-
314
Rozdział 9. • Redundancja w systemie Windows Server 2019
wiedni serwer WWW. Dzięki temu taki serwer jest mniej obciążony, ponieważ nie musi po-
święcać czasu procesora na szyfrowanie i deszyfrowanie pakietów. Jednak w tej książce nie
będziemy w ogóle omawiać sprzętowych modułów równoważących obciążenie, ale raczej zapre-
zentujemy funkcje równoważenia obciążenia sieciowego, które są dostępne bezpośrednio w syste-
mie Windows Server 2019.
Coś innego niż usługa DNS typu round-robin

Z biegiem lat odkryłem, że niektórzy, mówiąc o równoważeniu obciążenia sieciowego, mają
tak naprawdę na myśli usługę DNS typu round-robin. Podam przykład: administrujesz stroną
intranetową, do której codziennie logują się wszyscy użytkownicy. Sensowne byłoby, gdyby
istniała pewna redundancja dla tego systemu, dlatego utworzyłeś dwa serwery WWW na wypa-
dek awarii jednego z nich. Jednak w przypadku, gdy któryś z nich przestanie działać, nie
chciałbyś wykonywać ręcznych operacji w celu przełączenia ruchu na dodatkowy serwer —
wolałbyś, aby wszystko zadziałało automatycznie. W systemie DNS można utworzyć dwa re-
kordy A hosta, które będą miały tę samą nazwę, ale będą wskazywały różne adresy IP. Jeśli ma-
szyna o nazwie Server01 ma adres 10.10.10.5, a adres maszyny Server02 jest równy
10.10.10.6, mógłbyś utworzyć dwa rekordy DNS, oba o nazwie INTRANET, z których jeden
wskazywałby na 10.10.10.5, a drugi na 10.10.10.6. Zapewniłoby to działanie usługi DNS
w trybie round-robin, ale nie powodowało żadnego rzeczywistego równoważenia obciążenia.
W sytuacji gdy komputery klienckie kontaktują się z nazwą INTRANET, DNS przekazuje im
jeden lub drugi adres IP w celu nawiązania połączenia. DNS nie dba o to, czy ta strona faktycz-
nie działa — po prostu odpowiada adresem IP. Bądź więc ostrożny, nawet jeśli wydaje Ci się,
że po skonfigurowaniu system działa bezbłędnie, ponieważ klienci łączą się zarówno z maszyną
Server01, jak i Server02. W razie awarii serwera będzie co prawda istnieć wiele klientów, które
nadal będą pracować, ale też duża liczba użytkowników nagle stwierdzi, że strona się nie wy-
świetla. Będą to te osoby, które zostaną przekierowane przez usługę DNS na adres IP uszko-
dzonego serwera.
Równoważenie obciążenia sieciowego jest znacznie inteligentniejsze niż powyższe rozwiąza-

nie. Gdy węzeł w macierzy serwerów NLB ulegnie awarii, ruch sieciowy zostanie skierowany
tylko do systemu, który wciąż działa. Przekonasz się o tym wkrótce, gdy zdefiniujemy równowa-
żenie obciążenia sieciowego na naszej stronie intranetowej.
Jakie role mogą korzystać z równoważenia obciążenia

sieciowego?
Równoważenie obciążenia sieciowego zostało zaprojektowane przede wszystkim dla aplikacji
bezstanowych, czyli takich, które nie przechowują zbyt długo danych w pamięci ani nie wyma-
gają stanu połączenia. W przypadku aplikacji bezstanowej każde wysłane z niej żądanie może
być obsługiwane przez chwilę przez maszynę Server01, a następnie przechwycone przez
Server02 bez przerywania jej działania. Niektóre aplikacje radzą sobie z tym bardzo dobrze
(na przykład strony internetowe), a niektóre gorzej.
315
Usługi sieciowe (IIS) zdecydowanie w największym stopniu korzystają z redundancji zapewnia-

nej przez NLB. Równoważenie obciążenia sieciowego jest dość łatwe do skonfigurowania i bez
ponoszenia dodatkowych kosztów zapewnia pełną redundancję dla stron internetowych uru-
chomionych na serwerach Windows. To rozwiązanie można także wykorzystać w serwerach
FTP, zaporach i serwerach proxy.
Z równoważeniem obciążenia sieciowego często też współdziała rola dostępu zdalnego. W szcze-
gólności usługa DirectAccess może korzystać z wbudowanego równoważenia obciążenia
sieciowego systemu Windows, aby zapewnić środowisku zdalnego dostępu nadmiarowe
serwery będące punktami wejściowymi. Podczas konfigurowania funkcji DirectAccess w celu
skorzystania z równoważenia obciążenia nie jest od razu oczywiste, że będziesz używał
technologii redundancji wbudowanej w system operacyjny, ponieważ ustawienia równoważe-
nia obciążenia wprowadzasz z poziomu konsoli zarządzania dostępem zdalnym, a nie konsoli
NLB. Po zakończeniu obsługi kreatorów zarządzania dostępem zdalnym w celu zdefiniowania
równoważenia obciążenia konsola dostępu zdalnego faktycznie sięga do usługi NLB zaszytej
w systemie operacyjnym i konfiguruje ją w taki sposób, aby jej algorytmy i mechanizmy trans-
portowe były elementami używanymi przez DirectAccess do rozdzielania ruchu pomiędzy wiele
serwerów.
Jedną z największych zalet równoważenia obciążenia sieciowego jest możliwość wprowadzania

zmian w środowisku bez wpływania na istniejące węzły. Czy chciałbyś dodać nową maszynę
do istniejącej macierzy serwerów NLB? To nie problem. Umieść go w grupie bez konieczności
przerywania pracy. A może musisz usunąć serwer w celu przeprowadzenia konserwacji? Ta
operacja również jest dostępna. Równoważenie obciążenia sieciowego może przestać działać
w określonym węźle, umożliwiając innemu serwerowi z macierzy przejęcie pracy. W rzeczy-
wistości równoważenie obciążenia sieciowego jest powiązane z kartą sieciową, dlatego w tym
samym serwerze możesz definiować różne tryby NLB dla określonych kart sieciowych. Możesz
więc wskazać, aby równoważenie obciążenia sieciowego przestało działać na danej karcie siecio-
wej, a zatem usunąć serwer z macierzy. Co więcej, jeśli przełączenie serwera w tryb offline nie
musi być natychmiastowe, możesz wydać polecenie drainstop, zamiast od razu go wyłączyć.
Dzięki temu istniejące sesje sieciowe, które są aktywne na tym serwerze, zakończą się bezpro-
blemowo. Żadne nowe sesje nie zostaną obsłużone przez kartę sieciową, którą zatrzymałeś pole-
ceniem drainstop, a istniejące po pewnym czasie po prostu poprawnie zakończą swoje działanie.
Po zamknięciu wszystkich sesji na serwerze możesz go usunąć i wyłączyć w celu przeprowa-
dzenia konserwacji.
Adresy IP wirtualne i dedykowane

Ważne jest, aby zrozumieć, w jaki sposób NLB korzysta z adresów IP. Przede wszystkim każda
karta sieciowa na serwerze, która powinna zostać elementem macierzy równoważenia obcią-
żenia, musi mieć przypisany statyczny adres IP. Równoważenie obciążenia sieciowego nie działa
z adresowaniem DHCP. W świecie NLB statyczny adres IP na karcie sieciowej jest nazywany
dedykowanym adresem IP (DIP). Każda karta sieciowa ma inny adres, co oczywiście oznacza,
że każdy serwer ma swój własny adres DIP. Na przykład w moim środowisku serwer WEB1 ma
adres DIP 10.10.10.40, a maszyna WEB2 ma adres DIP 10.10.10.41.
316
Każdy serwer obsługuje tę samą stronę internetową za pomocą odpowiednich adresów DIP.
Ważne jest, aby zrozumieć, że ustanawiając równoważenie obciążenia sieciowego między dwoma
serwerami, muszę im zapewnić dedykowane adresy IP, ale powinienem także utworzyć dodat-
kowy adres, który będzie przez nie współdzielony. Ten wspólny adres IP nosi nazwę wirtualnego
adresu IP (VIP). Gdy wkrótce przeprowadzimy konfigurację NLB, adres 10.10.10.42 stanie
się adresem VIP, ponieważ do tej pory nie był używany w mojej sieci. Oto krótka lista adre-
sów IP, które będą używane w trakcie konfigurowania witryny z równoważeniem obciążenia
sieciowego:
Adres DIP serwera WEB1 = 10.10.10.40
Adres DIP serwera WEB2 = 10.10.10.41
Współdzielony adres VIP = 10.10.10.42
Podczas definiowania rekordu DNS dla adresu intranet.contoso.local, który jest nazwą mojej
strony intranetowej, utworzę tylko jeden rekord A hosta, wskazujący na wirtualny adres
IP 10.10.10.42.
Tryby pracy NLB

Wkrótce rozpoczniemy proces konfiguracji równoważenia obciążenia i będziemy zmuszeni
do podjęcia kilku decyzji. Jedna z ważniejszych dotyczy wyboru trybu NLB. Tryb emisji poje-
dynczej jest wybierany domyślnie. Jak wynika z mojego doświadczenia, podczas konfiguro-
wania równoważenia obciążenia sieciowego jest on wybierany przez większość firm — być
może po prostu dlatego, że jest to opcja domyślna i administratorzy nigdy nie zastanawiali
się nad jej zmianą. Poświęćmy chwilę na omówienie każdej z dostępnych opcji, aby się upewnić,
że będziesz mógł wybrać tę, która najbardziej odpowiada Twoim potrzebom sieciowym.
Tryb emisji pojedynczej (unicast)

W tym podpunkcie dokładniej wyjaśnię, w jaki sposób NLB dystrybuuje pakiety między
różnymi serwerami. Ponieważ nie mamy fizycznego modułu równoważenia obciążenia, który
najpierw odbierałby ruch, a następnie decydował, w którą stronę go wysłać, zadajmy sobie pyta-
nie: W jaki sposób serwery z równoważeniem obciążenia decydują o przydzielaniu pakietów
danych?
Aby odpowiedzieć na to pytanie, musimy się na chwilę zatrzymać i przeanalizować przepływ ru-
chu w Twojej sieci. Gdy otworzysz przeglądarkę internetową na swoim komputerze i urucho-
misz stronę HTTP://WEB1, usługa DNS przypisze jej adres IP 10.10.10.40. Gdy pakiety danych
pojawią się w Twoich przełącznikach, będą one musiały zdecydować, dokąd należy przesłać
ruch pochodzący z adresu 10.10.10.40. Zapewne znane jest Ci pojęcie adresów MAC.
Każda karta sieciowa ma adres MAC. Po przypisaniu adresu IP do karty sieciowej oba adresy,
MAC i IP, są następnie rejestrowane w sprzęcie sieciowym. Adresy MAC są przechowywane
w tablicy ARP, która znajduje się w większości przełączników, routerów i zapór sieciowych.
Gdy mój serwer WEB1 otrzymał adres IP 10.10.10.40, zarejestrował swój adres MAC odpowia-
dający temu adresowi IP. Gdy pakiety danych muszą zostać przesłane do serwera WEB1,
317
przełączniki wiedzą, że ruch przeznaczony dla adresu 10.10.10.40 powinien zostać skierowany
na adres MAC tej konkretnej karty sieciowej, więc odpowiednio go przekierowują.
Gdy w świecie NLB wysyłasz pakiety do jednego adresu IP, który jest wykorzystywany przez
wiele kart sieciowych, w jaki sposób ten ruch jest przetwarzany na poziomie adresów MAC?
Odpowiedź w przypadku użycia trybu emisji pojedynczej polega na tym, że adres MAC fizycz-
nej karty sieciowej zostaje zastąpiony wirtualnym adresem MAC, który przypisuje się do
wszystkich kart sieciowych w macierzy serwerów NLB. Powoduje to, że pakiety przepływające do
tego adresu MAC są dostarczane do wszystkich kart sieciowych, a więc do wszystkich serwerów
w tej macierzy. Jeśli wydaje Ci się, że w takim rozwiązaniu przełączniki obsługują zbyt wiele
niepotrzebnego ruchu sieciowego, masz rację. Tryb emisji pojedynczej oznacza, że gdy pojawią
się pakiety przeznaczone dla wirtualnego adresu MAC macierzy serwerów, ruch w zasadzie
będzie przetwarzany przez wszystkie porty przełącznika, zanim dotrze do miejsca docelowego.
Największą zaletą tego trybu jest to, że emisja pojedyncza działa w większości przypadków bez
konieczności specjalnego konfigurowania przełączników lub sprzętu sieciowego. Równoważenie
ruchu sieciowego definiujesz na poziomie narzędzi Windows Server, a sam system zajmuje się
resztą. Wadą trybu emisji pojedynczej jest to, że pojawiają się pewne problemy związane z ko-
munikacją wewnątrz macierzy serwerów, ponieważ ten sam adres MAC istnieje w każdym z wę-
złów. Innymi słowy, serwery obsługujące równoważenie obciążenia sieciowego będą miały
problemy z łączeniem się ze sobą. Często nie ma to większego znaczenia, gdyż serwer WEB1
rzadko miałby powód do bezpośredniej komunikacji z WEB2. Jeśli jednak naprawdę chciał-
byś, aby serwery sieciowe łączyły się ze sobą w sposób konsekwentny i niezawodny, najłatwiej
będzie zainstalować oddzielną kartę sieciową na każdym z nich i użyć jej do komunikacji we-
wnątrz macierzy, pozostawiając podstawową kartę sieciową skonfigurowaną dla ruchu NLB.
Inną wadą trybu emisji pojedynczej jest to, że może on powodować przepełnianie przełączni-
ków. Przełączniki nie są w stanie nauczyć się stałej trasy dla wirtualnego adresu MAC, ponie-
waż jest on przypisany do wszystkich węzłów w naszej macierzy. Każdy pakiet kierowany do
wirtualnego adresu MAC jest wysyłany wszelkimi możliwymi portami przełącznika, by mógł
trafić do wszystkich kart sieciowych macierzy serwerów. Z tego powodu przełączniki mogą zo-
stać przeciążone nadmierną liczbą pakietów sieciowych. Jeśli niepokoi Cię to lub od admini-
stratorów sieciowych otrzymujesz skargi dotyczące przepełniania przełączników, powinieneś
w swoim klastrze NLB użyć jednego z trybów multiemisji.
Alternatywną metodą ochrony przed przepełnianiem przełączników w trakcie używania trybu

emisji pojedynczej jest inteligentne tworzenie sieci VLAN na przełącznikach. Jeśli planujesz
użycie macierzy serwerów NLB i chcesz mieć pewność, że ruch generowany przez nią nie
wpłynie na inne systemy w sieci, z pewnością możesz na swoich przełącznikach utworzyć nie-
wielką sieć VLAN i podłączyć do niej tylko te karty sieciowe, które obsługują równoważenie ob-
ciążenia sieciowego. Gdy nastąpi planowane przepełnienie, będzie ono oddziaływać tylko na
niewielką liczbę portów w Twojej sieci VLAN, zamiast objąć cały przełącznik.
Tryb multiemisji (multicast)

Wybranie trybu multiemisji dla równoważenia obciążenia sieciowego wiąże się z pewnymi ko-
rzyściami, jak i kłopotami. Pozytywne jest to, że każda karta sieciowa uzyskuje dodatkowy ad-
318
res MAC. Dzięki temu każdy element macierzy NLB ma dwa adresy MAC: oryginalny i ten,
który został utworzony przez mechanizm NLB. Powoduje to, że przełączniki i sprzęt sieciowy
łatwiej uczą się tras i wysyłają ruch do właściwych miejsc docelowych, bez użycia nadmiernej
liczby pakietów. Aby uzyskać taką funkcjonalność, należy poinformować przełączniki, które
adresy MAC powinny odbierać ruch NLB. Jeśli tego nie zrobimy, pojawi się przepełnienie
przełączników, tak jak w przypadku trybu emisji pojedynczej. Aby poinformować przełączniki,
z którymi adresami MAC należy się kontaktować, należy się zalogować do nich i utworzyć sta-
tyczne wpisy ARP. Jeśli firma ma administratora sieci, zwykle biegłego w obsłudze sprzętu Cisco,
nie będzie to problemem. Jeśli jednak nie jesteś zaznajomiony z modyfikowaniem tabel ARP
i dodawaniem tras statycznych, poprawne wykonanie tej operacji może być trochę uciążliwe.
W sumie jednak tryb multiemisji jest na ogół lepszy od trybu emisji pojedynczej, chociaż może
powodować problemy administracyjne. Ja mimo wszystko optuję za wyborem trybu emisji
pojedynczej, szczególnie w mniejszych firmach. Jest on używany w wielu różnych sieciach bez
żadnych problemów, a jego ważną zaletą jest to, że możemy zapomnieć o programowaniu
przełączników.
Tryb multiemisji IGMP (multicast IGMP)

Jeszcze lepszym trybem, ale nie zawsze możliwym do zrealizowania, jest tryb multiemisji
z protokołem Internet Group Management Protocol (IGMP). Wybór tego trybu rzeczywi-
ście chroni przed przepełnianiem przełączników, ale działa on tylko wtedy, gdy przełączniki
obsługują protokół IGMP snooping. Oznacza to, że przełącznik ma możliwość podejrzenia
pakietów trybu multiemisji w celu ustalenia, dokąd dokładnie powinny zostać przesłane. Tak
więc tryb emisji pojedynczej z założenia powoduje przepełnianie przełączników, tryb multiemi-
sji może pomóc zmniejszyć uciążliwość tego problemu, a IGMP może całkowicie go usunąć.
Wybór trybu NLB będzie w dużej mierze zależał od możliwości Twojego sprzętu sieciowego.
Jeśli Twoje serwery mają tylko jedną kartę sieciową, spróbuj użyć trybu multiemisji, w przeciw-
nym razie wystąpią problemy w komunikacji wewnątrz macierzy. Z drugiej strony, jeśli Twoje
przełączniki i routery nie obsługują tego trybu, nie masz wyboru — emisja pojedyncza będzie
jedyną opcją dostępną w konfiguracji równoważenia obciążenia sieciowego systemu Windows.
Konfigurowanie strony WWW

z równoważeniem obciążenia
Dość gadania! Nadszedł czas, aby skonfigurować równoważenie sieciowe. Mam dwa serwery
sieciowe działające w sieci laboratoryjnej — WEB1 i WEB2. Oba używają usługi IIS do zarzą-
dzania witryną intranetową. Moim celem jest udostępnienie użytkownikom jednego rekordu
DNS, z którym mogliby się komunikować. Cały ruch sieciowy powinien jednak zostać podzielony
pomiędzy dwa serwery z zastosowaniem rzeczywistego równoważenia obciążenia. Aby to zreali-
zować, postępuj zgodnie z poniższymi instrukcjami.
319
Włączanie opcji NLB

Przede wszystkim musimy się upewnić, że serwery WEB1 i WEB2 zostały przygotowane do
obsługi równoważenia obciążenia sieciowego, ponieważ nie jest ono instalowane domyślnie.
Opcja NLB jest funkcją dostępną w systemie Windows Server 2019 i dodajesz ją w sposób
standardowy, przez uruchomienie kreatora Add roles and features (Dodaj role i funkcje).
Dodaj tę funkcję na wszystkich serwerach, które mają być częścią macierzy NLB:
Zezwolenie na spoofing adresu MAC w maszynach wirtualnych

Czy pamiętasz, jak podczas omawiania równoważenia obciążenia sieciowego w trybie emisji
pojedynczej wspominałem o tym, że fizyczny adres MAC karty sieciowej jest zastępowany wirtu-
alnym adresem MAC, używanym do komunikacji w macierzy NLB? No cóż, maszyny wirtual-
ne tego nie lubią. W przypadku równoważenia obciążenia serwerów fizycznych z fizycznymi
kartami sieciowymi możesz pominąć ten punkt. Wielu czytelników będzie jednak korzystać
z serwerów sieciowych, które są maszynami wirtualnymi. Niezależnie od tego, czy są one zarzą-
dzane za pomocą środowiska Hyper-V, VMware czy też innej technologii wirtualizacji, w kon-
figuracji samej maszyny wirtualnej istnieje dodatkowa opcja, którą musisz zmodyfikować,
aby Twój serwer z chęcią przyjął zmianę adresu MAC.
Nazwa tego ustawienia będzie czymś zbliżonym do opcji Enable MAC address spoofing (Zezwól
na spoofing adresu MAC), chociaż oczywiście może się różnić w zależności od używanej
technologii wirtualizacji. Ustawienie powinno być prostym polem wyboru, które musisz włączyć,
aby spoofing adresu MAC mógł poprawnie działać. Wykonaj tę operację dla wszystkich
wirtualnych kart sieciowych, które zamierzasz wykorzystać do równoważenia obciążenia
sieciowego. Pamiętaj, że jest to ustawienie karty sieciowej, a nie maszyny wirtualnej. Jeśli
w maszynie wirtualnej masz wiele kart sieciowych, może być konieczne zaznaczenie pola dla
każdej z ich, jeśli planujesz wszystkich użyć do równoważenia obciążenia.
320
Aby można było wprowadzić modyfikację, maszyna wirtualna musi zostać wyłączona. Zamkną-
łem więc swoje serwery WEB1 i WEB2. A teraz znajdź wymagane pole wyboru i zaznacz je.
Ponieważ używana przeze mnie technologia opiera się na systemach firmy Microsoft, oczywiście
wykorzystuję Hyper-V jako platformę wirtualizacyjną dla moich maszyn z laboratorium. Jeśli
w Hyper-V kliknę prawym przyciskiem myszy serwer WEB1, a następnie przejdę do ustawień
maszyny wirtualnej, mogę następnie wybrać kartę sieciową, aby wyświetlić różne parametry,
które można dla niej zmieniać. W najnowszych wersjach środowiska Hyper-V wymagane
przez nas ustawienie znajduje się we właściwościach karty sieciowej, w sekcji Advanced Features
(Funkcje zaawansowane). Tu właśnie znalazłem pole wyboru Enable MAC address spoofing
(Zezwól na spoofing adresu MAC). Po prostu kliknij je, aby włączyć opcję, i to wszystko:
Jeśli opcja Enable MAC address spoofing jest niedostępna, pamiętaj, że maszyna wirtualna
musi zostać całkowicie wyłączona, zanim będzie można wprowadzić zmiany. Zamknij serwer,
a następnie wejdź do ustawień i spróbuj ponownie. Opcja powinna być teraz możliwa do
zmodyfikowania.
Konfigurowanie opcji NLB

Podsumujmy, w który miejscu obecnie jesteśmy. Mam dwa serwery WWW o nazwach WEB1
i WEB2. Każdy z nich ma obecnie po jednym adresie IP i ma uruchomione usługi IIS, które
zarządzają pojedynczą witryną internetową. Na każdym z nich zezwoliłem na spoofing adresów
MAC (ponieważ są one maszynami wirtualnymi) i właśnie zakończyłem instalowanie funkcji
NLB. Mamy już wszystkie składniki, które umożliwią skonfigurowanie równoważenia obciążenia
sieciowego i dzielenie ruchu między oba serwery.
Aby zdefiniować początkową konfigurację opcji NLB, będę używać serwera WEB1. Gdy się na
niego zalogujesz, będziesz mógł zauważyć, że na liście narzędzi dostępnych w Menedżerze ser-
wera pojawiła się nowa opcja o nazwie Network Load Balancing Manager (Menedżer równowa-
żenia obciążenia sieciowego). Kliknij ją, aby otworzyć konsolę. Po otwarciu Menedżera równo-
ważenia obciążenia sieciowego kliknij prawym przyciskiem myszy nazwę Network Load
Balancing Clusters (Klastry równoważenia obciążenia sieciowego) i z menu podręcznego wybierz
opcję New Cluster (Nowy klaster), jak pokazano na poniższym zrzucie ekranu:
321
Podczas tworzenia nowego klastra można zauważyć, że obecnie nie ma w nim żadnych maszyn.
Nawet serwer, w którym uruchomiliśmy tę konsolę, nie został automatycznie dodany do klastra
i musimy pamiętać, aby to zrobić. Tak więc wprowadzę nazwę swojego serwera, WEB1, i kliknę
przycisk Connect (Połącz). Po wykonaniu tej czynności Menedżer NLB wyśle zapytanie do ser-
wera WEB1 w poszukiwaniu jego kart sieciowych i wyświetli ich listę, którą mogę wykorzystać
w celu skonfigurowania równoważenia obciążenia:
Ponieważ w tym serwerze mam tylko jedną kartę sieciową, po prostu pozostawię ją wybraną
i kliknę przycisk Next (Dalej). Na następnym ekranie będzie możliwość ustawienia dodatkowych
adresów IP do serwera WEB1, ale korzystamy tylko z jednej karty sieciowej, dlatego opuszczę
ten ekran bez wprowadzania żadnych zmian i ponownie kliknę przycisk Next.
Obecnie widzimy okno zawierające prośbę o wprowadzenie adresów IP klastra. Są to adresy

wirtualne, których zamierzamy użyć do łączenia się z naszym klastrem NLB. Jak wspomniałem,
322
adresem VIP dla strony WWW będzie 10.10.10.42, więc kliknę przycisk Add… (Dodaj…)
i wpiszę ten adres IPv4 wraz z odpowiednią maską podsieci:
Kolejne kliknięcie przycisku Next spowoduje wyświetlenie okna z parametrami klastra. Zawiera
ono grupę o nazwie Cluster operation mode (Tryb działania klastra). W zależności od konfiguracji
sieci wybierz jedną z opcji Unicast (Emisja pojedyncza), Multicast (Multiemisja) i IGMP
multicast (Multiemisja IGMP) (zobacz pierwszy rysunek na następnej stronie).
Kolejny ekran kreatora NLB umożliwia konfigurację reguł portów. Domyślnie istnieje jedna re-
guła, która aktywuje równoważenie obciążenia dla każdego ruchu sieciowego korzystającego
z dowolnego portu, ale jeśli chcesz, możesz to zmienić. Ja nie znam wielu osób, które definiują tu
reguły pozwalające na przypisanie określonych portów do miejsc docelowych.
Ciekawszą opcją dostępną na tym ekranie jest jednak możliwość wyłączenia niektórych zakresów
portów. Ta funkcja może być bardzo przydatna, jeśli chcesz zablokować niepotrzebny ruch
w warstwie NLB. Na poniższym zrzucie ekranu pokazano przykładową konfigurację, która nie
pozwalałaby mechanizmowi NLB na obsługę ruchu sieciowego dla portów wyższych lub
równych 81 (zobacz drugi rysunek na następnej stronie).
323
Ukończenie tego kreatora jest równoznaczne z utworzeniem klastra NLB! Jednak do tej pory
skonfigurowaliśmy tylko adres VIP i serwer WEB1. Nie ustawiliśmy jeszcze żadnych parame-
trów serwera WEB2. Istnieje już macierz serwerów NLB, ale obecnie zawiera ona tylko jeden
węzeł, więc cały ruch sieciowy dociera wyłącznie do maszyny WEB1. Kliknij prawym przyci-
skiem myszy nowy klaster i wybierz opcję Add Host To Cluster (Dodaj hosta do klastra):
324
Wprowadź nazwę serwera WEB2, kliknij przycisk Connect (Połącz) i użyj kreatora, aby dodać
nowy węzeł WEB2 do klastra. Po skonfigurowaniu obu węzłów nasza macierz NLB — lub,
inaczej mówiąc, klaster — będzie gotowa do użycia (czy nie wspominałem, że słowo klaster
jest używane w wielu miejscach, nawet jeśli w ogóle nie mamy na myśli klastra pracy awaryjnej?).
Jeśli w konfiguracji kart sieciowych naszych serwerów WWW klikniesz przycisk Advanced
(Zaawansowane) dostępny w oknie właściwości protokołu TCP/IPv4, zobaczysz, że do interfejsu
sieciowego został dodany nasz nowy adres IP klastra 10.0.0.42. Każda karta sieciowa będzie
teraz zawierać zarówno przypisany jej adres DIP, jak i adres VIP współdzielony w macierzy:
Ruch sieciowy przeznaczony dla adresu IP 10.10.10.42 będzie rozdzielany na dwa węzły.
Na razie jednak strony WWW działające na serwerach WEB1 i WEB2 wciąż są skonfigurowane
w taki sposób, aby wykorzystywały dedykowane adresy 10.10.10.40 i 10.10.10.41, więc musimy
to zmienić.
Konfigurowanie usług IIS i DNS

Wystarczy prosta modyfikacja usługi IIS na każdym z naszych serwerów sieciowych, aby witryna
zaczęła używać odpowiedniego adresu IP. Po zdefiniowaniu konfiguracji NLB i potwierdzeniu,
że nowy adres VIP, 10.10.10.42, został dodany do kart sieciowych, możemy go użyć jako powią-
325
zania strony WWW. Otwórz konsolę zarządzania IIS i rozwiń folder Sites (Witryny), aby wy-
świetlić właściwości swojej witryny. Kliknij prawym przyciskiem myszy nazwę strony i z menu
podręcznego wybierz opcję Edit Bindings… (Edytuj powiązania…):
W oknie dialogowym Site Bindings (Powiązania witryny) wybierz powiązanie, które chcesz zmo-
dyfikować, a następnie kliknij przycisk Edit… (Edytuj…). Nasza witryna intranetowa jest
prostą stroną HTTP, więc wybiorę odpowiednie powiązanie HTTP. Jest ono obecnie przypisane
do adresu 10.10.10.40 w serwerze WEB1 i adresu 10.10.10.41 w serwerze WEB2. Oznacza
to, że witryna odpowiada tylko na ruch przychodzący na te adresy IP. Aby to zmienić, wystarczy
z menu rozwijanego IP address (Adres IP) wybrać nasz nowy adres VIP, czyli 10.10.10.42.
Po wprowadzeniu tej modyfikacji (na obu serwerach) i kliknięciu przycisku OK strona natych-
miast zacznie odpowiadać na ruch przychodzący przez adres IP 10.10.10.42:
Dochodzimy do ostatniego elementu układanki — jest nim usługa DNS. Pamiętaj, że chcieli-
byśmy, aby użytkownicy mogli w swoich przeglądarkach internetowych po prostu wprowa-
dzić adres http://intranet w celu przeglądania nowej witryny wykorzystującej równoważenie
obciążenia sieciowego, dlatego musimy odpowiednio skonfigurować rekord A hosta w usłudze
326
DNS. To działanie będzie dokładnie takie samo jak w przypadku dodawania każdego innego
rekordu hosta DNS. Po prostu utwórz go i przypisz adresowi intranet.contoso.local adres
10.10.10.42:
Testowanie rozwiązania
Czy skonfigurowano usługę równoważenia obciążenia sieciowego? Tak.
Czy powiązania IIS zostały zaktualizowane? Tak.
Czy utworzono rekord DNS? Tak.
Możemy więc przetestować nasze rozwiązanie. Jeśli otworzę przeglądarkę internetową na kom-
puterze klienckim i przejdę do adresu http://intranet, zostanie wyświetlona następująca witryna:
W jaki sposób możemy jednak sprawdzić, czy funkcja równoważenia obciążenia naprawdę
działa? Jeśli nadal będę odświeżać stronę lub przeglądać ją z innego klienta, przez cały czas będę
uzyskiwał dostęp do adresu http://intranet, aż wreszcie mechanizm NLB zdecyduje, że nowe żą-
danie powinno zostać wysłane do serwera WEB2 zamiast do WEB1. Gdy tak się stanie, wy-
świetli się następująca strona:
327
Na potrzeby tego testu zmodyfikowałem treść stron znajdujących się na serwerach WEB1
i WEB2, aby móc rozróżnić, z którego węzła są pobierane. Gdybyśmy mieli do czynienia
z prawdziwą produkcyjną witryną intranetową, musielibyśmy się upewnić, że zawartość obu
stron jest dokładnie taka sama, dzięki czemu użytkownicy byliby całkowicie nieświadomi, że
w tle działa równoważenie obciążenia sieciowego. Powinni oni tylko wiedzieć, że witryna
będzie poprawnie działać przez cały czas.
Opróżnianie pamięci podręcznej ARP

We wcześniejszej części tego rozdziału analizowaliśmy przez chwilę sposób, w jaki przełączni-
ki przechowują informacje o ARP w swojej pamięci podręcznej, co skraca czas potrzebny na
podjęcie decyzji, dokąd powinny zostać skierowane pakiety danych. Gdy karcie sieciowej
przypisujesz adres IP, wówczas w przypadku niektórych urządzeń sieciowych zostaje on
powiązany w tabeli ARP z adresem MAC tej karty. Przełączniki, routery, zapory sieciowe —
narzędzia te zwykle mają tak zwaną tabelę ARP, która zawiera zestaw danych znany pod nazwą
pamięci podręcznej ARP.
Podczas konfigurowania równoważenia obciążenia sieciowego, szczególnie w przypadku

trybu emisji pojedynczej, adres MAC karty sieciowej jest zastępowany nowym, wirtualnym
adresem MAC. Czasami przełączniki i inny sprzęt sieciowy bardzo szybko rozpoznają tę
zmianę, kojarzą nowy adres MAC z nowym adresem IP, i wszystko działa poprawnie. Zauważy-
łem jednak, że podczas konfigurowania równoważenia obciążenia sieciowego następujące
stwierdzenie jest prawdziwe: im bardziej inteligentny i droższy jest sprzęt sieciowy, tym gorzej
działa on podczas konfigurowania równoważenia obciążenia sieciowego. Chodzi mi o to, że
Twój sprzęt sieciowy może nadal używać informacji o poprzednim adresie MAC, które są prze-
chowywane w tabeli ARP i nie zostały zaktualizowane w celu odzwierciedlenia nowego
adresu MAC.
Jak to wygląda w rzeczywistości? Pakiety danych przestaną docierać do tych kart sieciowych,
których modyfikacje nie zostały zauważone przez sprzęt sieciowy. Czasami po ustanowieniu
równoważenia obciążenia sieciowego i jego włączeniu cały ruch sieciowy nagle przestaje korzy-
stać z tych interfejsów sieciowych. Co należy zrobić, aby rozwiązać problem? Czasami wy-
starczy poczekać, i w ciągu kilku minut, godzin, a nawet dni przełączniki usuną stare informacje
z pamięci podręcznej ARP i pozwolą nowym wirtualnym adresom MAC na zarejestrowanie
się w tabeli. Co możesz zrobić, aby przyspieszyć ten proces? Opróżnić pamięć podręczną ARP.
Właściwa procedura realizująca tę czynność będzie się różniła w zależności od rodzaju

sprzętu sieciowego, którego używasz. Wszystko zależy od tego, czy jest to przełącznik czy router,
jaka jest jego marka, model itd. Każde z tych urządzeń powinno jednak zawierać opcję, której
328
nazwa będzie zbliżona do opróżniania pamięci podręcznej ARP. Gdy uruchomisz tę opcję na
swoim sprzęcie, usunie ona tabelę ARP, pozbywając się starych informacji, które powodują
problemy. Dzięki temu pozwolisz nowym adresom MAC na zarejestrowanie się w odświe-
żonej tabeli.
Pamiętaj o powyższej uwadze, gdybyś podczas konfigurowania równoważenia obciążenia

sieciowego zauważył, że serwer przestał odbierać ruch sieciowy z zewnątrz. Jest bardzo
prawdopodobne, że będziesz miał wówczas do czynienia z problemem związanym z pamięcią
podręczną ARP na co najmniej jednym urządzeniu sieciowym, które próbuje zarządzać ruchem
kierowanym do serwera.
Klaster pracy awaryjnej

Ustaliliśmy, że równoważenie obciążenia sieciowego jest doskonałym rozwiązaniem dla
aplikacji bezstanowych, czego najlepszym przykładem są witryny, które chcesz udostępniać
w sposób bezawaryjny. Co można jednak zrobić w przypadku innych ról lub funkcji serwera,
które chciałbyś uczynić redundantnymi? Cóż, odwrotnością systemów bezstanowych są systemy
stanowe, więc co sądzisz o zapewnieniu wysokiej dostępności technologiom stanowym?
Taką funkcjonalność zapewnia klaster pracy awaryjnej i może być on używany w przypad-
kach, w których węzły klastra uzyskują dostęp do współdzielonych danych. Jest to kluczowy
czynnik decydujący o sposobie zaprojektowania klastrów pracy awaryjnej, ponieważ pamięć
używana przez węzły klastra musi być współdzielona i dostępna dla tych węzłów, które jej po-
trzebują. Istnieje wiele różnych ról i usług, które mogą korzystać z klastra pracy awaryjnej.
Cztery technologie wydają się jednak stanowić większość klastrów działających obecnie
w centrach danych: Hyper-V, usługi plikowe, Exchange i SQL. Jeśli wykorzystujesz którąkol-
wiek z nich (a możliwe, że używasz każdej), musisz się zapoznać z opcjami wysokiej dostępno-
ści, którą można wdrożyć w Twojej infrastrukturze za pomocą klastrów pracy awaryjnej.
Chociaż klaster pracy awaryjnej zapewniany przez system Windows Server został zaprojek-
towany w firmie Microsoft i może bardzo dobrze współpracować z wieloma innymi rolami
i usługami, należy pamiętać, że aplikacje innych firm, które działają na serwerach Windows
w Twoim środowisku, a nawet te stworzone przez programistów Twojej firmy, również mogą
korzystać z klastra pracy awaryjnej. Dopóki aplikacja korzysta z pamięci współdzielonej
i można dla niej zdefiniować zadania, które powinny być wykonywane przez narzędzia służące
do administrowania klastrami (uruchomienie i zatrzymanie usługi, monitorowanie jej stanu itp.),
można ją wykorzystać w klastrze pracy awaryjnej i zapewnić jej znaczny poziom redundancji.
Klastrowanie hostów Hyper-V

Jeden z najważniejszych przykładów wykorzystania klastra pracy awaryjnej jest jego powiąza-
nie z funkcjonalnością Hyper-V. Możliwe jest stworzenie dwóch lub większej liczby serwerów
Hyper-V, połączenie ich w klaster, a następnie udostępnienie każdemu z nich możliwości
zarządzania maszynami wirtualnymi przechowywanymi w środowisku wirtualizacji. Zapewniw-
329
szy wszystkim serwerom Hyper-V dostęp do tej samej współdzielonej pamięci, w której
przechowywane są wirtualne dyski twarde, a także konfigurując klaster pracy awaryjnej dla
węzłów, możesz stworzyć niezwykle wydajne i redundantne środowisko wirtualizacji dla swojej
firmy. Gdy jakiś serwer Hyper-V ulegnie awarii, maszyny wirtualne, które na nim działały,
zostaną w trybie awaryjnym przeniesione na inną maszynę Hyper-V i na niej się uruchomią.
Po minimalnym zakłóceniu usługi podczas uruchamiania się maszyn wirtualnych wszystko

wraca automatycznie do normy i nie potrzeba żadnych działań administracyjnych. Co więcej,
może chciałbyś zainstalować aktualizacje lub z jakiegoś innego powodu przełączyć serwer
Hyper-V w tryb offline w celu jego konserwacji? Można w prosty sposób przenieść maszyny
wirtualne na inny serwer będący elementem klastra. Będą one przenoszone „na żywo”, więc
nie pojawią się żadne przestoje. Następnie możesz usunąć węzeł i wykonać w nim określone
prace konserwacyjne przed ponownym umieszczeniem go w klastrze. Używamy maszyn wirtu-
alnych i serwerów do wszelkiego rodzaju zastosowań, więc czyż nie byłoby wspaniale, gdybyś
mógł się pozbyć pojedynczych punktów awarii w swoim środowisku wirtualizacyjnym? Wła-
śnie to może zapewnić klaster pracy awaryjnej.
Równoważenie obciążenia maszyny wirtualnej

W rzeczywistości klaster Hyper-V nie tylko ma możliwość szybkiego powrotu do stanu
działania w przypadku, gdy węzeł Hyper-V przejdzie w tryb offline, ale dodatkowo jest w nim
zawarta inteligentna logika równoważenia obciążenia współpracująca z usługami klastrowymi.
Jeśli klaster Hyper-V obsługuje zbyt wiele maszyn wirtualnych, warto dodać do niego kolejny
węzeł, który zwiększy jego możliwości i moc obliczeniową. Czy wiesz, ile pracy po dodaniu
węzła wymaga przeniesienie do niego niektórych maszyn wirtualnych?
Nie będzie potrzebne żadne działanie! Jeśli została włączona funkcja równoważenia obciąże-
nia maszyn wirtualnych, obciążenie klastra jest oceniane w sposób automatyczny, a odpowied-
nie maszyny wirtualne są przenoszone w trakcie ich działania, bez przestojów, w locie, dzięki
czemu praca jest w równym stopniu przydzielana do każdego z węzłów klastra, włącznie z nowo
utworzonym. Równoważenie obciążenia maszyn wirtualnych możesz uruchamiać na żądanie,
gdy tylko uznasz to za stosowne. Możesz także zapewnić automatyczne wykonywanie usługi
i sprawdzanie środowiska co 30 minut. Dzięki temu decyzja o przenoszeniu maszyn wirtual-
nych będzie podejmowana bez Twojego udziału.
Klastry dla usług plikowych

Klastrowanie serwerów plików jest już dostępne od dłuższego czasu. Zapotrzebowanie na
taką funkcjonalność była jednym z powodów powstania klastrów pracy awaryjnej. Pierwotnie
klastry serwerów plikowych były użyteczne tylko w przypadku korzystania z dokumentów
i tradycyjnych plików. Inaczej mówiąc, użytkownicy potrzebowali codziennego dostępu do
plików i folderów, które powinny być wysoce dostępne. Do tej pory ten ogólny typ klastra
serwera plikowego działa w trybie aktywno-pasywnym. Gdy wiele serwerów plików jest połą-
czonych razem w klastrze w celu uzyskania dostępu do plików ogólnego przeznaczenia, tylko
jeden z węzłów jest aktywny i prezentowany użytkownikom. W razie uszkodzenia aktywnego
330
węzła rola udostępniania plików zostaje przekazana do jednego z pozostałych elementów

klastra.
Skalowalny serwer plików

Chociaż ogólne klastry serwerów plikowych dobrze wywiązują się ze swojego zadania podczas
sporadycznego dostępu do plików i folderów, nie są wystarczająco uniwersalne, aby obsłużyć
również pliki, które są otwarte przez cały czas lub są wciąż zmieniane. Najlepszym przykładem
takich plików są wirtualne dyski twarde używane przez maszyny wirtualne Hyper-V.
Oczywiście, konieczne jest zastosowanie redundancji dla plików wirtualnych dysków twardych.
Ich utrata byłaby zgubna dla firmy. Na szczęście mamy funkcjonalność skalowalnego serwera
plików (ang. Scale-Out File Server, w skrócie SOFS), która potrafi zapewnić wysoki poziom
dostępu do danych aplikacyjnych. Jeśli planujesz zarządzać maszynami wirtualnymi za pomocą
usługi Hyper-V, zdecydowanie powinieneś się zainteresować możliwościami klastra pracy
awaryjnej, które mogą wspomóc tę usługę. Jeśli ponadto zamierzasz korzystać z serwerów
Hyper-V umieszczonych w klastrze, powinieneś użyć serwera z funkcjonalnością SOFS do
obsługi tego wysoce dostępnego środowiska wirtualizacji. Wspiera on działanie klastra pracy
awaryjnej w ten sposób, że zapewnia serwerom plików możliwość używania wielu węzłów
jednocześnie (tryb aktywny-aktywny), które przez cały czas są ze sobą połączone. Jeśli wówczas
jeden serwer z danymi ulegnie awarii, pozostałe zastąpią go i staną się natychmiast dostępne.
Nie nastąpi żaden proces przełączania, który wymagałby przestoju maszyn. Jest to ważne,
gdy bierzemy pod uwagę różnicę w obsłudze danych statycznych, takich jak dokumenty, i plików
wirtualnych dysków twardych, do których mają dostęp maszyny wirtualne. Maszyny wirtualne
są w stanie wciąż działać podczas awarii serwera plików zawierającego funkcjonalność
SOFS, a to naprawdę niesamowita sprawa!
Poziomy klastrowania
Konieczne będzie zrozumienie pewnego zagadnienia związanego z klastrem pracy awaryjnej.
Chodzi o różne tryby pracy klastra, które w określonych sytuacjach mogą być wykorzysty-
wane przez użytkowników. Istnieją dwa takie poziomy pozwalające na korzystanie z klastro-
wania. Możesz użyć tylko jednego z nich, ale także mógłbyś wykorzystać oba jednocześnie,
aby naprawdę zaimponować kolegom z działu wdrażania wysokiej dostępności.
Klastrowanie na poziomie aplikacji

Klastrowanie na poziomie aplikacji zwykle polega na zainstalowaniu usługi klastra pracy
awaryjnej na maszynach wirtualnych. Korzystanie z maszyn wirtualnych nie jest warunkiem
koniecznym, ale jest najczęstszą metodą instalacji. W środowisku klastrowym możesz łączyć
maszyny wirtualne z serwerami fizycznymi, o ile każdy z tych serwerów spełnia kryteria instala-
cji. Tryb klastrowania na poziomie aplikacji jest przydatny, gdy w systemie operacyjnym
działa określona usługa lub rola, którą chcesz uczynić redundantną. Potraktuj ten tryb bardziej
331
jako możliwość ustanowienia fragmentarycznego klastra pozwalającego uczynić redundantnym

pojedynczy składnik systemu operacyjnego, którego działanie w razie awarii głównego serwera
może przejąć inny węzeł.
Klastrowanie na poziomie serwera

Jeśli klastrowanie na poziomie aplikacji jest skalą mikro, wówczas klastrowanie na poziomie
serwera jest bardziej skalą makro. Najlepszy przykład, jaki mogę podać, to ten, z którym
większość administratorów rozpoczyna swoją przygodę z klastrem pracy awaryjnej. Mam na
myśli Hyper-V. Załóżmy, że masz dwa serwery fizyczne, przy czym każdy z nich zarządza
w Twoim środowisku maszynami wirtualnymi. Chciałbyś połączyć te serwery w taki sposób,
aby wszystkie maszyny wirtualne zarządzane przez nie w usłudze Hyper-V mogły być re-
dundantne. Jeśli jakiś serwer Hyper-V ulegnie awarii, drugi będzie w stanie uruchomić jego
maszyny wirtualne. Po krótkiej przerwie w pracy maszyny wirtualne wykonujące realne za-
dania w Twoim środowisku ponownie zaczynają działać i są dostępne dla użytkowników i ich
aplikacji.
Połączenie obu poziomów klastrowania

Wspomniane dwa tryby korzystania z klastra pracy awaryjnej można z pewnością połączyć
razem, aby uzyskać jeszcze lepszą i bardziej kompleksową obsługę wysokiej dostępności. Oto
przykład niewymagający komentarza: masz dwa serwery Hyper-V, z których na każdym można
uruchomić zestaw maszyn wirtualnych. Wykorzystujesz już klastrowanie na poziomie serwera,
więc jeśli jedna fizyczna skrzynka ulegnie awarii, druga zacznie działać. Jest to już obecnie
bardzo dobre rozwiązanie, ale jeśli często używasz bazy SQL, chciałbyś mieć pewność, że także
ona będzie wysoce dostępna. Możesz więc uruchomić dwie maszyny wirtualne, z których każda
zawiera serwer bazy SQL, a następnie skonfigurować dla nich klaster pracy awaryjnej na po-
ziomie aplikacji przeznaczony do usług SQL. Jeśli więc coś się stanie z pojedynczą maszyną
wirtualną, nie trzeba będzie awaryjnie się przełączać na zapasowy serwer Hyper-V, a problem
może zostać rozwiązany w prosty sposób przez udostępnienie drugiego węzła SQL. Drugi
serwer fizyczny nie musiał przejąć całej funkcjonalności pierwszego, jednak zastosowano dodat-
kowy klaster pracy awaryjnej, aby się upewnić, że baza SQL będzie zawsze dostępna. Jest to
doskonały przykład klastra zbudowanego na klastrze. Działając w ten sposób, możesz zacząć
wykazywać się kreatywnością, aby wykorzystać w swojej sieci wszystkie dostępne sposoby
użycia klastrów pracy awaryjnej.
Jak działa tryb pracy awaryjnej?

Po skonfigurowaniu klastra pracy awaryjnej wiele węzłów jest przez cały czas połączonych
ze sobą. Dzięki temu w razie awarii któregoś z nich reszta natychmiast się o tym dowiaduje i może
przenieść usługi na inny węzeł, aby przywrócić je do trybu działania. Klaster pracy awaryjnej
używa rejestru do przechowywania wielu ustawień dla poszczególnych węzłów. Te dane są syn-
chronizowane między węzłami, a gdy jeden z nich przestaje działać, niezbędne ustawienia są
wysyłane do innych serwerów. Następny węzeł w klastrze otrzymuje zadanie uruchomienia
332
wszystkich aplikacji, maszyn wirtualnych lub innych usług działających w urządzeniu, które
uległo awarii. Mogą występować niewielkie przerwy w działaniu systemów, ponieważ kom-
ponenty będą musiały poświęcić pewien czas na uruchomienie się w nowym węźle. Cały
proces jest jednak zautomatyzowany i przebiega bez angażowania administratora, co ogranicza
przestoje do absolutnego minimum.
Gdy planujesz przeniesienie usług z jednego węzła do drugiego, na przykład w celu zainstalo-
wania na serwerze poprawek lub przeprowadzenia konserwacji, pojawia się jeszcze ciekaw-
sza możliwość. Dzięki procesowi znanemu jako migracja na żywo możesz przenieść usługi
na inny węzeł bez żadnych przestojów. W ten sposób możesz usunąć węzły z klastra w celu
ich konserwacji, zainstalowania łatek bezpieczeństwa lub z jakiegokolwiek innego powodu,
nie wpływając w żaden sposób na pracę użytkowników lub systemu. Migracja na żywo jest
szczególnie przydatna w klastrach Hyper-V, w których przypadku często trzeba samemu
zdecydować, na jakim serwerze powinno się umieścić określone maszyny wirtualne, aby mieć
możliwość wykonania pewnych prac na innym węźle (lub węzłach).
Jeśli klastrów jest więcej niż jeden, stosuje się opcję o nazwie kworum. Oznacza ona, że jeśli
klaster zostanie podzielony, czyli przykładowo jakiś węzeł przestanie odpowiadać lub wiele
węzłów stanie się nagle niedostępnych z powodu rozłączenia sieci, wówczas zostanie aktywo-
wana logika kworum w celu ustalenia, który segment klastra jest tym działającym. Załóżmy, że
masz duży klaster, który obejmuje wiele podsieci, a coś niedobrego stanie się w warstwie sieci,
która rozdziela węzły tego klastra od siebie. Wówczas obie strony klastra nie mogłyby się ko-
munikować z innymi jego elementami. Bez opcji kworum te dwie strony automatycznie przy-
jęłyby, że powinny teraz wziąć odpowiedzialność za zarządzanie klastrem.
Ustawienia kworum informują klaster, ile awarii węzłów może się wydarzyć, zanim konieczne
będzie podjęcie jakichś działań. Gdy cały klaster zna konfigurację kworum, może to być przy-
datne w udzieleniu odpowiedzi na pytanie, która sekcja klastra powinna stać się podstawową
w razie jego awaryjnego podziału. W wielu przypadkach klastry zapewniają kworum, polegając
na innym obiekcie, zwanym świadkiem. Jak sama nazwa wskazuje, świadek obserwuje status
klastra i pomaga podejmować decyzje o tym, kiedy i gdzie powinno nastąpić przejście do trybu
awaryjnego. Omawianie tego zagadnienia w tym miejscu jest tylko wstępem do bardziej
szczegółowej analizy dotyczącej nowych opcji technologii klastrowania zawartych w systemie
Server 2019, z których jedna polega na ulepszeniu sposobu działania świadków w niewielkich
środowiskach.
Tworzenie złożonych klastrów, które zawierają kworum i świadków, wymaga zapoznania się
ze znacznie większą ilością informacji. Jeśli chcesz się dowiedzieć więcej na ten temat, odwiedź
stronę https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/understand-quorum.
Konfigurowanie klastra pracy awaryjnej

Poświęćmy kilka minut, aby skonfigurować niewielki klaster serwerów, dzięki czemu będziesz
mógł się zapoznać z narzędziami służącymi do zarządzania oraz opcjami, których należy
użyć, aby uzyskać pożądany rezultat. Z serwerów WEB1 i WEB2 usunąłem już całą konfigurację
333
związaną z równoważeniem obciążenia sieciowego, którą zdefiniowaliśmy wcześniej, dzięki

czemu obecnie są to po prostu zwykłe serwery WWW bez żadnej redundancji. Skonfigurujmy
więc nasz pierwszy klaster pracy awaryjnej i dodajmy do niego oba te serwery.
Konfigurowanie serwerów
Mamy już dwa serwery z zainstalowanym systemem Windows Server 2019. Na tych serwerach
nie skonfigurowałem nic specjalnego oprócz tego, że dodałem do nich rolę File Server (Serwer
plików), ponieważ docelowo stworzę z nich klaster serwerów plikowych. Kluczową kwestią jest
to, że serwery powinny być jak najbardziej podobne do siebie. Role, z których zamierzasz
korzystać w klastrze, powinny być już wcześniej zainstalowane.
Jeszcze jedna uwaga na tym etapie: jeśli to możliwe, postaraj się, aby serwery składowe należące
do tego samego klastra znajdowały się w tej samej jednostce organizacyjnej (OU) w usłudze
Active Directory (AD). Powód tego wymagania jest dwojaki. Po pierwsze, zapewnia to stosowa-
nie tych samych obiektów zasad grupy do całej grupy serwerów, dzięki czemu ich konfigu-
racje są możliwie zbliżone.
Po drugie, podczas tworzenia klastra będą automatycznie generowane pewne obiekty, które
następnie zostaną umieszczone w AD. Gdy serwery składowe będą się znajdować w tej samej
jednostce organizacyjnej, te nowe obiekty również zostaną w niej utworzone. W działającym
klastrze bardzo często zdarza się, że jego obiekty w AD są częścią tej samej jednostki organiza-
cyjnej i że jest ona przeznaczona specjalnie dla tego klastra:
334
Instalowanie funkcji
Gdy nasze serwery zostały już podłączone do sieci i działają, chcemy na nich zainstalować
opcję tworzenia klastra. Ponieważ jedną z funkcji systemu Windows Server jest Failover
Clustering (Klaster pracy awaryjnej), otwórz kreatora Add roles and features (Dodaj role
i funkcje) i dodaj ją do wszystkich węzłów przyszłego klastra:
Uruchamianie menedżera klastra pracy awaryjnej

Podobnie jak w przypadku większości pozostałych ról lub funkcji, które można zainstalować
w systemie Windows Server 2019, również teraz w menu Tools (Narzędzia) dostępnym
w Menedżerze serwera pojawi się nowa opcja. Jeśli więc zaloguję się do serwera WEB1, będę
mógł zobaczyć opcję o nazwie Failover Cluster Manager (Menedżer klastra pracy awaryjnej).
Mam zamiar otworzyć to narzędzie i zacząć konfigurować za jego pomocą pierwszy klaster:
335
Uruchamianie sprawdzania poprawności klastra

Gdy już otworzyliśmy Menedżera klastra pracy awaryjnej, w sekcji Management (Zarządzanie),
w okolicach środka okna, widzimy listę zadań dostępnych do wykonania:
Zanim będziemy mogli skonfigurować sam klaster lub dodać do niego węzły serwerów, musimy
najpierw sprawdzić konfigurację sprzętową. Klaster pracy awaryjnej jest dość złożonym zesta-
wem technologii, więc istnieje wiele elementów, których niepoprawne konfiguracje lub niespój-
ności mogłyby doprowadzić do awarii całego środowiska. Twoje plany związane z konfiguracją
klastra mają oczywiście na celu uzyskanie niezawodnej redundancji, ale nawet prosty błąd
w konfiguracji serwerów składowych może powodować problemy na tyle duże, że awaria
węzła nie doprowadzi do automatycznego odzyskania systemu, co kłóci się z głównym celem
definiowania klastra. Aby się upewnić, że wszystkie szczegóły zostaną poprawnie skonfigu-
rowane, w Menedżerze klastra pracy awaryjnej zdefiniowano kilka złożonych procedur
sprawdzania, które są czymś w rodzaju wbudowanego analizatora najlepszych wzorców postę-
powania. Analizę można uruchomić w dowolnym momencie — przed stworzeniem klastra
lub po wielu latach jego produkcyjnego użytkowania. Jeśli kiedykolwiek będziesz musiał
wysłać zgłoszenie do pomocy technicznej w firmie Microsoft, najprawdopodobniej pierwszą
czynnością, o którą zostaniesz poproszony, będzie uruchomienie narzędzi sprawdzania popraw-
ności konfiguracji i umożliwienie pracownikom działu obsługi technicznej przejrzenia wyników.
Aby rozpocząć proces sprawdzania poprawności, kliknij łącze Validate Configuration…

(Zweryfikuj konfigurację…). Uruchomiliśmy kreatora pozwalającego wybrać, które elementy
technologii klastrowej chcielibyśmy sprawdzić. Po raz kolejny musimy zacząć myśleć zgodnie
z filozofią scentralizowanego zarządzania wymyśloną przez firmę Microsoft: ten kreator nie
wie tego — ani o to nie dba — że działa na jednym z serwerów składowych, który zamierzam
dodać do klastra. Musimy zidentyfikować każdy z węzłów serwera, które chcemy przeska-
nować w celu sprawdzenia ich poprawności, tak więc poinformuję kreatora, że chciałbym
sprawdzić serwery WEB1 i WEB2 (zobacz pierwszy rysunek na następnej stronie).
Na ekranie Testing Options (Opcje testowania) można wybrać opcję Run only tests I select (Uru-
chom tylko wybrane testy), dzięki czemu będziesz mógł uruchomić tylko określone testy kontrol-
ne. W zasadzie podczas konfigurowania nowego klastra będziesz chciał uruchomić wszystkie
testy, aby się upewnić, że wszystko działa poprawnie. W systemie produkcyjnym można jed-
nak ograniczyć liczbę uruchomionych testów. Jest to stwierdzenie szczególnie prawdziwe w od-
niesieniu do testowania opcji Storage (Magazyn), ponieważ w tym przypadku podczas urucha-
miania testów klaster może przejść w tryb offline, a przecież nie chciałbyś ingerować w działające
usługi produkcyjne, jeśli nie wykonujesz swojej pracy w zaplanowanym oknie obsługi (zobacz
drugi rysunek na następnej stronie).
336
Ponieważ zakładam nowy klaster, pozwolę sobie na uruchomienie wszystkich testów, dlatego
zalecaną opcję Run all tests (recommended) (Uruchom wszystkie testy (zalecane)) pozostawiam
wybraną i klikam przycisk Next (Dalej):
Po zakończeniu testów zobaczysz podsumowanie wyników. Możesz kliknąć przycisk View

Report… (Wyświetl raport…), aby zapoznać się ze szczegółowymi informacjami dotyczącymi
przeprowadzonych testów. Pamiętaj, że istnieją trzy rodzaje wyników. Komunikat w kolorze
337
zielonym jest pozytywny, w czerwonym natomiast negatywny, a kolor żółty oznacza, że opcja
będzie działać, ale nie stosujesz się do najlepszych wzorców. Na przykład każdy z moich serwe-
rów jest wyposażony tylko w jedną kartę sieciową. Kreator ostrzega, że powinny one zawierać po
dwie karty, aby moja konfiguracja była naprawdę redundantna. Oczywiście, będę mógł kontynu-
ować pracę, ale otrzymam wskazówkę, że powinienem ulepszyć klaster przez dodanie drugiej
karty sieciowej do każdego z węzłów.
Jeśli kiedykolwiek będziesz musiał ponownie otworzyć ten raport lub go pobrać, aby zapisać go
w bezpiecznym miejscu, pamiętaj o tym, że znajduje się on w katalogu, z którego uruchomiono
testy, czyli C:\Windows\Cluster\Reports:
Uruchamianie kreatora tworzenia klastra

Jeśli pojawiło się wiele punktów, które wymagają naprawy, faza sprawdzania poprawności
może trochę potrwać, zanim będziesz mógł kontynuować swoją pracę. Gdy jednak sprawdzanie
poprawności zakończy się pełnym sukcesem, będziesz mógł rozpocząć tworzenie klastra. W tym
celu kliknij następną czynność dostępną w konsoli Menedżera klastra pracy awaryjnej, czyli
Create Cluster… (Utwórz klaster…).
Ponownie musimy najpierw określić, które serwery powinny być częścią nowego klastra, dlatego
wprowadzę tutaj nazwy swoich serwerów, WEB1 i WEB2. Oprócz tego w celu skonfigurowania
klastra nie trzeba podawać zbyt wielu danych, jednakże na ekranie Access Point for Administering
the Cluster (Punkt dostępu do administrowania klastrem) musisz wprowadzić unikatową nazwę,
która będzie używana przez klaster i współdzielona między jego serwerami składowymi. Jest
ona znana jako Cluster Name Object (obiekt nazwy klastra, w skrócie CNO). Po zakończeniu
konfiguracji klastra zobaczysz tę nazwę w postaci obiektu AD:
338
Po zakończeniu pracy kreatora możesz zauważyć, że w interfejsie Menedżera klastra pracy

awaryjnej pojawił się nowy klaster, dzięki czemu będziesz mógł się zająć bardziej szczegółowym
konfigurowaniem jego funkcji, takich jak Configure Role… (Konfiguruj rolę…), której bę-
dziesz musiał użyć przy ustalaniu rzeczywistego zastosowania klastra, oraz Add Node… (Dodaj
węzeł…), która pozwoli na dodanie kolejnych serwerów składowych:
Najnowsze ulepszenia dotyczące

klastrowania w systemie Windows Server
Funkcjonalność klastrowania jest dostępna już od jakiegoś czasu, ale wciąż jest ulepszana.
W dwóch najnowszych wydaniach LTSC (Server 2016 i Server 2019) wprowadzono duże
zmiany i nowe elementy. Niektóre modyfikacje, które omówimy, zostały pierwotnie wprowa-
dzone w wersji Server 2016, więc nie są zupełnie nowe, ale też dotyczą metody obsługiwania
klastrów w wersji Server 2019, dlatego warto o nich wspomnieć.
Prawdziwe dwuwęzłowe klastry ze świadkami

wykorzystującymi medium USB
Zanim pojawił się system Server 2019, klaster dwuwęzłowy podczas konfigurowania kworum
wymagał użycia trzech serwerów, ponieważ świadek kworum musiał się znajdować na jakimś
udziale, zazwyczaj oddzielnym serwerze plików.
339
Począwszy od wersji Server 2019 świadek może być zwykłym dyskiem USB i nie musi nawet
zostać podłączony do systemu Windows Server! Istnieje wiele urządzeń sieciowych (przełącz-
niki, routery itp.), które mogą akceptować nośniki danych oparte na USB. Pamięć USB podłą-
czona do takiego urządzenia sieciowego spełnia wymagania świadka klastra. Jest to ważna
zaleta podczas definiowania klastrów w niewielkich środowiskach.
Wyższe bezpieczeństwo klastrów

W systemie Windows Server 2019 wprowadzono szereg ulepszeń bezpieczeństwa dotyczą-
cych klastrów pracy awaryjnej. Poprzednie wersje wykorzystywały protokół New Technology
LAN Manager (NTLM) do uwierzytelniania ruchu wewnątrz klastra, ale wiele firm podejmuje
aktywne działania, aby przestać go używać (a przynajmniej jego wczesnych wersji) w swoich
sieciach. Klaster pracy awaryjnej może teraz realizować wewnętrzną komunikację przy użyciu
protokołu Kerberos i certyfikatów służących do sprawdzania poprawności ruchu sieciowego,
dzięki czemu nie trzeba już stosować NTLM.
Inną opcją związaną z bezpieczeństwem i stabilnością, która została zaimplementowana podczas

ustanawiania udziału plikowego dla świadka klastra pracy awaryjnej, jest niedopuszczanie
świadków przechowywanych w rozproszonym systemie plików. Tworzenie świadka w udziale
rozproszonego systemu plików nigdy nie było obsługiwane, jednakże wcześniej konsola pozwa-
lała na taką operację. Okazało się, że niektóre firmy wdrożyły takie rozwiązanie i zapłaciły za
to wysoką cenę, ponieważ może ono powodować problemy związane ze stabilnością klastra.
Narzędzia do zarządzania klastrami zostały odpowiednio zaktualizowane w celu sprawdzania
istnienia przestrzeni nazw rozproszonego systemu plików podczas tworzenia świadka, dlatego
nie pozwalają już na taką operację.
Klastry korzystające z wielu lokalizacji

Czy mogę skonfigurować klaster pracy awaryjnej dla podsieci? Innymi słowy, jeśli mam podsta-
wowe centrum danych, a także wynajmuję przestrzeń od firmy KoLo za rogiem lub używam
dodatkowego centrum danych położonego w innym miejscu, czy będę miał dostępne opcje
konfiguracji klastra między fizycznie oddzielonymi węzłami? Mam szybką i prostą odpowiedź:
tak, dla klastra pracy awaryjnej nie ma to znaczenia! Analogicznie do sytuacji, w której węzły
serwera znajdują się obok siebie, można również wykorzystać wiele lokalizacji, z których
każda zawiera własne węzły klastrowe. Usługi będą mogły być przenoszone pomiędzy tymi
lokalizacjami.
Klastry w wielu domenach lub grupie roboczej

Kiedyś mogliśmy ustanowić klaster pracy awaryjnej jedynie między węzłami przyłączonymi
do tej samej domeny. System Windows Server 2016 daje możliwość wyjścia poza to ogranicze-
nie, a nawet można zbudować klaster zupełnie pozbawiony usługi Active Directory. W syste-
mach Server 2016 i Server 2019 oczywiście nadal możesz tworzyć klastry, w których wszystkie
węzły są połączone z tą samą domeną. Spodziewam się, że na tym będzie polegać większość
340
instalacji. Jeśli jednak masz serwery połączone z różnymi domenami, możesz teraz ustanowić
klaster między nimi. Ponadto serwery składowe klastra mogą obecnie należeć tylko do grupy
roboczej i wcale nie muszą zostać dołączone do domeny.
Chociaż poszerza to dostępne możliwości tworzenia klastrów pracy awaryjnej, jest również kilka
ograniczeń. Podczas korzystania z klastrów w wielu domenach lub grupie roboczej będziesz
musiał używać wyłącznie programu PowerShell, który jest interfejsem służącym do zarządzania.
Jeśli jesteś przyzwyczajony do interakcji z klastrami za pomocą jednego z narzędzi graficz-
nych, powinieneś w tym przypadku zmienić swój sposób myślenia. Konieczne będzie również
utworzenie lokalnego konta użytkownika, które zostanie użyte w klastrze i udostępnione do każ-
dego z jego węzłów. Konto musi mieć na tych serwerach węzłowych uprawnienia administracyjne.
Migracja klastrów między domenami

Chociaż tworzenie klastrów w wielu domenach było możliwe już od kilku lat, opcja migracji
klastrów z jednej domeny AD do drugiej nie była dostępna. Zmieniło się to jednak w wersji
Server 2019. Mamy obecnie większe możliwości w trakcie tworzenia klastrów w wielu dome-
nach, a także możemy migrować klastry pomiędzy nimi. Ta funkcjonalność wspiera admini-
stratorów podczas przejmowania firm i realizowania projektów konsolidacji domen.
Uaktualnienia stopniowe systemu operacyjnego klastra

Ta nowa funkcja, która pojawiła się w wersji Server 2016, ma co prawda dziwną nazwę, ale jest
rzeczywiście interesująca. To coś, co powinno pomóc ulepszyć środowisko tym administratorom,
którzy od jakiegoś czasu korzystali z klastra pracy awaryjnej. Jeśli obecnie wykorzystujesz
klaster oparty na systemie Windows Server 2012 R2, zdecydowanie warto, abyś przyjrzał się
temu rozwiązaniu. Funkcja uaktualniania stopniowego systemu operacyjnego klastra umożliwia
bezprzestojowe uaktualnienie systemów operacyjnych węzłów klastra z wersji Server 2012 R2
do Server 2016, a następnie do Server 2019. Nie ma potrzeby zatrzymywania żadnej z usług
w środowisku Hyper-V lub skalowalnym serwerze plików korzystającym z klastra. Wystarczy
przeprowadzić proces stopniowego uaktualnienia, a wszystkie węzły klastra będą zawierać
nowszą wersję systemu Windows Server. Klaster wciąż będzie widoczny w sieci i aktywny, a nikt
nie będzie wiedział, że nastąpiła jego aktualizacja. Oczywiście nikt oprócz Ciebie.
Różni się to znacznie od poprzedniego procesu aktualizacji, w którym w celu zainstalowania

systemu Server 2012 R2 na serwerach klastra trzeba było przełączyć go w tryb offline, dodać
nowe węzły serwera z uruchomionym systemem 2012 R2, a następnie przywrócić klaster.
Cały proces wymagał dużo przestojów. Ta perspektywa była bardzo stresująca i przyprawiała
administratorów o ból głowy.
Sztuczka, która obecnie umożliwia bezproblemową aktualizację, polega na tym, że sam klaster
nadal działa na poziomie funkcjonalności 2012 R2, dopóki nie wydasz polecenia przełączenia go
na poziom funkcjonalności systemu Server 2016. Do czasu wykonania tego polecenia klaster
działa na starszym poziomie funkcjonalnym, nawet w przypadku nowo wprowadzonych węzłów
zaopatrzonych w system operacyjny Server 2016. W trakcie indywidualnego uaktualniania
pojedynczych węzłów pozostałe serwery, które nadal są aktywne w klastrze, pozostają w trybie
341
online i wciąż obsługują użytkowników i aplikacje, dzięki czemu wszystkie systemy z punktu wi-
dzenia środowiska działają poprawnie. Nowe maszyny z systemem Server 2016, które są doda-
wane do klastra, przechodzą w tryb online, ale na poziomie funkcjonalności Windows Server
2012 R2. Jest to określane jako tryb mieszany. Dzięki temu możesz nawet usunąć ostatnią ma-
szynę z Windows 2012 R2, zmienić jej system na Server 2016 i przywrócić do klastra — nikt
nie będzie o tym wiedział. Następnie, po zakończeniu wszystkich aktualizacji systemu opera-
cyjnego, wydajesz w programie PowerShell polecenie Update-ClusterFunctionalLevel, aby przełą-
czyć poziom funkcjonalności, i masz w wyniku tego klaster systemu Windows Server 2016,
który został bezproblemowo zaktualizowany bez przestojów.
Odporność maszyn wirtualnych

Jak można wywnioskować z nazwy, odporność maszyn wirtualnych to ulepszenie funkcjo-
nalności klastra, które szczególnie korzystnie wpływa na klastry serwerów Hyper-V. Gdy klastry
wykorzystywały system Server 2012 R2, często zdarzały się problemy z komunikacją we-
wnętrzną. Czasami oznaczało to przejściową awarię: klaster sądził, że jakiś węzeł przechodzi
w tryb offline, choć w rzeczywistości tak się nie działo, a następnie uruchamiał przełączenie
awaryjne, które mogło powodować więcej przestojów w porównaniu z sytuacją, gdyby wzorce
rozpoznawania prawdziwej awarii zostały po prostu trochę lepiej skonstruowane. W większości
przypadków sam klaster i przełączanie awaryjne jego węzłów działały, ale oczywiście zawsze
można wprowadzić jakieś ulepszenia. Jednym z nich jest właśnie odporność maszyn wirtual-
nych. Możesz obecnie konfigurować opcje odporności, aby móc dokładniej określić zacho-
wanie węzła klastra podczas jego awarii. Można zdefiniować takie elementy jak poziom odpor-
ności, który informuje klaster, jak powinien sobie radzić z awariami. Określasz także okres
odporności, czyli czas, przez który maszyny wirtualne mogą działać w stanie izolowanym.
Inna zmiana polega na tym, że niepoprawnie działające węzły klastra są obecnie umieszczane
w kwarantannie na czas określony przez administratora. Nie wolno im ponownie przyłączyć
się do klastra, dopóki nie zostaną zidentyfikowane jako w pełni funkcjonalne i nie spędzą okre-
ślonego czasu w kwarantannie. Zapobiega to sytuacjom takim jak awaria węzła, który utknął
w czasie restartu, ponieważ niezamierzenie przyłączył się do klastra, i powodował ciągłe pro-
blemy przez to, że cyklicznie przełączał swój stan z offline na online.
Storage Replica
Storage Replica (w skrócie SR) to nowy sposób synchronizacji danych między serwerami.
Jest to technologia replikacji danych na poziomie bloków, która umożliwia wykonywanie
procesu kopiowania pomiędzy serwerami znajdującymi się nawet w różnych lokalizacjach
fizycznych. Storage Replica jest pewnym rodzajem redundancji, który nie istniał przed wy-
daniem systemu Windows Server 2016. Wcześniej, aby skorzystać z takiej funkcjonalności,
musieliśmy polegać na narzędziach innych firm. Tę technologię warto przy tym zaprezento-
wać zaraz po analizie klastra pracy awaryjnej, ponieważ jest ona tajemniczym składnikiem,
który umożliwia tworzenie klastrów pracy awaryjnej korzystających z wielu lokalizacji. Jeśli
chcesz zarządzać węzłami klastra znajdującymi się w wielu różnych lokalizacjach fizycz-
342
nych, potrzebujesz sposobu, aby się upewnić, że dane używane przez te węzły są synchroni-
zowane w sposób ciągły, tak aby możliwe było zrealizowanie przełączenia awaryjnego. Taki
przepływ danych zapewnia technologia Storage Replica.
Jedną ze sprytnych cech rozwiązania Storage Replica jest to, że pozwala jednemu dostawcy
rozwiązania (przy czym tym dostawcą jest oczywiście firma Microsoft) udostępniać kom-
pleksową technologię i oprogramowanie służące do przechowywania danych oraz tworzenia
klastrów. Jest ono również niezależne od sprzętu, co daje możliwość korzystania z własnych
nośników pamięci.
Rozwiązanie Storage Replica stanowi jedną z technologii wspierających dojrzałe środowisko

klastra pracy awaryjnej i jest ściśle z nim zintegrowane. Graficzny interfejs zarządzania SR znaj-
duje się faktycznie w oprogramowaniu Menedżera klastra pracy awaryjnej. Tę technologię
można oczywiście konfigurować także za pomocą programu PowerShell. Zainteresuj się więc
połączeniem klastra pracy awaryjnej z rozwiązaniem Storage Replica, ponieważ ich dobra
współpraca będzie korzystna dla Twojego środowiska.
Jeśli chodzi o system Windows Server 2019, wart podkreślenia jest fakt, że technologia Storage
Replica jest obecnie dostępna już w wersji Server 2019 Standard Edition (wcześniej wymagała
ona wersji Datacenter, która nie mogła być wykorzystywana w niektórych implementacjach)!
Zarządzanie rozwiązaniem jest możliwe za pomocą znanej już Ci aplikacji Windows Admin
Center (WAC).
Bezpośrednie miejsce do magazynowania

Bezpośrednie miejsce do magazynowania (ang. Storage Spaces Direct — S2D) to technologia
klastrowa, ale poświęciłem jej oddzielny punkt, ponieważ jest ona podstawowym składnikiem
programowalnego centrum danych (SDDC) i przez ostatnich kilka lat tak bardzo się rozwijała,
że w rzeczywistości stała się oddzielną kategorią.
Mówiąc w skrócie, S2D jest sposobem pozwalającym zbudować niezwykle wydajną i redun-
dantnie scentralizowaną platformę przechowywania danych opartą na sieci, wykorzystującą
wyłącznie serwery Windows. Mimo że zadaniem tej technologii jest przechowywanie plików,
przez co nie różni się od tradycyjnych systemów NAS lub SAN, jest oparta na zupełnie innym
rozwiązaniu, ponieważ nie wymaga specjalistycznego sprzętu, specjalnych przewodów ani
połączenia między węzłami klastra S2D.
Do stworzenia bezpośredniego miejsca do magazynowania wymagane są wyłącznie maszyny

z systemem Windows Server. Im będą one wydajniejsze, tym lepiej, ale mogą to być również
normalne serwery do zwykłych zastosowań. Serwery te muszą być ze sobą połączone przez
sieć, ale nie istnieją tu żadne specjalne wymagania. Po prostu powinny być podłączone do sieci,
tak jak w przypadku każdego innego serwera w Twoim środowisku. Po uruchomieniu tych
serwerów możesz wykorzystać technologię klastra lub interfejs nowego menedżera WAC, aby
dodać je do macierzy S2D.
343
Bezpośrednie miejsce do magazynowania jest składnikiem ogólnej technologii infrastruktury

hiperkonwergentnej (ang. Hyper-Converged Infrastructure — HCI) i dzięki temu jest wspaniałą
metodą uzyskania wyjątkowo szybkiej i chronionej pamięci do dowolnych zastosowań, jednak
szczególnie sprawdza się w takich rozwiązaniach jak klastry serwerów Hyper-V. Jak już wiesz,
podczas tworzenia klastra serwerów Hyper-V jego węzły muszą mieć dostęp do pamięci
współdzielonej, w której będą się znajdować pliki dysków twardych maszyn wirtualnych.
S2D to najlepszy sposób na zapewnienie scentralizowanej pamięci.
Dzięki tej technologii dyski twarde serwerów będących węzłami klastra S2D zostaną połą-
czone ze sobą, tak że utworzą pule pamięci definiowane programowo. Te pule pamięci będą
miały funkcje buforowania, a nawet wbudowaną odporność na uszkodzenia. Oczywiście nie
chciałbyś, aby pojedynczy węzeł S2D, a nawet pojedynczy dysk twardy przestał działać, co mo-
głoby spowodować problem dla środowiska Storage Space Direct. Oczywiście firma Microsoft
także nie chce, aby tak się stało. Gdy więc grupujesz serwery i umieszczasz wszystkie ich
dyski twarde w dużych pulach pamięci S2D, dyski te są automatycznie konfigurowane w taki
sposób, aby informacje o parzystości były rozproszone pomiędzy nimi, tak więc nawet jeśli
jakiś komponent przestanie działać, nie spowoduje to utraty danych, ani nawet spowolnienia
systemu.
Bezpośrednie miejsce do magazynowania jest najlepszym rozwiązaniem do przechowywania

danych dla klastrów skalowalnych serwerów plików (SOFS) i Hyper-V.
Chociaż w przypadku wersji Server 2016 obsługa S2D polega głównie na wykorzystaniu pro-
gramu PowerShell (co niestety oznacza, że wielu administratorów nie próbowało wdrażać
tego rozwiązania), jednak Windows Server 2019 zapewnia nowy zestaw narzędzi i opcji konfigu-
racyjnych, zawarty w aplikacji Windows Admin Center:
Bezpośrednie miejsce do magazynowania to jedna z technologii, którym należałoby poświęcić

całą książkę, jednak każdy administrator, który chciałby ją przetestować, powinien zacząć od za-
poznania się z dokumentacją dostępną pod adresem https://docs.microsoft.com/en-us/windows-
-server/storage/storage-spaces/storage-spaces-direct-overview.
344
Nowości w systemie Windows Server 2019

Oto lista nowości szczególnie przydatnych dla osób, które znają już technologię bezpośredniego
miejsca do magazynowania i chciałyby się dowiedzieć, co zostało dodane lub zmieniło się w wer-
sji Server 2019:
 Lepsze wykorzystanie woluminów systemu plików Resilient File System (ReFS):
istnieje obecnie możliwość deduplikacji i kompresji woluminów ReFS
zarządzanych przez S2D.
 Świadek w postaci pamięci USB: wspominałem już, że w celu nadzorowania
klastra S2D, który składa się tylko z dwóch węzłów, możesz teraz użyć pamięci
USB podłączonej do urządzenia sieciowego, zamiast uruchamiać w tym celu
dodatkowy, trzeci serwer.
 WAC: aplikacja WAC zawiera obecnie narzędzia i funkcje służące do definiowania
klastrów S2D i zarządzania nimi. Ułatwi to wdrażanie rozwiązań osobom, które
nie mają dużego doświadczenia w programowaniu PowerShell.
 Zwiększona pojemność: klaster może mieć obecnie wielkość 4 PB.
 Zwiększona wydajność: chociaż technologia S2D sprawnie działała od samego
początku, w wersji Server 2019 wprowadzono pewne dodatkowe ulepszenia.
Na zeszłorocznej konferencji Ignite firma Microsoft zaprezentowała ośmiowęzłowy
klaster S2D, który był w stanie osiągnąć 13 000 000 operacji wejścia-wyjścia
na sekundę (IOP). Coś niesamowitego!
Podsumowanie
Redundancja jest we współczesnym świecie kluczowym elementem wpływającym na sposób
planowania infrastruktury i tworzenia serwerów. Windows Server 2019 ma wbudowane potęż-
ne funkcje, z których natychmiast możesz skorzystać w swoim środowisku! Mam nadzieję, że
dzięki zdobyciu odpowiedniej wiedzy na temat zarówno równoważenia obciążenia sieciowego,
jak i klastra pracy awaryjnej będziesz w stanie usprawnić działanie swojej organizacji przez
zastosowanie zaprezentowanych technik i poprawę współczynnika dostępności usług. Jeśli mógł-
bym coś zasugerować, rozpocznij od zbudowania własnej infrastruktury hiperkonwergentnej.
Wykorzystaj w tym celu bezpośrednie miejsce do magazynowania i klaster pracy awaryjnej,
dzięki czemu Twoja infrastruktura Hyper-V zostanie uodporniona. Wdrożenie infrastruktury
hiperkonwergentnej zmieni sposób Twojej pracy i zapewni Ci spokój, którego wcześniej nie
mógłbyś osiągnąć w świecie dążącym do 99,999% ciągłości czasu działania. W następnym roz-
dziale przyjrzymy się programowi PowerShell.
345
Pytania
1. Jaka technologia jest bardziej odpowiednia do implementacji redundancji ruchu
sieciowego na serwerze WWW — równoważenie obciążenia sieciowego czy klaster
pracy awaryjnej?
2. Co oznaczają akronimy DIP i VIP w przypadku równoważenia obciążenia
sieciowego?
3. Jakie są trzy tryby pracy równoważenia obciążenia sieciowego?
4. Czy opcja „równoważenie obciążenia sieciowego” jest w systemie Windows
Server 2019 rolą czy funkcją?
5. Jakie role są najczęściej wykorzystywane w przypadku klastra pracy awaryjnej?
6. Jakiego rodzaju niewielkiego urządzenia można obecnie używać jako świadka
kworum klastra (jest to nowość w systemie Server 2019)?
7. Bezpośrednie miejsce do magazynowania wymaga użycia dysków SSD —
prawda czy fałsz?
346
10
PowerShell
Bądźmy szczerzy — wielu z nas nadal codziennie korzysta z wiersza poleceń. Jeśli jednak
należysz do tych osób, które zaczęły używać nowszej powłoki PowerShell jako całkowitego
zamiennika wiersza poleceń, czapki z głów! Sam nadal mam tendencję do otwierania z przy-
zwyczajenia programu cmd.exe, chociaż w najnowszych wersjach systemu Windows 10
i Windows Server 2019 zdecydowanie częściej podejmuję świadomy wysiłek, aby korzystać
z nowszego, bardziej niebieskiego, ładniejszego i potężniejszego interfejsu, jakim jest PowerShell.
W tym rozdziale dowiesz się, dlaczego też powinieneś to zrobić. Poza faktem, że firma Micro-
soft zmniejszyła domyślny rozmiar czcionki w oknie starego interfejsu, aby zniechęcić nas
do korzystania z niego (co uważam za dość zabawne), istnieją przyczyny czysto techniczne,
dla których PowerShell jest o wiele bardziej przydatny i potężniejszy, niż kiedykolwiek mógłby
być wiersz poleceń.

 Dlaczego warto używać interfejsu PowerShell?
 Praca z programem PowerShell.
 Zintegrowane środowisko skryptowe PowerShell.
 Zdalne zarządzanie serwerem.
 Konfiguracja żądanego stanu.
Dlaczego warto używać interfejsu

PowerShell?
Nie sądzę, aby administratorzy zastanawiali się kiedykolwiek, czy program PowerShell jest
faktycznie ewolucją wiersza poleceń, ale powodem, dla którego wielu z nas wciąż domyślnie
korzysta ze starego interfejsu, jest to, że nadal pozwala nam realizować zadania związane
z serwerami. Interfejs wiersza poleceń tak naprawdę pozwala w dalszym ciągu wykonywać
te same zadania, do których zawsze go wykorzystywaliśmy, i to wszystko. Nie zdajemy sobie

nawet sprawy, jak wiele funkcji używamy w środowisku graficznym, które nie są obsługiwane
w oknie wiersza poleceń.
Ograniczenia wiersza poleceń, które zmuszają Cię do używania myszy i współpracy z inter-
fejsem graficznym, nie istnieją w programie PowerShell. Jest on jak najbardziej wszech-
stronny i może modyfikować prawie każdy aspekt systemu operacyjnego Windows. W jaki
sposób PowerShell stał się o wiele potężniejszy niż wiersz poleceń? Różni się on od dowol-
nej klasycznej powłoki poleceń tym, że został zbudowany na platformie .NET, i dlatego jest
bardziej podobny do języka programowania niż prostych instrukcji wejścia i wyjścia.
Polecenia cmdlet
Większość funkcji, których użyje tradycyjny administrator serwera, będzie miało postać pole-
ceń cmdlet (skrót od angielskich słów command-let). Są to polecenia uruchamiane z wiersza
poleceń programu PowerShell, ale można je traktować raczej jako narzędzia niż proste in-
strukcje. Poleceń cmdlet można używać zarówno do uzyskiwania informacji, jak i wprowadza-
nia danych i parametrów do serwera. Wiele poleceń cmdlet ma intuicyjne nazwy, które zaczy-
nają się od get lub set. Podobnie jak większość interfejsów wiersza poleceń, również każde
polecenie cmdlet zawiera różne przełączniki lub opcje, które można konfigurować i umiesz-
czać na końcu instrukcji, aby uzyskać zaawansowaną funkcjonalność. Warto wiedzieć, że pole-
cenia cmdlet zawsze występują w postaci czasownik-rzeczownik. Ty określasz akcję, którą
chcesz wykonać (na przykład get lub set), a następujący po niej rzeczownik jest elementem
systemu Windows, który próbujesz modyfikować. Oto kilka prostych przykładów poleceń
cmdlet w programie PowerShell, które dają wyobrażenie o tym, jak one wyglądają i jak proste
mają nazwy:
 Get-NetIPAddress: za pomocą tego polecenia cmdlet możemy wyświetlić adresy
IP istniejące w naszym systemie.
 Set-NetIPAddress: możemy użyć tego polecenia do zmodyfikowania istniejącego
adresu IP.
 New-NetIPAddress: to polecenie cmdlet pozwala nam utworzyć dla komputera
nowy adres IP.
 Rename-Computer: jak już wiesz, to polecenie umożliwia szybkie i łatwe
wprowadzenie nazwy komputera w systemie.
Jeśli nie będziesz pamiętać nazwy lub składni określonego polecenia, zawsze możesz sko-
rzystać z witryny internetowej Microsoft Docs (dawniej, a czasami i obecnie nazywanej
TechNetem), która zawiera pełne informacje o każdym poleceniu cmdlet dostępnym w pro-
gramie PowerShell. Może być ona niezwykle przydatna, ale niekiedy po prostu nie będziesz
chciał tracić czasu na wchodzenie do internetu, aby znaleźć nazwę polecenia, którego w tej
chwili nie pamiętasz. Jedno z najbardziej przydatnych poleceń cmdlet w programie Po-
werShell wyświetla listę wszystkich dostępnych poleceń. Koniecznie sprawdź w działaniu
Get-Command:
348
Rozdział 10. • PowerShell
Wyświetliło się nam mnóstwo stron z poleceniami cmdlet! Zamiast przeszukiwać całą listę,
aby znaleźć potrzebne polecenie, można w prosty sposób ją przefiltrować według dowol-
nych kryteriów. Gdybyśmy chcieli zobaczyć tylko polecenia dotyczące adresowania IP, mo-
glibyśmy spróbować wykonać coś takiego:
Get-Command -Name *IPAddress*
Polecenie cmdlet Get-Command w połączeniu z parametrem -Name umożliwia selektywne wy-

szukiwanie przydatnych elementów w programie PowerShell, które odnoszą się do dowolnej
nazwy lub jej fragmentu:
PowerShell jest podstawą

Jak będziesz mógł się dowiedzieć w tym rozdziale, używanie programu PowerShell pozwala
zyskać potężną władzę nad systemem. Czasem jednak dowiadujemy się, że administratorzy
nie w pełni ufają interfejsowi PowerShell, ponieważ są przyzwyczajeni do wykonywania
działań i wprowadzania zmian za pomocą interfejsu graficznego. Po wykonaniu pojedyncze-
go polecenia cmdlet programu PowerShell w celu uruchomienia procesu konfiguracyjnego,
który alternatywnie wymagałby kilkunastu różnych kliknięć myszą, faktycznie łatwo jest myśleć,
349
że tak naprawdę nic nie zostało wykonane. To było chyba zbyt proste, a program za szybko
przetworzył moje polecenie, prawda? W każdym razie lepiej wrócę do interfejsu graficzne-
go, aby dokładniej sprawdzić, czy PowerShell rzeczywiście wykonał zadanie.
Gdy zacząłem używać programu PowerShell, ciągle mnie kusiło, aby robić dokładnie to, o czym
wspomniałem powyżej. Ale im częściej go wykorzystywałem i im dokładniej analizowałem
interfejsy graficzne, tym bardziej zdawałem sobie sprawę, że nie tylko ja go używam. Wiele gra-
ficznych narzędzi administracyjnych również to robi! Nawet nie zdając sobie z tego sprawy,
używasz programu PowerShell do wykonywania różnych zadań w systemie operacyjnym
Windows Server. Co się stanie, gdy otworzysz konsolę zarządzania, aby mieć możliwość mo-
dyfikacji każdego składnika serwera, wprowadzisz jakąś zmianę, a następnie klikniesz przycisk
Przejdź lub Zakończ? Jak myślisz, w jaki sposób ta konsola graficzna wprowadziła do syste-
mu Twoją modyfikację? Użyła programu PowerShell. Konsola w tle odczytuje wprowadzane
informacje i uzupełnia nimi polecenia cmdlet programu PowerShell, które następnie uruchamia
w celu wykonania rzeczywistej akcji. Wiele narzędzi administracyjnych, które uruchamiamy
z poziomu Menedżera serwera, stosuje taką metodę — oczekuje na wprowadzenie danych, a na-
stępnie umieszcza odpowiednie parametry w poleceniach programu PowerShell, które
działają w tle, aby wprowadzić zmiany w życie.
Nie powinieneś się więc wahać przed użyciem programu PowerShell, jeśli uważasz, że po
prostu nie jesteś do niego przyzwyczajony lub nie ufasz, że będzie on działać inaczej niż używany
przez Ciebie interfejs graficzny. Pamiętaj, że gdy używasz myszy do zmiany ustawień na
serwerze, w rzeczywistości wywołujesz polecenia cmdlet programu PowerShell.
Skrypty
Im więcej korzystasz z programu PowerShell, tym staje się on potężniejszy. Oprócz doraź-
nego uruchamiania pojedynczych instrukcji i poleceń cmdlet możesz tworzyć złożone
skrypty, które mogą wykonywać różne czynności. Jak pamiętasz, wspomniałem, że program
PowerShell jest podobny do zwykłego języka programowania. Do tego przyczyniają się wła-
śnie skrypty. PowerShell zapewnia możliwość tworzenia plików skryptów, co wkrótce zrobimy,
aby mieć je pod ręką i od czasu do czasu łatwo uruchamiać. Podobnie jak w innych językach,
można również używać zmiennych, co pozwala definiować parametry wejściowe i obiekty,
które mogą być używane przez skrypty, a dzięki temu czynić je bardziej uniwersalnymi i osiągać
jeszcze większą funkcjonalność.
Server Core
Jeśli istniałby jakikolwiek obszar, w którym jako administratorzy serwerów moglibyśmy le-
piej wykorzystać dostępną technologię, byłoby to, moim zdaniem, użycie programu Po-
werShell do realizacji modelu scentralizowanego zarządzania zdefiniowanego przez firmę
Microsoft. Gdy musimy coś zrobić na serwerze, najczęściej logujemy się do tego serwera
(zwykle przez RDP), a następnie używamy myszy do klikania opcji, aby wykonać zadanie.
Logowanie do serwera staje się coraz bardziej niepotrzebne, ponieważ moglibyśmy zaosz-
350
czędzić dużo czasu dzięki skorzystaniu z dostępnych narzędzi do centralnego zarządzania.

PowerShell jest jednym z nich. Zamiast łączyć się za pomocą RDP, po prostu na komputerze
lokalnym użyj polecenia PowerShell, aby uzyskać dostęp do zdalnego serwera i zmodyfiko-
wać jego ustawienia.
Tego rodzaju zdalne zarządzanie nie tylko staje się bardziej wydajne, ale także jest niezbęd-
ne, ponieważ zaczynamy coraz częściej używać serwerów bezobsługowych. Mam nadzieję,
że poziom wykorzystania systemu Server Core w naszych organizacjach zwiększy się w ciągu
najbliższych kilku lat, a interakcja z takimi serwerami będzie wymagać od administratorów
zmiany sposobu myślenia. Gdy nauczysz się wykonywać codzienne zadania z poziomu programu
PowerShell, będziesz lepiej przygotowany do rozpoczęcia administrowania serwerami bez-
obsługowymi, które będą wymagały od Ciebie innego rodzaju interakcji, niż do tej pory
zwykle stosowałeś.
Praca z programem PowerShell

Pierwszym krokiem prowadzącym do realnego zaprzyjaźnienia się z programem PowerShell
jest nauczenie się korzystania z platformy i rozpoczęcie wykonywania w tej aplikacji codziennych
czynności zamiast ciągłego polegania na kursorze myszy. Poniżej zaprezentujemy niektóre
z najczęstszych sposobów wykorzystania programu PowerShell przez administratorów do
zwiększenia wydajności ich pracy.
Uruchamianie środowiska PowerShell

Prosta sprawa. Pierwszą czynnością, jaką musimy wykonać, aby można było zacząć korzystać
z programu PowerShell, jest jego uruchomienie. Konsola PowerShell jest zainstalowana domyśl-
nie we wszystkich najnowszych wersjach systemu Windows, dzięki czemu można ją uruchomić
z menu Start, przypiąć do pulpitu lub uzyskać do niej dostęp w dowolny sposób, który umożli-
wia otwarcie aplikacji.
Ponieważ staram się używać klawiatury do wszystkiego, co tylko możliwe, sposobem, w jaki
zwykle otwieram program PowerShell, jest przytrzymanie klawisza Windows i naciśnięcie R
w celu otwarcia okna Run (Uruchamianie), wpisanie słowa powershell i naciśnięcie klawisza Enter
Ponieważ na swoim serwerze jestem zalogowany kontem administracyjnym, okno programu

PowerShell zostało uruchomione z podwyższonymi uprawnieniami. Widać to po tym, że na
górnym pasku tego okna wyświetla się napis „Administrator”. Pamiętaj, że podobnie jak wiersz
poleceń, również okno programu PowerShell można otworzyć ze zwykłymi uprawnieniami
użytkownika lub podwyższonymi uprawnieniami administratora. Lepiej (bezpieczniej) jest pra-
cować z poziomu zwykłej sesji programu PowerShell, która nie ma podwyższonych uprawnień,
chyba że zadanie, które próbujesz wykonać, wymaga dodatkowych kompetencji.
351
Innym szybkim i łatwym sposobem otwarcia programu PowerShell na dowolnej nowszej

platformie Windows jest kliknięcie prawym przyciskiem myszy przycisku Start i wybranie
aplikacji bezpośrednio z wyświetlonej listy szybkich zadań. Jak widać na poniższym zrzucie
ekranu, w jednej ze swoich nowych maszyn Server 2019 kliknąłem prawym przyciskiem my-
szy Start i teraz mogę wybrać, czy chcę otworzyć program PowerShell ze zwykłymi czy podwyż-
szonymi (administracyjnymi) uprawnieniami:
352
Jeśli klikniesz prawym przyciskiem myszy przycisk Start, a w wyświetlonym menu nie znajdziesz
opcji pozwalających na otwarcie programu PowerShell, ale zamiast tego będziesz mógł otwo-
rzyć wiersz poleceń, nie przejmuj się. Te opcje są konfigurowalne, więc w menu szybkich
zadań administracyjnych możesz wyświetlić akcje związane z wierszem poleceń lub programem
PowerShell. Jeśli prawym przyciskiem myszy klikniesz pasek zadań i wybierzesz opcję Taskbar
settings (Ustawienia paska zadań), będziesz mógł znaleźć przełącznik o długiej nazwie Replace
Command Prompt with Windows PowerShell in the menu when I right-click the start button
or press Windows key+X (Po kliknięciu prawym przyciskiem myszy przycisku Start lub naciśnię-
ciu klawiszy Windows+X zastępuj w menu wiersz polecenia programem Windows PowerShell).
Jego przełączanie będzie powodować odpowiednią zmianę zawartości menu.
Możesz również wywołać program PowerShell z istniejącego okna wiersza poleceń. Zwykle
podczas pracy z użyciem wiersza poleceń nie można stosować żadnych poleceń cmdlet pro-
gramu PowerShell. Spróbujmy to zmienić. Otwórz administracyjne okno wiersza poleceń i spró-
buj wpisać nazwę jednego z poleceń cmdlet, o których wspominałem. Możesz przykładowo użyć
polecenia Get-NetIPAddress, aby wyświetlić dostępne adresy IP w systemie. Ojej, nie udało się,
ponieważ polecenie cmdlet Get-NetIPAddress po prostu nie zostało rozpoznane.
A teraz wprowadź słowo powershell i naciśnij klawisz Enter. Nie zostało otwarte nowe okno pro-
gramu PowerShell, ale w istniejącym zmienił się tylko znak zachęty. Jesteś obecnie w powłoce
PowerShell, która została uruchomiona z wnętrza czarnego okna wiersza poleceń, więc możesz
zacząć swobodnie używać poleceń cmdlet. Ponowne uruchomienie polecenia Get-NetIPAddress
wygeneruje już pewne informacje:
Z powłoki PowerShell możesz wrócić do zwykłego trybu wiersza poleceń przez wpisanie pole-
cenia exit.
353
Domyślne zasady wykonywania

Podczas korzystania z interfejsu programu PowerShell można po prostu wprowadzać polecenia
cmdlet i w ten sposób wykonywać swoją pracę. Jedną z wielkich zalet programu PowerShell
jest jednak możliwość tworzenia, zapisywania i uruchamiania skryptów. Czasami, jeśli otwo-
rzysz interfejs PowerShell, utworzysz skrypt, a następnie spróbujesz go uruchomić, nie zadziała
on, a zamiast tego pojawi się bardzo rozbudowany komunikat o błędzie:
Nie powinno się to zdarzyć na zupełnie nowej instancji systemu Windows Server 2019, ale
może się zdarzyć, jeśli w serwerze zostaną użyte obiekty GPO lub jeśli użyjesz innego sys-
temu operacyjnego i spróbujesz uruchomić niektóre skrypty PowerShell. Wówczas możesz
zaraz na początku utknąć przy jednym z tego typu komunikatów o błędzie. Chociaż sposób
działania niektórych wersji systemu Windows, domyślnie blokujących uruchamianie skryptów,
oznacza poprawę poziomu bezpieczeństwa, powoduje też powstanie problemu, który należy
w jakiś sposób rozwiązać. Jeśli go napotkasz, na szczęście rozwiązanie będzie proste: aby
umożliwić poprawne wykonanie skryptów, wystarczy w programie PowerShell dostosować
domyślne zasady wykonywania (ang. Default Execution Policy — DEP).
Niestety, nie jest to zwykłe wyłączenie lub włączenie opcji. Zasady wykonywania mają pięć
różnych poziomów i ważne jest, aby zrozumieć każdy z nich, ponieważ dzięki temu będziesz
mógł wybrać odpowiednią opcję w kontekście zabezpieczeń, które chcesz wprowadzić na swoich
serwerach. Oto objaśnienia dotyczące każdego z poziomów, w kolejności od konfiguracji
najbardziej bezpiecznej do najmniej bezpiecznej.
Restricted
Zasady Restricted pozwalają co prawda na uruchamianie instrukcji i poleceń cmdlet, ale całko-
wicie blokują wykonywanie skryptów.
AllSigned
Każdy uruchamiany skrypt musi zostać podpisany przez zaufanego wydawcę. Jeśli wybierzesz
zasady AllSigned, nawet te skrypty, które sam napiszesz, będą musiały przejść proces sprawdza-
nia poprawności i zostać podpisane, zanim będą mogły być uruchamiane.
RemoteSigned
Jest to domyślna zasada w systemie Windows Server 2019. W przypadku skryptów pobranych
z internetu wymaga się, aby były one podpisane podpisem cyfrowym pochodzącym od zaufanego
wydawcy. Jeśli jednak zdecydujesz się utworzyć własne skrypty, będziesz mógł je uruchamiać,
nawet jeśli nie będą podpisane cyfrowo.
354
Unrestricted
Podpisane lub niepodpisane skrypty mogą być uruchamiane. Nadal pojawia się ostrzeżenie
podczas korzystania ze skryptów pobranych z internetu.
Bypass
W trybie Bypass nic nie jest blokowane i nie są wyświetlane żadne ostrzeżenia podczas urucha-
miania skryptów. Krótko mówiąc, jesteś zdany wyłącznie na siebie.
Czasami pojedyncza zasada wykonania nie spełnia wszystkich Twoich wymagań. Zależy to od
tego, w jaki sposób korzystasz ze skryptów PowerShell. Zasady DEP można więc dodatkowo
ulepszyć przez określenie zakresu zasad wykonywania (ang. Execution Policy Scope), który po-
zwala zdefiniować różne zasady wykonywania dla różnych aspektów systemu. Trzy zakresy,
które można wykorzystywać, to Process (proces), CurrentUser (bieżący użytkownik) i Local-
Machine (maszyna lokalna). Domyślnie zasady DEP dotyczą maszyny lokalnej, więc wszystkie
uruchomione skrypty są z nimi zgodne. Możesz jednak zdefiniować inne zasady DEP dla bie-
żącego użytkownika, lub nawet pojedynczego procesu, jeśli jest to wymagane.
Jeśli nie jesteś pewien, jakie są obecne zasady wykonywania, lub podejrzewasz, że ktoś mógł
je zmienić, możesz łatwo wyświetlić zdefiniowany poziom DEP za pomocą prostego polecenia
cmdlet o nazwie Get-ExecutionPolicy. Jak widać na poniższym zrzucie ekranu, moje zasady
DEP mają poziom Restricted, co wyjaśnia pojawienie się wcześniej zaprezentowanego komuni-
katu o błędzie, gdy próbowałem uruchomić skrypt:
Po podjęciu decyzji, jaki poziom DEP chciałbyś ustawić na serwerze lub stacji roboczej, możesz
użyć prostego polecenia cmdlet, aby to wykonać. Moje serwery znajdują się w laboratorium
testowym, w sieci odizolowanej, dlatego nie martwię się o ich bezpieczeństwo. Chciałbym więc,
aby ich skrypty mogły być uruchamiane, dlatego zamierzam zmienić poziom na Unrestricted.
Oto w jaki sposób należy to zrobić (zobacz pierwszy rysunek na następnej stronie):
Set-ExecutionPolicy Unrestricted
Pamiętaj, że w tej chwili uruchamiamy PowerShell w systemie lokalnym (jestem zalogowany

do swojego serwera WEB3), więc jedyną ustawioną przeze mnie zasadą wykonania jest polityka
lokalna dla serwera WEB3. Gdybym chciał zmienić to ustawienie globalnie lub dla określonej
grupy komputerów, mógłbym użyć w tym celu zasad grupy. Oto lokalizacja pozwalająca na konfigu-
rowanie zasad wykonywania skryptów PowerShell: Computer Configuration/Policies/Administrative
Templates/Windows Components/Windows PowerShell/Turn on script execution (Konfiguracja
komputera/Zasady/Szablony administracyjne/Składniki systemu Windows/Windows PowerShell/
Włącz wykonywanie skryptu).
355
Użycie klawisza Tab

Zanim zaczniemy aktywnie korzystać z programu PowerShell, chciałbym zwrócić uwagę na
jeszcze jedno zagadnienie: gdy znajdziesz się w oknie powłoki PowerShell, przyzwyczaj się
do używania klawisza Tab! Jeśli wpiszesz kilka pierwszych liter dowolnej instrukcji lub pole-
cenia cmdlet, a następnie naciśniesz Tab, reszta nazwy zostanie automatycznie uzupełniona.
Jeśli wpiszesz ciąg znaków get-co, a następnie naciśniesz klawisz Tab, w oknie automatycz-
nie pojawi się pełne polecenie cmdlet Get-Command. Ponieważ istnieje wiele poleceń cmdlet,
które zaczynają się od znaków get-co, po kilkakrotnym naciśnięciu klawisza Tab będzie
można zauważyć, że są one cyklicznie wyświetlane.
Klawisz Tab działa również w przypadku nazw plików i folderów. Przykładowo pobrałem
poprawkę, którą należy zainstalować na serwerze. Chcę uruchomić tę poprawkę za pomocą
wiersza poleceń programu PowerShell, który mam już otwarty, ale nie chcę marnować czasu,
próbując wpisać jej bardzo długą nazwę. Przemieściłem się już do folderu, w którym znajduje
się moja poprawka. Jeśli teraz po prostu podam kilka pierwszych liter nazwy pliku i nacisnę
klawisz Tab, PowerShell uzupełni resztę nazwy pliku. Następnie wystarczy nacisnąć klawisz
Enter, aby uruchomić instalatora:
356
Przydatne polecenia cmdlet używane

do codziennych zadań
Gdy zacząłem używać programu PowerShell w ramach swoich codziennych zajęć, stworzyłem
sobie listę często używanych instrukcji i poleceń cmdlet. Jeśli nie będą one dla Ciebie łatwo
dostępne, nie zostaną zapamiętane i nie staną się Twoją drugą naturą, istnieje szansa, że nie
będziesz ich używać i powrócisz do starej metody konfigurowania serwerów. Oto lista wybranych
poleceń, z których regularnie korzystam podczas tworzenia serwerów. Część to tradycyjne kon-
strukcje, które działałyby również z wiersza poleceń, a inne są poleceniami cmdlet. Wszystkie
jednak są przydatne w trakcie pracy w oknie programu PowerShell:
 Get-Command: jest przydatne do wyszukiwania dodatkowych instrukcji lub poleceń
cmdlet, które będziesz chciał uruchomić lub przetestować.
 Get-Command -Name *fragment_nazwy*: przełącznik -Name zwiększa użyteczność
polecenia Get-Command, dzięki czemu możesz filtrować wyniki dla każdego rodzaju
poleceń cmdlet, których szukasz.
 GCM: jest to po prostu krótka, alternatywna nazwa polecenia Get-Command.
Chciałem zwrócić na to uwagę, ponieważ niektóre z poleceń cmdlet programu
PowerShell mają aliasy, takie jak GCM, które pozwalają je uruchamiać przy użyciu
mniejszej liczby naciśnięć klawiszy.
 Get-Alias: ponieważ wspomnieliśmy właśnie o aliasie GCM dla polecenia Get-Command,
możesz się zastanawiać, jakie inne nazwy alternatywne są dostępne w programie
PowerShell. Aby zobaczyć ich pełną listę, wystarczy uruchomić polecenie cmdlet
Get-Alias.
 Rename-Computer: pozwala nadać serwerowi nową nazwę.
 Add-Computer: użyj tego polecenia, aby dołączyć serwery lub komputery do domeny.
 Hostname: wyświetla nazwę systemu, do którego jesteś obecnie zalogowany.
Często używam tego polecenia, aby mieć pewność, że rzeczywiście pracuję na
serwerze, który mam na myśli. Czy kiedykolwiek zrestartowałeś niewłaściwy
serwer? Ja tak. Uruchamiając polecenie Hostname, możesz mieć pewność, że
funkcja, którą zamierzasz wykonać, naprawdę dotyczy odpowiedniego systemu.
 $env:computername: również wyświetla nazwę systemu, do którego jesteś zalogowany.
Chciałbym zwrócić uwagę na to, że program PowerShell może w prosty sposób
wykorzystać zmienne środowiskowe w celu uzyskania określonej informacji.
Prostsze polecenie Hostname jest przydatne, gdy jesteś zalogowany w systemie
lokalnym i po prostu próbujesz zweryfikować jego nazwę. Możliwość pobierania
informacji ze zmiennej takiej jak $env:computername będzie znacznie bardziej
użyteczna podczas tworzenia skryptów lub pracy ze zdalnym systemem.
 Logoff: to oczywiste — polecenie Logoff po prostu wylogowuje Cię z systemu.
Zamiast wyszukiwać funkcję Sign out (Wyloguj) po kliknięciu menu Start serwera,
możesz w wierszu poleceń lub oknie programu PowerShell szybko wprowadzić
polecenie Logoff, co spowoduje natychmiastowe wylogowanie się z sesji.
Używam tego polecenia zawsze podczas zamykania połączeń RDP.
357
Zarówno polecenie shutdown, jak i Restart-Computer są przydatne do wyłączenia lub po-

nownego uruchomienia serwera. Ja na swoim komputerze najczęściej poprzedzam te pole-
cenia wywołaniem instrukcji hostname. Podczas restartu serwera należy zwrócić szczególną
uwagę na to, aby użyć właściwego komputera, dlatego uważam, że najlepiej jest otworzyć
okno programu PowerShell, szybko sprawdzić nazwę za pomocą hostname, a następnie wy-
konać polecenie restartu z tego samego miejsca. Dzięki temu jestem pewien, że restartuję
serwer, który został wyświetlony w wyniku polecenia hostname.
Polecenie shutdown
Jeśli uruchomisz proste polecenie shutdown, system wyłączy się po minucie. Nie jestem pewien,
dlaczego taka jest domyślna funkcjonalność, ponieważ nigdy nie spotkałem żadnego admini-
stratora IT, który tak naprawdę chciałby poczekać dodatkową minutę przed wyłączeniem
systemu. Na szczęście możemy zmienić ten czas. W poleceniu shutdown /r /t 0 zdecydowałem,
że chcę zrestartować system, zamiast go zamykać (opcja /r). Zarządziłem także, aby polecenie
czekało zero sekund przed wykonaniem restartu (opcja /t 0). Dzięki temu następuje on natych-
miast i nie muszę czekać na upłynięcie domyślnych 60 sekund.
Polecenie query user (quser)

Polecenie quser, często najbardziej przydatne w środowiskach RDS, wyświetla wszystkich
użytkowników, którzy są zalogowani na serwerze, w tym informacje dotyczące tego, czy są
oni zalogowani lokalnie czy zdalnie, a także jak długo trwają ich sesje:
Polecenie quser /computer:WEB1

Użycie polecenia quser w połączeniu z przełącznikiem /computer pozwala na wyświetlenie
użytkowników zalogowanych w systemie zdalnym. W ten sposób w swojej farmie serwerów
RDS możesz być zalogowany na jednej maszynie, ale sprawdzać sesje użytkowników bez ko-
nieczności logowania się na innych systemach. Możesz nawet napisać skrypt uruchamiający
to polecenie na każdym serwerze zarządzającym sesjami i zapisujący dane do pliku. Taki
skrypt można uruchomić zgodnie z harmonogramem i wykorzystać jako mechanizm raportowa-
nia zwracający informacje, jacy użytkownicy w danym momencie byli zalogowani do określo-
nych serwerów sesji RDS.
Polecenie Install-WindowsFeature
Użyj polecenia Install-WindowsFeature programu PowerShell, aby uprościć instalację ról i funk-
cji na serwerach.
358
Polecenie New-NetIPAddress
Użyj polecenia New-NetIPAddress, aby przypisać adresy IP do swoich kart sieciowych. Oto
przykład:
New-NetIPAddress -InterfaceIndex 12 -IPAddress 10.10.10.40 -PrefixLength
24 -DefaultGateway 10.10.10.1
Należy pamiętać, że dane wykorzystane w powyższym poleceniu cmdlet są przykładowe i należy

je zastąpić własnymi informacjami.
Polecenie Set-DnsClientServerAddress
Polecenie Set-DnsClientServerAddress jest często używane w połączeniu z poleceniem
New-NetIPAddress. Służy ono do wprowadzania adresów serwerów DNS we właściwościach
karty sieciowej, na przykład:
Set-DnsClientServerAddress -InterfaceIndex 12 -ServerAddresses 10.10.10.2,10.10.10.3
Użycie polecenia Get-Help

Ile razy używałeś opcji /? w wierszu poleceń, aby uzyskać dodatkowe informacje na temat
instrukcji, którą chciałbyś uruchomić? Dodatkowe informacje dostarczone przez tę funkcję
pomocy mogą czasami decydować o tym, czy polecenie będzie przydatne czy całkowicie
bezużyteczne. Polecenia cmdlet programu PowerShell mają podobną funkcjonalność. Nie
można jednak użyć znaków /? na końcu polecenia cmdlet programu PowerShell, ponieważ
spacja oznacza, że masz zamiar określić parametr, który ma być używany z tym poleceniem.
Na przykład, jeśli spróbujemy użyć znaków /? z poleceniem cmdlet Restart-Computer, aby do-
wiedzieć się więcej na jego temat, znak zapytania nie zostanie rozpoznany jako poprawny
parametr i uzyskamy następujące dane wyjściowe:
W programie PowerShell istnieje jednak jeszcze potężniejsza funkcja pomocy, oddzielne

polecenie o nazwie Get-Help. Podobnie jak w każdym innym poleceniu cmdlet musimy wprowa-
dzić dodatkowe parametry, aby określić i pobrać informacje, których potrzebujemy. Funkcja
359
pomocy jest więc oddzielną jednostką i nie musi być aktywowana w danym poleceniu, inaczej
niż w przypadku znaku zapytania.
Uruchomienie polecenia Get-Help bez żadnych parametrów pozwala na uzyskanie dokładniej-

szych informacji na temat jego samego, co może być przydatne. Teraz jednak jesteś bardziej za-
interesowany wiedzą o tym, w jaki sposób moglibyśmy użyć polecenia Get-Help, aby uzyskać
dodatkowe informacje o innych funkcjach, które chcemy uruchomić, takich jak Restart-Computer.
Musimy więc użyć Get-Help jako polecenia cmdlet, a następnie określić inne polecenie jako
jego parametr, umieszczając przed nim spację:
Get-Help Restart-Computer
Informacje dostarczone przez polecenie Get-Help są bardzo wyczerpujące. W niektórych

przypadkach uzyskamy takie same informacje jak te, które można znaleźć w witrynie TechNet.
Korzystaj z funkcji Get-Help, aby pogłębiać swoją wiedzę na temat dowolnych poleceń
cmdlet w programie PowerShell!
Formatowanie danych wyjściowych

Podczas wyświetlania informacji w programie PowerShell często spotykam się z sytuacją,
w której dostarczono mi ich zbyt wiele i trudno jest je posortować. Czy próbujesz znaleźć
przydatne polecenia cmdlet przy użyciu Get-Command, a może szukasz określonego aliasu za
pomocą Get-Alias? Danych wyjściowych z tych poleceń cmdlet może być zdumiewająco
dużo. Wcześniej omawialiśmy niektóre parametry (na przykład -Name), których możesz użyć do
zmniejszenia wielkości wyniku. Istnieje jednak kilka innych parametrów formatowania, które
również można dołączyć do poleceń cmdlet w celu zmodyfikowania danych wyjściowych.
Parametr Format-Table
Cel parametru Format-Table jest dość prosty: dane wyjściowe z polecenia są wyświetlane w po-
staci tabeli. Powoduje to, że informacje są zasadniczo łatwiejsze do odczytania i zrozumienia.
Spójrzmy na przykład. Użyliśmy kilka razy polecenia Get-NetIPAddress, ale bądźmy szczerzy,
otrzymane wyniki są trochę nieuporządkowane. Uruchomienie polecenia cmdlet na moim
serwerze wirtualnym, do którego przypisano tylko jedną kartę sieciową, powoduje wyświetlenie
360
czterech stron danych w oknie programu PowerShell, włącznie z wszelkiego rodzaju polami
informacyjnymi, które są niewypełnione lub nieistotne podczas wyszukiwania adresów IP
przypisanych do serwera:
Jeśli jednak umieścimy opcję Format-Table na końcu polecenia cmdlet Get-NetIPAddress,

wygenerowane dane będą znacznie bardziej przyjazne dla oczu, a przy tym od razu przekażą
ważne informacje, których tak naprawdę poszukuję — mam na myśli adresy IP używane
w systemie:
Get-NetIPAddress | Format-Table
361
Niektórzy czytelnicy mogą znać polecenie cmdlet o nazwie Select-Object, które ma tę samą
funkcjonalność co parametr Format-Table. Chociaż Select-Object wydaje się bardziej znanym
poleceniem, z mojego doświadczenia wynika, że jest ono mniej wydajne niż użycie parametru
Format-Table, dlatego sugeruję, abyś postarał się je przetestować.
Parametr Format-List
Parametr Format-List działa podobnie do opcji Format-Table i pozwala na wyświetlenie danych
wyjściowych polecenia w postaci listy właściwości. Wypróbujmy to w praktyce. Wiesz już,
że Get-Command udostępnia nam polecenia cmdlet dostępne w programie PowerShell i domyślnie
wyświetla je w formie tabeli.
Jeśli jednak chcielibyśmy wyświetlić dane wyjściowe w postaci listy, która dodatkowo zawierałaby
więcej informacji przy każdym z poleceń cmdlet, moglibyśmy użyć następującej instrukcji:
Get-Command | Format-List
W wyniku otrzymałem tak olbrzymią ilość informacji, że moje okno programu PowerShell
miało problem z ich wyświetleniem. Może więc powinniśmy trochę ją zmniejszyć przez ogra-
niczenie zakresu wyszukiwania. Wyszukajmy zatem wszystkie polecenia cmdlet zawierające
słowo Restart i wyświetlmy je w formacie listy:
Get-Command -Name *Restart* | Format-List
362
Zintegrowane środowisko skryptowe

PowerShell
Większość administratorów serwerów zna sposób tworzenia plików wsadowych w środowi-
sku wiersza poleceń. Czy masz zestaw poleceń, które chciałbyś po kolei uruchomić? A może
chcesz w przyszłości uruchomić tę sekwencję poleceń na różnych serwerach lub wielokrotnie jej
użyć? Wprowadzenie instrukcji w dokumencie tekstowym, a następnie zapisanie go z rozszerze-
niem .BAT spowoduje utworzenie pliku wsadowego, który można uruchomić na dowolnym
komputerze z systemem Windows. Polecenia zostaną wykonane w takiej kolejności, w jakiej
zostały wprowadzone, co oszczędza czas i wysiłek związany z ręcznym uruchamianiem poszcze-
gólnych instrukcji w interfejsie wiersza poleceń.
Skrypty w programie PowerShell wykorzystują ten sam pomysł, ale są znacznie potężniejsze.
Instrukcje wykonywane w wierszu poleceń są użyteczne, ale ograniczone, podczas gdy polecenia
cmdlet programu PowerShell umożliwiają zarządzanie dowolnymi elementami systemu opera-
cyjnego. Z powłoki PowerShell możemy się również odwoływać do wewnętrznych zmiennych
środowiskowych lub rejestru. Można z łatwością wydawać polecenia zdalnym systemom, a na-
wet używać zmiennych w skryptach PowerShell, tak jak w przypadku dowolnego typowego
języka programowania.
Poznaj kilka różnych sposobów, za pomocą których możesz rozpocząć tworzenie swoich pierw-
szych skryptów PowerShell.
363
Pliki PS1
Prosty plik .PS1 (plik skryptów PowerShell) tworzy się prawie tak samo jak plik .BAT. Wystarczy
w swoim ulubionym edytorze utworzyć nowy dokument tekstowy, umieścić w nim szereg
instrukcji lub poleceń cmdlet, a następnie zapisać plik jako NAZWA_PLIKU.PS1. Jeśli środowi-
sko PowerShell pozwala na uruchamianie skryptów (patrz wcześniejszy punkt „Domyślne
zasady uruchamiania”), możesz teraz kliknąć dwukrotnie ten plik lub uruchomić go z dowol-
nego okna programu PowerShell, aby wykonać zapisaną w nim serię poleceń. Sprawdźmy to
w praktyce i udowodnijmy, że możemy stworzyć prosty skrypt, a następnie go uruchomić.
Ponieważ zamierzasz tworzyć skrypty wykonujące określone zadania, zastanówmy się nad
przykładem z realnego świata. Dość często zdarza mi się obsługiwać serwery terminalowe
— przepraszam, serwery RDS — a częste żądanie klientów dotyczy informacji o tym, jacy użyt-
kownicy są zalogowani do których serwerów. Prostym sposobem na zebranie tych informacji
jest utworzenie skryptu, który będzie zapisywał w pliku dane użytkownika podczas jego logowa-
nia. Taki skrypt powinien się uruchamiać w trakcie procesu logowania. Aby skrypt był bardziej
interesujący i uniwersalny, zamierzam wykorzystać niektóre zmienne zawierające nazwę
użytkownika oraz bieżącą datę i godzinę, a także zapamiętać nazwę serwera RDS, do którego
się loguję. W ten sposób mogę przeanalizować zbiorczy zestaw dzienników i łatwo ustalić,
którzy użytkownicy byli zalogowani na poszczególnych serwerach. Do stworzenia tego
skryptu zamierzam użyć programu Notatnik. Otworzyłem jego nową instancję, wprowadziłem
poniższe polecenia i zapisuję plik jako C:\Scripts\UserReporting.ps1:
$User = $env:username
$RDSH = $env:computername
$Date = Get-Date
echo $User,$Date,$RDSH | Out-File C:\Scripts\UserReporting.txt -append
Prawdopodobnie wiesz już, co wykonuje ten skrypt, ale i tak postaramy się go przeanalizo-
wać. Po pierwsze, definiujemy trzy zmienne. Zmiennej $User przypisujemy wartość odczytaną
ze zmiennej środowiskowej przechowującej nazwę użytkownika systemu. Zmienna $RDSH
będzie nazwą serwera, na którym loguje się użytkownik. Tę nazwę również pobieramy z odpo-
364
wiedniej zmiennej środowiskowej. Trzecia zdefiniowana zmienna to $Date, która po prostu

zawiera bieżącą datę systemową odczytaną przez wywołanie polecenia cmdlet Get-Date programu
PowerShell.
Po wczytaniu wszystkich informacji do zmiennych PowerShell zapisuję je do pliku tekstowego,

który znajduje się na dysku twardym mojego serwera.
Po kilkukrotnym użyciu skryptu mogę otworzyć plik UserReporting.txt i zauważyć, że zdefinio-

wane zmienne zostają w nim poprawnie zapisane za każdym razem, gdy skrypt jest uruchamiany:
Zintegrowane środowisko skryptowe PowerShell

Prawdę mówiąc, stworzenie tego prostego skryptu, który właśnie uruchomiliśmy, wymagało
użycia metody prób i błędów. Każdą instrukcję musiałem oddzielnie przetestować w pro-
gramie PowerShell, zanim się upewniłem, że będzie działać w moim skrypcie. Próbowałem
też pobrać nazwę użytkownika bez użycia zmiennej środowiskowej, jednak ta metoda nie
zadziałała. Dlaczego miałem tyle problemów z zaledwie kilkoma prostymi wierszami kodu?
Ponieważ podczas ich wprowadzania w programie Notatnik nie miałem absolutnie pojęcia,
czy będą działać, gdy zapiszę i spróbuję uruchomić skrypt. Cała jego zawartość była wyświetlana
na białym tle za pomocą czcionki w kolorze czarnym, a dodatkowo musiałem się opierać
wyłącznie na własnej wiedzy i umiejętnościach tworzenia skryptów, aby stworzyć coś, co fak-
tycznie zadziała.
Na szczęście mamy dostęp do zintegrowanego środowiska skryptowego PowerShell (ISE).

Jest to program instalowany domyślnie w systemie Windows Server 2019, który pozwala na
tworzenie skryptów PowerShell i zapewnia odpowiednie wsparcie. Otwórzmy go więc. Jeśli
masz jakieś pliki PS1 skryptów PowerShell, możesz po prostu kliknąć jeden z nich prawym
365
przyciskiem myszy i wybrać opcję Edit (Edytuj). W przeciwnym razie kliknij prawym przyci-
skiem myszy ikonę aplikacji PowerShell (na przykład znajdującą się na pasku zadań), a znajdziesz
opcję uruchomienia programu Windows PowerShell ISE bezpośrednio w menu podręcznym:
Jeśli teraz zaczniemy wprowadzać te same instrukcje, których wcześniej użyłem w Notatniku,
nawet w trakcie tej czynności będą się pojawiać wyskakujące okienka i zachęty, pomagające
w podjęciu decyzji, które polecenia cmdlet lub zmienne powinniśmy wykorzystać. Środowisko
działa w sposób podobny do inteligentnych wirtualnych klawiatur na naszych smartfonach.
Po rozpoczęciu wprowadzania tekstu udostępnia odpowiednie podpowiedzi, dzięki czemu
nie musisz pamiętać, jak dokładnie nazywają się polecenia cmdlet lub parametry. Możesz
pamiętać, od jakiej litery rozpoczyna się nazwa polecenia, a następnie po jej wprowadzeniu
wybrać określoną instrukcję z zaprezentowanej listy. Po prawej stronie okna znajduje się również
lista wszystkich dostępnych poleceń, którą można przeszukiwać! To świetna funkcjonalność, któ-
ra naprawdę pomaga podczas tworzenia skryptów (zobacz pierwszy rysunek na następnej
stronie).
Przydatny jest także mniejszy, niebieski ekran powłoki PowerShell, który zajmuje dolną połowę
okna w zintegrowanym środowisku projektowym. Gdy wpisujesz określone instrukcje, śro-
dowisko pomaga się upewnić, że będą one poprawnie działać, zaznacza bowiem odpowiednimi
kolorami polecenia cmdlet i parametry w celu ich łatwej identyfikacji. Następnie na pasku
zadań możesz kliknąć zielony przycisk strzałki o nazwie Run Script (F5) (Uruchom skrypt
(F5)). Nawet jeśli nie zapisałeś swojego skryptu, środowisko wykona Twoje polecenia i zapre-
zentuje dane wyjściowe w niebieskim oknie PowerShell. Pozwala to na przetestowanie całego
programu lub wprowadzonych przez siebie modyfikacji bez konieczności zapisania pliku, a na-
stępnie uruchomienia go oddzielnie przy użyciu tradycyjnego okna programu PowerShell
(zobacz drugi rysunek na następnej stronie).
366
367
Jeszcze lepsze jest to, że możesz wyróżnić poszczególne sekcje skryptu i wybrać uruchamianie
wyłącznie izolowanych fragmentów kodu. Pozwala to przetestować niektóre fragmenty
skryptu lub wykonać inną, kreatywną czynność. Typowy plik skryptu PS1 może być pełen
często używanych poleceń programu PowerShell. Gdy będziesz chciał uruchomić tylko jedno
z nich, możesz po prostu zaznaczyć odpowiedni fragment tekstu, a następnie kliknąć ikonę
Run Selection (Uruchom wybrany fragment) lub nacisnąć klawisz F8. Dzięki temu zaznacze-
niu zostaną uruchomione jedynie wybrane polecenia cmdlet. Na poniższym zrzucie ekranu
widzimy, że w moim pliku skryptu znajduje się dużo różnych poleceń cmdlet, ale uruchomione
zostanie wyłącznie to, które zostało wyróżnione:
Zdalne zarządzanie serwerem

Gdy przetestowaliśmy już działanie lokalnej instancji programu PowerShell i przeanalizowali-
śmy kilka metod, które można zastosować podczas tworzenia skryptów, nadszedł czas, aby przyj-
rzeć się, w jaki sposób środowisko PowerShell dopasowuje się do scentralizowanych wymagań
368
administracyjnych. Jeśli zaczniesz używać programu PowerShell do administrowania ser-

werem, ale w celu uzyskania połączenia z nim będziesz wykorzystywać usługę zdalnego
pulpitu (RDP), takie działanie będzie niepoprawne. Jak wiadomo, możesz podłączyć zdalne
serwery do Menedżera serwera, aby można było nimi centralnie zarządzać. Wiemy również,
że narzędzia dostępne w Menedżerze serwera w większości wysyłają po kliknięciu przyci-
sku po prostu serię poleceń cmdlet programu PowerShell. Na podstawie tych dwóch infor-
macji możesz przypuszczać, że instrukcje i polecenia cmdlet programu PowerShell można
łatwo uruchamiać w systemach zdalnych, włącznie z tymi, na których użytkownik nie jest
zalogowany.
Korzystając z tego pomysłu i realizując go, przeanalizujemy kryteria niezbędne do tego, aby
zdalne zarządzanie serwerami za pomocą programu PowerShell było możliwe również w naszym
środowisku. Postaramy się sprawić, aby jeden z serwerów mógł przyjmować zdalne połączenia
PowerShell. Następnie użyjemy programu PowerShell zainstalowanego na innym komputerze,
aby odczytywać informacje i wprowadzać zmiany na zdalnym serwerze.
Przygotowanie zdalnego serwera

Na zdalnych serwerach wystarczy uruchomić tylko kilka elementów, aby można było nimi
zdalnie zarządzać za pomocą programu PowerShell. Jeżeli wszystkie Twoje serwery mają
zainstalowany system Windows Server 2019 (w rzeczywistości wystarczy Windows Server
2012 lub nowszy), wówczas zdalne zarządzanie programem PowerShell jest domyślnie włą-
czone i nie musisz czytać kilku następnych punktów tego rozdziału. Jeśli jednak spróbujesz
użyć programu PowerShell do zdalnej obsługi i zakończy się to niepowodzeniem, ważne
jest, abyś zrozumiał, jak to wszystko zostało skonfigurowane. Jeśli więc pojawią się jakieś
kłopoty lub będzie używany starszy system operacyjny, wymagający dodatkowych działań,
możesz rozwiązać problem i ręcznie włączyć możliwość zdalnego zarządzania. Możliwe jest
również, że w systemie istnieją zasady bezpieczeństwa, które wyłączają komponenty pozwalające
na wykorzystanie zdalnego połączenia PowerShell. Jeśli więc okaże się, że zdalny dostęp nie
działa, należy sprawdzić poniżej zaprezentowane składniki.
Usługa WinRM
Jednym z elementów składających się na funkcjonalność zdalnego zarządzania jest usługa
WinRM. Po prostu upewnij się, że jest ona uruchomiona. Jeśli ją zatrzymałeś, ponieważ
chciałeś zwiększyć poziom bezpieczeństwa serwera, musisz przywrócić działanie usługi, aby
móc korzystać ze zdalnego połączenia poprzez program PowerShell.
Po uruchomieniu modułu services.msc możesz oczywiście sprawdzić stan usługi WinRM.

Ponieważ jednak w tym rozdziale omawiamy program PowerShell, wiedz, że możesz to również
wykonać za pomocą następującego polecenia:
Get-Service WinRM
369
Polecenie Enable-PSRemoting
Jedyne, co należy zrobić na zdalnym serwerze, to wykonanie prostego polecenia cmdlet. Oczy-
wiście maszyna musi mieć dostęp do sieci, w przeciwnym razie nie będzie można jej znaleźć.
Tak więc przy użyciu konsoli serwera musisz się upewnić, że połączenie sieciowe funkcjonuje
i ruch sieciowy się odbywa, a także wykonać następujące polecenie, które umożliwi tej maszynie
akceptowanie przychodzących zdalnych połączeń PowerShell:
Enable-PSRemoting -Force
Użycie opcji -Force na końcu polecenia Enable-PSRemoting powoduje, że jest ono uruchamiane
bez pytania o potwierdzenie. W tle jest wykonywanych kilka czynności. Po pierwsze, polecenie
próbuje uruchomić usługę WinRM. Dlaczego wcześniej wspomniałem, że jej stan należy
sprawdzić ręcznie? Ponieważ jeśli wyłączyłeś ją w ramach strategii blokowania, może to zakłócić
działanie polecenia Enable-PSRemoting. Sprawdzanie usługi WinRM przed użyciem polecenia
Enable-PSRemoting zwiększa szanse na jego udane uruchomienie. Instrukcja wykonuje także
dwie inne czynności: uruchamia proces nasłuchujący dla połączeń zdalnych i tworzy odpowied-
nią regułę zapory w systemie, aby umożliwić pomyślny przepływ ruchu przychodzącego.
Jeśli zamierzasz używać programu PowerShell na dużą skalę, zniechęcające może być logowanie
się do każdego serwera i uruchamianie omówionego powyżej polecenia. Na szczęście nie musisz
tego robić! Podobnie jak w przypadku większości funkcji w świecie Windows, możemy użyć
zasad grupy, aby automatycznie wprowadzić odpowiednią modyfikację. Utwórz nowy obiekt
zasad grupy, podłącz go i odpowiednio przefiltruj, aby dotyczył tylko tych serwerów, którymi
chcesz centralnie zarządzać, a następnie skonfiguruj następujące ustawienie: Computer
Configuration/Policies/Administrative Templates/Windows Components/Windows Remote Mana-
gement (WinRM)/WinRM Service (Konfiguracja komputera/Zasady/Szablony administracyjne/
Składniki systemu Windows/Zdalne zarządzanie systemem Windows (WinRM)/Usługa WinRM).
Włącz opcję Allow remote server management through WinRM (Zezwalaj na zdalne zarządzanie
serwerem za pośrednictwem usługi WinRM), jak pokazano na zrzucie ekranu na następnej stronie.
Zezwalanie na dostęp do maszyn z innych domen lub grup roboczych

Jeśli obsługujesz serwery, które są częścią tej samej domeny korporacyjnej (co będzie najczęst-
szym przypadkiem), wówczas uwierzytelnianie między komputerami jest łatwe. Na tym po-
ziomie maszyny automatycznie sobie ufają. Jeśli jednak z serwerem, który powinien akceptować
370
zdalne połączenia, będą się łączyć komputery z innej domeny, która nie jest zaufana, a nawet
z grupy roboczej, wówczas będziesz musiał wydać polecenie pozwalające ręcznie dodać je
do zbioru maszyn zaufanych. Na przykład, jeśli planuję zarządzać wszystkimi swoimi serwerami
z komputera klienckiego o nazwie Win10Client, któremu te maszyny nie ufają, muszę na nich
uruchomić następujące polecenie:
Set-Item wsman:\localhost\client\trustedhosts Win10Client
Jeśli chciałbyś zezwolić na wykonywanie zdalnego połączenia dowolnemu komputerowi,

mógłbyś zastąpić nazwę pojedynczego komputera znakiem gwiazdki (*), ale ogólnie rzecz
biorąc, nie byłoby to dobrą praktyką. Tylko prosiłbyś się o kłopoty.
Łączenie ze zdalnym serwerem

Zazwyczaj administratorzy używają zdalnego połączenia PowerShell na dwa różne sposoby.
Możesz doraźnie wykonywać niektóre polecenia w zdalnym systemie, przy czym okno programu
PowerShell nadal jest używane w kontekście lokalnym. Możesz także uruchomić pełną sesję
zdalną programu PowerShell, aby jego interfejs działał tak, jakby się znajdował w zarządza-
nym przez Ciebie systemie. Przyjrzyjmy się obu tym opcjom.
Użycie opcji -ComputerName

Wielu poleceń cmdlet dostępnych w programie PowerShell (szczególnie tych, które zaczynają
się od słowa Get-) można używać z parametrem -ComputerName. Oznacza to, że polecenie,
które zamierzasz uruchomić, zostanie wykonane w systemie zdalnym określonym w opcji
371
-ComputerName. W naszym przypadku użyję okna PowerShell na swoim komputerze klienc-

kim z systemem Windows 10, aby uzyskać dostęp do informacji o niektórych serwerach znajdu-
jących się w sieci. Chciałbym sprawdzić usługę WinRM, aby upewnić się, że jest urucho-
miona. Aby udowodnić, że łączę się zdalnie z serwerem WEB3, najpierw przetestuję
lokalną usługę WinRM, którą zdarzyło mi się wyłączyć na swojej stacji roboczej z systemem
Windows 10.
Jak widać, lokalna usługa WinRM ma stan Stopped (Zatrzymana). Gdy jednak wydam to samo
polecenie z parametrem -ComputerName odpowiadającym serwerowi WEB3, otrzymam informację,
że usługa WinRM rzeczywiście poprawnie działa na tej zdalnej maszynie:
Hostname
Get-Service WinRM
Get-Service WinRM -ComputerName WEB3
Teraz postaram się sprawdzić, jakie role są zainstalowane na serwerze WEB4, który zawiera
nową instancję systemu Server Core, skonfigurowaną jakiś czas temu (zobacz pierwszy ry-
sunek na następnej stronie):
Get-WindowsFeature -ComputerName WEB4 | Where Installed
W parametrze -ComputerName można jednocześnie określić wiele nazw serwerów. Gdybym

chciał sprawdzić stan usługi WinRM na kilku swoich serwerach z użyciem tylko jednego
polecenia, mógłbym wywołać poniższą instrukcję (zobacz drugi rysunek na następnej stronie):
Get-Service WinRM -ComputerName WEB1,WEB2,DC1
372
Użycie polecenia Enter-PSSession

Jeśli na określonym serwerze chciałbyś uruchomić wiele różnych poleceń cmdlet, wówczas bar-
dziej sensowne byłoby wywołanie na tej maszynie pełnoprawnej zdalnej instancji PowerShell.
Jeśli w lokalnym systemie otworzysz program PowerShell i użyjesz polecenia cmdlet Enter-
-PSSession, Twój interfejs PowerShell stanie się w pełni zdalną reprezentacją programu
PowerShell z innego serwera. Twoje polecenia będą wykonywane tak, jakbyś był zalogowa-
ny do konsoli zdalnego serwera i miał w niej otwarty program PowerShell. Po raz kolejny
używam komputera klienckiego z systemem Windows 10, w którym uruchomiłem powłokę
PowerShell. Wykonuję następujące polecenie, aby połączyć się zdalnie z serwerem WEB4:
Enter-PSSession -ComputerName WEB4
Będziesz mógł zauważyć zmianę znaku zachęty, co oznacza, że pracuję teraz w kontekście
serwera WEB4.
373
Jeśli Twoje konto użytkownika nie ma dostępu do serwera, możesz zdefiniować alterna-
tywne poświadczenia, które będą używane podczas tworzenia zdalnego połączenia. Do
polecenia cmdlet Enter-PSSession wystarczy dodać opcję -Credential NAZWA_UŻYTKOWNIKA,
aby określić inne konto użytkownika.
Polecenia, które teraz będę wykonywać, zostaną uruchomione w kontekście serwera WEB4.
Sprawdźmy to. Jeśli wyświetlę zawartość zmiennej $env:computername, będę mógł zobaczyć,
że na ekranie pojawia się nazwa WEB4:
Aby przeprowadzić dodatkową weryfikację, na swoim zdalnym serwerze sprawdzę zainsta-

lowane role i funkcje systemu Windows. Zauważysz, że mam zainstalowaną rolę Web Server
(Serwer sieci Web), ponieważ początkowo skonfigurowaliśmy tę maszynę w taki sposób, by
była serwerem sieci WWW. Oczywiście na swojej stacji roboczej z systemem Windows 10 nie
mam zainstalowanej roli Web Server — powłoka PowerShell pobiera informacje z serwera
WEB4.
Get-WindowsFeature | Where Installed
Ta funkcjonalność jest rzeczywiście potężna. Jesteśmy zalogowani na stacji roboczej, mamy

utworzoną zdalną sesję PowerShell uruchomioną na serwerze WEB4 i dzięki temu jesteśmy
w stanie uzyskać z niego różne informacje, ponieważ wygląda to tak, jakbyśmy korzystali
z programu PowerShell bezpośrednio na tej zdalnej maszynie. Zróbmy coś więcej i spróbujmy
wprowadzić zmiany w konfiguracji serwera WEB4, aby sprawdzić, czy jest to możliwe. Może
374
zainstalujmy na nim jakąś nową funkcję. Często używam klienta Telnet do testowania połączeń
sieciowych, jednakże widzę, że nie jest on obecnie zainstalowany na serwerze WEB4.
Get-WindowsFeature -Name *telnet*
Za pomocą polecenia cmdlet Add-WindowsFeature powinienem móc zainstalować wymaganą

funkcję:
Add-WindowsFeature Telnet-Client
Możliwość wywołania zdalnej sesji PowerShell to potężne narzędzie, które pozwala na obsługę
nie tylko serwerów z pełnym interfejsem graficznym Desktop Experience, ale także zabez-
pieczonych systemów Server Core. Umiejętność pracy w zdalnych sesjach PowerShell będzie
niezbędna do pomyślnego wdrożenia wersji Server Core w Twojej infrastrukturze.
Konfiguracja żądanego stanu

W nowszych wersjach środowiska PowerShell pojawiła się kolejna potężna funkcja, zwana
konfiguracją żądanego stanu (ang. Desired State Configuration, w skrócie DSC). Jest to plat-
forma zarządzania połączona z programem PowerShell i udostępniająca kilka ciekawych
funkcji i poleceń cmdlet, które można wykorzystać w skryptach. Jak sama nazwa wskazuje,
system pozwala na tworzenie konfiguracji w programie PowerShell, które zapewnią żądany
stan. Co mam na myśli? Cóż, generalnie DSC zapewnia, że skrypty PowerShell, które tworzysz,
zawsze będą działały w ten sam sposób na wszystkich serwerach, na których je zastosujesz.
375
Bardzo łatwo jest utworzyć skrypt w taki sposób, aby działał poprawnie na serwerze, którego
obecnie używasz. Jeśli jednak spróbujesz wdrożyć ten sam skrypt na innej maszynie, która może
znajdować się w odmiennej jednostce organizacyjnej (OU) lub mieć zainstalowane w systemie
inne elementy, skrypt może zwracać wyniki różne od oczekiwanych. Konfiguracja żądanego
stanu ma za zadanie właśnie przeciwdziałanie takim sytuacjom.
Tworząc konfigurację DSC, identyfikujesz określone role, ustawienia, funkcje, konta, zmienne itd.,
które chcesz zachować w określonym, żądanym stanie. Po zdefiniowaniu tych elementów DSC
będzie działać w taki sposób, aby zapewnić, że ich stan się nie zmieni i będzie zgodny z Twoimi
zasadami konfiguracji. Oznacza to, że elementy będą miały taki sam stan również na innych
serwerach, na których uruchomisz dany skrypt.
Konfiguracja żądanego stanu chroni również przed niezamierzonymi zmianami na serwerach.

Jeśli skrypt obsługujący konfigurację żądanego stanu wykryje, że jakaś usługa nie jest włą-
czona, a powinna na określonych serwerach działać przez cały czas, wówczas DSC pomoże
ją ponownie uruchomić, aby nie wystąpiła awaria. Możliwe, że masz także skrypt, który konfigu-
ruje serwer zgodnie z określonymi standardami. Następnie pojawia się jakaś osoba z działu IT,
która zmienia tę konfigurację — być może z jakiegoś powodu celowo loguje się na serwerze
i zatrzymuje usługę. Takie działanie mogłoby spowodować awarię maszyny, ale DSC uruchomi
usługę ponownie, aby zachować pierwotnie skonfigurowany żądany stan tego serwera. DSC
jest więc czymś w rodzaju Twojej niani skryptowej. Pomaga tworzyć konfiguracje, które pozostaną
jednolite na wielu platformach, a następnie pilnuje, by się nie zmieniały. Możesz więc mieć
pewność, że Twoje serwery zawsze się znajdują w określonym, żądanym stanie.
Po stworzeniu konfiguracji określającej elementy, które powinny zostać zainstalowane lub

monitorowane, rozpoczyna działanie tak zwany Menedżer konfiguracji lokalnej (ang. Local
Configuration Manager, w skrócie LCM), aby zapewnić zgodność zasobów ze specyfikacjami
tej konfiguracji. LCM regularnie sprawdza system, obserwując nieprawidłowości i zmiany,
a w razie potrzeby podejmuje działania, aby przywrócić w serwerach konfigurację żądanego
stanu.
Podstawowym celem DSC jest sprawienie, by serwery i usługi znajdowały się w niezmiennym
i spójnym stanie. Możliwości konfiguracji żądanego stanu oraz jej dostęp do składników systemu
operacyjnego są coraz lepsze, w miarę jak modyfikowane są role w celu współpracy z platformą
DSC. Uważam, że celem firmy Microsoft jest sprawienie, by w każdym serwerze działał
skrypt konfiguracyjny DSC, zapewniając ciągłą pracę w ramach zdefiniowanych standardów
i pomagając utrzymać stan dostępności na poziomie 99,999%.
Tematyka związana z platformą DSC jest bardzo rozległa, więc zachęcam Cię do dokładniejszego
zapoznania się z tym zagadnieniem, gdy tylko nauczysz się tworzyć skrypty PowerShell oraz
ich używać. Oto parę polecanych stron, które pozwolą dowiedzieć się więcej o konfiguracji
żądanego stanu:
 https://docs.microsoft.com/en-us/powershell/scripting/dsc/overview/
overview?view=powershell-6,
 https://channel9.msdn.com/Series/Getting-Started-with-PowerShell-
-DSC?l=ZwHuclG1_2504984382.
376
Podsumowanie
Wiele składników systemu Windows Server 2019 preferuje rozwiązanie polegające na wykony-
waniu zadań administracyjnych za pomocą programu PowerShell. Ponieważ programy
okienkowe służące do zarządzania są obecnie tylko powłokami uruchamiającymi skrypty
PowerShell, a domyślną opcją instalacji dla systemu Windows Server jest Server Core, możemy
założyć, że serwery bezobsługowe wykorzystujące wiersz poleceń będą naszymi maszynami
przyszłości. Mimo że interfejs PowerShell stanowi rdzeń funkcjonalności systemu operacyjnego
od wersji Server 2012, wciąż uważam, że kiedyś był postrzegany przez większość administrato-
rów jako po prostu alternatywny sposób zarządzania serwerami. Tak — oczywiście wiem, że
taki program istnieje i powinienem zacząć go używać, a jego skrypty wyglądają całkiem nieźle,
ale nadal mogę zrobić wszystko, co chcę, za pomocą starego, dobrego wiersza poleceń lub
przycisku mojej myszy. Ten przestarzały sposób myślenia szybko się jednak zmienia.
Gdy pojawiają się nowe technologie, takie jak DSC, widzimy, że PowerShell zaczyna być
wyposażany w funkcje, które po prostu nie istnieją nigdzie indziej w systemie operacyjnym.
W połączeniu z możliwością zdalnego zarządzania zapewnianą przez znormalizowaną plat-
formę PowerShell, której można używać na wszystkich urządzeniach wyposażonych w nowe
wersje systemu Windows (a nawet na serwerach znajdujących się na platformie Azure!),
oznacza to, że na pewno rola interfejsu PowerShell będzie wzrastała w kolejnych wydaniach
systemów operacyjnych i usług firmy Microsoft. W następnym rozdziale omówimy kontenery
i Nano Server.
Pytania
1. Jaki jest najszybszy sposób przejścia z wiersza poleceń do programu PowerShell?
2. Jakie polecenie cmdlet wyświetla wszystkie dostępne polecenia cmdlet programu
PowerShell?
3. Jakiego polecenia cmdlet programu PowerShell można użyć do połączenia
interfejsu PowerShell ze zdalnym komputerem?
4. Jakie rozszerzenie ma plik skryptu PowerShell?
5. Jaki poziom ustawień mają domyślne zasady wykonywania w nowo zainstalowanym
systemie Windows Server 2019?
6. Jakiego klawisza na klawiaturze można użyć do automatycznego uzupełnienia
pozostałej części polecenia cmdlet lub nazwy pliku podczas pracy w interfejsie
PowerShell?
7. Jaka usługa musi zostać uruchomiona w systemie, aby można się było z nim połączyć
za pomocą zdalnej sesji PowerShell?
377
378
11
Kontenery
i Nano Server
Wiele nowych technologii zawartych w systemie Windows Server 2019 zaprojektowano tak,
aby odzwierciedlały możliwości przetwarzania w chmurze. Pozwalają one na definiowanie
chmur prywatnych i umożliwiają wykorzystywanie w ramach własnej infrastruktury fizycz-
nej takich samych rozwiązań jak te, które są oferowane przez dostawców chmur publicznych.
Nowości w kilku ostatnich wersjach systemu operacyjnego Windows Server dotyczyły rów-
nież wirtualizacji. Kontenery aplikacji to rozwiązanie, które łączy przetwarzanie w chmurze
z wirtualizacją. Sprawi ono, że wdrażanie systemów będzie lepsze, bezpieczniejsze i bardziej
wydajne. Kontenery są stosunkowo nowym pomysłem w świecie firmy Microsoft, więc admini-
stratorzy IT nie są nimi jeszcze zbytnio podekscytowani, ale wkrótce się to zmieni. Jest to
rozwiązanie, które od jakiegoś czasu usprawnia obliczenia wykonywane w systemie Linux.
Dzięki najnowszemu systemowi operacyjnemu Windows Server ta technologia zostanie
udostępniona większej liczbie użytkowników.
Twórcy aplikacji będą bardzo zainteresowani kontenerami dostarczanymi przez system Win-
dows Server 2019. Prawdę mówiąc, najprawdopodobniej rozumieją oni koncepcję kontenerów
znacznie lepiej niż tradycyjny administrator serwera. Chociaż z założenia w tej książce nie
analizujemy zagadnień programistycznych ani nie zajmujemy się systemem Linux, omówimy
kontenery, ponieważ korzyść z ich użycia mogą odnieść nie tylko programiści, ale też my, ope-
ratorzy systemowi. Powinniśmy więc umieć definiować i uruchamiać kontenery, abyśmy mogli
zapewnić infrastrukturę, która będzie wymagana przez naszych projektantów.
W tym rozdziale omówimy niektóre zagadnienia dotyczące kontenerów aplikacji, a w szczegól-

ności nowe opcje dostępne w systemie Windows Server 2019 pozwalające na wdrożenie tej
technologii w naszych centrach danych:
 Co to są kontenery aplikacji?
 Kontenery i Nano Server.
 Kontenery Windows Server a kontenery Hyper-V.

 Docker i Kubernetes.
 Używanie kontenerów.
Co to są kontenery aplikacji?
Co oznacza sformułowanie „kontener aplikacji”? W dzisiejszych czasach potrafimy sprawnie
przechowywać serwery za pomocą technologii wirtualizacji. Mając sprzęt fizyczny, przekształ-
camy go w serwer wirtualizacji Hyper-V, a następnie uruchamiamy w nim wiele maszyn wirtu-
alnych. Jest on dla nich czymś w rodzaju kontenera. W zasadzie oszukujemy te maszyny, aby
wciąż „wierzyły”, że są niezależnymi jednostkami. Są one zupełnie nieświadome tego, że współ-
dzielą zasoby i sprzęt z innymi maszynami wirtualnymi działającymi na tym samym serwerze.
W czasie dzielenia się zasobami sprzętowymi możemy zapewnić wysoki poziom izolacji między
maszynami wirtualnymi, aby mieć pewność, że nie pojawią się żadne problemy z uprawnie-
niami ani dostępem do nich — szczególnie w przypadku, gdy korzystamy z chmury publicznej,
ponieważ oznaczałoby to katastrofę.
Również kontenery aplikacji to wirtualizacja, ale na innym poziomie. Podczas gdy maszyny
wirtualne są związane z wirtualizacją sprzętu, kontenery przypominają raczej wirtualizację
systemu operacyjnego. Zamiast tworzyć oddzielne maszyny wirtualne do obsługi naszych
aplikacji, możemy zdefiniować kontenery, które są znacznie mniejsze. Następnie uruchamiamy
w nich aplikacje, którym „wydaje się”, że działają w przeznaczonej im instancji systemu
operacyjnego.
Ogromną zaletą korzystania z kontenerów jest możliwość zespolenia zespołów projektowania

i eksploatacji. Obecnie bardzo modne stało się pojęcie DevOps, które oznacza połączenie pro-
cesów projektowania i eksploatacji w celu usprawnienia procesu wdrażania aplikacji. Wyko-
rzystanie kontenerów będzie miało ogromny wpływ na metodykę DevOps, ponieważ projektanci
mogą teraz wykonywać swoją pracę (tworzyć aplikacje) bez konieczności dostosowywania się
do procesów eksploatacyjnych i infrastruktury. Gdy aplikacja będzie już gotowa, administrato-
rzy umieszczą kontener, w którym się ona znajduje, w odpowiedniej infrastrukturze bez żadnej
obawy, że serwer zostanie uszkodzony lub wystąpi jakikolwiek problem z kompatybilnością.
Uważam, że kontenery zastąpią wiele maszyn wirtualnych, jednakże stanie się to tylko wtedy,
gdy administratorzy zainteresują się tą technologią i sami ją przetestują. Przeanalizujmy
więc kilka szczególnych korzyści, jakie można osiągnąć dzięki użyciu kontenerów.
Współdzielenie zasobów
Kontenery aplikacji, podobnie jak maszyny wirtualne, współdzielą fizyczne zasoby sprzętu.
Dzięki temu na tym samym serwerze (fizycznym lub wirtualnym) możemy uruchamiać wiele
kontenerów.
380
Rozdział 11. • Kontenery i Nano Server
Jednak w tym przypadku kontenery nie mają przewagi nad maszynami wirtualnymi, ponieważ
po prostu również współużytkują sprzęt. Korzyścią z wykorzystywania kontenerów zamiast
oddzielnych maszyn wirtualnych jest to, że te kontenery mogą używać tego samego, standardo-
wego systemu operacyjnego. Są one tworzone przy użyciu tej samej podstawowej konfiguracji,
co sprawia, że ich wdrażanie jest niezwykle szybkie, ale też oznacza, że współdzielą te same
zasoby jądra. Każda instancja systemu operacyjnego ma własny zestaw procesów użytkownika.
Czasami trudno jest uruchomić wiele aplikacji na jednym serwerze, ponieważ mają one dostęp
do tego samego zestawu procesów i mogą przez to negatywnie na nie wpływać. Innymi słowy,
jest to powód, dla którego w dzisiejszych czasach mamy tendencję do uruchamiania tak wielu
serwerów, utrzymując każdą z aplikacji na oddzielnej maszynie, aby nie mogły one na siebie
oddziaływać. Czasami aplikacje po prostu nie mogą się znajdować na tym samym serwerze.
Jądro w systemie Windows Server 2019 zostało ulepszone i dzięki temu może obsługiwać
wiele kopii procesów działających w trybie użytkownika. Oznacza to, że nie tylko możesz trady-
cyjnie uruchamiać instancje tej samej aplikacji na wielu różnych serwerach, ale również istnieje
możliwość uruchamiania wielu różnych programów na tej samej maszynie, nawet jeśli zazwyczaj
nie najlepiej ze sobą współpracują.
Izolowanie
Jedną z wielkich zalet kontenerów aplikacji jest to, że projektanci mogą tworzyć swoje apli-
kacje w kontenerach działających na ich własnych stacjach roboczych! Komputer służący do
przechowywania kontenerów może być serwerem z systemem Windows Server lub stacją
roboczą z Windows 10. Po umieszczeniu aplikacji w odizolowanym kontenerze projektanci
będą pewni, że zawiera ona wszystkie składniki i zależności, których potrzebuje do popraw-
nego funkcjonowania, a także nie wymaga dodatkowych zasobów ze znajdującego się pod
spodem systemu operacyjnego. Oznacza to, że projektant może stworzyć aplikację, upewnić
się, że działa w lokalnym środowisku, a następnie łatwo przenieść kontener aplikacji na wła-
ściwy serwer, gdzie zostanie włączony i będzie gotowy do zastosowań produkcyjnych. Taka
maszyna produkcyjna może być nawet zasobem udostępnianym w chmurze, ale dla aplikacji
nie ma to żadnego znaczenia. Odizolowanie kontenera od systemu operacyjnego pozwala na
zdefiniowanie standardu tworzenia aplikacji, dzięki czemu staje się ona przenośna i mobil-
na. Oszczędza także czas projektanta i zmniejsza złożoność jego pracy, ponieważ w trakcie
procesu projektowania nie musi on już uwzględniać różnic w podstawowych systemach ope-
racyjnych.
Innym aspektem izolowania jest poziom bezpieczeństwa. Podobna sytuacja występuje w przy-
padku, gdy na tym samym serwerze działa wiele maszyn wirtualnych, szczególnie w środowisku
chmurowym. Chciałbyś, aby były one od siebie bezpiecznie odizolowane, co w rzeczywistości
oznacza, że nie powinny absolutnie nie wiedzieć o istnieniu obok nich innych maszyn. Wyma-
gasz także odizolowania maszyn wirtualnych od systemu operacyjnego hosta, ponieważ na pewno
nie chciałbyś, aby dostawca usług publicznych w chmurze przeglądał ich zawartość. W przy-
padku kontenerów aplikacji sytuacja jest taka sama.
Procesy uruchomione w kontenerze nie są widoczne w systemie operacyjnym hosta, nawet

jeśli zużywają jego zasoby. W kontenerach stosuje się dwie różne formy izolowania. Istnieje
381
izolacja przestrzeni nazw, co oznacza, że kontenery są ograniczone do własnego systemu

plików i rejestru. Istnieje również izolacja zasobów, oznaczająca, że możemy wskazać zasoby
sprzętowe dostępne dla poszczególnych kontenerów, które nie będą w stanie ich sobie wykradać.
Wkrótce omówimy dwie różne kategorie kontenerów: kontenery Windows Server i kontenery
Hyper-V. Te dwa typy kontenerów implementują standard izolowania w odmienny sposób —
za chwilę dowiesz się więcej na ten temat.
Wiesz już, że kontenery współdzielą zasoby i są uruchamiane z tego samego obrazu podstawo-
wego, zachowując jednocześnie swoje procesy odseparowane od podstawowego systemu opera-
cyjnego, który dzięki temu nie może negatywnie wpływać na aplikację. I odwrotnie, aplikacja
nie zakłóca działania systemu operacyjnego hosta. W jaki jednak sposób jest przeprowadzane
izolowanie składników sieciowych? Kontenery aplikacji wykorzystują technologię wirtualnego
przełącznika Hyper-V, aby elementy sieci działały poprawnie. Gdy faktycznie zaczniesz używać
kontenerów, wkrótce zauważysz, że do każdego kontenera jest przypisany unikatowy adres IP
w celu zachowania określonego poziomu odizolowania.
Skalowalność
Odizolowanie kontenera w połączeniu z uruchamianiem go z tego samego obrazu podstawo-
wego pozwala uzyskać bardzo atrakcyjne możliwości skalowania i rozbudowy. Pomyśl o zarzą-
dzanej przez Ciebie aplikacji internetowej, której wykorzystanie może się zmieniać z dnia na
dzień. Zapewnienie wystarczających zasobów, aby mogła działać podczas okresów wyższego
obciążenia, oznacza w przypadku tradycyjnego rozwiązania przepłacanie za zasoby obliczeniowe
w czasie, gdy nie jest intensywnie używana. Technologie chmurowe zapewniają w przypadku
nowoczesnych rodzajów aplikacji dynamiczne skalowanie, ale często zwiększają lub zmniejszają
zasoby dla całych maszyn wirtualnych. Istnieją trzy typowe problemy związane z dynamicz-
nym skalowaniem tego typu aplikacji. Pierwszy to czas potrzebny na utworzenie dodatkowych
maszyn wirtualnych. Nawet jeśli proces ten zostanie zautomatyzowany, aplikacja może przez
pewien czas działać wolniej, zanim pojawią się dodatkowe zasoby. Naszym drugim wyzwaniem
są problemy, z którymi musi walczyć projektant, aby stworzyć aplikację działającą bez
względu na niespójności występujące między różnymi docelowymi komputerami. Trzecia sprawa
to koszty. Nie chodzi tylko o sam sprzęt, ponieważ nowo uruchamiane maszyny wirtualne
będą zużywać cały zestaw zasobów jądra, ale także o pieniądze. Uruchamianie lub wyłączanie
maszyn wirtualnych w środowisku chmury może szybko stać się kosztowne. Te przeszkody
nie istnieją, gdy jako metody wdrażania aplikacji używasz kontenerów.
Ponieważ kontenery aplikacji używają tego samego jądra i tego samego obrazu podstawowego,
ich czas uruchamiania jest niezwykle krótki. Nowe kontenery można bardzo szybko wyłączać lub
włączać (nawet po kilka naraz) bez konieczności oczekiwania na uruchomienie procesów
w trybie rozruchu i jądra. Ponadto, ponieważ udostępniliśmy projektantom izolowaną strukturę
kontenerów, w której można stworzyć aplikację, wiemy, że będzie mogła ona działać z powodze-
niem wszędzie tam, gdzie umieścimy jeden z tych kontenerów. Nie musisz się już martwić,
czy nowa maszyna wirtualna, która będzie dostępna w sieci, zostanie stworzona zgodnie ze
standardami, kontenery bowiem są dla określonej aplikacji zawsze takie same i zawierają wszyst-
kie niezbędne zależności, których ona potrzebuje.
382
Kontenery i Nano Server

W tym punkcie wracamy do analizy systemu Nano Server i powodu, dla którego nie jest on już
opcją instalacji systemu Windows Server. Zanim omówimy cel, jakiemu obecnie służy Nano
Server, rzućmy okiem na strukturę kontenera opartego na systemie Windows. Oto rysunek za-
pożyczony z kolekcji slajdów, która była częścią prezentacji Microsoft Ignite:
Najniższa warstwa kontenera to podstawowy system operacyjny. Podczas uruchamiania kontene-

ra potrzebny jest podstawowy zestaw kodu i jądra, z którego można korzystać. Takim syste-
mem może być Server Core lub Nano Server.
Następnie mamy warstwę dostosowania. W tym miejscu znajdują się technologie, które osta-
tecznie będą używane przez Twoją aplikację. Na przykład nasze kontenery mogą zawierać
usługę IIS do zarządzania stroną internetową, program PowerShell, a nawet bibliotekę .NET.
Wszystkie te narzędzia znajdują się w tej warstwie.
Na samej górze kontenera znajduje się warstwa aplikacyjna. Jest nią oczywiście określona aplika-
cja, którą planujesz umieścić w tym kontenerze i do której użytkownicy powinni mieć dostęp.
Chociaż Server Core to system operacyjny, który jest idealny do tworzenia niewielkich i wydaj-
nych serwerów, wciąż jest zbyt rozbudowany w porównaniu z wersją Nano Server, która jest
tak odmienna i niewiarygodnie mała, że faktycznie nie można jej z niczym porównać. Prawdo-
podobnie pamiętasz naszą instalację systemu Server Core, który wymagał dysku twardego
o wielkości co najmniej 6 GB. Chociaż ta wartość jest i tak znacznie mniejsza od wielkości dysku
używanego przez Windows Server Desktop Experience, oto informacja, która powinna wywrzeć
na Tobie duże wrażenie: obraz podstawowy systemu Nano Server może zajmować mniej niż
500 MB!
To faktycznie niewiele. Ponadto oczekuje się, że aktualizacje systemu Nano Server będą nieliczne
i rzadko stosowane. Oznacza to, że w kontenerach aplikacji nie będziesz musiał przejmować
się comiesięcznymi poprawkami i aktualizacjami. Ponieważ kontenery zawierają wszystko, czego
potrzebują, aby uruchomić zawarte w nich aplikacje, ogólnie przyjmuje się, że w sytuacji, w któ-
rej trzeba będzie coś zaktualizować, po prostu stworzy się nowy obraz kontenera, a nie będzie się
instalować poprawek w istniejącym. Jeśli Nano Server otrzyma aktualizację, po prostu utwórz
383
nowy kontener, zainstaluj w nim i przetestuj aplikację, a następnie ją udostępnij. Czy chciałbyś
wprowadzić jakieś zmiany w samej aplikacji? Zamiast zastanawiać się, jak zaktualizować istniejący
obraz kontenera, szybko i łatwo stwórz nowy, przetestuj go poza środowiskiem produkcyjnym,
a gdy będzie gotowy, po prostu zacznij go włączać do produkcji, wygaszając jednocześnie
starą wersję.
Nano Server jest obecnie podstawowym systemem operacyjnym dla kontenerów. To coś nowego,
ponieważ w czasie, gdy pojawił się Server 2016, funkcjonalność Nano była znacznie większa. Je-
śli używasz wersji Nano Server w celach innych niż obsługa kontenerów, musisz rozpocząć przy-
gotowania do przeniesienia systemów na bardziej tradycyjne serwery, takie jak Server Core.
Być może zastanawiasz się: „Dlaczego ktokolwiek miałby używać systemu Server Core do
przechowywania obrazu kontenera, jeśli mamy Nano Server?”. Chodzi o zgodność aplikacji.
Nano Server jest niewiarygodnie mały i dlatego brakuje mu dużo kodu, który istnieje w wersji
Server Core. Gdy zaczynasz rozważać wykorzystanie kontenerów do przechowywania swoich
aplikacji, należy zawsze próbować użyć prostszej wersji Nano Server. Jednakże często Twoje
aplikacje po prostu nie będą mogły działać na tej platformie, więc w takich przypadkach powi-
nieneś wybierać Server Core jako podstawowy system operacyjny.
Kontenery Windows Server

a kontenery Hyper-V
Należy pamiętać, że istnieją dwie kategorie kontenerów, które mogą działać w systemie
Windows Server 2019. Wszystko, co do tej pory omówiliśmy, dotyczyło kontenerów Windows
Server lub kontenerów Hyper-V. Kontenery Hyper-V są podobne do kontenerów Windows
Server i mogą uruchamiać ten sam kod lub te same obrazy, a wysoki poziom izolowania gwaran-
tuje, że ważne elementy pozostaną oddzielone od siebie. Decyzja o użyciu kontenerów
Windows Server lub Hyper-V prawdopodobnie sprowadza się do poziomu bezpieczeństwa,
który należy wdrożyć w kontenerach. Poniżej omówimy istniejące różnice, abyś lepiej wiedział,
co należy wybrać.
Kontenery Windows Server

Podobnie jak kontenery systemu Linux współdzielą pliki jądra systemu operacyjnego hosta,
również kontenery Windows Server korzystają z tej funkcjonalności w celu zwiększenia swojej
wydajności. Oznacza to jednak, że chociaż przestrzeń nazw, system plików i izolacja sieci są
przygotowane do oddzielenia kontenerów od siebie, wciąż istnieją pewne potencjalne luki
w zabezpieczeniach dotyczące kontenerów Windows Server działających na serwerze zarzą-
dzającym. Na przykład, jeśli zalogujesz się do systemu operacyjnego hosta na serwerze zarzą-
dzającym, możesz wyświetlić procesy działające w każdym z kontenerów. Kontener co prawda
nie jest w stanie zobaczyć samego serwera zarządzającego ani pozostałych kontenerów i jest
nadal odizolowany od hosta, ale wiedząc, że można przeglądać jego procesy, możemy stwierdzić,
że istnieje pewna interakcja na tym poziomie współdzielenia. Kontenery systemu Windows
384
Server będą najbardziej przydatne w okolicznościach, w których serwer zarządzający i same

kontenery znajdują się na tym samym poziomie zaufania. W większości przypadków oznacza to,
że kontenery z systemem Windows Server będą używane na serwerach będących własnością
firmy. Powinny to być kontenery, które również należą do firmy i którym można wewnętrznie
zaufać. Jeśli ufasz zarówno serwerowi zarządzającemu, jak i kontenerom, a także nie masz
nic przeciwko temu, aby ufały one sobie wzajemnie, wdrożenie zwykłych kontenerów systemu
Windows Server jest najbardziej wydajnym sposobem wykorzystania zasobów sprzętowych.
Kontenery Hyper-V
Jeśli chciałbyś zwiększyć poziom odizolowania i bezpieczeństwa, powinieneś wykorzystać
kontenery Hyper-V. Przypominają one raczej zoptymalizowaną wersję maszyny wirtualnej.
W takim rozwiązaniu zasoby jądra nadal są współdzielone przez kontenery, więc są one znacz-
nie bardziej wydajne niż standardowe maszyny wirtualne. Każdy kontener Hyper-V otrzymuje
jednak własną powłokę Windows, w której może działać. Oznacza to, że poziom odizolowania
kontenerów Hyper-V od siebie jest podobny jak w przypadku maszyn wirtualnych. Mimo to
nadal możesz sprawnie uruchamiać nowe kontenery, ponieważ odpowiednia infrastruktura
wciąż jest dostępna. Kontenery Hyper-V będą bardziej przydatne w infrastrukturach z wieloma
dzierżawcami, w których chcesz się upewnić, że nie dojdzie do wycieku danych między konte-
nerem a hostem lub między dwoma różnymi kontenerami, które mogą być własnością różnych
podmiotów. Wcześniej napisałem, że system operacyjny hosta może zobaczyć procesy uru-
chomione w kontenerze Windows Server, jednakże taka sytuacja jest niemożliwa w przypadku
kontenerów Hyper-V. System operacyjny serwera zarządzającego w ogóle nie wie o usługach
uruchomionych w kontenerach Hyper-V i nie jest w stanie z nich skorzystać. Te procesy są teraz
po prostu niewidoczne.
Dostępność kontenerów Hyper-V oznacza, że nawet jeśli masz aplikację, która musi być
izolowana na wysokim poziomie, nie musisz już poświęcać jej pełnej maszyny wirtualnej Hyper-V.
Obecnie możesz uruchomić kontener Hyper-V, umieścić w nim aplikację i cieszyć się pełnym
odizolowaniem, jednocześnie nadal współdzieląc zasoby i zapewniając jej lepszą, bardziej skalo-
walną obsługę.
Docker i Kubernetes
Docker to projekt o otwartym oprogramowaniu, a tak naprawdę zestaw narzędzi, który pier-
wotnie został stworzony, aby umożliwić uruchamianie kontenerów w systemach operacyjnych
Linux. Chwileczkę, o co chodzi? Słowa Linux i otwarte oprogramowanie znów pojawiają się
w książce o systemie firmy Microsoft! Do czego zmierza ten świat? No cóż, kontenery szybko
zdobywają uznanie — i bardzo dobrze. W systemie Server 2016 firma Microsoft zaczęła się
interesować kontenerami. Pojawiły się odpowiednie polecenia cmdlet środowiska PowerShell,
które można wykorzystać do uruchamiania ich i zarządzania nimi. Jednak ze względu na tempo
rozwoju platformy Docker firma Microsoft oczekuje obecnie, że każda osoba, która będzie
chciała uruchomić kontenery na swoich komputerach z systemem Windows, zrobi to właśnie
385
za pośrednictwem zestawu narzędzi Docker. Jeśli chcesz w swoim środowisku używać kontene-
rów lub choćby je testować, musisz najpierw wdrożyć rozwiązanie Docker for Windows.
Docker to platforma kontenerowa. Oznacza to, że udostępnia polecenia i narzędzia potrzebne do

pobierania, tworzenia, pakowania, dystrybucji i uruchamiania kontenerów. Narzędzie to jest
w pełni obsługiwane zarówno w systemie Windows 10, jak i Windows Server 2019. Instalując
platformę Docker for Windows, otrzymujesz wszystkie narzędzia potrzebne do tego, by zacząć
korzystać z kontenerów w celu zwiększenia poziomu odizolowania i skalowalności aplikacji.
Projektanci mogą używać systemu Docker do tworzenia na lokalnej stacji roboczej środowiska,
które będzie odzwierciedlać środowisko serwera. Pozwala to umieścić aplikacje w kontenerach
i zapewnić, że będą one działać po przeniesieniu ich na serwer. Docker to platforma udostęp-
niająca projektantom możliwości pakowania, wysyłania i uruchamiania kontenerów. Po zakoń-
czeniu projektowania pakiet z kontenerem można przekazać administratorowi systemu, który
go rozpakuje, uruchomi kontener zawierający aplikację i odpowiednio go wdroży. Projektant
nie zna infrastruktury hosta kontenerów ani go ona nie interesuje, a z drugiej strony admini-
strator nie zna procesu projektowania i się nim nie zajmuje, podobnie jak kompatybilnością
aplikacji z jego serwerami.
Kontenery Linux
Możliwości systemu Windows Server 2019 pozwalające na współpracę z różnymi rodzajami
kontenerów znacząco się zmieniły w porównaniu z poprzednimi wydaniami. We wcześniejszej
wersji Windows Server 2016 host kontenerów mógł uruchamiać tylko kontenery oparte na sys-
temie Windows, ponieważ współdzielą one jądro systemu operacyjnego serwera, tak więc nie
było możliwości używania kontenerów Linux.
Czasy się zmieniają, więc obecnie w systemie Server 2019 mamy kilka nowych funkcji pozwala-
jących na obsługę kontenerów Linux. Chociaż te funkcje wciąż są dopracowywane, istnieją
już pewne opcje, zwane Moby VM i LCOW, które umożliwiają uruchamianie kontenerów Linux
na hoście kontenerów Windows Server, w tym równolegle z innymi kontenerami Windows!
Wszystkie te rozwiązania są wciąż nowe i rozwijają się, zatem więcej szczegółów zostanie
podanych w przyszłości. Jeśli jesteś zainteresowany uruchamianiem kontenerów Linux, odwiedź
następujący adres, aby się dowiedzieć, jak wygląda obecna sytuacja: https://docs.microsoft.
com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers.
Docker Hub
Pracując z kontenerami, tworzysz ich obrazy, które można wykorzystać w dowolnej instancji
serwera z tym samym systemem operacyjnym hosta — to najbardziej skrócona informacja
o tym, w jaki sposób można ich używać. Gdy uruchamiasz kolejną instancję kontenera, po pro-
stu wykonujesz nową kopię tego samego obrazu, który zawiera wszystkie niezbędne elementy.
Tego rodzaju znormalizowana metodyka prowadzi do stworzenia współdzielonego zbioru ob-
razów czy też repozytorium, z którego mogą korzystać także inne osoby. W końcu Docker jest
386
projektem o otwartym oprogramowaniu. Czy więc istnieje taki zasób, który można odwiedzić,
aby pobrać pliki obrazów kontenerów do przetestowania, a nawet przesłać do niego utworzone
przez siebie obrazy i udostępnić je całemu światu? Oczywiście, że tak! Nazywa się on Docker
Hub i jest dostępny pod adresem https://hub.docker.com/.
Odwiedź tę stronę i załóż na niej konto, a natychmiast uzyskasz dostęp do tysięcy obrazów
kontenerów, które zostały utworzone i przesłane przez użytkowników. Dzięki nim można szybko
uruchomić laboratorium z kontenerami. Wiele z tych obrazów można nawet wykorzystać
w systemach produkcyjnych, uruchamiając aplikacje, które zostały w nich umieszczone. Możesz
też użyć strony Docker Hub do przesyłania i przechowywania własnych obrazów kontenerów:
W istocie powinieneś już teraz założyć konto na stronie Docker Hub, ponieważ jeśli chcesz
aktywnie uczestniczyć w czytaniu dalszej części rozdziału i przetestować wdrażanie kontenera
przy użyciu platformy Docker, musisz się zalogować.
Docker Trusted Registry

Jeśli jesteś podobny do mnie, zapewne uważasz, że strona Docker Hub jest świetna: to dobre
miejsce do przechowywania obrazów, a nawet udostępniania ich społeczności. Jednak inną
moją skłonnością jest przyglądanie się sprawom przez pryzmat zastosowań profesjonalnych,
co szybko zmienia stan mojej perspektywy z miłej na niebezpieczną. Innymi słowy, umieszczanie
obrazów w tym publicznym repozytorium może nie być bezpieczne. Na pewno nie powinieneś
tam wrzucać obrazów, które zawierają wrażliwe dane związane z Twoją organizacją.
387
W tym miejscu przychodzi z pomocą Docker Trusted Registry. Jest to repozytorium obrazów
kontenerów, podobne do strony Docker Hub, ale różne o tyle, że można go używać w lokalnej
sieci za własnymi zaporami sieciowymi i systemami bezpieczeństwa. Dzięki temu uzyskujesz
system, który nie udostępnia poufnych informacji reszcie świata.
Kubernetes
Chociaż Docker jest naszym głównym interfejsem służącym do tworzenia kontenerów i zarzą-
dzania nimi, ponieważ umożliwia budowanie platform, na których możemy w nowy i ekscytu-
jący sposób wdrażać aplikacje, prawdziwa magia pojawia się dopiero po zakończeniu konfigu-
racji kontenera. Rzućmy okiem w przyszłość i załóżmy, że masz już aplikację zawartą
w kontenerze. Ten kontener może zostać uruchomiony w środowisku serwera zarządzającego
lub nawet bardzo łatwo przerzucony do chmury Azure. Co prawda zapewnia to łatwą współ-
pracę z infrastrukturą potrzebną do płynnego skalowania tej aplikacji, ale jest jeden element,
którego tu brakuje — mam na myśli orkiestrację.
Kubernetes jest orkiestratorem pozwalającym na uruchamianie skonteneryzowanych aplikacji.

Oznacza to, że Kubernetes organizuje lub definiuje sposób działania kontenerów. Jest to na-
rzędzie, które umożliwia bezproblemowe współdziałanie wielu kontenerów, tak jakby były
jedną dużą aplikacją. Jeśli zamierzasz tworzyć aplikacje skalowalne, które mają możliwość
uruchamiania nowych kontenerów za każdym razem, gdy potrzebne są dodatkowe zasoby,
koniecznie skorzystaj z orkiestratora kontenerów. Najlepszą i najpopularniejszą tego typu plat-
formą jest obecnie Kubernetes.
Firma Microsoft zauważyła tę popularność i podjęła kroki w celu zapewnienia pełnej obsługi
Kubernetes w systemie Windows Server 2019.
Podobnie jak w przypadku każdego innego oprogramowania, również tu istnieje konkurencja.

W rzeczywistości Docker ma własną platformę orkiestracyjną o nazwie Docker Swarm. Chociaż
wydaje się, że Docker mógłby lepiej współpracować z platformą Docker Swarm niż z każdym
innym orkiestratorem, liczby nie kłamią. Najnowsze raporty pokazują, że 82% firm korzystają-
cych z aplikacji skalowalnych w chmurze wykorzystuje środowisko Kubernetes w celu orkie-
stracji kontenerów.
Jak wspomniałem, narzędzia takie, jak kontenery, Docker i Kubernetes, są częścią filozofii chmury.
Większość firm zacznie wdrażać kontenery przy użyciu własnych serwerów i infrastruktury.
388
Jest to jednak technologia, której można już użyć w chmurze. Ponieważ same kontenery są
bardzo ujednolicone i mobilne, co ułatwia ich rozbudowę i przenoszenie, można je łatwo
umieszczać w środowisku chmurowym.
Używanie kontenerów
Aby wdrożyć technologię kontenerów w Twoim środowisku, należy skonfigurować wiele
elementów, jednak w rzeczywistości nie jest to zbyt trudne. Poniżej przedstawimy proces prze-
kształcania systemu Windows Server 2019 w supermaszynę z działającymi kontenerami.
Instalowanie roli i funkcji

Ilość pracy, którą musisz wykonać, zależy od tego, czy chcesz uruchomić kontenery z syste-
mem Windows Server, kontenery Hyper-V czy też oba rodzaje jednocześnie. Przede wszystkim
musisz zainstalować funkcję Containers (Kontenery). Można to zrobić przy użyciu opcji Add
roles and features (Dodaj role i funkcje) z poziomu Menedżera serwera lub następującego
polecenia PowerShell:
Add-WindowsFeature Containers
Jeśli ponadto zamierzasz uruchomić kontenery Hyper-V, musisz się upewnić, że na serwerze
zarządzającym zostaną zainstalowane podstawowe komponenty środowiska Hyper-V. Aby to zro-
bić, na tym samym serwerze zainstaluj rolę Hyper-V i towarzyszące jej narzędzia do zarządzania.
Po instalacji roli i funkcji będziesz musiał wykonać restart serwera.
W tym momencie możesz się zacząć zastanawiać: „Jeśli mój serwer zarządzający musi mieć
zainstalowaną rolę Hyper-V, czy to nie oznacza, że musi to być serwer fizyczny? Przecież nie
można zainstalować roli Hyper-V na maszynie wirtualnej”. Nieprawda. System Windows Server
2019 obsługuje tak zwaną wirtualizację zagnieżdżoną, która została dodana na potrzeby konte-
nerów. To, że trzeba użyć fizycznego sprzętu, staje się obecnie czynnikiem ograniczającym działy
IT, ponieważ prawie wszystko jest obsługiwane przez maszyny wirtualne. Sensowne jest więc,
389
aby firmy, które chcą wdrożyć kontenery, mogły używać serwerów zarządzających w postaci
maszyn wirtualnych zawierających wiele obrazów kontenerów. Z tego względu konieczne
było zaimplementowanie zagnieżdżonej wirtualizacji. Jeśli korzystasz z fizycznego serwera
Windows Server 2019 będącego hiperwizorem, w którym została zainstalowana maszyna
wirtualna, również z tym samym systemem, przekonasz się, że bezpośrednio na niej możesz
pomyślnie zainstalować rolę Hyper-V. Przecież wspominałem, że maszyny wirtualne są obecnie
na tyle popularne, by mogły być używane do uruchamiania innych maszyn wirtualnych!
Pamiętaj, że możemy również zarządzać kontenerami i je uruchamiać na komputerach

z systemem Windows 10! Aby przygotować klienta Windows 10 do tego celu, po prostu
dodaj do yniego funkcję o nazwie Containers (Kontenery), tak jak zrobiłeś w systemie
operacyjnym serwera.
Instalacja środowiska Docker for Windows

Gdy już przygotowaliśmy serwer zarządzający kontenerami i wyposażyliśmy go w niezbędne
składniki, musimy pobrać z internetu program Docker for Windows. Jego interfejs dostarczy
nam wszystkich poleceń niezbędnych do tworzenia kontenerów i ich obsługi.
W tym momencie niezbędne będzie zalogowanie się do usługi Docker Hub. Jeśli chcesz przete-
stować kontenery na własnej stacji roboczej i musisz zainstalować aplikację Docker Desktop
for Windows w swoim systemie Windows 10, najprościej będzie odwiedzić witrynę Docker
Hub, zalogować się w niej, a następnie wyszukać oprogramowanie klienckie Docker. Oto adres
prowadzący do tego programu (jest to narzędzie, którego należy użyć w systemie Windows
10): https://hub.docker.com/editions/community/docker-ce-desktop-windows.
Ponieważ jednak jestem zalogowany w systemie Windows Server 2019, mam uprawnienia licen-
cyjne pozwalające na użycie także wersji Docker Enterprise, którą można pobrać bez konieczno-
ści odwiedzania strony Docker Hub. Jeśli uruchomię program PowerShell z uprawnieniami
administracyjnymi, a następnie wykonam następujące dwa polecenia, mój serwer pobierze
aplikację Docker Enterprise i zainstaluje ją:
Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
Install-Package -Name docker -ProviderName DockerMsftProvider -Force -
RequiredVersion 18.03
390
Po zakończeniu instalacji pakietu, aplikacja Docker będzie dostępna na serwerze jako usługa.
Należy ją uruchomić za pomocą następującego polecenia:
Start-Service docker
Polecenia środowiska Docker

Bez względu na to, czy wykorzystujesz komputer z systemem Windows Server 2019 czy
Windows 10, po zakończeniu instalacji środowiska Docker zostanie uruchomiony silnik
Docker Engine i będzie gotowy do przyjmowania poleceń, dzięki czemu będziesz mógł rozpo-
cząć pracę z kontenerami. Gdybyś musiał zapamiętać tylko jedno hasło związane z obsługą
kontenerów, byłoby nim słowo Docker. Wynika to stąd, że każde polecenie wydawane w celu
interakcji z kontenerami zaczyna się od słowa docker. Przyjrzyjmy się więc kilku typowym
poleceniom, których będziesz używać.
Polecenie docker --help

To polecenie jest czymś w rodzaju wywołania docker /? — oczywiście, gdyby takie istniało.
Opcja --help spowoduje wygenerowanie listy poleceń, które można wykonać. To dobry punkt
startowy w pracy z kontenerami.
Polecenie docker images

Po pobraniu obrazów kontenerów z repozytorium (zrobimy to w następnym punkcie tego roz-
działu) możesz użyć polecenia docker images, aby wyświetlić wszystkie obrazy dostępne w sys-
temie lokalnym.
Polecenie docker search

Opcja search pozwala wyszukiwać w repozytoriach kontenerów (takich jak Docker Hub) ich ob-
razy, które można wykorzystać w swoim środowisku. Na przykład, aby wyszukać i znaleźć
obrazy dostarczone z repozytorium Microsoft Docker Hub, wydaj następujące polecenie:
docker search microsoft
Polecenie docker pull

Możemy użyć polecenia docker pull, aby pobrać obrazy kontenerów z repozytoriów dostępnych
w sieci. Istnieje wiele repozytoriów, z których można pobrać obrazy kontenerów. Najczę-
ściej będziesz używać obrazów ze strony Docker Hub, z której wkrótce pobierzemy jeden
z nich. Istnieją jednak inne repozytoria sieciowe, z których można pobrać obrazy kontenerów,
takie jak publiczny rejestr kontenerów firmy Microsoft, znany pod skrótową nazwą MCR.
Oto kilka przykładowych poleceń docker pull prezentujących sposób pobierania obrazów kon-
tenerów ze strony Docker Hub, a także MCR:
docker pull Microsoft\nanoserver
docker pull Microsoft\windowsservercore
docker image pull mcr.microsoft.com/windows/servercore:1809
docker image pull mcr.microsoft.com/windows/nanoserver:1809
391
Polecenie docker run

Jest to polecenie tworzenia nowego kontenera na podstawie obrazu podstawowego. Okazuje
się, że w lokalnym repozytorium możesz przechowywać wiele kontenerów, które są oparte
na tym samym obrazie. Gdy dodajesz nowe składniki do swoich kontenerów lub aktualizu-
jesz aplikację, która się wewnątrz nich znajduje, możesz tworzyć nowe obrazy kontenerów,
które stają się podzbiorem istniejącego obrazu kontenera. Przykładowo możesz mieć wiele obra-
zów kontenerów o tych samych nazwach windowsservercore. W takim przypadku bardzo
ważne stają się znaczniki kontenerów, ponieważ pozwalają rozróżnić wersje obrazów. Oto przy-
kładowe polecenie tworzące kontener na podstawie obrazu windowsservercore, z którym
skojarzyłem znacznik ltsc2019:
docker run -it --rm Microsoft\windowsservercore:ltsc2019
Użycie opcji -it w powyższym poleceniu umożliwia utworzenie powłoki, dzięki której możemy
zarządzać kontenerami, co jest przydatne podczas ich budowania i testowania. Ogólnie
rzecz biorąc, ta opcja nie byłaby niezbędna podczas uruchamiania kontenerów przeznaczo-
nych do produkcji, które zawierają aplikacje w pełni przetestowane i gotowe do działania.
Opcja --rm zapewnia porządkowanie — po zakończeniu pracy kontener i jego system plików
zostaną automatycznie usunięte.
Polecenie docker ps -a
Z polecenia docker ps skorzystasz, gdy będziesz chciał wyświetlić listę kontenerów, które są uru-
chomione w Twoim systemie.
Polecenie docker info

To polecenie spowoduje wyświetlenie podsumowania dotyczącego środowiska Docker, w tym
liczby uruchomionych kontenerów i dodatkowych informacji o samej platformie hosta.
Pobieranie obrazu kontenera

Pierwszym poleceniem, które uruchomimy na naszym nowo utworzonym serwerze kontenerów,
będzie docker images. Dzięki niemu zostanie wyświetlona lista zawierająca nazwy wszystkich
obrazów kontenerów, które obecnie znajdują się w naszym systemie:
Oczywiście, na razie nie mamy żadnych obrazów, ponieważ jeszcze ich nie pobraliśmy. Zdo-
bądźmy więc kilka obrazów, abyśmy mogli je przetestować. Zespół projektantów środowiska
.NET stworzył przykładowy plik obrazu kontenera. Ten obraz prezentuje uruchamianie
aplikacji .NET w kontenerze Nano Server. Moglibyśmy od niego zacząć i dzięki niemu spraw-
dzić, czy możemy pomyślnie uruchomić kontenery na naszym nowym serwerze. Po pierwsze,
392
powinniśmy użyć polecenia docker search, aby wyświetlić listę obrazów kontenerów, które znaj-
dują się w repozytorium Microsoft Docker Hub. Gdy już znajdziemy obraz, który nas inte-
resuje, użyjemy polecenia docker pull, aby pobrać go na nasz serwer:
docker search microsoft
docker image pull microsoft/nanoserver
Użycie poprzedniego polecenia pozwoliło na pobranie kopii standardowego obrazu podsta-

wowego systemu Nano Server. Chcielibyśmy jednak, aby nasz kontener wykonał jakąś pracę,
dlatego teraz pobierzemy również przykładowy obraz .NET:
docker image pull microsoft/dotnet-samples:dotnetapp-nanoserver-1809
Po zakończeniu pobierania ponownie wykonamy polecenie docker images. Teraz zostaną
wyświetlone dwa elementy: obraz kontenera Nano Server, a także przykładowy obraz .NET:
Gdy już mamy te obrazy, możemy uruchomić prawdziwy kontener.
Uruchamianie kontenera
Już za chwilę uruchomimy kontener na naszym serwerze! Gdy zainstalowaliśmy usługę,
wdrożyliśmy środowisko Docker i zaimportowaliśmy jego moduł do programu PowerShell, a na-
stępnie pobraliśmy podstawowy obraz kontenera, możemy w końcu wydać polecenie urucho-
mienia kontenera z tego obrazu. Wystartujmy więc wcześniej pobrany kontener .NET:
docker run microsoft/dotnet-samples:dotnetapp-nanoserver-1809
393
Kontener uruchamia się i wykonuje dołączony kod, który wyświetla zabawną grafikę na ekranie:
Uruchomienie tego kontenera potwierdza, że znajdują się w nim wszystkie składniki niezbędne
do wykonania aplikacji .NET. Jest on oparty na serwerze Nano Server, co oznacza, że zajmuje
niewiarygodnie mało miejsca. Na podstawie poprzednio wykonanego polecenia docker images
mogę stwierdzić, że obraz ma wielkość jedynie 417 MB! Co za oszczędność zasobów w porów-
naniu z uruchomieniem aplikacji na tradycyjnym serwerze WWW zawierającym usługę IIS!
Podstawowa dokumentacja firmy Microsoft dotycząca kontenerów znajduje się pod adresem
https://docs.microsoft.com/pl-pl/virtualization/windowscontainers/. Narzędzia używane do zarzą-
dzania kontenerami wciąż się zmieniają; pojawiają się także nowe wersje środowisk Docker
i Kubernetes. Koniecznie odwiedź witrynę Microsoft Docs, aby zapoznać się z najnowszymi
wzorcami postępowania i obsługiwaną ścieżką instalacji pozwalającą na przygotowanie serwera
kontenerów.
394
Podsumowanie
Kontenery zrewolucjonizują sposób, w jaki tworzymy nowoczesne aplikacje i nimi zarzą-
dzamy. Dzięki konteneryzacji systemów będziemy mogli uruchamiać o wiele więcej aplikacji na
jednym serwerze fizycznym, ponieważ mogą one być całkowicie odizolowane od siebie. Do-
datkowo użycie kontenerów pozwala na tworzenie aplikacji w sposób bardziej bezproblemowy.
Autorzy aplikacji mogą je tworzyć w kontenerach działających na ich własnych laptopach, a po
zakończeniu procesu po prostu przekazywać wynik zespołowi zarządzającemu infrastrukturą,
który umieści obraz kontenera na serwerze produkcyjnym. Taki serwer może się znajdować
w sieci lokalnej, a nawet w chmurze. Narzędzia do orkiestracji, takie jak Kubernetes, można
następnie wykorzystać w celu skalowania aplikacji, a także zwiększania lub zmniejszania ilości
zasobów i liczby koniecznych kontenerów w zależności od obciążenia lub innych czynników. Po-
ziom użyteczności kontenerów w świecie rzeczywistym został znacznie zwiększony dzięki śro-
dowisku Docker. Jego twórcy wyraźnie przodują w tym obszarze rynku, dlatego firma Microsoft
zdecydowała się dołączyć projekt o otwartym oprogramowaniu opracowany na potrzeby systemu
Linux (czyli środowisko Docker) bezpośrednio do systemu Windows Server 2019. Możemy
obecnie używać zarówno silnika środowiska Docker do uruchamiania kontenerów na serwerach
Windows, jak i jego klienckiego zestawu narzędzi do zarządzania nimi i modyfikowania ich z po-
ziomu systemu Windows w taki sam sposób, w jaki mogliśmy do tej pory obsługiwać kontenery
w świecie Linuksa.
Kontenery Linux i Windows Server mają wiele wspólnego ze sobą i działają w zasadzie w ten
sam sposób. Sprytny pomysł firmy Microsoft polegający na zaprojektowaniu dodatkowego typu
kontenerów (kontenery Hyper-V) zapewnia znaczące wsparcie dla obszaru bezpieczeństwa
związanego z ogólną koncepcją kontenerów. Obecnie wszyscy intensywnie korzystają z maszyn
wirtualnych; Nie sądzę, by ktokolwiek mógł się z tym nie zgodzić. Zakładając, że w przyszłości
kontenery będą łatwe do wdrażania i zarządzania, przewiduję, iż w nadchodzących latach
kontenery Hyper-V zastąpią wiele istniejących maszyn wirtualnych Hyper-V. Pozwoli to zaosz-
czędzić czas, pieniądze i miejsce na serwerze.
Jeśli już wspomniałem o wirtualizacji Hyper-V, należałoby również stwierdzić, że stała się ona
integralną częścią wielu obecnych sieci korporacyjnych. W następnym i zarazem ostatnim
rozdziale dowiesz się więcej o tej niesamowitej technologii wirtualizacji.
Pytania
1. Kontener Windows Server może zostać uruchomiony w jednym z dwóch
rodzajów podstawowego systemu operacyjnego. Jakie są ich nazwy?
2. Jaki rodzaj kontenera zapewnia jeszcze większy poziom izolacji od kontenera
Windows Server?
3. W systemie Windows Server 2016 na tej samej platformie hosta można uruchomić
zarówno kontenery z systemem Windows, jak i Linux — prawda czy fałsz?
395
4. Jak brzmi polecenie środowiska Docker umożliwiające wyświetlenie listy obrazów

kontenerów znajdujących się w systemie lokalnym?
5. Jak nazywa się najpopularniejsze oprogramowanie służące do orkiestracji
kontenerów, które integruje się z systemem Windows Server 2019?
6. Programiści mogą zainstalować środowisko Docker na swoich stacjach roboczych
z systemem Windows 10, aby rozpocząć tworzenie aplikacji w kontenerach —
prawda czy fałsz?
396
12
Wirtualizacja centrum
danych za pomocą
hiperwizora Hyper-V
Zawsze lubiłem wieś. Wolny czas zwykle wypełniają mi jazdy po bezdrożach, dłubanie przy
samochodach i polowanie. Podróż do miast, a zwłaszcza ostatni wyjazd do Hongkongu, zawsze
wiąże się z szokiem kulturowym. Wszystkie te drapacze chmur i wysokie budynki mieszkalne
służą jednak ważnemu celowi i są związane z moją metaforą: jeśli nie ma wystarczającej ilości
miejsca, by się rozbudowywać, należy piąć się w górę. Pionowy rozwój dużych miast jest po-
dobny do tego, co w ciągu ostatniej dekady mogliśmy zauważyć w naszych centrach danych.
Miasta potrzebują coraz więcej miejsca dla mieszkańców i firm, a my musimy przechowywać
coraz więcej serwerów. Zamiast realizować ekspansję poziomą z ogromnymi serwerowniami wy-
pełnionymi szafami i sprzętami, wzorujemy się na metodzie budowania wieżowca i wszystko
wirtualizujemy. Instalujemy znacznie mniej serwerów, za to czynimy je niesamowicie wydajny-
mi. Na tego typu superkomputerach możemy uruchomić dziesiątki, jeśli nie setki, serwerów
wirtualnych. W środowisku opartym na produktach firmy Microsoft stosuje się technologię zapew-
niającą istnienie warstwy hiperwizora oraz możliwość uruchamiania maszyn wirtualnych (VM).
Jest nią rola Hyper-V, dostępna w systemie Windows Server. To jedna z najważniejszych ról
z punktu widzenia administratora serwera, ponieważ jeśli Twoja organizacja nie korzysta jesz-
cze z wirtualizacji, na pewno wkrótce zacznie. Wirtualizacja jest pieśnią przyszłości. Poniżej
omówimy niektóre zagadnienia, które pozwolą zapoznać się z możliwościami wirtualizacji za-
pewnianymi przez firmę Microsoft w systemie Windows Server 2019:
 Projektowanie i wdrażanie serwera Hyper-V.
 Korzystanie z wirtualnych przełączników.
 Implementacja serwera wirtualnego.
 Zarządzanie serwerem wirtualnym.
 Chronione maszyny wirtualne.

 Integracja z Linuksem.
 Deduplikacja w systemie Resilient File System (ReFS)
 Serwer Hyper-V 2019.
Projektowanie i wdrażanie serwera Hyper-V

Tworzenie serwera Hyper-V jest zwykle dość proste: instalujesz system operacyjny, dodajesz
rolę Hyper-V, i to wszystko. W rzeczywistości możesz zainstalować rolę Hyper-V nawet na
komputerze z systemem Windows 10 Pro lub Enterprise, jeśli chciałbyś na własnym pulpicie
uruchomić jakieś maszyny wirtualne. Większość nowoczesnego sprzętu w pełni obsługuje
funkcjonalność hiperwizora, jednakże niektórzy czytelnicy podczas próby zainstalowania roli
Hyper-V mogą otrzymać następujący komunikat o błędzie:
Nie wygląda to ciekawie. Taki problem może mieć dwie przyczyny: procesor w moim kom-
puterze naprawdę nie obsługuje wirtualizacji albo po prostu mam wyłączone pewne usta-
wienia BIOS związane z wirtualizacją. Istnieją trzy warunki, które należy spełnić, aby się
upewnić, że serwer jest gotowy do uruchomienia roli Hyper-V. Po pierwsze, musisz używać
procesora opartego na architekturze x64. Jest to dość oczywiste, ponieważ system Windows
Server 2019 i tak jest dostępny tylko w wersji 64-bitowej. Jeśli nie masz procesora x64, nie
będziesz w stanie zainstalować systemu operacyjnego. Po drugie, procesory muszą być zdolne do
wirtualizacji wspomaganej sprzętowo. Zazwyczaj taka funkcjonalność nosi nazwę Intel
Virtualization Technology (Intel VT) lub AMD Virtualization (AMD-V). Wreszcie musisz
mieć dostępne i włączone zabezpieczenie Data Execution Prevention (DEP). Jeśli sprawdziłeś
sprzęt i wydaje się, że może obsługiwać wirtualizację, ale nadal nie możesz jej uruchomić,
398
Rozdział 12. • Wirtualizacja centrum danych za pomocą hiperwizora Hyper-V
prawdopodobnie w ustawieniach BIOS jest wyłączona opcja DEP. Wejdź więc do systemu
BIOS i włącz funkcję DEP, a także inne opcje, których nazwy mogą wskazywać, że dotyczą
uruchamiania maszyn wirtualnych.
Gdy stwierdzisz, że procesor potrafi obsłużyć maszyny wirtualne, możesz przekształcić sprzęt
o dowolnej wielkości w hiperwizora przez zainstalowanie na nim roli Hyper-V. Nie powinieneś
się zastanawiać nad minimalnymi wymaganiami systemowymi, ponieważ i tak chciałbyś, aby
Twój serwer Hyper-V był jak najbardziej wydajny. Im więcej rdzeni procesora, pamięci RAM
i miejsca na dysku twardym, tym więcej maszyn wirtualnych będzie można uruchomić. Nawet
najsłabsze serwery Hyper-V, jakie spotykałem w środowiskach produkcyjnych, używały podwój-
nych procesorów Xeon, 96 GB pamięci RAM i wielu terabajtów przestrzeni dyskowej. Taka
ilość pamięci RAM może się wydawać nadmiarową wartością dla jednego systemu, ale jeśli
pojedynczy serwer przeciętnie wykorzystuje 8 GB (co i tak jest dość niską wartością), a chciałbyś
uruchomić 12 serwerów wirtualnych, przekroczyłeś już możliwości maszyny Hyper-V wyposa-
żonej w zaledwie 96 GB. Liczba 8 pomnożona przez 12 daje w wyniku 96, a przecież nie pozo-
stawiłeś żadnego miejsca dla systemu operacyjnego hosta! Jaki jest morał? Użyj zaawanso-
wanego serwera albo zapomnij o wirtualizacji!
Instalowanie roli Hyper-V

Hyper-V to po prostu kolejna rola w systemie Windows Server 2019. Podczas jej instalacji
będziesz jednak musiał podjąć kilka decyzji, więc powinieneś dobrze zrozumieć, czego dotyczą,
aby mieć pewność, że nowy serwer Hyper-V zostanie poprawnie skonfigurowany i będzie
działać wydajnie. Przede wszystkim, aby zainstalować rolę o nazwie Hyper-V, musisz mieć zain-
stalowany system Windows Server 2019 i użyć opcji Add roles and features (Dodaj role i funkcje):
399
Podczas pracy z kreatorem instalacji roli w pewnym momencie pojawi się ekran Create Virtual
Switches (Tworzenie przełączników wirtualnych). W dalszej części tego rozdziału omówimy
nieco więcej zagadnień związanych z siecią w Hyper-V, ale ważne jest, abyś już teraz mógł
określić, które z fizycznych kart sieciowych Twojego serwera będą powiązane z hiperwizorem
Hyper-V i dostępne dla maszyn wirtualnych. Dobrym pomysłem jest, aby serwer Hyper-V
miał wiele kart sieciowych. Na pewno będziesz chciał mieć jedną kartę sieciową specjalnie
przeznaczoną dla samego hosta, dlatego na tym ekranie nie powinieneś jej wybrać. Zarezerwuj
ją, aby umożliwić wykonywanie połączeń przez hiperwizora. Oprócz niej będziesz potrzebować
co najmniej jednej karty sieciowej, która może łączyć maszyny wirtualne z siecią korpora-
cyjną. Wybierzesz właśnie ją, co widać na poniższym zrzucie ekranu. Jeśli na serwerze będziesz
zarządzać wieloma maszynami wirtualnymi, które będą musiały korzystać z różnych sieci fizycz-
nych, być może trzeba będzie na nim zainstalować wiele kart sieciowych:
Po zdefiniowaniu kart sieciowych musimy zdecydować, czy serwer Hyper-V będzie w stanie
obsłużyć migrację na żywo maszyn wirtualnych. To możliwość przeniesienia maszyny wirtualnej
z jednego hosta Hyper-V na inny bez przerywania działania uruchomionych na niej usług.
Jak widać na poniższym zrzucie ekranu, istnieje kilka różnych sposobów skonfigurowania
serwera w celu przygotowania go do obsługi migracji na żywo. Zwróć uwagę na informację
podaną w dolnej części okna, która ostrzega, abyś nie włączał migracji, jeśli planujesz uczynić ten
serwer Hyper-V częścią klastra. W środowiskach klastrowych ustawienia migracji są obsługiwane
na innej warstwie (zobacz rysunek na następnej stronie).
Ostatni ekran, który chciałbym zaprezentować, pozwala wskazać miejsce do przechowywa-

nia danych maszyny wirtualnej. Po utworzeniu maszyny wirtualnej możesz sprawdzić, czym ona
jest z punktu widzenia dysku (biorąc pod uwagę rzeczywiste pliki tworzone dla tej maszyny).
400
Zauważysz, że istnieją dwa kluczowe elementy związane z maszyną wirtualną: plik wirtualnego
dysku twardego (VHD lub VHDX) oraz folder zawierający jej pliki konfiguracyjne.
Jak widać na poniższym zrzucie ekranu, domyślne lokalizacje służące do przechowywania

tych elementów są czymś, czego można było oczekiwać od aplikacji klienckiej instalowanej
na laptopie. Nie spodziewałbyś się jednak, że coś tak zaawansowanego jak serwer Hyper-V
będzie przechowywać główne pliki w folderze Dokumenty udostępnionym dla użytkownika.
Wynika to zapewne stąd, że firma Microsoft nie zna konfiguracji Twojego serwera, więc nie
może zgadywać, gdzie tak naprawdę chciałbyś przechowywać te dane. Proponowana jest więc
wartość, która technicznie jest poprawna, ale prawdopodobnie powinna zostać zmieniona i nie
być wzorem do naśladowania. W wielu serwerach Hyper-V pojawi się dedykowana pamięć
masowa, choćby dodatkowy dysk twardy, na którym administrator określi miejsce służące do
przechowywania plików maszyn wirtualnych. Poświęć więc chwilę na analizę ekranu i zmień
domyślne lokalizacje plików VM (zobacz rysunek na następnej stronie).
Pamiętaj, że używana przez Ciebie wersja systemu Windows Server 2019 określa, ile ma-
szyn wirtualnych będzie można uruchomić na danym hoście. System Server 2019 Standard
pozwala na uruchomienie dwóch maszyn wirtualnych, natomiast edycja Datacenter
umożliwia uruchomienie tylu maszyn, ile może obsłużyć serwer.
401
Użycie przełączników wirtualnych

Po zakończeniu instalacji roli Hyper-V pierwszą Twoją czynnością mogłoby być natychmiastowe
rozpoczęcie tworzenia maszyn wirtualnych. Warto jednak poświęcić chwilę, aby się upewnić, że
opcje sieciowe serwera Hyper-V odpowiadają potrzebom. Podczas procesu instalacji roli wybra-
liśmy fizyczne karty sieciowe, które mają być udostępnione usłudze Hyper-V. Na ekranie
kreatora została wyświetlona informacja, że będziemy tworzyć wirtualny przełącznik dla każdej
z tych kart. Ale jak to wygląda w konsoli? Jakie istnieją możliwości definiowania sieci między
naszymi maszynami wirtualnymi?
Aby odpowiedzieć na te pytania, musimy otworzyć interfejs zarządzania usługą Hyper-V.

Podobnie jak w przypadku każdej innej nowo zainstalowanej roli systemu Windows, również
teraz w menu Tools (Narzędzia) Menedżera serwera pojawi się nowa opcja, Hyper-V Manager
(Menedżer funkcji Hyper-V). Kliknij ją, co spowoduje uruchomienie programu, za pomocą
którego będziesz zarządzać każdym składnikiem środowiska Hyper-V (zobacz pierwszy ry-
sunek na następnej stronie).
Obecnie konsola nie wyświetla zbyt wielu informacji, ponieważ nie mamy jeszcze urucho-
mionych żadnych maszyn wirtualnych. Po prawej stronie okna możesz zauważyć odnośnik
Virtual Switch Manager… (Menedżer przełącznika wirtualnego…). Kliknij go, aby przejść do
ustawień wirtualnych przełączników i sieci (zobacz drugi rysunek na następnej stronie).
Po lewej stronie okna widnieje lista Virtual Switches (Przełączniki wirtualne). W przypadku
mojego serwera na liście mamy tylko jeden przełącznik, nazwany tak jak fizyczna karta sieciowa,
z którą jest połączony. Jest to przełącznik wirtualny, który powstał w trakcie procesu instalacji
roli, gdy wybraliśmy kartę sieciową wykorzystywaną przez hipewizora Hyper-V. Jeśli podczas
instalacji roli wybierzesz wiele kart sieciowych, dostępnych będzie odpowiednio więcej prze-
łączników wirtualnych, z których każdy zostanie połączony z jedną fizyczną kartą sieciową.
402
Każda tworzona maszyna wirtualna będzie używała jednej lub więcej wirtualnych kart siecio-
wych. Wkrótce dowiesz się, że istnieje możliwość wyboru przełącznika, do którego można
taką kartę podłączyć. Jeśli masz do dyspozycji pięć różnych sieci fizycznych, z którymi mogą
się łączyć Twoje maszyny wirtualne, na serwerze Hyper-V możesz użyć pięciu fizycznych
kart sieciowych. Podłączasz każdą z nich do innej sieci, a następnie w konsoli otrzymujesz
pięć przełączników wirtualnych, z którymi łączysz swoje maszyny wirtualne.
Jak widać na powyższym zrzucie ekranu, istnieje przycisk o nazwie Create Virtual Switch
(Utwórz przełącznik wirtualny), którego przeznaczenie jest oczywiste. Za jego pomocą two-
rzymy trzy rodzaje przełączników. Poświęćmy chwilę na omówienie różnic między nimi.
403
Zewnętrzny przełącznik wirtualny

Maszyny wirtualne, które muszą się łączyć z siecią produkcyjną, najczęściej wykorzystują
zewnętrzny przełącznik wirtualny. Jest on powiązany z fizyczną kartą sieciową zainstalowaną
na serwerze Hyper-V. Po wybraniu opcji utworzenia takiego przełącznika pojawia się nowe
okno z kilkoma opcjami konfiguracyjnymi, wśród których jest nawet możliwość zmiany typu
tego przełącznika. Na poniższym zrzucie ekranu zmieniłem nazwę swojego zewnętrznego
przełącznika wirtualnego, aby łatwiej można go było zidentyfikować, gdy w przyszłości zdecy-
duję się dodać do serwera kolejne karty sieciowe:
404
Wewnętrzny przełącznik wirtualny

Wewnętrzne przełączniki wirtualne nie są powiązane z fizyczną kartą sieciową, więc jeśli utwo-
rzysz jeden z nich i podłączysz do niego maszynę wirtualną, nie będzie się mogła ona połą-
czyć z siecią fizyczną istniejącą poza serwerem Hyper-V. Taka konstrukcja odgrywa rolę pośred-
nika między pozostałymi dwoma rodzajami przełączników. Użycie wewnętrznego przełącznika
wirtualnego jest przydatne w sytuacji, gdy chcesz, aby ruch sieciowy maszyny wirtualnej nie
wychodził poza środowisko Hyper-V. Wciąż zapewnia on jednak połączenie między maszynami
wirtualnymi a samym hostem Hyper-V. Innymi słowy, maszyny wirtualne podłączone do we-
wnętrznego przełącznika wirtualnego będą mogły się komunikować wyłącznie ze sobą i z serwe-
rem Hyper-V.
Prywatny przełącznik wirtualny

Prywatny przełącznik wirtualny jest dokładnie tym, co sugeruje jego nazwa: jest prywatny.
Maszyny wirtualne podłączone do tego samego prywatnego przełącznika wirtualnego mogą się
komunikować wyłącznie ze sobą. Nawet serwer Hyper-V nie ma połączenia sieciowego z pry-
watnym przełącznikiem wirtualnym. Laboratorium testowe jest doskonałym przykładem stoso-
wania prywatnych przełączników wirtualnych. Przeanalizujemy je dokładniej za chwilę, gdy
zaczniemy tworzyć własny przełącznik wirtualny.
Tworzenie nowego przełącznika

wirtualnego
Oto przykład, który często wykorzystuję. Używam serwera Hyper-V, który jest fizycznie podłą-
czony do mojej sieci korporacyjnej, dzięki czemu mogę uruchomić nowe maszyny wirtualne,
podłączyć je do zewnętrznego przełącznika wirtualnego i umożliwić im bezpośrednią komuni-
kację z tą siecią. To z kolei pozwala na dołączenie maszyn do domeny i używanie ich w taki
sposób, w jaki używam każdego innego serwera w mojej sieci. Być może musiałbym też utwo-
rzyć maszyny wirtualne, które co prawda powinny się komunikować ze sobą, ale nie mogłyby
mieć połączenia z moją siecią produkcyjną. Dobrym przykładem tego scenariusza w świecie
realnym jest budowa laboratorium testowego. W rzeczywistości zastosowałem to podejście do
wszystkich serwerów, których używaliśmy na potrzeby tej książki. Fizyczny serwer Hyper-V
znajduje się w sieci produkcyjnej, jednak cała domena Contoso i wszystkie działające w niej
maszyny wirtualne mają własną, osobną sieć, która jest całkowicie oddzielona od sieci produk-
cyjnej. Taką funkcjonalność uzyskałem dzięki utworzeniu prywatnego przełącznika wirtualnego.
Pamiętaj, że po podłączeniu maszyn wirtualnych do tego rodzaju przełącznika mogą się one
komunikować z innymi maszynami podłączonymi do niego, ale nie mogą się łączyć z żadnym
obiektem znajdującym się poza nim.
405
W oknie Virtual Switch Manager (Menedżer przełącznika wirtualnego) wybieram rodzaj prze-
łącznika wirtualnego, który chcę utworzyć, w tym przypadku Private (Prywatny), a następnie
klikam przycisk Create Virtual Switch (Utwórz przełącznik wirtualny). Następnie podaję nazwę
nowo tworzonego przełącznika, i od razu mogę podłączyć do niego maszyny wirtualne. Na
poniższym zrzucie ekranu widzimy, że utworzyłem dwa prywatne przełączniki wirtualne:
jeden do podłączenia wewnętrznych kart sieciowych maszyn wirtualnych mojego laboratorium
testowego i drugi, który będzie działał jako jego sieć DMZ:
Implementacja serwera wirtualnego

Jesteśmy gotowi do uruchomienia naszego pierwszego serwera wirtualnego! Podobnie jak
w przypadku przełączników wirtualnych, również proces tworzenia nowej maszyny wirtualnej
jest dość prosty, jednakże po drodze pojawi się kilka zagadnień, które mogą wymagać wyjaśnie-
nia. Zaczynamy od tego samego interfejsu zarządzania, którego używamy do wszystkich
działań związanych z wirtualizacją Hyper-V. Otwórz program Hyper-V Manager (Menedżer
funkcji Hyper-V), a następnie kliknij prawym przyciskiem myszy nazwę swojego serwera
Hyper-V. Z menu wybierz opcję New/Virtual Machine… (Nowe/Maszyna wirtualna…), aby
uruchomić kreatora (zobacz pierwszy rysunek na następnej stronie).
Pierwszy ekran, na którym musimy podjąć pewne decyzje, nosi nazwę Specify Name and Location
(Określanie nazwy i lokalizacji). Podaj nazwę nowej maszyny wirtualnej — jest to dość łatwe.
Pojawi się wówczas jednak pytanie o miejsce do przechowywania tej maszyny. Jeśli podczas
instalacji roli Hyper-V wskażesz poprawną lokalizację domyślną dla wszystkich maszyn
wirtualnych, jest szansa, że nie będziesz musiał jej zmieniać. Ja wybrałem jednak domyślne
406
opcje w trakcie instalowania roli, więc maszyna wirtualna zostałaby umieszczona w katalogu
C:\ProgramData, co nie jest dla mnie zbyt szczęśliwym rozwiązaniem. Zaznaczyłem więc
opcję wyboru, a następnie określiłem lokalizację, w której chciałbym przechowywać swoją
maszynę wirtualną. Na podstawie zrzutu ekranu możemy stwierdzić, że do przechowywania
maszyn wirtualnych używam osobnego dysku, co ogólnie jest dobrą praktyką. Jeszcze lepszym
rozwiązaniem w przypadku bardziej rozległego środowiska byłoby wykorzystanie bezpiecznej
lokalizacji, takiej jak infrastruktura Storage Spaces Direct, do której dostęp odbywałby
się przez sieć:
Następnie musisz zdecydować, czy utworzysz maszynę wirtualną w wersji Generation 1

(Generacja 1) czy Generation 2 (Generacja 2). Tych dwóch opcji nie muszę zbyt szczegółowo
objaśniać, ponieważ dokładne opisy są podane w programie i na poniższym zrzucie ekranu.
407
Jeśli w maszynie wirtualnej ma działać starszy system operacyjny, prawdopodobnie należy

wybrać generację pierwszą w celu zapewnienia zgodności. Jeśli jednak na maszynie wirtualnej
planujesz zainstalować najnowszy system operacyjny, druga generacja będzie lepszym wyborem
ze względu na nowe funkcje i zwiększone bezpieczeństwo:
Teraz określ, ile pamięci chcesz przypisać do maszyny wirtualnej. Pamiętaj, że jest to ustawienie,
które możesz zmienić w przyszłości, dzięki czemu nie musisz się nim zbytnio przejmować.
Ilość pamięci RAM przeznaczonej dla maszyny wirtualnej będzie zależeć od ilości pamięci
RAM dostępnej w systemie hosta Hyper-V oraz od ilości pamięci wymaganej do uruchomienia
ról i usług, które planujesz zainstalować na tej maszynie. W polu Startup memory (Pamięć
początkowa) możesz podać dowolną wartość. Na przykład gdybym chciał zarezerwować
około 2 GB RAM, mógłbym wpisać przybliżoną wartość 2000 MB. Zauważyłem jednak, że
większość osób nadal używa dokładnej wartości podanej w megabajtach, ponieważ zawsze
tak robiono w przypadku sprzętu fizycznego. Zamiast więc zaokrąglać wartość do 2000, zamie-
rzam przydzielić swojej maszynie 2 GB lub 2048 MB pamięci RAM.
Pozostawienie niezaznaczonego pola Use Dynamic Memory for this virtual machine (Użyj
pamięci dynamicznej dla tej maszyny wirtualnej) oznacza, że hiperwizor Hyper-V przeznaczy
2048 MB swojej fizycznie dostępnej pamięci RAM dla tej określonej maszyny wirtualnej.
Niezależnie od tego, czy maszyna wirtualna będzie w danym momencie używać 2048 MB
czy tylko 256 MB, pełne 2 GB zostaną dla niej przeznaczone i będą nieużywane przez inne
składniki serwera Hyper-V. Jeśli jednak zaznaczysz to pole, maszyna wirtualna będzie zabierać
hostowi Hyper-V tylko tyle pamięci, ile faktycznie zużyje. Jeśli wybierzesz wartość 2048 MB,
ale maszyna wirtualna w czasie bezczynności będzie zużywać tylko 256 MB, wówczas zabierze
hostowi Hyper-V tylko 256 MB pamięci RAM (zobacz pierwszy rysunek na następnej stronie).
Następnym ekranem będzie Configure Networking (Konfigurowanie sieci), na którym po

prostu wybierzemy, do jakiego przełącznika wirtualnego zostanie podłączona karta sieciowa
naszej maszyny wirtualnej. Później będziemy mogli dodać kolejne karty sieciowe, ale pod-
czas tworzenia nowej maszyny wirtualnej otrzymujemy pojedynczą kartę i musimy tylko
określić, do jakiego przełącznika powinna zostać podłączona. Tworzony przeze mnie serwer
WWW zostanie na razie podłączony do wewnętrznej sieci korporacyjnej Test Lab, dzięki czemu
408
będę mógł zainstalować aplikację internetową i przetestować ją przed wdrożeniem produkcyj-

nym. Jeśli wyświetlę listę dostępnych połączeń, pojawi się na niej zewnętrzny przełącznik
wirtualny, a także dwa nowe prywatne przełączniki wirtualne, które utworzyłem:
Należy również określić kilka szczegółów związanych z dyskiem twardym nowo tworzonej
maszyny wirtualnej. Najczęściej będziesz używać pierwszej opcji, dzięki której maszyna
otrzyma zupełnie nowy dysk twardy. Masz również możliwość użycia wcześniej utworzonego
dysku wirtualnego, jeśli uruchamiasz system z istniejącego pliku, lub dołączenia dysku
w późniejszym czasie, jeśli nie jesteś jeszcze przygotowany do podjęcia tej decyzji. Pozwólmy,
aby kreator wygenerował nowy wirtualny dysk twardy o domyślnym rozmiarze 127 GB. W polu
Size (Rozmiar) mógłbym podać dowolną wartość, jednak ważne jest, aby pamiętać, że utwo-
rzony dysk nie zajmie od razu obszaru o podanym rozmiarze. Rozmiar dysku będzie tak duży,
jak dużo miejsca maszyna faktycznie zużyje, więc na początku pozostanie wykorzystana tyl-
ko część z podanej wartości. Wspominam o tym, aby zaznaczyć, że liczba, której tu użyjesz,
powinna być większa niż planowany maksymalny rozmiar tworzonego dysku. Pamiętaj, aby
odpowiednio zadbać o właściwe rozmiary dysków, dzięki czemu będzie przestrzeń do rozbudowy
maszyny o nowe aplikacje (zobacz pierwszy rysunek na następnej stronie).
Ostatni ekran kreatora pozwala ustawić parametry systemu operacyjnego, z którym będzie
działać nasza maszyna wirtualna. Inaczej mówiąc, określimy, skąd ten system operacyjny zostanie
zainstalowany. Zamierzam pozostawić opcję domyślną, aby zainstalować system operacyjny
później, dzięki czemu będziemy mogli zobaczyć, co się stanie, gdy na ekranie nie zmienisz
żadnych ustawień (zobacz drugi rysunek na następnej stronie).
409
Uruchamianie maszyny wirtualnej i łączenie się z nią

Utworzyliśmy maszynę wirtualną, którą można zobaczyć w konsoli Menedżera funkcji Hyper-V.
Uruchomienie tej maszyny jest tak proste, jak kliknięcie jej nazwy prawym przyciskiem my-
szy, a następnie wybranie opcji Start (Uruchom). Po wybraniu opcji uruchomienia maszyny
wirtualnej kliknij ją ponownie prawym przyciskiem myszy i wybierz Connect… (Połącz…).
Zostanie otwarte okno konsoli, na którym będziesz mógł obejrzeć proces uruchamiania nowego
serwera:
410
Czego mógłbyś się spodziewać w oknie konsoli po uruchomieniu naszej nowej maszyny wir-
tualnej? Oczywiście komunikatu o błędzie uruchamiania:
Instalowanie systemu operacyjnego

Otrzymujemy komunikat o błędzie uruchamiania, ponieważ w trakcie pracy kreatora nie
określiliśmy żadnego nośnika systemu operacyjnego. Hiperwizor Hyper-V co prawda utworzył
maszynę wirtualną i dysk twardy, ale podobnie jak podczas tworzenia nowego serwera fizyczne-
go, musisz teraz zainstalować na dysku wirtualnym oprogramowanie systemu operacyjnego.
Na szczęście instalacja systemu operacyjnego na maszynie wirtualnej jest jeszcze łatwiejsza
niż instalacja na serwerze fizycznym. Wróć do konsoli Menedżera funkcji Hyper-V, kliknij
prawym przyciskiem myszy nazwę nowej maszyny wirtualnej i przejdź do opcji Settings…
(Ustawienia…).
Na poniższym zrzucie ekranu można zauważyć, że maszyna wirtualna ma napęd DVD, którym
zarządza kontroler IDE 1. Jeśli klikniesz opcję DVD Drive (Napęd DVD), będziesz mógł z ła-
twością wskazać, by do tego napędu podłączono plik ISO. Na dysk twardy serwera Hyper-V
skopiuj więc plik ISO instalatora systemu operacyjnego, który chcesz uruchomić.
Wszystkie swoje pliki ISO umieszczam zazwyczaj w osobnym folderze o nazwie ISO, znajdują-
cym się obok katalogu z maszynami wirtualnymi. Następnie z użyciem przycisku Browse…
(Przeglądaj…) wybieram z tego folderu odpowiedni plik ISO. Podłączanie pliku ISO do maszyny
wirtualnej działa tak samo, jakbyś podłączał prawdziwą płytę instalacyjną DVD do fizycznego
serwera:
411
Po zamontowaniu nośnika uruchom ponownie maszynę wirtualną, a zobaczysz, że instalator

systemu operacyjnego automatycznie się uruchomi (zobacz rysunek na następnej stronie).
Zarządzanie serwerem wirtualnym

Menedżera funkcji Hyper-V użyliśmy do zarządzania przełącznikami wirtualnymi i utworzenia
maszyny wirtualnej. To narzędzie jest bardzo przydatne podczas modyfikowania opcji ma-
szyn wirtualnych, dlatego w codziennej pracy często z niego korzystam. Przyjrzyjmy się, do czego
możesz jeszcze użyć Menedżera funkcji Hyper-V, a także przeanalizujmy inne metody, które
można zastosować do obsługi maszyn wirtualnych utworzonych na serwerze Hyper-V.
412
Menedżer funkcji Hyper-V

Jak wiadomo, Menedżer funkcji Hyper-V jest podstawowym narzędziem służącym do zarządza-
nia serwerem Hyper-V. To przyjazna konsola, która pozwala sprawnie uzyskać informacje o ma-
szynach wirtualnych i umożliwia ich wszechstronną obsługę. Ponieważ używam tylko jednego
serwera, nie wspominaliśmy do tej pory o opcji polegającej na zarządzaniu wieloma serwerami
Hyper-V z jednej konsoli Menedżera funkcji Hyper-V. Podobnie jak w przypadku każdej in-
nej konsoli MMC działającej w świecie firmy Microsoft, również tutaj możesz kliknąć prawym
przyciskiem myszy nazwę Hyper-V Manager (Menedżer funkcji Hyper-V) w lewym górnym
rogu ekranu, a następnie wybrać opcję Connect to Server… (Połącz z serwerem…). Dzięki
temu w jednej konsoli Menedżera funkcji Hyper-V można wyświetlać informacje z różnych
serwerów Hyper-V:
413
Ponadto oprogramowanie Menedżera funkcji Hyper-V może zostać uruchomione na kom-

puterze klienckim. Rolę Hyper-V możesz zainstalować na komputerze z systemem Windows 10,
co przy okazji spowoduje zainstalowanie konsoli zarządzającej. Następnie będziesz mógł użyć
lokalnego Menedżera funkcji Hyper-V działającego w systemie Windows 10 w celu zdalnego
zarządzania serwerami Hyper-V bez potrzeby logowania się na nich.
Niektóre z najbardziej przydatnych opcji są wyświetlane w Menedżerze funkcji Hyper-V po

prawej stronie okna w obszarze o nazwie Actions (Akcje). Wśród nich można wymienić zarządza-
nie przełącznikami wirtualnymi oraz możliwość utworzenia nowej maszyny wirtualnej. Po
uruchomieniu maszyny wirtualnej w menu kontekstowym wyświetlonym po kliknięciu jej
nazwy prawym przyciskiem myszy pojawi się wiele przydatnych funkcji, jak pokazano na
poniższym zrzucie ekranu:
Niektóre z nich są oczywiste, innymi zaś warto się bliżej zainteresować. Użyliśmy już opcji
Connect… (Połącz…) w celu połączenia się z konsolą naszej maszyny wirtualnej. Druga
opcja, Settings… (Ustawienia…), pozwala zmienić wiele parametrów maszyny. Omówimy ją
dokładniej w następnym punkcie. Jednym z najczęstszych powodów, dla których otwieram
414
to menu prawym przyciskiem myszy, są funkcje zasilania maszyn wirtualnych. Istnieją dwie
opcje zasilania: Turn Off… (Wyłącz…) i Shut Down… (Zamknij…). Pierwsza z nich działa jak
naciśnięcie wyłącznika na serwerze, czyli natychmiast odcina zasilanie, co jest niezbyt przyjemne
dla systemu Windows. Inaczej działa druga funkcja, która inicjuje poprawne zamknięcie
systemu — przynajmniej wówczas, gdy na maszynach wirtualnych używasz systemów operacyj-
nych firmy Microsoft. Zamykanie serwera to faktycznie nic wielkiego, ale prawdziwa potęga
tej operacji polega na tym, że możesz jednocześnie zamknąć wiele maszyn wirtualnych. Na
przykład, jeśli uruchomiłem kilkanaście różnych maszyn wirtualnych we wszystkich laborato-
riach testowych, a następnie zauważyłem, że zajmują one zbyt wiele zasobów i powodują
problemy na serwerze Hyper-V, mogę je wszystkie zaznaczyć, kliknąć prawym przyciskiem
myszy, a następnie jednorazowo kliknąć opcję Shut Down…, co natychmiast uruchomi pro-
ces zamykania wszystkich wybranych maszyn wirtualnych. Po zamknięciu lub wyłączeniu
maszyny wirtualnej pojawi się opcja Start (Uruchom). Również w tym przypadku możesz
wybrać wiele serwerów i uruchomić je wszystkie naraz.
Opcja Settings
Szczegółowa modyfikacja ustawień maszyny wirtualnej jest możliwa po kliknięciu jej nazwy
prawym przyciskiem myszy, a następnie wybraniu opcji Settings… (Ustawienia…). W oknie
ustawień możesz zmienić dowolny parametr sprzętowy maszyny wirtualnej, co jest najczęstszym
powodem do jego otwarcia. Natychmiast po tym, jak pojawi się okno ustawień, możesz wybrać
opcję Add Hardware (Dodaj sprzęt), aby dodać sprzęt do maszyny wirtualnej. W tym miejscu
będziesz mógł dodać do swojego serwera wirtualnego więcej kontrolerów dysków twardych
lub kart sieciowych (zobacz pierwszy rysunek na następnej stronie).
Nie jestem pewien, czy widać to dokładnie na powyższym zrzucie ekranu, ale przycisk Add
(Dodaj) jest obecnie nieaktywny. To ważne spostrzeżenie. Wiele zmian można wprowadzać
w locie, gdy maszyna wirtualna jest uruchomiona. Niektórych funkcji nie można jednak wyko-
nać, dopóki maszyna nie zostanie wyłączona. Dodanie sprzętu jest jedną z nich. Jeśli do maszyny
wirtualnej chcesz dodać nowy dysk twardy lub nową kartę sieciową, musisz ją najpierw
zamknąć.
Następnie mamy opcję Memory (Pamięć). Jej obsługa wydaje się dość prosta, nieprawdaż?
Wystarczy wprowadzić ilość pamięci RAM, którą ma wykorzystywać maszyna wirtualna. Chciał-
bym tu podkreślić znaczną poprawę funkcjonalności tej opcji. Począwszy od wersji Windows
Server 2016 możesz dostosować ilość pamięci RAM w trakcie działania maszyny wirtualnej!
W poprzednich wersjach środowiska Hyper-V, by to zrobić, trzeba było zamknąć maszyny
wirtualne. W tej chwili mój serwer WEB3 działa i obsługuje użytkowników, a jednak mogę
wybrać tę opcję i dowolnie zwiększyć ilość pamięci przeznaczoną dla serwera.
Powiedzmy, że wcześniej przydzielona wartość, 2 GB, nie wystarcza już do obsługi aplikacji,
dlatego chciałbym ją zwiększyć do 4 GB. Pozostawiam serwer działający, otwieram ustawie-
nia Menedżera funkcji Hyper-V dla maszyny wirtualnej i w polu RAM wprowadzam wartość
4096 MB (zobacz drugi rysunek na następnej stronie).
415
Ilość przydzielonej pamięci RAM natychmiast się zmienia. Jeśli teraz wyświetlę właściwości
systemu dla serwera WEB3, zauważę, że parametry systemu operacyjnego zostały zaktualizo-
wane, tak że teraz odzwierciedlają zainstalowaną ilość pamięci, czyli 4 GB:
416
Inne przydatne opcje to Processor (Procesor) i Network Adapter (Karta sieciowa). Możesz
określić liczbę procesorów wirtualnych przypisanych do maszyny wirtualnej oraz wagi wydajno-
ści związane z tymi procesorami. Na ekranie dotyczącym karty sieciowej możesz zmienić
wirtualny przełącznik, do którego są podłączone wirtualne karty sieciowe. Często używam tej
sekcji podczas przenoszenia serwerów pomiędzy różnymi lokalizacjami.
Opcja Checkpoints
Ostatnia opcja menu ustawień, którą chciałbym omówić, nazywa się Checkpoints (Punkty
kontrolne). Była ona wcześniej zwana migawkami (ang. snapshots), co moim zdaniem dla więk-
szości z nas ma większy sens. Punkty kontrolne to opcja, którą można uruchomić z Menedże-
ra funkcji Hyper-V przez kliknięcie prawym przyciskiem myszy jednej lub więcej maszyn wirtu-
alnych. Jej działanie polega na utworzeniu dla maszyny wirtualnej migawki z danego
momentu. Można też potraktować punkty kontrolne jako coś, co pozwala na uzyskanie
punktów przywracania dla serwerów. Jeśli przykładowo utworzysz punkt kontrolny we wtorek,
a w środę ktoś dokona na serwerze zmiany konfiguracji, co spowoduje powstanie problemu,
możesz przywrócić stan maszyny z tego wcześniej wykonanego punktu kontrolnego.
417
Istnieje kilka różnych sposobów uruchamiania punktów kontrolnych. Właściwe parametry

techniczne określamy w menu ustawień. Kliknij prawym przyciskiem myszy dowolną maszynę
wirtualną, przejdź do okna Settings, a następnie kliknij zadanie zarządzania o nazwie Checkpoints
(Punkty kontrolne). Na poniższym zrzucie ekranu przedstawiono wygląd ekranu z odpo-
wiednimi opcjami:
Te ustawienia są indywidualnie określane dla każdej maszyny wirtualnej — możesz przykła-

dowo obsługiwać punkty kontrolne w maszynie WEB1 inaczej niż w WEB2. Domyślnie
wybrana jest opcja o nazwie Production checkpoints (Produkcyjne punkty kontrolne). To prefero-
wana metoda szybkiego tworzenia obrazów serwerów, ponieważ jest najbardziej poprawna.
Podczas generowania produkcyjnego punktu kontrolnego środowisko Hyper-V wywołuje
funkcję tworzenia kopii zapasowej systemu Windows w lokalnym systemie operacyjnym
maszyny wirtualnej. Jest to funkcjonalność podobna do zalogowania się na tej maszynie
wirtualnej i ręcznego uruchomienia zadania tworzenia kopii zapasowej systemu operacyjnego.
Pamiętaj, że wykonanie produkcyjnego punktu kontrolnego przez środowisko Hyper-V nie
oznacza, że powstanie dokładna kopia całej maszyny wirtualnej działającej w danej chwili.
418
Zostanie raczej utworzony plik kopii zapasowej, którego można później użyć, aby przywrócić
system operacyjny do stanu z tego momentu. Innymi słowy, produkcyjny punkt kontrolny
przywraca do wcześniejszego stanu sam system Windows, ale nie są w nim uwzględniane
żadne aplikacje i dane, które wciąż się zmieniają na serwerze.
Takich ograniczeń jest pozbawiona druga opcja, o nazwie Standard checkpoints (Standardowe
punkty kontrolne). Polega ona na uproszczonym przechwyceniu maszyny wirtualnej, podobnie
jak w przypadku, gdy kliknie się prawym przyciskiem myszy plik dysku twardego VHDX
i wybierze opcję kopiowania, a następnie wklei ten plik w innym miejscu. Przywracanie
standardowego punktu kontrolnego może być procesem trudniejszym, ponieważ jeśli był on
tworzony, gdy aplikacja na serwerze była w trakcie wykonywania ważnej funkcji, wówczas
przywrócenie spowodowałoby, że funkcja musiałaby kontynuować swoje działanie, co w przy-
padku zapisu do bazy danych mogłoby spowodować problemy.
Gdy już podejmiesz decyzję, jaki rodzaj punktu kontrolnego należy zastosować, jego wywołanie
jest bardzo proste. Po powrocie do głównego ekranu Menedżera funkcji Hyper-V wystarczy
kliknąć maszynę wirtualną prawym przyciskiem myszy, a następnie z menu kontekstowego
wybrać opcję Checkpoint (Punkt kontrolny). Po wykonaniu tej czynności zobaczysz, że w środ-
kowym panelu Menedżera funkcji Hyper-V, w sekcji Checkpoints (Punkty kontrolne), której
być może nawet wcześniej nie zauważyłeś, pojawią się nowe informacje.
W tym miejscu zostanie wyświetlony nowy punkt kontrolny, który właśnie utworzyliśmy. Czeka on
na przywrócenie, jeśli zajdzie taka potrzeba. Kliknięcie tego punktu kontrolnego prawym przyci-
skiem myszy, a następnie wybranie opcji Apply… (Zastosuj…) zainicjuje proces przywracania:
419
Konsola Hyper-V, protokół pulpitu zdalnego (RDP)

czy PowerShell
Co prawda modyfikacje związane ze sprzętem maszyn wirtualnych muszą być wykonywane
za pomocą Menedżera funkcji Hyper-V, jednak nawet codzienne używanie tych serwerów
w swoim środowisku nie musi oznaczać konieczności logowania się do serwera Hyper-V. Jeśli
znajdujesz się w Menedżerze funkcji Hyper-V, możesz szybko i łatwo użyć jego funkcji Connect
(Połącz) w celu uruchomienia konsoli dla danego serwera. Taki rodzaj dostępu przydaje się,
jeśli chcesz coś sprawdzić w ustawieniach BIOS lub poza systemem operacyjnym Windows,
który jest uruchomiony na danej maszynie wirtualnej. Często jednak nie potrzebujesz takiego
poziomu dostępu do konsoli.
Gdy Twoje serwery Windows są maszynami wirtualnymi, znacznie częściej wchodzisz z nimi
w interakcje w taki sam sposób jak w przypadku tradycyjnych serwerów fizycznych. Co
prawda w tym rozdziale uzyskiwałem na początku dostęp do swojego serwera WEB3 za pośred-
nictwem konsoli Hyper-V, ale obecnie, gdy zainstalowałem już na nim system Windows Server
2019 i włączyłem funkcję RDP, nie ma powodu, dla którego nie mógłbym po prostu uruchomić
programu MSTSC i z własnego pulpitu zalogować się na maszynie w standardowy sposób:
To samo dotyczy programu PowerShell lub innego tradycyjnego sposobu uzyskiwania zdalnego
dostępu do usług na dowolnym serwerze. Ponieważ maszyna wirtualna jest podłączona do
sieci i ma zainstalowany system operacyjny serwera, mogę użyć programu PowerShell do zarzą-
dzania nią również z innego serwera lub komputera stacjonarnego. Po skonfigurowaniu sprzętu
i zainstalowaniu systemu operacyjnego na maszynie wirtualnej rzadko się zdarza, że trzeba
użyć konsoli Hyper-V do jej obsługi. Głównym powodem uruchamiania Menedżera funkcji
Hyper-V w celu uzyskania dostępu do maszyny wirtualnej są zmiany na poziomie jej sprzętu,
takie jak dodanie dysku twardego, dostosowanie ilości pamięci RAM lub podłączenie karty
sieciowej do innego przełącznika.
420
Windows Admin Center (WAC)

Nie bez powodu wspominałem kilka razy w tej książce o aplikacji WAC. To nowe, świetne
narzędzie, promowane przez firmę Microsoft jako sposób zarządzania serwerami i interakcję
z nimi. Maszyny wirtualne Hyper-V nie są tu wyjątkiem. Możesz skorzystać z zestawu narzędzi
WAC w celu administrowania maszynami działającymi na Twoich hostach Hyper-V, a także
do zarządzania samymi serwerami hosta.
Chronione maszyny wirtualne

Jeśli w swojej codziennej pracy nie zajmujesz się wirtualizacją Hyper-V, być może nigdy nie
słyszałeś o chronionych maszynach wirtualnych (ang. shielded VMs). Nazwa tej technologii
została całkiem dobrze dobrana, ponieważ wyjaśnia jej funkcjonalność na poziomie podstawo-
wym. Chroniona maszyna wirtualna powinna być taką maszyną, która jest w jakiś sposób
chroniona lub zabezpieczona, nieprawdaż?
Chroniona maszyna wirtualna jest zasadniczo maszyną wirtualną, która jest zaszyfrowana.
Mówiąc dokładniej, sam plik dysku twardego (VHDX) jest szyfrowany przy użyciu funkcji
BitLocker. Brzmi to prosto, ale istnieją pewne ścisłe wymagania. Aby szyfrowanie funkcją
BitLocker działało poprawnie, do maszyny wirtualnej jest wstrzykiwany wirtualny układ TPM
(ang. Trusted Platform Module). Moduły TPM można coraz częściej spotkać na poziomie
sprzętowym, ale w rzeczywistości są one nadal dla większości administratorów tajemniczą,
czarną skrzynką. Chronione maszyny wirtualne można również tak skonfigurować, aby działały
tylko na uprawnionych i zabezpieczonych serwerach hosta, co jest niesamowitą zaletą dla osób
dbających o bezpieczeństwo. Taką możliwość zapewnia zastosowanie kilku różnych opcji
zaświadczeń, które wkrótce omówimy.
Aby lepiej wyjaśnić korzyści ze stosowania chronionych maszyn wirtualnych, zastanówmy

się nad tym, co może się stać, gdy takie maszyny nie są zabezpieczone. Pamiętaj, że zastosowanie
idei chronionych maszyn wirtualnych jest o wiele ważniejsze w przypadku serwerów
umieszczonych w chmurze publicznej lub prywatnej, ponieważ nie masz wówczas dostępu
do realnego sprzętu. Jeśli jeszcze nie wdrożyłeś chronionych maszyn wirtualnych w swoim
środowisku, chciałbym zaprezentować funkcjonalność, która jest obecnie dostępna dla dowolnej
z Twoich istniejących maszyn wirtualnych.
Wiesz już, że korzystam z serwera Hyper-V, na którym zdefiniowałem maszynę wirtualną

o nazwie WEB3. A teraz załóżmy, że jestem dostawcą usług w chmurze, a WEB3 to serwer
sieciowy dzierżawiony przez jedną z firm. Udostępniłem więc swojemu najemcy prywatny
przełącznik wirtualny, aby mógł zarządzać parametrami sieciowymi maszyny, więc obecnie
nie mam do niej dostępu na poziomie sieci. Ponadto serwer WEB3 jest dołączony do domeny
i sieci mojego najemcy, a ja, jako dostawca usług chmurowych, absolutnie nie mam poświadczeń
jego domeny ani żadnych innych środków, które mógłbym wykorzystać do faktycznego zalogo-
wania się na tym serwerze.
421
Na razie brzmi całkiem nieźle, zgadza się? Jako najemca z pewnością nie chciałbyś, aby Twój
dostawca chmury miał dostęp do zawartości zarządzanych przez niego maszyn wirtualnych. Nie
podobałoby Ci się też, gdyby inni dzierżawcy, których maszyny wirtualne działałyby na tym
samym serwerze w chmurze, mogli mieć jakikolwiek dostęp do Twoich serwerów. Ta sama
zasada obowiązuje w przypadku chmur prywatnych. Jeśli zarządzasz chmurą prywatną i zezwa-
lasz różnym firmom lub oddziałom na uruchamianie maszyn wirtualnych w tej samej infra-
strukturze, chciałbyś się upewnić, że są one odizolowane od siebie, a także od samego hosta.
A teraz dla zabawy zmienię się w złoczyńcę. Jestem nieuczciwym pracownikiem w firmie
będącej dostawcą usług chmurowych i postanawiam wyrządzić szkody, zanim się z niej zwolnię.
Najłatwiej byłoby oczywiście całkowicie usunąć serwer WEB3, ponieważ mam dostęp do
konsoli administracyjnej. Jednak prawdopodobnie zostałoby to od razu zauważone, a firma
dzierżawiąca po prostu uruchomiłaby nowy serwer WWW lub przywróciła go z kopii zapasowej.
Zamiast więc usuwać maszynę, zamierzam ją pozostawić działającą, ale zmienię zawartość
samej witryny. Niech klienci tej firmy będą mieli okazję do plotek!
Aby zmienić witrynę firmy dzierżawiącej serwer WEB3, nie potrzebuję żadnych uprawnień
do samej maszyny wirtualnej, ponieważ mam już bezpośredni dostęp do pliku wirtualnego
dysku twardego. Powinienem się tylko podłączyć do tego pliku VHD, zmodyfikować witrynę
i przez to sprawić, by wyświetlała dowolne informacje.
Najpierw loguję się na serwerze Hyper-V (pamiętaj, że to moja własność, ponieważ jestem
dostawcą usług i zarządzam wirtualizacją), a następnie znajduję lokalizację pliku VHD, którego
używa maszyna WEB3. Wszystko to dzieje się w infrastrukturze technicznej, więc nie potrze-
buję żadnych danych uwierzytelniających najemcy. Co więcej, żadne moje działanie nie jest
rejestrowane, więc najemca nie będzie w żaden sposób wiedział, że coś robię z jego maszyną.
Po prostu klikam prawym przyciskiem myszy odnaleziony dysk VHD i wybieram opcję Mount
(Zamontuj):
Gdy już dysk VHD został podłączony bezpośrednio do systemu operacyjnego serwera hosta,
mogę go przeglądać w taki sposób, jakby był on jednym z moich własnych dysków. Prze-
chodzę do folderu wwwroot zawierającego pliki witryny, a następnie zmieniam domyślną
stronę, aby wyświetlała wybraną przeze mnie treść:
422
Po zakończeniu działań mogę otworzyć narzędzie Disk Management (Zarządzanie dyskami),

kliknąć prawym przyciskiem myszy zamontowany dysk i wybrać opcję Detach VHD (Odłącz
VHD), aby posprzątać po sobie:
A później, dla zabawy, kopiuję cały plik VHD na urządzenie USB, aby móc zabrać go ze sobą
i jeszcze bardziej popsuć.
423
Czy chciałbyś teraz umieszczać swoje maszyny wirtualne w chmurze? Ten przykład pokazuje,
dlaczego tak wiele firm boi się wykonać ten pierwszy krok w kierunku usługi chmurowej —
poziom bezpieczeństwa takiego środowiska jest nieokreślony. Na szczęście firma Microsoft
stara się wyeliminować tę lukę w zabezpieczeniach dzięki nowej technologii zwanej chroniony-
mi maszynami wirtualnymi.
Szyfrowanie dysków VHD

Rozwiązanie stojące za chronionymi maszynami wirtualnymi jest dość proste. Firma Microsoft
stworzyła świetną technologię o nazwie BitLocker służącą do szyfrowania dysków. Chronione
maszyny wirtualne to po prostu standardowe maszyny wirtualne Hyper-V z włączonym szy-
frowaniem dysków za pomocą funkcji BitLocker. Ponieważ cały dysk jest chroniony i szyfrowany,
nikt nie będzie mógł uzyskać do niego dostępu podstępem. Próba zamontowania dysku
VHD, tak jak właśnie to zrobiliśmy, spowodowałaby tylko wyświetlenie komunikatu o błędzie:
Co ciekawsze, odpowiednie skonfigurowanie infrastruktury w celu obsługi chronionych ma-

szyn wirtualnych powoduje, że zabraniasz także dostępu do nich poprzez konsolę Hyper-V.
Chociaż ta funkcjonalność nie jest już tak znacząca jak szyfrowanie dysków, wciąż jest wystar-
czająco ważna, aby zwrócić na nią uwagę. Jeśli ktoś ma dostęp do serwera hosta Hyper-V
i otwiera Menedżera funkcji Hyper-V, zazwyczaj może skorzystać z funkcji Connect (Połącz),
aby podłączyć się do dowolnej maszyny wirtualnej należącej do firmy dzierżawiącej i wyświetlić
to, co w danym momencie dzieje się na konsoli. Najprawdopodobniej taka osoba zobaczy
tylko ekran logowania, którego, miejmy nadzieję, nie będzie w stanie obejść. Gdyby jednak
konsola tej maszyny wirtualnej była pozostawiona w stanie zalogowanym, można byłoby jej
użyć do zmodyfikowania systemu, nawet jeśli sam dysk byłby zaszyfrowany. Kiedy więc
tworzysz chronioną maszynę wirtualną, nie tylko będzie ona miała dysk VHD zaszyfrowany
za pomocą technologii BitLocker, ale także zostanie zablokowany dostęp do jej konsoli z poziomu
Menedżera funkcji Hyper-V.
Czy ten wysoki poziom ochrony może przeszkadzać podczas poprawnego rozwiązywania
problemów związanych z daną maszyną wirtualną? Co powinieneś zrobić w przypadku, gdybyś
musiał użyć konsoli Hyper-V, aby się dowiedzieć, dlaczego maszyna wirtualna nie chce się uru-
chomić lub ma jakąś inną awarię? Tak, to ważne zagadnienie, które należy wziąć pod uwagę.
Chronione maszyny wirtualne mają znacznie zwiększony poziom bezpieczeństwa — do tego
stopnia, że w rzeczywistości traci się możliwość rozwiązywania problemów, które ich doty-
czą. Jak to często bywa w świecie IT, wymieniamy użyteczność na bezpieczeństwo.
424
Wymagania dotyczące infrastruktury

dla chronionych maszyn wirtualnych
Jeśli chcesz wdrożyć chronione maszyny wirtualne, musisz pamiętać o kilku ważnych
wymaganiach.
Hosty zabezpieczone
Aby zarządzać chronionymi maszynami wirtualnymi, będziesz musiał wdrożyć jeden lub
więcej hostów zabezpieczonych (ang. guarded hosts). Można powiedzieć, że są to serwery
Hyper-V na sterydach. Będą zarządzać maszynami wirtualnymi, jak każdy inny serwer Hyper-V,
ale zostaną specjalnie przygotowane i skonfigurowane do obsługi zaszyfrowanych dysków
należących do chronionych maszyn wirtualnych oraz informowania o swoim stanie w ramach
ogólnej strategii bezpieczeństwa.
Hosty zabezpieczone muszą używać systemu Datacenter Server 2016 lub Datacenter Server
2019. Ogólnie rzecz biorąc, powinny się uruchamiać przy użyciu interfejsu UEFI i zawierać
układ TPM 2.0 (nie jest on co prawda wymagany, ale z pewnością zalecany).
Hosty zabezpieczone zastępują tradycyjne serwery Hyper-V. Ich zadaniem jest przechowywanie
maszyn wirtualnych i zarządzanie nimi.
Usługa ochrony hosta

Usługa ochrony hosta (ang. Host Guardian Service — HGS) to usługa działająca na serwerze
lub częściej w klastrze trzech serwerów, która zaświadcza o właściwym stanie hostów za-
bezpieczonych. Gdy chroniona maszyna wirtualna próbuje się uruchomić, host musi się naj-
pierw skontaktować z usługą HGS i poświadczyć, że jest bezpieczny. Dopiero gdy host
otrzyma od usługi HGS pozytywne poświadczenie swojego stanu, będzie można na nim uru-
chomić chronioną maszynę wirtualną.
Usługa HGS ma zasadnicze znaczenie dla działania chronionej infrastruktury. Jeśli ulegnie
ona awarii, żadna z chronionych maszyn wirtualnych nie będzie mogła się uruchomić!
Wymagania dotyczące usługi HGS różnią się w zależności od trybu poświadczenia, z które-
go będą korzystać hosty zabezpieczone. O tych trybach dowiesz się w następnej części tego
rozdziału. Usługa HGS musi zostać uruchomiona w systemie Server 2016 lub Server 2019,
a oprócz tego zalecane jest używanie serwerów fizycznych działających w klastrze o trzech
węzłach.
Chciałbym również zwrócić uwagę na funkcję związaną z usługą HGS, która pojawiła się w sys-
temie Windows Server 2019 — mam na myśli pamięć podręczną HGS. Ograniczeniem
chronionych maszyn wirtualnych we wcześniejszym systemie Server 2016 było to, że z usługą
HGS trzeba było się kontaktować za każdym razem, gdy host zabezpieczony chciał uruchomić
jedną z nich. Może to stać się problematyczne, jeśli usługa HGS będzie niedostępna z jakiegoś
tymczasowego powodu. Nowością w wersji Server 2019 jest pamięć podręczna HGS
425
przechowująca klucze maszyn wirtualnych. Dzięki temu host zabezpieczony może od razu
uruchamiać maszyny wirtualne na podstawie ich kluczy zawartych w pamięci podręcznej,
zamiast łączyć się za każdym razem z usługą HGS. Może to być pomocne, jeśli usługa HGS
jest wyłączona (chociaż stan, w którym usługa HGS nie działa, prawdopodobnie oznacza, że
masz duże problemy). Użycie pamięci podręcznej HGS ma większy sens w przypadku zdalnych
oddziałów, w których host zabezpieczony ma niewydajne połączenie sieciowe z usługą HGS.
Poświadczenia hosta
Poświadczenie hostów zabezpieczonych jest kluczem do wdrożenia chronionych maszyn
wirtualnych. Jest to podstawowe wymaganie bezpieczeństwa w przypadku, jeśli chciałbyś
wdrożyć takie rozwiązanie we własnym środowisku. Zdolność hostów do potwierdzania
swojego stanu i tożsamości zapewnia Ci spokojną pracę, ponieważ wiesz, że nie zostały one
zmodyfikowane bez Twojej wiedzy. Chroni Cię również przed skopiowaniem przez złośliwego
pracownika wszystkich plików dysków twardych należących do maszyn wirtualnych, które
to pliki mógłby następnie zabrać do domu i uruchomić. Chronione maszyny wirtualne będą
działać wyłącznie na hostach zabezpieczonych i nigdzie indziej.
Istnieją dwa różne tryby, które może wykorzystywać host zabezpieczony w celu przekazania
poświadczenia z usługi HGS. Prawdę mówiąc, są trzy tryby, ale jeden z nich jest już przestarzały.
Poświęć chwilę na dokładniejsze zapoznanie się z nimi.
Poświadczenia zaufane TPM

To optymalna opcja! Moduły TPM to fizyczne układy zainstalowane na płytach głównych
serwera, zawierające unikatowe informacje. Co najważniejsze, nie można tych informacji zmo-
dyfikować ani w jakikolwiek sposób się do nich włamać z poziomu systemu operacyjnego
Windows. Gdy hosty zabezpieczone zostaną wyposażone w układy TPM 2.0, umożliwi to
wygenerowanie niesamowicie potężnego poświadczenia. Host wykorzystuje funkcję Secure Boot
i pewne metody kontroli integralności kodu przechowywane w module TPM w celu sprawdze-
nia, czy jest sprawny i nie został zmodyfikowany. Usługa HGS porównuje następnie infor-
macje przesyłane z układu TPM z danymi o początkowej konfiguracji serwera, aby się upewnić,
że maszyna żądająca jest naprawdę jednym z zatwierdzonych hostów zabezpieczonych i nie
została zmodyfikowana. Jeśli konfigurujesz nowe serwery Hyper-V, upewnij się, że zawierają
układy TPM 2.0, abyś mógł skorzystać z ich poświadczeń.
Poświadczenia klucza hosta

Jeśli moduły TPM Cię nie interesują lub są poza możliwościami Twojego sprzętu, możesz
wygenerować prostsze poświadczenie dotyczące klucza hosta. Możliwość generowania przez
hosty zabezpieczone klucza, który może być znany usłudze HGS i przez nią weryfikowany,
jest nowością w systemie Windows Server 2019. Do sprawdzania stanu hostów zabezpieczonych
wykorzystywana jest technologia asymetrycznej pary kluczy. Ogólnie mówiąc, będziesz musiał
utworzyć nową parę kluczy hosta lub użyć istniejącego certyfikatu. Następnie prześlesz publiczny
składnik klucza lub certyfikatu do usługi HGS. Gdy hosty zabezpieczone będą chciały urucho-
426
mić chronioną maszynę wirtualną, za pomocą usługi HGS postarają się uzyskać poświadczenie,
które zostanie zatwierdzone lub odrzucone na podstawie pary kluczy.
Jest to z pewnością szybszy i łatwiejszy sposób, aby chronione maszyny wirtualne stały się
rzeczywistością w Twojej sieci, jednak to rozwiązanie nie jest tak bezpieczne jak poświadczenia
zaufane TPM.
Poświadczenia zaufane administratora

— opcja przestarzała w systemie Server 2019
Jeśli Twoje środowisko jest zupełnie nowe i oparte na systemie Server 2019, nie zwracaj na
tę opcję żadnej uwagi. Jednak wciąż są osoby, które korzystają z chronionych maszyn wirtual-
nych w infrastrukturze systemu Windows Server 2016. W takim przypadku dostępna jest dodat-
kowa opcja uzyskiwania poświadczeń. To bardzo prosta (i niezbyt bezpieczna) metoda, znana
pod nazwą poświadczeń zaufanych administratora, która umożliwia hostom zabezpieczonym
informowanie usługi HGS, że są zatwierdzone. Ogólnie rzecz biorąc, musiałeś utworzyć grupę
zabezpieczeń Active Directory (AD) i dodać do niej hosty zabezpieczone. Wówczas usługa
HGS uznawała, że każdy host, który był częścią tej grupy, jest zaufany i zdolny do uruchamiania
chronionych maszyn wirtualnych.
Integracja z systemem Linux

Różne firmy używają systemu Linux w mniejszym lub większym zakresie. System ten fak-
tycznie może być już gotowy do bliższej współpracy ze środowiskiem Windows Server od
momentu, gdy w wersji Server 2019 pojawiła się możliwość wyższego poziomu integracji.
Istnieje kilka metod używania maszyn wirtualnych z systemem Linux na serwerze wyposażonym
w środowisko Windows Server 2019:
 Uruchamianie w środowisku Hyper-V: kiedyś maszyny wirtualne obsługiwane
przez serwer Hyper-V musiały zawierać system operacyjny Windows. To się
zmieniło. Host wirtualizacji Hyper-V został ulepszony i obecnie w Menedżerze
funkcji Hyper-V można uruchamiać maszyny wirtualne z systemem Linux.
Integrują się one poprawnie nawet z klawiaturą i myszą!
 Chronione maszyny wirtualne z systemem Linux: w tym rozdziale dowiedziałeś
się już o możliwości uruchamiania w środowisku Hyper-V chronionych maszyn
wirtualnych, a także maszyn opartych na systemie Linux. Czy to oznacza, że
możemy połączyć te dwa pomysły i uruchomić maszynę wirtualną z systemem
Linux, która również będzie chroniona? Jak najbardziej. Ta funkcjonalność została
wprowadzona w systemie Windows Server 1709 i jest również dostępna w najnowszej
wersji LTSC systemu Windows Server 2019.
 Uruchamianie w kontenerach: mimo że większość administratorów serwerów
i środowisk Hyper-V nie będzie za bardzo chętna do instalowania systemu Linux
na swoich serwerach, ponieważ po prostu nie będzie miała ku temu żadnych
powodów, na pewno bardziej podekscytowani tym zagadnieniem będą inżynierowie
427
DevOps. Tworząc skalowalne aplikacje przeznaczone dla chmury, często planujemy

uruchamianie ich w kontenerach. W przeszłości zarządzanie kontenerami w systemie
Windows Server oznaczało, że również sam kontener musiał mieć zainstalowane
wyłącznie środowisko Windows. Obecnie możesz mieć kontenery oparte na systemie
Linux i przechowywać je w systemie Windows Server 2019. Zapewnia to dużą
elastyczność w procesie tworzenia aplikacji i będzie ważnym czynnikiem wspierającym
rozwój kontenerów.
Deduplikacja w systemie Resilient File

System (ReFS)
Chociaż system plików z funkcją deduplikacji to technologia, której nie można się spodziewać
w przypadku wirtualizacji Hyper-V, ulepszenia w środowisku Server 2019 związane z systemem
plików ReFS i deduplikacją danych przynoszą ogromne korzyści dla serwerów Hyper-V. Poświęć
zatem chwilę na zapoznanie się z tymi dwoma zagadnieniami.
System plików ReFS

Każdy, kto przez jakiś czas używał komputerów, wie, co oznaczają nazwy FAT, FAT32 i NTFS.
Są to systemy plików, które mogą być używane do formatowania dysków twardych. Różne
wersje systemów plików zapewniają różne możliwości wykorzystania dysku twardego. Od wielu
lat system NTFS jest de facto standardem dla wszystkich dysków twardych podłączonych do
komputerów ze środowiskiem Windows.
W rzeczywistości tak było, dopóki nie pojawił się system Windows Server 2016. Jest obec-
nie dostępny nowy typ systemu plików o nazwie Resilient File System (ReFS). Nawet jeśli
od dawna pracujesz w dziale IT, być może nigdy o nim nie słyszałeś, ponieważ do tej pory
nie jest zbyt często wykorzystywany. Stosuje się go głównie w serwerach używających infra-
struktury Storage Spaces Direct (S2D). Jeśli więc jest to najnowszy i najlepszy system plików
firmy Microsoft, dlaczego nie jest domyślną opcją w nowych systemach? Przede wszystkim
dlatego, że nie można go używać w dyskach rozruchowych. To natychmiast eliminuje moż-
liwość wdrożenia systemu ReFS na całym dysku w przypadku systemów z jednym dyskiem
twardym. Oznacza to, że ReFS dotyczy woluminów dodatkowych, w tym takich, które są
przeznaczone do przechowywania dużych ilości danych.
W przypadku gdy formatujesz drugi wolumin w systemie ReFS, a następnie przechowujesz

na nim dane, wykorzystanie tego nowego systemu plików ma w porównaniu z systemem NTFS
pewne zalety związane z odpornością na awarie i wydajnością. Te cechy mają usprawnić imple-
mentację infrastruktury S2D.
428
Deduplikacja danych
Deduplikacja danych to po prostu zdolność systemu komputerowego do wykrywania wielu
takich samych sekwencji danych na dysku, a następnie ich usuwania. Gdyby w systemie
było sześć dokładnych kopii tego samego pliku, deduplikacja mogłaby usunąć pięć z nich,
zachowując tylko jedną wersję i udostępniając ją we wszystkich sześciu lokalizacjach. Taka
funkcjonalność pozwala na znaczną oszczędność miejsca na dysku. Nie jest to jednak nowy
pomysł, ponieważ został już zaimplementowany w wersji Server 2012.
Windows Server 2019 jest pierwszą platformą, w której przypadku można włączyć deduplikację
danych na woluminie sformatowanym w systemie ReFS.
Dlaczego jest to ważne dla środowiska Hyper-V?

Deduplikacja danych może być niezwykle korzystna w przypadku woluminu przechowują-
cego pliki dysków twardych maszyn wirtualnych Hyper-V. Można sobie wyobrazić, że jeśli takich
maszyn jest wiele, jest także bardzo dużo takich samych danych. Weź pod uwagę choćby
pliki systemu operacyjnego Windows, które będą identyczne dla wszystkich maszyn wirtualnych
działających na hoście Hyper-V. Jest całkiem oczywiste, dlaczego korzystne byłoby włącze-
nie deduplikacji danych na woluminie, w którym są przechowywane pliki VHDX.
Ponieważ system ReFS w porównaniu z NTFS ma pewne zalety związane z odpornością na awa-
rie i wydajnością, dlatego najlepiej byłoby, gdyby pliki VHDX były przechowywane na wo-
luminie ReFS.
Windows Server 2019 to pierwsza platforma, która pozwala Ci mieć ciastko, a zarazem je zjeść.
Obecnie możemy utworzyć wolumin ReFS do przechowywania dysków twardych maszyn
wirtualnych, a także włączyć na nim deduplikację danych.
Środowisko Hyper-V Server 2019

Bardzo szybko można się zacząć cieszyć wirtualizacją. Weź jakiś sprzęt, zainstaluj na nim
Windows Server 2019, zaimplementuj rolę Hyper-V, i to wszystko! Jesteś gotowy, aby w swoim
środowisku rozpocząć wdrażanie setek maszyn wirtualnych… Czy rzeczywiście mam rację?
Niekoniecznie. Nie wspominałem jeszcze o licencjonowaniu. Zbyt często nasze możliwości

techniczne są ograniczone wymogami licencyjnymi. To samo dotyczy Hyper-V. Każda maszyna
wirtualna, którą uruchamiasz, musi mieć własną licencję na system operacyjny. Ten wymóg
ma sens. Nie jest już jednak tak oczywiste, że na serwerze Hyper-V możesz uruchomić tylko
określoną liczbę maszyn wirtualnych, w zależności od tego, jakiej wersji systemu używasz
dla hosta.
429
Największym problemem jest to, że użycie systemu Windows Server 2019 Standard Edition
jako serwera Hyper-V spowoduje, że będziesz w stanie uruchomić dwie maszyny wirtualne.
Tylko dwie i nic więcej! Jasne jest, że wersja systemu Standard Edition nie została zapro-
jektowana, by być serwerem Hyper-V.
Pozostaje więc wersja Windows Server 2019 Datacenter Edition. Na szczęście pozwala ona
na uruchamianie nieograniczonej liczby maszyn wirtualnych! To dobra wiadomość! Z wyjątkiem
jednego drobiazgu — Datacenter Edition może kosztować nawet kilkadziesiąt tysięcy złotych.
Jest to bardzo ograniczający czynnik przy wdrażaniu serwerów Hyper-V.
Cała ta dyskusja na temat licencjonowania i tego, jak drogie i skomplikowane może ono być,
prowadzi do jednego wniosku: Hyper-V Server 2019. Moment, przecież o tym cały czas piszemy
w tym rozdziale! Czy nie jest to tylko Windows Server 2019 z zainstalowaną rolą Hyper-V?
Nie, wcale nie.
Hyper-V Server 2019 jest samodzielną wersją systemu operacyjnego. Ma własnego instalatora
i zupełnie inny interfejs użytkownika niż tradycyjny serwer. Zainstalowanie na urządzeniu
systemu Hyper-V Server 2019 spowoduje, że serwer będzie mógł obsługiwać nieograniczoną
liczbę maszyn wirtualnych Hyper-V, jednakże nie będzie miał żadnej innej funkcjonalności.
Nie będzie go można używać jako serwera ogólnego przeznaczenia do zarządzania innymi rolami
lub usługami. System Hyper-V Server nie ma także graficznego interfejsu użytkownika.
Środowisko Hyper-V Server 2019 ma jedną ogromną zaletę: jest ZA DARMO. Oczywiście,
nadal jesteś odpowiedzialny za licencjonowanie samych maszyn wirtualnych, ale posiadasz
darmowy system operacyjny hosta, który może obsługiwać ich nieograniczoną liczbę. Jest to coś,
co mój portfel na pewno polubi.
Program instalacyjny środowiska Hyper-V Server 2019 nagrałem na płycie DVD (na szczęście
jest niewielki i zmieścił się bez problemu!), a następnie uruchomiłem na swoim sprzęcie.
Instalacja samego systemu operacyjnego przebiegła zupełnie typowo: wszystkie ekrany instalacji
i opcje były takie same, jak gdybym instalował pełną wersję systemu Windows Server 2019.
Gdy instalator zakończył pracę i uruchomiłem system operacyjny Hyper-V Server 2019,
wszystko jednak wyglądało zupełnie inaczej (zobacz rysunek na następnej stronie).
Jest dostępny jedynie wiersz poleceń, w którym automatycznie uruchomiono narzędzie konfigu-
racyjne o nazwie SConfig. Przy użyciu klawiatury mogę zmienić nazwę serwera, dołączyć go
do domeny i skonfigurować ustawienia sieciowe. Po zakończeniu korzystania z tego interfejsu
w celu ustawienia podstawowych parametrów i uzyskania połączenia z siecią nie musisz ponow-
nie uzyskiwać dostępu do konsoli tego serwera, chyba że trzeba byłoby coś zmienić w samej
konfiguracji. Zamiast tego na innym serwerze lub komputerze klienckim podłączonym do sieci
wystarczy użyć Menedżera funkcji Hyper-V lub programu PowerShell, aby zacząć zdalnie
zarządzać maszynami wirtualnymi uruchomionymi na tym urządzeniu.
430
Na poniższym zrzucie ekranu widzimy, że uruchomiłem Menedżera funkcji Hyper-V. Korzystam

z komputera z systemem Windows 10, na którym mam zainstalowaną rolę Hyper-V. Klikam
prawym przyciskiem myszy pole Hyper-V Manager (Menedżer funkcji Hyper-V), a następnie
wybieram opcję Connect to Server… (Połącz z serwerem…). Wprowadzam nazwę nowego
serwera Hyper-V, a konsola tworzy zdalne połączenie. Dzięki temu w swoim komputerze z sys-
temem Windows 10 mogę teraz korzystać ze wszystkich funkcji Hyper-V w taki sposób, jakbym
był zalogowany bezpośrednio na nowym serwerze (zobacz rysunek na następnej stronie).
Do obsługi środowiska Hyper-V Server i administrowania nim służy zdalna konsola Menedżera
funkcji Hyper-V. Jest to rozwiązanie podobne do tego, które stosuje się w przypadku zdalnego
zarządzania wersjami Server Core lub Nano Server przy użyciu konsoli lub programu
PowerShell.
System Hyper-V Server zapewnia wzrost poziomu bezpieczeństwa wynikający z zastosowania

tekstowego interfejsu użytkownika oraz możliwość zarządzania nieograniczoną liczbą maszyn
wirtualnych w cenie, z którą nie sposób dyskutować!
431
Podsumowanie
Co prawda nie dysponuję oficjalnymi statystykami, ale zaryzykuję i stwierdzę, że obecnie
działa już więcej serwerów wirtualnych niż fizycznych. Dzięki temu nasz świat się kręci. Wciąż
trwa bitwa o miano najlepszej platformy wirtualizacji. Zazwyczaj chodzi o wybór pomiędzy
rozwiązaniami Hyper-V i VMware. Nie można jednak zignorować tego, że wirtualizacja jest
przyszłością środowisk IT. Firma Microsoft poświęca wiele czasu i zasobów, aby rozwiązanie
Hyper-V zawsze wyprzedzało konkurencję, i z każdym nowym wydaniem wprowadza do
niego coraz więcej funkcji, dzięki czemu Twoja zwirtualizowana infrastruktura działa bez pro-
blemu przez cały czas. Czy potencjał wirtualizacji w chmurze jest większy niż na lokalnym
serwerze Hyper-V? Myślę, że tak, ponieważ infrastruktura istniejąca u dostawcy usług w chmu-
rze zyskuje coraz więcej możliwości w porównaniu z tym, co pojedyncza firma może zapew-
nić we własnym centrum danych. Czy to oznacza, że możesz całkowicie zapomnieć o Hyper-V
i po prostu skorzystać z serwerów udostępnianych w chmurze? Może kiedyś tak będzie, ale
większość firm nie jest jeszcze gotowa na tak dużą zmianę. Zapotrzebowanie na lokalne serwery
i usługi wciąż jest ogromne, a niektóre branże po prostu nigdy nie pozwolą, aby ich dane i apli-
kacje były zarządzane przez obce firmy. Poznanie możliwości środowiska Hyper-V i umiejęt-
ność stworzenia tej infrastruktury od podstaw daje Ci znaczną przewagę podczas szukania
pracy w organizacji zorientowanej na produkty firmy Microsoft.
I to już koniec naszej historii dotyczącej nowego systemu Windows Server 2019. Wiele
omawianych tematów może być powodem do napisania oddzielnych książek. Mam nadzieję,
że zaprezentowane tu zagadnienia zachęcą Cię do głębszego zapoznania się z technologiami,
które będziesz chciał wykorzystać. Środowiska firmy Microsoft królują w większości centrów
danych na całym świecie. Nowe i zaktualizowane funkcje dostępne w systemie Windows
Server 2019 zapewnią, że trend ten się utrzyma.
432
Pytania
1. Jakie są trzy typy wirtualnych przełączników w środowisku Hyper-V?
2. Jaka generacja maszyny wirtualnej pozwala na jej uruchomienie przy użyciu
systemu UEFI?
3. W środowisku Hyper-V systemu Windows Server 2019 musisz zamknąć maszynę
wirtualną, aby zmienić przydzieloną jej ilość pamięci RAM — prawda czy fałsz?
4. Jedynym sposobem interakcji z maszyną wirtualną jest konsola Hyper-V —
prawda czy fałsz?
5. Jak nazywa się technologia Hyper-V umożliwiająca wykonywanie migawkowych
obrazów maszyn wirtualnych, które można później przywrócić?
6. Jak nazywa się rola, która obsługuje uwierzytelnianie serwerów hosta Hyper-V
podczas uruchamiania chronionych maszyn wirtualnych?
7. Która metoda poświadczeń jest najbardziej wszechstronna w przypadku chronionych
maszyn wirtualnych: poświadczenie klucza hosta, poświadczenie zaufane TPM
czy poświadczenie zaufane administratora?
433
434
Odpowiedzi na pytania
Rozdział 1. Pierwsze kroki w systemie Windows Server 2019

1. Kliknij prawym przyciskiem myszy przycisk Start i wybierz opcję Program
Windows PowerShell (Administrator) z menu szybkich zadań administracyjnych.
2. WinKey+X.
3. Microsoft Azure.
4. Standard i Datacenter.
5. Dwie.
6. Serwer Core.
7. Long-Term Servicing Channel (LTSC).
8. Oba programy są właściwym wyborem, chociaż użycie narzędzia Windows
Settings jest preferowaną metodą dla większości opcji konfiguracyjnych.
Rozdział 2. Instalowanie systemu Windows Server 2019

i zarządzanie nim
1. Windows Admin Center (WAC).
2. Fałsz. Windows Server 2019 można zainstalować na sprzęcie fizycznym
lub w postaci instancji maszyny wirtualnej.
3. Fałsz. Domyślną opcją dla systemu Windows Server 2019 jest Server Core,
który nie ma graficznego interfejsu użytkownika.
4. Get-WindowsFeature | Where Installed.
5. Prawda.
6. Narzędzia administracji zdalnej serwera (RSAT).

7. W czasie pisania tej książki — Microsoft Edge i Google Chrome.
Pamiętaj, że Internet Explorer nie jest obsługiwany.
Rozdział 3. Podstawowe usługi infrastrukturalne

1. Jednostka organizacyjna (OU).
2. Wstępne przygotowanie konta.
3. Lokalizacje i usługi Active Directory.
4. Kontroler domeny tylko do odczytu (RODC).
5. Domyślne zasady domeny.
6. Rekord hosta AAAA (Quad A).
7. DSA.MSC.
Rozdział 4. Certyfikaty w systemie Windows Server 2019

1. Urząd certyfikacji.
2. Główny urząd certyfikacji przedsiębiorstwa.
3. Nie, to nie jest zalecany scenariusz.
4. Nowy szablon certyfikatu musi zostać opublikowany.
5. Automatyczna rejestracja certyfikatu.
6. Klucz prywatny.
7. Żądanie podpisania certyfikatu (CSR).
Rozdział 5. Obsługa sieci w Windows Server 2019

1. 128 bitów.
2. 2001:ABCD:1:2::1.
3. PATHPING.
4. Fałsz. Może to spowodować problemy z routingiem. W systemie powinien zostać
zdefiniowany tylko jeden adres domyślnej bramy, bez względu na to, ile kart
sieciowych jest w serwerze.
5. New-NetRoute.
6. Windows Server 2019, 2016 i 2012 R2.
436
Odpowiedzi na pytania
Rozdział 6. Użycie opcji zdalnego dostępu

1. Always On VPN.
2. IKEv2 i SSTP.
3. Windows 10 1607.
4. Gdy chcesz skorzystać z tunelu urządzeń AOVPN.
5. Nie, Twoja sieć wewnętrzna może być całkowicie w wersji IPv4.
6. Network Location Server (NLS).
7. Serwer WAP może zostać zaimplementowany jako serwer proxy ADFS.
Rozdział 7. Hardening i bezpieczeństwo

1. Windows Defender Antivirus.
2. Profil domeny.
3. Publiczny i prywatny.
4. ICMPv4.
5. Zasady grupy.
6. Chroniona maszyna wirtualna.
7. Zaawansowana analiza zagrożeń.
Rozdział 8. Server Core

1. Prawda.
2. Fałsz. Zmiana wersji nie jest możliwa w systemie Windows Server 2019.
3. Wiersz poleceń.
4. Get-NetIPConfiguration.
5. Rename-Computer.
6. PowerShell, Menedżer serwera, RSAT i Windows Admin Center.
7. Sconfig.exe.
Rozdział 9. Redundancja w systemie Windows Server 2019

1. Równoważenie obciążenia sieciowego.
2. Dedykowany adres IP i wirtualny adres IP.
3. Tryb emisji pojedynczej, tryb multiemisji i tryb multiemisji IGMP.
4. NLB to funkcja.
5. Hyper-V i usługi plikowe.
437
6. Pamięć USB.
7. Fałsz, w technologii S2D możesz używać dowolnego rodzaju dysków twardych.
Rozdział 10. PowerShell

1. Po prostu wprowadź słowo powershell i naciśnij klawisz Enter.
2. Get-Command.
3. Enter-PSSession.
4. Rozszerzenie .PS1.
5. RemoteSigned.
6. Klawisz Tab.
7. Usługa WinRM.
Rozdział 11. Kontenery i Nano Server

1. Server Core lub Nano Server.
2. Kontener Hyper-V.
3. Fałsz. Możliwość uruchamiania kontenerów Windows i Linux istnieje od wersji
systemu Windows Server 2019.
4. docker images.
5. Kubernetes.
6. Prawda.
Rozdział 12. Wirtualizacja centrum danych

za pomocą hiperwizora Hyper-V
1. Zewnętrzne, wewnętrzne i prywatne.
2. Generacja 2.
3. Fałsz. Możesz na bieżąco dostosowywać ilość pamięci RAM maszyny wirtualnej.
4. Fałsz. Po zainstalowaniu systemu operacyjnego maszyny wirtualnej możesz się
z nim komunikować za pomocą innych, tradycyjnych metod administracyjnych,
takich jak protokół RDP.
5. Punkty kontrolne.
6. Host Guardian Service.
7. Poświadczenie zaufane TPM.
438

Windows Server 2019 Dla Profesjonalistow Wydanie II Jordan Krause Helion

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Windows Server 2019 Dla Profesjonalistow Wydanie II Jordan Krause Helion

Uploaded by

Copyright:

Available Formats

Wydanie II

Tłumaczenie: Jacek Janusz

Copyright © Packt Publishing 2019.

Polish edition copyright © 2020 by Helion SA

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi

• Poleć książkę na Facebook.com • Księgarnia internetowa

Rozdział 1. Pierwsze kroki w systemie Windows Server 2019 19

Używanie funkcji wyszukiwania 36

Rozdział 2. Instalowanie systemu Windows Server 2019 i zarządzanie nim 53

Rozdział 3. Podstawowe usługi infrastrukturalne 91

System nazw domen (DNS) 112

Rozdział 4. Certyfikaty w systemie Windows Server 2019 137

Rozdział 5. Obsługa sieci w Windows Server 2019 175

Polecenie Test-Connection 185

Rozdział 6. Użycie opcji zdalnego dostępu 211

Adresy IP klientów przekazywane do aplikacji 247

Rozdział 7. Hardening i bezpieczeństwo 251

Rozdział 8. Server Core 287

Co się stało z systemem Nano Server? 309

Rozdział 9. Redundancja w systemie Windows Server 2019 313

Rozdział 10. PowerShell 347

Praca z programem PowerShell 351

Rozdział 11. Kontenery i Nano Server 379

Rozdział 12. Wirtualizacja centrum danych za pomocą hiperwizora Hyper-V 397

Zarządzanie serwerem wirtualnym 412

Odpowiedzi na pytania 435

Premnath Sambasivam jest analitykiem technicznym z 6-letnim doświadczeniem w admini-

Wraz ze zmianami na świecie nastąpiły zmiany w infrastrukturze technologicznej. Obecnie wi-

Z perspektywy użytkownika jako konsumenta danych wymagania obliczeniowe dotyczące zaple-

Co zapewnia moc obliczeniową w centrach danych w większości firm na świecie? Windows

Aby uczynić moc obliczeniową bardziej uniwersalną i przystosowaną do chmury, Microsoft

Dla kogo jest przeznaczona ta książka?

i należy o nich pamiętać, pracując w centrum danych wykorzystującym produkty firmy

Jak w pełni wykorzystać tę książkę?

Konwencje formatowania tekstu

Kursywa: wykorzystywana w przypadku komunikatów, nazw plików i ścieżek, adresów interne-

Trochę wyprzedzam zagadnienia zaprezentowane w tej książce, ponieważ w dalszej części

Poświęćmy kilka minut na zapoznanie się z interfejsem graficznym i dostępnymi opcjami

Cel systemu Windows Server

Skąd te dane są pobierane i dokąd są przesyłane? Co umożliwia mechanizmom i aplikacjom

Tradycyjnie uważamy, że serwery wykorzystują architekturę klient-serwer. Użytkownik otwiera

W większości organizacji istnieje potrzeba zdefiniowania różnych serwerów, aby zapewnić

Możesz porównać role do mięsa i ziemniaków dostępnych na serwerze, jednakże następnym

Robi się pochmurno

Wersje systemu Windows Server

Wersje Standard i Datacenter

Desktop Experience, Server Core, Nano Server

Wygląda na to, że zainteresowanie platformą Nano Server wzrosło w związku z wydaniem

Modele licencjonowania — SAC i LTSC

Kanał obsługi półrocznej (SAC)

używane tylko do uruchamiania kontenerów. W tym nowym świecie uniwersalnego hostingu

Kanał obsługi długoterminowej (LTSC)

Przegląd nowych i zaktualizowanych

System Windows 10 wciąż działa

Nowym narzędziem, które pomaga konfigurować i utrzymywać klastry (włączając w to klastry

Windows Admin Center

Windows Defender Advanced Threat Protection

Omówimy ją dokładniej w rozdziale 7., „Hardening i bezpieczeństwo”, ale można w skrócie

Ulepszona funkcja Shielded Virtual Machines

Azure Network Adapter

Poruszanie się po interfejsie

Okazuje się, że Microsoft wysłuchał użytkowników i odpowiednio zreorganizował interfejs

Uaktualnione menu Start