Remote Desktop Services (RDS) — konfiguracja serwera terminali na Windows Server

Remote Desktop Services (RDS) to fundamentalna rola systemu Windows Server, która umożliwia wielu użytkownikom jednoczesne łączenie się z serwerem i korzystanie z aplikacji oraz pulpitów zdalnych. Dawniej znana jako Terminal Services, technologia ta jest podstawą infrastruktury serwerów terminali w firmach na całym świecie — od małych biur po korporacje z tysiącami pracowników.

W tym kompleksowym przewodniku pokażemy, jak zaprojektować, zainstalować i skonfigurować Remote Desktop Services na Windows Server 2022 i 2019. Omówimy wszystkie role serwera RDS, wymagania licencyjne (w tym licencje RDS CAL), konfigurację RemoteApp, RD Gateway oraz metody zapewnienia wysokiej dostępności. Jeśli planujesz wdrożenie serwera terminali lub chcesz zoptymalizować istniejącą infrastrukturę — ten artykuł jest dla Ciebie.

Co to jest Remote Desktop Services (RDS)?

Remote Desktop Services (wcześniej Terminal Services) to zestaw ról i usług w systemie Windows Server, które umożliwiają użytkownikom zdalny dostęp do pulpitów, aplikacji i danych przechowywanych na serwerze. Zamiast uruchamiać oprogramowanie lokalnie na każdym komputerze, wszystkie operacje wykonywane są na centralnym serwerze — klienci widzą jedynie obraz ekranu przesyłany przez sieć.

RDS ma zastosowanie w wielu scenariuszach:

• Praca zdalna — pracownicy łączą się z firmowym środowiskiem z dowolnego miejsca
• Cienki klient (thin client) — tanie terminale zastępują pełne komputery PC
• Centralizacja aplikacji — jedna instalacja oprogramowania dla wszystkich użytkowników
• BYOD (Bring Your Own Device) — bezpieczny dostęp z prywatnych urządzeń
• Laboratoria szkoleniowe — szybkie udostępnienie jednolitego środowiska
• Compliance i bezpieczeństwo — dane nigdy nie opuszczają serwera

W porównaniu z tradycyjnym modelem, gdzie każdy użytkownik ma własną stację roboczą z zainstalowanym oprogramowaniem, RDS znacząco redukuje koszty administracji, licencjonowania i sprzętu.

Architektura RDS — role serwera

Infrastruktura Remote Desktop Services składa się z kilku wyspecjalizowanych ról. W małych wdrożeniach wszystkie role mogą działać na jednym serwerze, ale w środowiskach produkcyjnych zaleca się ich rozdzielenie na dedykowane maszyny.

RD Session Host (Host sesji pulpitu zdalnego)

RD Session Host to główna rola RDS — serwer, na którym faktycznie uruchamiane są sesje użytkowników. Każdy użytkownik po zalogowaniu otrzymuje własną sesję systemu Windows z izolowanym środowiskiem. Wszystkie aplikacje i procesy działają na zasobach tego serwera (CPU, RAM, dysk).

Kluczowe aspekty RD Session Host:

• Obsługa wielu jednoczesnych sesji użytkowników
• Izolacja sesji — awaria jednego użytkownika nie wpływa na pozostałych
• Współdzielenie zasobów sprzętowych między sesjami
• Możliwość publikowania pełnych pulpitów lub pojedynczych aplikacji (RemoteApp)
• Wymaga licencji Windows Server CAL + RDS CAL dla każdego użytkownika/urządzenia

RD Connection Broker (Broker połączeń)

RD Connection Broker zarządza połączeniami użytkowników i kieruje ich do odpowiednich sesji. W środowisku z wieloma serwerami Session Host, broker równoważy obciążenie i zapewnia, że użytkownik ponownie łączący się trafia do swojej istniejącej sesji (session reconnection).

Funkcje Connection Brokera:

• Load balancing — rozkładanie sesji między serwerami w farmie
• Reconnection — przekierowanie do istniejącej sesji po rozłączeniu
• Zarządzanie kolekcjami — grupowanie serwerów Session Host
• Centralna konfiguracja — jeden punkt zarządzania wdrożeniem RDS

RD Web Access (Dostęp przez przeglądarkę)

