Zdalny pulpit w firmie - RDS, Azure Virtual Desktop czy Windows 365?

Gdy pracownik musi uruchomić firmową aplikację z domu, na służbowym laptopie albo z urządzenia, którego nie da się łatwo skonfigurować, zdalny pulpit przestaje być ciekawostką, a staje się elementem infrastruktury. W tym artykule wyjaśniam, czym w praktyce są rozwiązania określane jako remote desktop services, czym różnią się Remote Desktop Services, Azure Virtual Desktop i Windows 365 oraz jak dobrać model do aplikacji Windows, zespołu i budżetu.

Co naprawdę obejmują usługi zdalnego pulpitu Microsoftu

Najprościej mówiąc, użytkownik widzi na swoim komputerze interfejs Windows, ale aplikacja i dane działają na innym komputerze, serwerze lub maszynie wirtualnej. Przesyłany jest obraz, dźwięk i sygnały z klawiatury oraz myszy, natomiast obliczenia pozostają po stronie systemu zdalnego.

Podstawą komunikacji jest Remote Desktop Protocol, czyli RDP. Sam protokół nie jest jednak kompletną usługą. Potrzebuje systemu, mechanizmu uwierzytelniania, zasad dostępu, profili użytkowników i infrastruktury, która utrzyma sesje.

W Microsoftowym ekosystemie można zdalnie udostępnić trzy różne rzeczy:

• cały pulpit, gdy użytkownik potrzebuje środowiska przypominającego własny komputer,
• pojedynczą aplikację przez RemoteApp, gdy ma korzystać tylko z programu księgowego, ERP albo narzędzia .NET,
• osobisty Cloud PC, czyli przypisaną użytkownikowi maszynę Windows działającą w chmurze.

To rozróżnienie ma duże znaczenie. Publikowanie jednej aplikacji zwykle ogranicza bałagan i ryzyko przypadkowego dostępu do danych. Z kolei pełny pulpit jest wygodniejszy, gdy użytkownik pracuje z kilkoma programami, skrótami, dodatkami Office i własnym środowiskiem.

RDS nie oznacza po prostu aplikacji do zdalnego logowania

Remote Desktop Services w Windows Server to zestaw ról i mechanizmów do obsługi wielu zdalnych użytkowników. W zależności od konfiguracji obejmuje między innymi brokera połączeń, bramę dostępową, dostęp webowy, hosty sesji i publikowanie aplikacji.

W małej firmie często myli się RDS z uruchomieniem programu Pulpit zdalny. To drugie może wystarczyć do okazjonalnego połączenia z jednym komputerem, ale nie rozwiązuje problemów związanych z wieloma użytkownikami, licencjami, profilami, audytem i wysoką dostępnością.

RDS, Azure Virtual Desktop czy Windows 365

Największy błąd przy wyborze polega na porównywaniu samych nazw produktów. Ja zaczynam od pytania, kto ma zarządzać środowiskiem, jak bardzo użytkownicy potrzebują własnych maszyn i czy obciążenie jest stałe, czy zmienne.

RDS dla przewidywalnego środowiska

RDS dobrze pasuje do sytuacji, w której kilkadziesiąt osób korzysta z tych samych aplikacji, a firma ma już domenę, serwery Windows i zespół administracyjny. Jeden host sesji może obsługiwać wielu użytkowników, co bywa bardziej ekonomiczne niż osobna maszyna wirtualna dla każdej osoby.

Trzeba jednak pilnować zgodności aplikacji z trybem wielosesyjnym. Program napisany bez uwzględnienia pracy wielu użytkowników może zapisywać pliki tymczasowe w złym miejscu, blokować wspólne zasoby albo powodować konflikty w rejestrze. W takich przypadkach osobne maszyny lub AVD z pulą osobistych pulpitów mogą być bezpieczniejszym wyborem.

Azure Virtual Desktop dla skali i elastyczności

Azure Virtual Desktop, wcześniej znany jako Windows Virtual Desktop, jest usługą w Azure do wirtualizacji pulpitów i aplikacji. Pozwala budować host pools, czyli pule hostów sesji, a także udostępniać pulpity osobiste lub współdzielone.

Największą przewagę widać przy zmiennym zapotrzebowaniu. Jeśli zespół pracuje tylko w godzinach biznesowych, maszyny można uruchamiać zgodnie z harmonogramem, zamiast utrzymywać pełną moc przez całą dobę. To nie oznacza automatycznie niskich kosztów. Źle dobrane rozmiary VM, dyski, profile, transfer i zasoby sieciowe potrafią zniwelować oszczędności.

Windows 365 jako osobisty komputer z chmury

