Azure Virtual Desktop Classic wycofany: Następne kroki dla IT

Wprowadzenie

Emerytura Azure Virtual Desktop (klasyczny) tworzy ważne rozróżnienie między utratą usługi połączenia dziedziczonego a dalszą dostępnością podstawowych zasobów Azure. Dla zespołów IT, które przegapiły termin migracji, zrozumienie tego rozróżnienia jest kluczowe dla planowania odzyskiwania bez niepotrzebnej wymiany istniejącej infrastruktury. Artykuł ten wyjaśnia, co oznacza emerytura dla istniejących zasobów, jak zidentyfikować klasyczne wdrożenia, które opcje migracji pozostają warte oceny oraz jak wybrać wspieraną architekturę dostarczania aplikacji.

Co to oznacza, gdy Azure Virtual Desktop Classic zostaje wycofany?

Microsoft oficjalnie wycofał Azure Virtual Desktop (klasyczny) z dniem 30 września 2026 roku. Na podstawie oficjalnej dokumentacji Microsoftu, „po wycofaniu połączenia z klasycznymi usługami będą zablokowane.” W związku z tym wycofanie dotyczy konkretnego typu usług związanych z zarządzaniem wirtualnymi pulpitami i aplikacjami przy użyciu modelu wdrożeniowego Azure Virtual Desktop (klasyczny).

Jednak proces wycofania nie dotyczy nowoczesnego Azure Virtual Desktop, który korzysta z Azure Resource Manager (ARM). Dlatego głównym zmartwieniem użytkowników, którzy nadal korzystają z klasycznych zasobów, jest niemożność nawiązywania połączeń z wcześniej działającymi usługami. W związku z tym użytkownicy powinni szczególnie zwracać uwagę na zarządzanie klasycznymi zasobami, ponieważ same zasoby nie znikną po dacie wycofania.

Co dokładnie zostało wycofane?

Azure Virtual Desktop (klasyczny), wcześniej znany jako Windows Virtual Desktop, miał swoją infrastrukturę zarządzania opartą na dedykowanych poleceniach PowerShell, interfejsach API i obiektach usług.

W przeciwieństwie do nowoczesnego Azure Virtual Desktop, klasyczne pule hostów i grupy aplikacji nie były definiowane jako zjednoczone zasoby menedżera zasobów Azure.

Dziś te komponenty są włączone do systemu zarządzania zasobami Azure, co pozwala administratorom na stosowanie opartej na rolach kontroli dostępu Azure (RBAC), zarządzanie usługą za pośrednictwem portalu Azure oraz korzystanie z nowoczesnych wzorców infrastruktury jako kodu do automatyzacji wdrożeń.

Zdolność	AVD Classic (wycofany)	Nowoczesne AVD
Zarządzanie	Plan sterowania wstecznej kompatybilności	Menadżer zasobów Azure
portal Azure	Ograniczona integracja	Integracja natywna
Kontrola dostępu	Role dziedziczne najemcy	Azure RBAC
Automatyzacja	Klasyczne interfejsy API i PowerShell	ARM, API, Az PowerShell
Dostarczenie pulpitu i aplikacji	Połączenia zablokowane	Obsługiwany
Status usługi	Na emeryturze	Obsługiwany

Emerytura oznacza zmianę w podstawowej architekturze usługi, a nie tylko zmianę nazwy produktu.

Czy nowoczesny Azure Virtual Desktop nadal działa?

Tak. Nowoczesny Azure Virtual Desktop jest wspierany i nadal oferuje pełne pulpity Windows, platformy wielosesyjne oraz dostarczanie aplikacji indywidualnych za pomocą RemoteApp.

Organizacje, które już korzystają z hostów zintegrowanych z Azure Resource Manager (ARM), nie są dotknięte wycofaniem klasycznej usługi.

Menedżerowie IT powinni również zauważyć różnicę między końcem wsparcia dla klasycznego Azure Virtual Desktop a oddzielnym końcem wsparcia dla starszych klientów Remote Desktop. Klient Remote Desktop dla systemu Windows (MSI) miał osiągnąć koniec wsparcia dla publicznych środowisk chmurowych 27 marca 2026 roku, a dla Azure Virtual Desktop (klasycznego) 28 września 2026 roku.