RD Web Access udostępnia portal webowy, przez który użytkownicy mogą uruchamiać pulpity zdalne i aplikacje RemoteApp bezpośrednio z przeglądarki. Portal ten wyświetla listę dostępnych zasobów na podstawie uprawnień użytkownika.

Domyślny adres portalu po instalacji: https://serwer/RDWeb

RD Gateway (Brama pulpitu zdalnego)

RD Gateway umożliwia bezpieczny dostęp do wewnętrznej infrastruktury RDS z internetu. Zamiast otwierać port RDP (3389) na firewallu — co stanowi poważne zagrożenie bezpieczeństwa — RD Gateway tuneluje ruch RDP przez protokół HTTPS (port 443).

Główne zalety RD Gateway:

• Szyfrowanie całego ruchu RDP certyfikatem SSL/TLS
• Brak konieczności otwierania portu 3389 na firewallu
• Polityki autoryzacji połączeń (Connection Authorization Policies — CAP)
• Polityki autoryzacji zasobów (Resource Authorization Policies — RAP)
• Integracja z Network Policy Server (NPS) i MFA
• Pełna kompatybilność z NAP (Network Access Protection)

RD Licensing (Serwer licencji)

RD Licensing zarządza licencjami dostępowymi RDS CAL (Client Access License), które są wymagane do legalnego korzystania z sesji pulpitu zdalnego. Każdy użytkownik lub urządzenie łączące się z RD Session Host musi posiadać ważną licencję RDS CAL.

Serwer licencji musi być aktywowany w Microsoft Clearinghouse, a licencje CAL zainstalowane na serwerze licencji. Bez prawidłowej konfiguracji licencji, po upływie 120-dniowego okresu próbnego użytkownicy stracą możliwość łączenia się z serwerem.

Licencje RDS — Per User vs Per Device

Licencjonowanie Remote Desktop Services to jeden z najczęściej źle rozumianych aspektów wdrożenia. Wymagane są dwa poziomy licencji:

RDS CAL Per User (na użytkownika)

Licencja RDS CAL Per User przypisywana jest do konkretnego konta użytkownika w Active Directory. Jeden użytkownik może łączyć się z dowolnej liczby urządzeń — licencja „podąża" za nim.

Najlepszy wybór gdy:

• Pracownicy korzystają z wielu urządzeń (laptop, tablet, telefon)
• Firma wspiera model BYOD
• Liczba użytkowników jest mniejsza niż liczba urządzeń

RDS CAL Per Device (na urządzenie)

Licencja RDS CAL Per Device przypisywana jest do konkretnego komputera lub terminala. Dowolna liczba użytkowników może łączyć się z tego urządzenia.

Najlepszy wybór gdy:

• Wielu pracowników dzieli te same stanowiska (np. praca zmianowa)
• Terminale kiosków lub punktów obsługi
• Liczba urządzeń jest mniejsza niż liczba użytkowników

Wymagania sprzętowe dla serwera RDS

Wydajność serwera terminali zależy bezpośrednio od liczby jednoczesnych sesji i rodzaju uruchamianych aplikacji. Poniżej przedstawiamy rekomendowane wymagania sprzętowe:

Szacunkowa reguła: Przydziel ok. 2 GB RAM i 0.5 rdzenia CPU na każdą sesję użytkownika dla typowych zadań biurowych (Office, przeglądarka, poczta). Dla aplikacji CAD, graficznych lub analitycznych te wartości mogą być 3-5 razy wyższe.

Instalacja RDS na Windows Server 2022

Poniżej przedstawiamy krok po kroku proces instalacji Remote Desktop Services na Windows Server 2022 Standard. Proces jest analogiczny dla Windows Server 2019.

Krok 1: Przygotowanie środowiska

Przed instalacją upewnij się, że spełnione są następujące warunki:

• Serwer jest dołączony do domeny Active Directory
• System operacyjny jest zaktualizowany (Windows Update)
• Serwer ma statyczny adres IP
• DNS wskazuje na kontroler domeny
• Firewall dopuszcza ruch na portach: 3389 (RDP), 443 (HTTPS dla RD Web/Gateway)
• Masz uprawnienia administratora domeny

Krok 2: Instalacja ról RDS przez Server Manager

1. Otwórz Server Manager → Manage → Add Roles and Features
2. Wybierz typ instalacji: Remote Desktop Services installation
3. Wybierz tryb wdrożenia:
   • Quick Start — wszystkie role na jednym serwerze (do testów i małych wdrożeń)
   • Standard Deployment — role rozdzielone między serwery (produkcja)