Windows 365 przypisuje użytkownikowi gotowy Cloud PC. Administrator nie musi projektować całej architektury host pooli, a pracownik otrzymuje środowisko, które pozostaje dostępne niezależnie od jego lokalnego urządzenia.

To rozwiązanie wybieram przede wszystkim wtedy, gdy użytkownik potrzebuje stałego, osobistego pulpitu, a firma chce uprościć wdrożenie. Cena jest bardziej przewidywalna niż w przypadku rozliczanego godzinowo Azure, lecz abonament działa także wtedy, gdy komputer przez kilka dni nie jest używany.

Jak wygląda dostęp do aplikacji i pulpitu

Po stronie użytkownika potrzebny jest klient obsługujący połączenie. W aktualnym ekosystemie Microsoftu rolę wspólnego klienta pełni Windows App, który może łączyć się między innymi z Azure Virtual Desktop, Windows 365, Microsoft Dev Box i środowiskami RDS.

Sam proces wygląda prosto, ale pod spodem składa się z kilku etapów:

1. Użytkownik loguje się przy użyciu konta organizacyjnego.
2. System sprawdza uprawnienia, zasady dostępu warunkowego i dodatkowe uwierzytelnienie.
3. Broker wybiera odpowiedni host sesji albo przypisany Cloud PC.
4. Połączenie RDP przekazuje obraz pulpitu oraz urządzenia lokalne dopuszczone przez administratora.
5. Profil użytkownika i dane aplikacji są ładowane z ustalonego magazynu.

W przypadku RemoteApp użytkownik może widzieć tylko okno konkretnego programu. Technicznie aplikacja działa na serwerze, ale wizualnie zachowuje się podobnie do programu uruchomionego lokalnie. To wygodne na przykład dla aplikacji magazynowej, systemu kadrowego lub starszego programu WinForms, którego nie opłaca się przepisywać do przeglądarki.

Co wpływa na wygodę pracy

Najczęściej przecenia się szybkość łącza, a pomija opóźnienie i stabilność połączenia. Do pracy biurowej ważniejsze od bardzo wysokiego transferu może być stałe połączenie bez skoków opóźnień i utraty pakietów.

Problemy pojawiają się przy wideokonferencjach, animacjach, dużych arkuszach, grafice 3D i aplikacjach korzystających z lokalnych urządzeń. Przekierowanie drukarki, schowka, dysków lub skanera jest wygodne, ale każde dodatkowe przekierowanie zwiększa powierzchnię ryzyka i może pogarszać działanie sesji.

W aplikacjach .NET trzeba sprawdzić przede wszystkim sposób przechowywania konfiguracji, zależności od lokalnych ścieżek, użycie profilu użytkownika oraz wymagania dotyczące komponentów COM. Program może działać poprawnie na komputerze dewelopera, a w sesji wieloużytkownikowej ujawnić problemy dopiero przy równoczesnym obciążeniu.

Bezpieczeństwo i licencjonowanie bez skrótów

Najważniejsza zasada brzmi prosto: nie wystawiaj portu RDP bezpośrednio do Internetu. Publicznie dostępny port 3389 jest częstym celem automatycznych prób logowania. Lepszym podejściem jest użycie RD Gateway, prywatnej sieci, usługi zarządzanej przez Azure oraz dodatkowych reguł kontroli dostępu.

W praktycznej konfiguracji uwzględniam co najmniej:

• MFA, czyli uwierzytelnianie wieloskładnikowe dla kont użytkowników i administratorów,
• zasadę najmniejszych uprawnień,
• ograniczenie przekierowania schowka, dysków, drukarek i urządzeń USB,
• aktualizacje systemu operacyjnego oraz aplikacji,
• rejestrowanie logowań, rozłączeń i nietypowych prób dostępu,
• kopie zapasowe profili, danych i konfiguracji,
• separację środowisk produkcyjnych, testowych i administracyjnych.

Ważne jest też rozdzielenie licencji dostępowej od kosztu infrastruktury. W klasycznym RDS trzeba uwzględnić Windows Server, RDS CAL w modelu użytkownika lub urządzenia, serwery, magazyn danych i utrzymanie. W AVD koszt zależy między innymi od maszyn wirtualnych, dysków, transferu i uprawnień do Windows. Windows 365 działa zwykle jako abonament za Cloud PC, ale mogą dojść koszty dodatkowych usług zarządzania i sieci.

Nie podaję jednej uniwersalnej ceny, bo byłaby myląca. Ten sam zespół dziesięciu osób może potrzebować jednej współdzielonej puli aplikacji, dziesięciu osobistych komputerów albo kilku mocnych maszyn GPU. Każdy wariant ma inny profil kosztów.

Najczęstsze błędy projektowe