Jak zespoły IT mogą zidentyfikować klasyczne wdrożenia Azure Virtual Desktop?

Pierwszym krokiem jest zidentyfikowanie, czy jakiekolwiek obciążenia produkcyjne nadal zależą od wycofanej architektury.

To jest szczególnie istotne dla systemów, które zostały wprowadzone do produkcji lata temu i mogły zostać przejęte przez nowych administratorów lub zignorowane w aktualnej dokumentacji infrastruktury.

Sprawdź integrację z Azure Resource Manager

Powinieneś zacząć od zbadania zasobów Azure Virtual Desktop w portalu Azure. Nowoczesne wdrożenia Azure Virtual Desktop udostępniają pule hostów, grupy aplikacji i przestrzenie robocze jako zasoby Azure w subskrypcji i grupie zasobów. W przeciwieństwie do tego, klasyczne wdrożenia udostępniały obiekty usług zarządzane w różny sposób.

Obecność następujących elementów Azure Virtual Desktop stanowi silny wskaźnik klasycznego wdrożenia:

• Pule hostów, które używają klasycznego modułu PowerShell Azure Virtual Desktop
• Historyczne odniesienia do klasycznego najemcy usługi lub klasycznego interfejsu API usługi
• Grupy aplikacji, które nie mają odpowiadających zasobów ARM
• Maszyny wirtualne hosta sesji, które odnoszą się do starszej dokumentacji

Jednocześnie brak puli hostów w portalu Azure niekoniecznie oznacza klasyczne wdrożenie. Zawsze powinieneś sprawdzić, która subskrypcja, tenant Microsoft Entra oraz kontrola dostępu oparta na rolach przysługuje użytkownikowi, zanim przeanalizujesz problem dalej.

Przegląd narzędzi zarządzania dziedzictwem i zależnościami

Skrypty wdrożeniowe i repozytoria automatyzacji mogą służyć jako dodatkowe źródła dowodów.

Na przykład obecność skryptów zawierających odniesienia do Microsoft.RDInfra.RDPowerShell lub klasycznych operacji zarządzania na poziomie najemcy sugerowałaby, że środowisko zostało skonfigurowane za pomocą starszego stosu zarządzania.

Nowoczesne środowiska będą wykorzystywać zintegrowane interfejsy zarządzania Azure Resource Manager oraz powiązane moduły Az PowerShell.

Administratorzy powinni również sporządzić inwentaryzację wszystkich zasobów aplikacji, użytkowników i infrastruktury związanych z potencjalnie dotkniętymi pulami hostów.

To obejmuje to badanie maszyn wirtualnych hostów sesji, przypisania aplikacji, lokalizacji przechowywania profili, zależności uwierzytelniania, konfiguracji sieciowych oraz repozytoriów kopii zapasowych. Dokumentacja ręcznej migracji Microsoftu zawiera szczegółowe porównania między klasycznym modelem obiektów usług a zintegrowanym modelem zasobów Azure Resource Manager (ARM).

Co się stanie z Twoimi istniejącymi zasobami po zakończeniu wsparcia dla Azure Virtual Desktop Classic?

Najważniejsza różnica dotyczy wycofanego serwisu połączeń oraz podstawowej infrastruktury Azure.

Podczas gdy klasyczne połączenia pulpitu są zablokowane, istniejące maszyny wirtualne, zasoby pamięci i dane aplikacji mogą pozostać na miejscu.

Istniejące maszyny wirtualne i pamięć mogą pozostać dostępne

Maszyny wirtualne Azure to zasoby, które są zarządzane samodzielnie, bez polegania na wycofanym klasycznym interfejsie sterowania usługami. W związku z tym, wirtualne maszyny hostów sesji, zarządzane dyski i zasoby sieciowe, które zostały utworzone w subskrypcji, mogą nadal istnieć.