4. Wybierz scenariusz:
   • Session-based desktop deployment — tradycyjne sesje pulpitu zdalnego
   • Virtual machine-based desktop deployment — VDI (wirtualne pulpity)
5. Wskaż serwery dla poszczególnych ról (Connection Broker, Web Access, Session Host)
6. Potwierdź automatyczny restart i rozpocznij instalację

Krok 3: Instalacja przez PowerShell

Dla administratorów preferujących wiersz poleceń, RDS można zainstalować szybciej za pomocą PowerShell:

# Import modułu Remote Desktop
Import-Module RemoteDesktop

# Utworzenie nowej kolekcji sesji
New-RDSessionDeployment `
    -ConnectionBroker "rdcb.firma.local" `
    -WebAccessServer "rdwa.firma.local" `
    -SessionHost @("rdsh01.firma.local", "rdsh02.firma.local")

# Utworzenie kolekcji sesji
New-RDSessionCollection `
    -CollectionName "Aplikacje biurowe" `
    -SessionHost @("rdsh01.firma.local", "rdsh02.firma.local") `
    -ConnectionBroker "rdcb.firma.local" `
    -CollectionDescription "Kolekcja do zastosowań biurowych"

Krok 4: Konfiguracja serwera licencji

Po instalacji ról RDS konieczne jest skonfigurowanie serwera licencji:

1. Zainstaluj rolę Remote Desktop Licensing na wybranym serwerze
2. Otwórz Remote Desktop Licensing Manager
3. Kliknij prawym przyciskiem na serwerze → Activate Server
4. Postępuj według kreatora aktywacji (wymagane połączenie z Microsoft)
5. Po aktywacji zainstaluj licencje CAL: prawy przycisk → Install Licenses
6. W Server Manager → Remote Desktop Services → Overview → skonfiguruj wskazanie na serwer licencji

# Konfiguracja serwera licencji przez PowerShell
Set-RDLicenseConfiguration `
    -LicenseServer "rdlic.firma.local" `
    -Mode PerUser `
    -ConnectionBroker "rdcb.firma.local"

Konfiguracja sesji — profile, przekierowania i limity

Profile użytkowników

Prawidłowa konfiguracja profili jest kluczowa dla wydajności i wygody użytkowania. Dostępne są trzy główne podejścia:

Rekomendacja: W nowych wdrożeniach zdecydowanie zalecamy FSLogix — narzędzie przejęte przez Microsoft, które jest teraz darmowe dla posiadaczy licencji RDS CAL. Kontenery FSLogix eliminują problem powolnego logowania i zapewniają pełną kompatybilność z aplikacjami.

Przekierowania urządzeń

RDS umożliwia przekierowanie lokalnych zasobów klienta do sesji zdalnej. Konfiguracja odbywa się we właściwościach kolekcji:

• Dyski lokalne — dostęp do dysków komputera klienta z poziomu sesji
• Drukarki — drukowanie na lokalnych drukarkach (EasyPrint)
• Schowek — kopiowanie/wklejanie między sesją a komputerem lokalnym
• Porty COM/USB — dostęp do urządzeń podłączonych do klienta
• Karty inteligentne — uwierzytelnianie za pomocą smart card
• Audio/Wideo — odtwarzanie i nagrywanie dźwięku