Pierwszy błąd to dobieranie maszyny wyłącznie na podstawie liczby użytkowników. Dużo ważniejsze jest to, ilu z nich pracuje jednocześnie, jakie aplikacje uruchamia i czy obciążenie jest procesorowe, pamięciowe, dyskowe czy graficzne.

Drugi problem to wspólny profil bez odpowiedniego zarządzania. Profile użytkowników powinny być przechowywane i obsługiwane w sposób dopasowany do wybranego modelu. W środowiskach AVD często stosuje się profile FSLogix, które oddzielają dane profilu od systemu operacyjnego i ułatwiają przenoszenie użytkownika między hostami.

Trzeci błąd pojawia się wtedy, gdy firma testuje wyłącznie udane logowanie. Test powinien obejmować także przerwanie sieci, ponowne połączenie, drukowanie, kopiowanie danych, działanie antywirusa, aktualizacje i zachowanie aplikacji przy jednoczesnej pracy wielu osób.

Jak zaplanować wdrożenie w firmie

Nie zaczynałbym od tworzenia maszyn w Azure. Najpierw spisałbym aplikacje, użytkowników i wymagania. Taka krótka inwentaryzacja często pokazuje, że tylko część programów wymaga pełnego pulpitu, a resztę można udostępnić jako RemoteApp.

Etap pierwszy obejmuje aplikacje i użytkowników

Przy każdej aplikacji warto zanotować system operacyjny, wymagania sprzętowe, sposób licencjonowania, zależności od sieci lokalnej oraz to, czy program toleruje wielu użytkowników. Dla aplikacji .NET sprawdziłbym także wersję .NET, sterowniki, dostęp do udziałów SMB i integracje z lokalnymi urządzeniami.

Użytkowników dzielę według sposobu pracy, a nie wyłącznie działów. Księgowość może potrzebować stałego pulpitu, handlowcy lekkiej aplikacji przez RemoteApp, a programiści środowiska deweloperskiego z większą ilością pamięci.

Etap drugi to mały pilotaż

Pilotaż powinien objąć kilka osób o różnych potrzebach i trwać wystarczająco długo, aby ujawnić problemy z profilem, drukowaniem oraz wydajnością. Zwykle lepiej przetestować 5-10 użytkowników w realistycznych warunkach niż od razu migrować całą firmę.

W czasie pilotażu mierzę czas logowania, czas uruchomienia aplikacji, zużycie CPU i pamięci, opóźnienia oraz liczbę rozłączeń. Pytam też użytkowników o rzeczy, których monitoring nie pokaże, na przykład czy kopiowanie danych jest wygodne i czy aplikacja reaguje naturalnie podczas intensywnej pracy.

Przeczytaj również: SSH w Windows - instalacja, klucze i bezpieczny dostęp

Etap trzeci dotyczy automatyzacji i utrzymania

Środowisko zdalne szybko staje się trudne w obsłudze, jeśli każdą zmianę wykonuje się ręcznie. Przydatne są automatyzacja wdrożeń, obrazy bazowe, polityki Intune, skrypty PowerShell oraz kontrolowane pierścienie aktualizacji.

Dobrze zaprojektowane rozwiązanie powinno mieć także procedurę awaryjną. Trzeba wiedzieć, co stanie się po awarii hosta, niedostępności regionu Azure, uszkodzeniu profilu albo wygaśnięciu certyfikatu. Zdalny pulpit nie usuwa problemów infrastruktury, tylko przenosi je w inne miejsce.

Najrozsądniejszy wybór zależy od rytmu pracy, nie od samej nazwy usługi

Jeżeli potrzebuję prostego, centralnie zarządzanego dostępu do kilku aplikacji, zacząłbym od RDS i publikowania RemoteApp. Gdy liczba użytkowników rośnie, środowiska mają różne wymagania, a firma korzysta już intensywnie z Azure, sensowniejszy staje się Azure Virtual Desktop.

Windows 365 wybrałbym wtedy, gdy najważniejsza jest prostota i osobisty komputer dostępny z wielu urządzeń. Nie traktowałbym go jednak jako automatycznie tańszego zamiennika. Stały abonament kupuje przewidywalność, ale nie zawsze najlepsze wykorzystanie zasobów.

Najlepszy projekt często łączy kilka modeli. Aplikacja wspólna dla całego działu może działać jako RemoteApp, część pracowników może korzystać z puli współdzielonych pulpitów AVD, a programiści otrzymają osobiste środowiska. Taki podział zwykle daje lepszy efekt niż próba wtłoczenia wszystkich użytkowników w jedno rozwiązanie.

Moja praktyczna zasada jest prosta: najpierw zaprojektuj dostęp do aplikacji i danych, później wybierz technologię. Dzięki temu zdalny pulpit staje się przewidywalnym narzędziem pracy, a nie kolejną warstwą komplikacji nad aplikacjami Windows.