Jednak nie mogą być używane do przywrócenia wycofanego brokera połączeń. Żadne maszyny wirtualne utworzone w nowej infrastrukturze Azure nie są dostępne, aby przywrócić doświadczenie pulpitu organizacji do stanu roboczego.

Administratorzy powinni dokładnie zbadać każdy zasób, a jeśli można go ponownie wykorzystać w obsługiwanej konfiguracji, powinni wykonać następujące kroki.

Należy sprawdzić, czy system operacyjny maszyny wirtualnej jest obsługiwany oraz czy aplikacje i konfiguracje zabezpieczeń są zgodne.

Dostęp do aplikacji i dane użytkowników wymagają oddzielnych kontroli

Użytkownicy, którzy połączyli się za pomocą klasycznego typu sesji pulpitu lub RemoteApp, nie będą mogli już uruchamiać swoich aplikacji za pośrednictwem tej usługi.

Wynikiem wycofania usługi może być utrata dostępu do pulpitów, opublikowanych aplikacji oraz zakłócenia w procesach biznesowych.

Jednak zakończenie usługi nie gwarantuje, że dane związane z użytkownikami zostaną usunięte.

W większości przypadków to dane użytkowników są przechowywane na Azure Files, dyskach VM lub innych nośnikach pamięci, ale przechowywanie i dostępność tych informacji będą zależały od tego, jak zostały skonfigurowane, zabezpieczone uprawnieniami, zbackupowane itp.

W związku z tym, przed wycofaniem lub migracją zaangażowanych systemów, działy IT muszą upewnić się, że zachowały wszystkie niezbędne dane.

Czy zespół nadal może migrować klasyczny Azure Virtual Desktop po jego wycofaniu?

Microsoft dokumentuje dwie ścieżki migracji z Azure Virtual Desktop (klasyczny) do nowego zintegrowanego z ARM Azure Virtual Desktop: migrację automatyczną i migrację ręczną.

Obie opcje miały być dostępne do 30 września 2026 roku.

Ponieważ ta data jest w przeszłości, administratorzy nie powinni uznawać narzędzi opisanych w dokumentacji za gotowe do produkcji we wszystkich scenariuszach.

Dokumentacja Microsoftu nie zawiera wskazówek dotyczących okresu przejściowego.

Dlatego organizacje nie powinny polegać na żadnych narzędziach i procesach przejściowych po zakończeniu pracy.

Opcja 1: Automatyczna migracja

automatyczny proces migracji Microsoftu wykorzystuje narzędzie oparte na PowerShell do przenoszenia kwalifikujących się klasycznych konfiguracji usług do zasobów ARM.

Dokumentacja firmy zaleca, aby użytkownicy mieli aktywną subskrypcję Azure z odpowiednimi uprawnieniami oraz spełniali wymagania środowiskowe wymienione przez moduł migracji.

Na przykład, wytyczne Microsoftu sugerują, aby użytkownicy mieli przydzielone uprawnienia Współtwórcy do tworzenia zasobów Azure oraz uprawnienia Administratora dostępu użytkowników do zarządzania członkostwem w grupie aplikacji.

Jednak ważne jest, aby uznać, że narzędzie nie może zagwarantować odzyskania danych po wycofaniu.

Organizacje z aktywnymi klasycznymi wdrożeniami powinny skonsultować się z pomocą techniczną Microsoft, aby potwierdzić, czy proces migracji jest dostępną opcją dla ich środowiska.

Opcja 2: Migracja ręczna lub rekonstrukcja

Migracja ręczna wymaga utworzenia nowoczesnych zasobów Azure Virtual Desktop oraz ponownej konfiguracji ustawień usługi.

W zależności od konkretnego przypadku, administratorzy mogą potrzebować:

• Utwórz zintegrowane pule hostów opartych na ARM, grupy aplikacji i przestrzenie robocze
• Utwórz lub zastąp maszyny wirtualne hosta sesji
• Zarejestruj zgodne hosty sesji w nowych pulach hostów
• Odtwórz powiązania użytkownika i aplikacji
• Dostosuj konfiguracje tożsamości, sieci, bezpieczeństwa i profilu