# Konfiguracja przekierowań kolekcji
Set-RDSessionCollectionConfiguration `
    -CollectionName "Aplikacje biurowe" `
    -ClientDeviceRedirectionOptions @(
        "AudioVideoPlayBack",
        "AudioRecording",
        "SmartCard",
        "Clipboard",
        "Drive",
        "PlugAndPlayDevice"
    ) `
    -ClientPrinterRedirected $true `
    -ClientPrinterAsDefault $true `
    -ConnectionBroker "rdcb.firma.local"

Limity sesji

Prawidłowe ustawienie limitów sesji zapobiega marnowaniu zasobów serwera:

# Ustawienie limitów sesji
Set-RDSessionCollectionConfiguration `
    -CollectionName "Aplikacje biurowe" `
    -IdleSessionLimitMin 60 `
    -DisconnectedSessionLimitMin 480 `
    -ActiveSessionLimitMin 0 `
    -BrokenConnectionAction Disconnect `
    -AutomaticReconnectionEnabled $true `
    -TemporaryFoldersDeletedOnExit $true `
    -ConnectionBroker "rdcb.firma.local"

Zalecane wartości dla typowego środowiska biurowego:

• Idle session limit: 30-60 minut — sesja bezczynna zostaje rozłączona
• Disconnected session limit: 4-8 godzin — rozłączona sesja zostaje zakończona
• Active session limit: 0 (bez limitu) lub 12 godzin dla sesji całodziennych

RemoteApp — publikowanie aplikacji

RemoteApp to funkcja RDS, która pozwala udostępnić użytkownikom pojedyncze aplikacje zamiast pełnego pulpitu zdalnego. Aplikacja uruchamiana przez RemoteApp wygląda tak, jakby była zainstalowana lokalnie — ma własne okno na pasku zadań, własną ikonę i zachowuje się jak natywna aplikacja.

Zalety RemoteApp

• Lepsze doświadczenie użytkownika — brak „obcego" pulpitu, aplikacja wygląda natywnie
• Łatwiejsze zarządzanie — centralna instalacja i aktualizacja aplikacji
• Mniejsze zużycie pasma — przesyłany jest tylko obraz okna aplikacji, nie cały pulpit
• Bezpieczeństwo — użytkownik nie ma dostępu do pełnego środowiska serwera

Publikowanie aplikacji RemoteApp

# Publikowanie aplikacji RemoteApp
New-RDRemoteApp `
    -CollectionName "Aplikacje biurowe" `
    -DisplayName "Microsoft Word" `
    -FilePath "C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE" `
    -Alias "word" `
    -ShowInWebAccess $true `
    -ConnectionBroker "rdcb.firma.local"

New-RDRemoteApp `
    -CollectionName "Aplikacje biurowe" `
    -DisplayName "Microsoft Excel" `
    -FilePath "C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE" `
    -Alias "excel" `
    -ShowInWebAccess $true `
    -ConnectionBroker "rdcb.firma.local"

# Publikowanie aplikacji z parametrami
New-RDRemoteApp `
    -CollectionName "Aplikacje biurowe" `
    -DisplayName "Aplikacja ERP" `
    -FilePath "C:\ERP\erp-client.exe" `
    -Alias "erp" `
    -CommandLineSetting Require `
    -RequiredCommandLine "/server:erp-db.firma.local" `
    -ShowInWebAccess $true `
    -ConnectionBroker "rdcb.firma.local"

Po opublikowaniu aplikacje są dostępne przez portal RD Web Access pod adresem https://serwer/RDWeb, a także mogą być dystrybuowane jako pliki .rdp lub przez Group Policy.

RD Gateway — bezpieczny dostęp zdalny

RD Gateway jest krytycznym komponentem każdego wdrożenia RDS, które ma być dostępne z internetu. Bez niego administratorzy musieliby otworzyć port 3389 (RDP) bezpośrednio na firewallu — co jest jednym z najczęstszych wektorów ataku na serwery Windows.

Jak działa RD Gateway?

1. Klient RDP łączy się z RD Gateway przez HTTPS (port 443)
2. Gateway uwierzytelnia użytkownika i sprawdza polityki autoryzacji
3. Jeśli użytkownik jest uprawniony, gateway tworzy tunel do wewnętrznego serwera RDS
4. Cały ruch RDP jest szyfrowany SSL/TLS — nawet jeśli przechodzi przez internet

Konfiguracja RD Gateway

Wymagania wstępne:

• Certyfikat SSL/TLS z zaufanego CA (np. Let's Encrypt, DigiCert) — certyfikat self-signed nie jest zalecany
• Nazwa DNS wskazująca na publiczny IP bramy (np. rdgw.firma.pl)
• Port 443 otwarty na firewallu i przekierowany na serwer Gateway

# Dodanie roli RD Gateway
Add-RDServer `
    -Server "rdgw.firma.local" `
    -Role "RDS-GATEWAY" `
    -ConnectionBroker "rdcb.firma.local" `
    -GatewayExternalFqdn "rdgw.firma.pl"

# Import certyfikatu SSL
Set-RDCertificate `
    -Role RDGateway `
    -ImportPath "C:\Certs\rdgw.firma.pl.pfx" `
    -Password (ConvertTo-SecureString "haslo-cert" -AsPlainText -Force) `
    -ConnectionBroker "rdcb.firma.local"

Polityki autoryzacji

RD Gateway używa dwóch typów polityk:

Connection Authorization Policy (CAP) — określa kto może się łączyć:

• Grupy użytkowników Active Directory uprawnione do połączenia
• Wymagane metody uwierzytelniania (hasło, smart card, Windows Hello)
• Przekierowane urządzenia dozwolone/zablokowane
• Limit czasu bezczynności i sesji

Resource Authorization Policy (RAP) — określa do czego użytkownik może się łączyć:

• Lista serwerów (lub grupy w AD), do których użytkownik ma dostęp
• Dozwolone porty (domyślnie 3389)
• Grupy użytkowników uprawnione do łączenia się z tymi zasobami

Integracja z MFA (Multi-Factor Authentication)

Dla zwiększenia bezpieczeństwa RD Gateway można zintegrować z uwierzytelnianiem wieloskładnikowym. Najpopularniejsze metody:

• Azure MFA + NPS Extension — darmowe dla posiadaczy Azure AD Premium
• DUO Security — niezależny dostawca MFA
• RSA SecurID — tokenowe uwierzytelnianie w środowiskach enterprise

Wysoka dostępność RDS — farma serwerów

W środowiskach produkcyjnych pojedynczy serwer RDS stanowi single point of failure. Aby zapewnić ciągłość działania, należy wdrożyć architekturę wysokiej dostępności (HA).

HA dla RD Session Host

Najprostsza forma HA — dodanie wielu serwerów Session Host do jednej kolekcji. Connection Broker automatycznie rozdziela sesje między serwerami:

# Dodanie drugiego serwera Session Host do kolekcji
Add-RDSessionHost `
    -CollectionName "Aplikacje biurowe" `
    -SessionHost "rdsh02.firma.local" `
    -ConnectionBroker "rdcb.firma.local"