Podejście manualne staje się konieczne, gdy starsze konfiguracje zawierają nieudokumentowaną złożoność, rozbudowaną personalizację lub gdy nowoczesne narzędzia migracyjne okazują się niewystarczające.

Należy zauważyć, że rekonstrukcja infrastruktury dostarczania nie zawsze wiąże się z całkowitą wymianą aplikacji i danych.

Pozostałe komponenty można często ponownie wykorzystać poprzez odpowiednie oceny kompatybilności, oceny licencyjne i audyty bezpieczeństwa.

Decyzja powinna opierać się na aktualnym stanie istniejących zasobów i dostępnej pomocy ze strony Microsoft.

Sytuacja	Podejście do oceny
Kwalifikująca się klasyczna konfiguracja i Microsoft potwierdza wsparcie migracji	Automatyczna migracja
Złożona lub niedostępna klasyczna konfiguracja	Rekonstrukcja ręczna
Istniejące maszyny wirtualne i dane pozostają dostępne	Odbudować usługi dostawcze i ocenić ponowne wykorzystanie
Obciążenia dziedziczone nie są już wymagane	Bezpieczne wycofanie
Desktopy hostowane w chmurze Azure nie są już konieczne	Alternatywna architektura dostarczania

Co powinny zrobić zespoły IT, jeśli przegapiły termin zakończenia wsparcia?

Organizacje, które nie zakończą migracji do 30 września 2026 roku, powinny priorytetowo traktować zachowanie zasobów oraz przywrócenie dostępu do aplikacji biznesowych.

Zamiast próbować wielu połączeń z wycofaną usługą, administratorzy powinni przeprowadzić proces odzyskiwania.

Krok 1: Oceń wpływ usługi

Zidentyfikuj, którzy użytkownicy, pulpity i aplikacje są niedostępne.

Dowiedz się, czy dotyczy to całego środowiska, czy konkretnych obciążeń. Potwierdź, że problem jest związany z klasycznym wycofaniem, a nie z innym problemem związanym z uwierzytelnianiem, siecią lub hostem sesji.

Krok 2: Zachowanie infrastruktury i danych

Przejrzyj subskrypcje Azure, aby zidentyfikować bieżące maszyny wirtualne, zarządzane dyski, konta magazynowe i zasoby sieciowe.

Zarządzaj zależnościami dokumentów i zapewnij kopie zapasowe istnieć przed podjęciem jakichkolwiek działań. Nie usuwaj zasobów, dopóki dane aplikacji, profile użytkowników i informacje konfiguracyjne nie zostały zidentyfikowane.

Krok 3: Potwierdź opcje odzyskiwania z Microsoftem

Skontaktuj się z pomocą techniczną Microsoft, aby upewnić się, że nadal dostępne są wspierane procedury migracji/odzyskiwania.

Początkowe instrukcje dotyczące migracji automatycznej/ręcznej zostały opracowane z uwzględnieniem daty zakończenia i dlatego nie należy zakładać, że mają zastosowanie.

W przypadku, gdy klasyczna konfiguracja nie może zostać przeniesiona, może być konieczne odbudowanie środowiska z obsługiwanymi zasobami Azure Virtual Desktop.

Krok 4: Przywróć dostarczanie aplikacji i pulpitu

Wybierz architekturę, która wspiera aplikacje i pulpity, których potrzebują użytkownicy.

Dla organizacji, które planują pozostać na Azure Virtual Desktop, zazwyczaj wiąże się to z konfiguracją zintegrowanych pul hostów ARM, wspieranych hostów sesji, grup aplikacji i przypisań użytkowników.

Niektóre organizacje mogą stwierdzić, że inny publikacja aplikacji lub rozwiązanie stacjonarne lepiej odpowiada ich potrzebom.

Celem jest przywrócenie dostępu przy jednoczesnym unikaniu złożoności i zbędnych obciążeń poprzedniej konfiguracji.

Jaki jest sposób na zweryfikowanie migracji Azure Virtual Desktop?

Przywracanie infrastruktury nie gwarantuje normalnego działania użytkowników.

Migracja lub rekonstrukcja musi zatem zostać zweryfikowana na poziomie usług i aplikacji.

Weryfikacja uwierzytelniania i dostępu użytkownika

Potwierdź, że użytkownicy mogą uwierzytelnić się i uzyskać dostęp do zasobów, które zostały im przypisane.

Sprawdź Microsoft Entra, uwierzytelnianie wieloskładnikowe, zasady dostępu warunkowego oraz przypisania Azure RBAC, jeśli dotyczy.

Administratorzy powinni potwierdzić, że uprawnienia są zgodne z zasadą najmniejszych uprawnień oraz że nie ma żadnych dziedzicznych wzorców dostępu, które zostały nieumyślnie przeniesione.

Testowanie aplikacji krytycznych dla biznesu

Testuj opublikowane aplikacje i pulpity, wykorzystując różne reprezentatywne konta użytkowników.

Działania walidacyjne powinny obejmować uruchamianie aplikacji, połączenia z bazą danych, udostępnianie sieciowe, drukowanie, przekierowanie schowka oraz wymagane urządzenia peryferyjne, jeśli takie istnieją.

Aplikacje dziedziczone muszą być brane pod szczególną uwagę, ponieważ mogą wymagać specyficznej konfiguracji systemu operacyjnego, ścieżki sieciowej lub komponentu aplikacji.

Przykładem aplikacji dziedziczonej może być aplikacja ERP, która uruchamia się pomyślnie, ale nie może połączyć się z bazą danych z nowego hosta sesji.

Walidacja profili, wydajności i operacji

Firmy korzystające z FSLogix lub innych narzędzi do profilowania powinny upewnić się, że wszystko jest poprawnie podłączone, jest trwałe i można do tego właściwie uzyskać dostęp.

Ważne jest, aby przetestować to, logując się po raz pierwszy i sprawdzając, czy wszystko będzie działać poprawnie, gdy użytkownik otworzy aplikację i podczas następnego logowania. Również istotne jest, aby upewnić się, że procesy są monitorowane, kopiowane zapasowo i przywracane.

Migracja jest zakończona tylko wtedy, gdy wszystko jest gotowe, w tym użytkownicy mogą uzyskać dostęp do swoich aplikacji. Musi być możliwe prawidłowe utrzymanie systemu.

Czy organizacje powinny ponownie rozważyć swoją architekturę dostarczania pulpitu?

Emerytura Azure Virtual Desktop (klasyczny) jest głównie kwestią cyklu życia platformy, ale także stwarza okazję do oceny, czy obecna platforma dostarczania pulpitu nadal spełnia Twoje potrzeby.

Przejście na nowoczesny Azure Virtual Desktop jest oczywistym wyborem dla wielu, szczególnie dla tych, którzy już preferują Azure i korzystają z hostowanych w Azure pulpitów.

Inne organizacje mają mniej skomplikowane wymagania.

Kiedy nowoczesny Azure Virtual Desktop ma sens?

Nowoczesny Azure Virtual Desktop może być dobrym rozwiązaniem dla organizacji, które wymagają centralnie zarządzanych pulpitów i aplikacji Windows, hostowanych na Azure.

Umożliwia wielosesyjne modele RemoteApp oraz narzędzia do zarządzania i identyfikacji Microsoft.

Ma to sens dla przedsiębiorstw, które mają już obecność w Azure, ale działy IT wciąż muszą radzić sobie z złożonościami chmury, w tym z licencjonowaniem, sieciami, przechowywaniem, administracją i aspektami operacyjnymi.

Kiedy inna architektura publikacji aplikacji Windows jest odpowiednia?

Nie wszystkie organizacje wymagają w pełni wdrożonego środowiska wirtualizacji pulpitu hostowanego w Microsoft Azure.

Niektóre przedsiębiorstwa potrzebują tylko ograniczonej remote access do konkretnych aplikacji systemu Windows, takich jak aplikacje finansowe lub ERP lub aplikacje dziedziczone z linii biznesowej.