# Konfiguracja wag load balancingu
Set-RDSessionHost `
    -SessionHost "rdsh01.firma.local" `
    -NewConnectionAllowed Yes `
    -ConnectionBroker "rdcb.firma.local"

HA dla Connection Broker

Connection Broker w trybie HA wymaga:

• Minimum 2 serwerów Connection Broker
• Bazy danych SQL Server (Express, Standard lub AlwaysOn AG)
• Wspólnej nazwy DNS (round-robin lub load balancer)

Konfiguracja HA Connection Brokera to jedna z bardziej złożonych operacji w architekturze RDS — wymaga migracji bazy danych z lokalnego WID (Windows Internal Database) na zewnętrzny SQL Server.

HA dla RD Gateway

Dla RD Gateway HA można zastosować:

• Network Load Balancing (NLB) — wbudowany w Windows Server
• Load balancer sprzętowy — F5, Citrix ADC, HAProxy
• Azure Load Balancer — dla wdrożeń hybrydowych

Przykładowa architektura HA

Monitorowanie i optymalizacja wydajności RDS

Kluczowe metryki do monitorowania

Skuteczne zarządzanie farmą RDS wymaga ciągłego monitorowania kluczowych parametrów:

Polecenia diagnostyczne PowerShell

# Sprawdzenie aktywnych sesji na wszystkich serwerach
Get-RDUserSession -ConnectionBroker "rdcb.firma.local" |
    Select-Object UserName, HostServer, SessionState, CreateTime |
    Format-Table -AutoSize

# Sprawdzenie obciążenia serwerów Session Host
Get-RDSessionHost -CollectionName "Aplikacje biurowe" `
    -ConnectionBroker "rdcb.firma.local" |
    Select-Object SessionHost, NewConnectionAllowed, Sessions

# Wylogowanie nieaktywnych sesji starszych niż 24h
Get-RDUserSession -ConnectionBroker "rdcb.firma.local" |
    Where-Object { $_.SessionState -eq "STATE_DISCONNECTED" -and
                   $_.CreateTime -lt (Get-Date).AddHours(-24) } |
    ForEach-Object { Invoke-RDUserLogoff -HostServer $_.HostServer -UnifiedSessionID $_.UnifiedSessionId -Force }

Optymalizacja wydajności

Najważniejsze kroki optymalizacji serwera RDS:

1. Wyłącz niepotrzebne efekty wizualne — przez GPO ustaw „Adjust for best performance" dla sesji RDP
2. Skonfiguruj FSLogix — kontenery profili dramatycznie przyspieszają logowanie
3. Używaj SSD/NVMe — dysk jest najczęstszym wąskim gardłem w środowiskach RDS
4. Ustaw CPU Fair Share — HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Quota System\EnableCpuQuota = 1
5. Optymalizuj antywirus — dodaj wykluczenia dla profili FSLogix i plików tymczasowych
6. Wdróż RDSH Image Management — golden image z SCCM lub MDT zapewnia spójność
7. Skonfiguruj QoS — priorytet dla ruchu RDP na przełącznikach sieciowych

RDS vs Azure Virtual Desktop — porównanie

Microsoft oferuje dwa rozwiązania do zdalnego dostępu: tradycyjne RDS on-premises oraz chmurowe Azure Virtual Desktop (AVD), wcześniej znane jako Windows Virtual Desktop. Wybór między nimi zależy od wielu czynników:

Najczęstsze problemy z RDS i rozwiązania

Problem 1: „Serwer licencji pulpitu zdalnego nie jest dostępny"

Objawy: Użytkownicy widzą komunikat o brakującej licencji, sesje ograniczone do 120 dni.

Rozwiązanie:

1. Sprawdź, czy serwer licencji jest aktywowany: Remote Desktop Licensing Manager
2. Sprawdź, czy licencje CAL są zainstalowane i dostępne
3. Zweryfikuj wskazanie na serwer licencji: Get-RDLicenseConfiguration
4. Sprawdź firewall — port 135 (RPC) i dynamiczne porty RPC muszą być otwarte
5. Upewnij się, że wersja CAL odpowiada wersji Windows Server

Problem 2: Wolne logowanie do sesji RDS

Objawy: Logowanie trwa 30-120 sekund zamiast 5-15 sekund.

Rozwiązanie:

• Wdróż FSLogix zamiast profili mobilnych — logowanie skróci się do 5-10 sekund
• Przenieś profile na dysk SSD/NVMe
• Wyłącz mapowanie drukarek, jeśli nie jest potrzebne (główny winowajca)
• Sprawdź Group Policy — nadmiar polityk GPO wydłuża logowanie
• Skonfiguruj folder Temporary Internet Files jako niezapisywany w profilu

Problem 3: Błąd „CredSSP encryption oracle remediation"

Objawy: Klienci nie mogą się połączyć po aktualizacji Windows.

Rozwiązanie:

# Tymczasowe obejście (niezalecane na stałe)
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /v AllowEncryptionOracle /t REG_DWORD /d 2 /f

# Właściwe rozwiązanie: zainstaluj aktualizacje na OBIE strony — klient i serwer

Problem 4: Wysokie użycie CPU przez dwm.exe

Objawy: Proces dwm.exe (Desktop Window Manager) zużywa dużo CPU w sesjach RDS.

Rozwiązanie:

• Przez GPO ustaw: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Remote Session Environment → „Use hardware graphics adapters for all RDS sessions" = Disabled (jeśli brak GPU)
• Wyłącz efekty animacji i przezroczystości
• Na Windows Server 2022+ rozważ GPU acceleration, które odciąża CPU

Problem 5: Sesje „zawieszają się" lub mają opóźnienia

Objawy: Obraz w sesji laguje, mysz reaguje z opóźnieniem.

Rozwiązanie:

• Sprawdź metrykę Round Trip Time w Performance Monitor — powinno być < 150 ms
• Włącz UDP transport dla RDP: GPO → „Select RDP transport protocols" = „Use both UDP and TCP"
• Skonfiguruj QoS z priorytetem dla DSCP 46 (Expedited Forwarding) na ruchu RDP
• Sprawdź, czy na serwerze nie brakuje RAM — paging to główna przyczyna lagów
• Rozważ wdrożenie RD Gateway z compresją — poprawia wydajność na wolnych łączach

Bezpieczeństwo serwera RDS — najlepsze praktyki

Serwer terminali jest częstym celem ataków. Oto kluczowe zalecenia bezpieczeństwa:

1. Nigdy nie wystawiaj portu 3389 do internetu — zawsze używaj RD Gateway lub VPN
2. Włącz Network Level Authentication (NLA) — uwierzytelnienie przed nawiązaniem sesji
3. Wdróż MFA na RD Gateway — Azure MFA lub rozwiązanie trzecich firm
4. Aktualizuj serwery regularnie — łatki bezpieczeństwa RDP są krytyczne (BlueKeep, DejaBlue)
5. Ogranicz konta z dostępem RDP — grupa „Remote Desktop Users" powinna zawierać tylko potrzebnych użytkowników
6. Skonfiguruj Account Lockout Policy — blokada konta po 5 nieudanych próbach
7. Włącz audytowanie logowań — Event ID 4624/4625 w Security Log
8. Szyfrowanie sesji — ustaw poziom „High" w konfiguracji RDS
9. Używaj certyfikatów TLS zamiast self-signed dla wszystkich ról RDS
10. Segmentacja sieciowa — serwery RDS w osobnym VLAN z kontrolowanym dostępem

FAQ — najczęściej zadawane pytania

Ile licencji RDS CAL potrzebuję?

Potrzebujesz jednej licencji RDS CAL na każdego użytkownika (Per User) lub każde urządzenie (Per Device), które łączy się z serwerem RDS. Dodatkowo każdy użytkownik/urządzenie potrzebuje Windows Server CAL. Przykład: 50 pracowników łączących się zdalnie = 50 x RDS CAL Per User + 50 x Windows Server CAL. Sprawdź nasze pakiety licencji CAL.

Czy mogę zainstalować RDS bez domeny Active Directory?

Technicznie możesz zainstalować rolę RD Session Host w grupie roboczej, ale nie jest to zalecane. Bez Active Directory tracisz: centralne zarządzanie użytkownikami, Group Policy, wysoką dostępność (Connection Broker HA wymaga AD), oraz prawidłowe licencjonowanie RDS CAL Per User. W środowiskach produkcyjnych AD jest praktycznie wymagane.

Jaką wersję Windows Server wybrać do RDS?

Windows Server 2022 Standard jest najlepszym wyborem dla większości wdrożeń RDS. Zapewnia najnowsze funkcje bezpieczeństwa (TLS 1.3, secured-core), pełne wsparcie dla FSLogix i jest kompatybilny z najnowszymi licencjami RDS CAL. Wersja Datacenter jest potrzebna tylko przy dużej liczbie maszyn wirtualnych (nielimitowane VM).

Czy RDS działa z klientami Linux i macOS?

Tak. Microsoft udostępnia klienta Remote Desktop na macOS (App Store), a na Linuxie popularne są klienty open-source: Remmina, FreeRDP i xfreerdp. Wszyscy klienci obsługują RD Gateway, RemoteApp i NLA. Klienty mobilne (iOS, Android) są również dostępne.

Jak migrować z Windows Server 2019 RDS do 2022?

Migracja RDS wymaga starannego planowania. Zalecany proces: (1) dodaj nowe serwery Session Host z Server 2022 do istniejącej farmy, (2) zaktualizuj Connection Broker i Web Access do 2022, (3) zaktualizuj serwer licencji i zainstaluj RDS CAL 2022, (4) przenieś sesje użytkowników na nowe serwery, (5) usuń stare serwery 2019 z kolekcji. Pamiętaj: Connection Broker musi być w wersji równej lub wyższej niż Session Host.

Podsumowanie — jak rozpocząć wdrożenie RDS?

Remote Desktop Services to dojrzała, sprawdzona technologia, która umożliwia firmom centralizację aplikacji, redukcję kosztów sprzętowych i zapewnienie bezpiecznego dostępu zdalnego. Kluczem do udanego wdrożenia jest:

1. Prawidłowe planowanie — określ liczbę użytkowników, rodzaje aplikacji i wymagania bezpieczeństwa
2. Właściwe licencjonowanie — Windows Server + Windows Server CAL + RDS CAL
3. Bezpieczeństwo od pierwszego dnia — RD Gateway, NLA, MFA, regularne aktualizacje
4. Monitorowanie i optymalizacja — FSLogix, dyski SSD, limity sesji

Sprawdź również nasze inne przewodniki dotyczące Windows Server:

• Hyper-V na Windows Server — kompletny przewodnik po wirtualizacji
• Microsoft Exchange Server — konfiguracja i zarządzanie pocztą
• Failover Clustering — wysoka dostępność Windows Server