Te organizacje mogą rozważyć publikację aplikacji, które są hostowane na centralnie zarządzanych serwerach Windows, zamiast wdrażać zgeneralizowaną infrastrukturę wirtualnych pulpitów (VDI).

Nowoczesny Azure Virtual Desktop to nie tylko wirtualizacja pulpitu lub aplikacji, ale także publikacja aplikacji.

Dziś możliwe jest publikowanie aplikacji Azure za pomocą metody RemoteApp.

Rzeczywistość jest taka, że nie ma dychotomii w obszarze dostarczania aplikacji, lecz raczej kontinuum, które przebiega od publikacji aplikacji do wirtualizacji pulpitu.

Dyskusja powinna koncentrować się na znalezieniu najbardziej odpowiedniej architektury dostarczania aplikacji dla danej organizacji i przypadków użycia.

Na przykład, jeśli istnieje długo działająca aplikacja hostowana w folderze Windows Server, do której uzyskuje dostęp zestaw uprawnionych użytkowników, organizacja nie musi publikować jej w Azure Virtual Desktop, gdy starsza infrastruktura nadal działa prawidłowo.

Zamiast tego, może być korzystne dla takich przedsiębiorstw, aby pozostawić lokalizację hostingu aplikacji na miejscu, jednocześnie modernizując metodę dostępu do aplikacji.

Jakie czynniki powinny kierować decyzją?

Działy IT powinny ocenić wybór w kontekście potrzeb wdrożeniowych, a nie funkcji wycofanego systemu.

Rozważenie	Kluczowe pytanie
Hosting	Czy obciążenia muszą działać w Azure?
Doświadczenie użytkownika	Pełne pulpity czy wybrane aplikacje?
Kompatybilność	Czy istniejące aplikacje Windows będą działać?
Bezpieczeństwo	Jak są chronione tożsamość i dostęp do sesji?
Zarządzanie	Kto utrzymuje infrastrukturę?
Licencjonowanie	Jakie licencje Microsoft i oprogramowania mają zastosowanie?
Skalowalność	Ilu jednoczesnych użytkowników jest wymaganych?
Koszt	Jaki jest całkowity koszt posiadania?

Celem jest wybranie architektury korporacyjnej, która spełni wymagania dotyczące dostępności, bezpieczeństwa i zmniejszonej złożoności administracyjnej.

Szukasz alternatywy dla dostarczania aplikacji i pulpitu w systemie Windows?

Migracja do nowoczesnego Azure Virtual Desktop niekoniecznie jest najlepszą opcją dla każdej organizacji. Firmy, które przede wszystkim potrzebują dostępu do istniejących aplikacji Windows lub centralnie hostowanych pulpitów, mogą skorzystać z prostszej architektury, szczególnie gdy nie wymagają w pełni hostowanego w chmurze środowiska wirtualnego pulpitu.

TSplus Zdalny Dostęp umożliwia zespołom IT publikowanie aplikacji Windows i pełnych pulpitów zdalnych za pośrednictwem klientów zgodnych z RDP lub portalu internetowego HTML5. Dzięki wsparciu dla lokalnych i hostowanych w chmurze serwerów Windows, oferuje praktyczną alternatywę dla organizacji, które chcą utrzymać swoje istniejące aplikacje, jednocześnie upraszczając dostarczanie aplikacji zdalnych.

Wniosek

Emerytura Azure Virtual Desktop (klasyczny) sprawia, że kluczowe jest zidentyfikowanie dotkniętych wdrożeń, zachowanie istniejących zasobów i przywrócenie dostępu poprzez wspieraną infrastrukturę. Zespoły IT powinny zweryfikować dostępne opcje odzyskiwania przed próbą migracji lub rekonstrukcji.

Niezależnie od tego, czy organizacje kontynuują korzystanie z nowoczesnego Azure Virtual Desktop, czy przyjmują inną architekturę dostarczania, priorytetem pozostaje zapewnienie bezpiecznego i niezawodnego dostępu do aplikacji bez zbędnej złożoności operacyjnej.