Azure Virtual Desktop Classic Retired: Pașii următori pentru IT

Introducere

Pensionarea Azure Virtual Desktop (clasic) creează o distincție importantă între pierderea unui serviciu de conectare moștenit și disponibilitatea continuă a resurselor Azure subiacente. Pentru echipele IT care au ratat termenul limită de migrare, înțelegerea acestei distincții este esențială pentru planificarea recuperării fără a înlocui inutil infrastructura existentă. Acest articol explică ce înseamnă pensionarea pentru resursele existente, cum să identificați implementările clasice, ce opțiuni de migrare rămân demne de evaluat și cum să alegeți o arhitectură de livrare a aplicațiilor suportată.

Ce înseamnă când Azure Virtual Desktop Classic este retras?

Microsoft a retras oficial Azure Virtual Desktop (clasic) începând cu 30 septembrie 2026. Conform documentației oficiale a Microsoft, „conexiunile la serviciile clasice vor fi blocate după retragere.” Prin urmare, retragerea afectează tipul specific de servicii legate de gestionarea desktopurilor virtuale și aplicațiilor utilizând modelul de implementare Azure Virtual Desktop (clasic).

Cu toate acestea, procesul de retragere nu se aplică desktopului virtual modern Azure care utilizează Azure Resource Manager (ARM). Astfel, principala preocupare pentru utilizatorii care încă utilizează resursele clasice este incapacitatea de a stabili conexiuni cu serviciile care funcționau anterior. Prin urmare, utilizatorii ar trebui să fie în mod special conștienți de gestionarea resurselor clasice, deoarece resursele în sine nu vor dispărea după data de retragere.

Ce anume a fost retras?

Azure Virtual Desktop (classic), cunoscut anterior sub numele de Windows Virtual Desktop, avea infrastructura sa de management bazată pe cmdlet-uri PowerShell dedicate, API-uri și obiecte de serviciu.

Spre deosebire de Azure Virtual Desktop modern, grupurile de gazde clasice și grupurile de aplicații nu au fost definite ca resurse unificate ale managerului de resurse Azure.

Astăzi, aceste componente sunt integrate în sistemul de gestionare a resurselor Azure, permițând administratorilor să aplice controlul accesului bazat pe roluri Azure (RBAC), să gestioneze serviciul prin portalul Azure și să utilizeze modele moderne de infrastructură ca cod pentru automatizarea desfășurării.

Capacitate	AVD Classic (retired)	AVD modern
Management	Plan de control moștenit	Manager de resurse Azure
portal Azure	Integrare limitată	Integrare nativă
Controlul accesului	Roluri de chiriaș moștenit	Azure RBAC
Automatizare	API-uri clasice și PowerShell	ARM, API-uri, Az PowerShell
Livrarea desktopului și aplicațiilor	Conexiuni blocate	Susținut
Starea serviciului	Pensionat	Susținut

Pensionarea reprezintă o schimbare în arhitectura serviciului de bază, nu doar o redenumire a produsului.

Funcționează încă Modern Azure Virtual Desktop?

Da. Azure Virtual Desktop modern este suportat și continuă să ofere desktopuri complete Windows, platforme multisesiune și livrarea aplicațiilor individuale prin RemoteApp.

Organizațiile care utilizează deja grupurile de gazde integrate cu Azure Resource Manager (ARM) nu sunt afectate de retragerea serviciului clasic.

Managerii IT ar trebui să observe de asemenea diferența dintre sfârșitul suportului pentru Azure Virtual Desktop clasic și sfârșitul separat al suportului pentru clienții Remote Desktop mai vechi. Clientul Remote Desktop pentru Windows (MSI) era programat să ajungă la sfârșitul suportului pentru medii de cloud public pe 27 martie 2026 și pentru Azure Virtual Desktop (clasic) pe 28 septembrie 2026.

Cum pot echipele IT să identifice implementările Azure Virtual Desktop Classic?

Primul pas este să identificăm dacă există sarcini de producție care depind încă de arhitectura retrasă.

Acest lucru este deosebit de critic pentru sistemele care au fost puse în producție cu ani în urmă și care pot fi fost preluate de noi administratori sau ignorate în documentația actuală a infrastructurii.

Verificați integrarea Azure Resource Manager

Ar trebui să începi prin inspectarea resurselor Azure Virtual Desktop în portalul Azure. Implementările moderne Azure Virtual Desktop expun grupuri de gazde, grupuri de aplicații și spații de lucru ca resurse Azure într-o subscripție și un grup de resurse. În contrast, implementările clasice erau folosite pentru a expune obiecte de serviciu gestionate în moduri diferite.

Prezența următoarelor elemente Azure Virtual Desktop reprezintă un indicator puternic al unei implementări clasice:

• Pooluri de gazde care utilizează modulul PowerShell clasic Azure Virtual Desktop
• Referințe istorice la un chiriaș de serviciu clasic sau API de serviciu clasic
• Grupuri de aplicații care nu au resurse ARM corespunzătoare
• Mașini virtuale gazdă de sesiune care se referă la documentația mai veche

În același timp, absența unui grup de gazde în portalul Azure nu este neapărat o indicație a unei implementări clasice. Ar trebui să verificați întotdeauna ce abonament, chiriaș Microsoft Entra și control al accesului bazat pe rol are utilizatorul înainte de a analiza problema mai departe.

Revizuirea instrumentelor de gestionare a moștenirii și a dependențelor

Scripturile de implementare și repositoarele de automatizare pot servi ca surse suplimentare de dovezi.

De exemplu, prezența scripturilor care conțin referințe Microsoft.RDInfra.RDPowerShell sau operațiuni clasice de gestionare la nivel de chiriaș ar sugera că mediul a fost configurat cu stiva de gestionare mai veche.

Mediile moderne vor utiliza interfețele de gestionare integrate cu Azure Resource Manager și modulele asociate Az PowerShell.

Administratorii ar trebui, de asemenea, să inventarieze toate resursele de aplicație, utilizator și infrastructură asociate cu grupurile de gazde potențial afectate.

Aceasta include examinarea mașinilor virtuale gazdă de sesiune, a asignărilor de aplicații, a locațiilor de stocare a profilurilor, a dependențelor de autentificare, a configurațiilor de rețea și a repositoarelor de backup. documentația de migrare manuală Microsoft conține comparații detaliate între modelul clasic de obiect de serviciu și modelul de resurse integrat Azure Resource Manager (ARM).

Ce se poate întâmpla cu resursele dvs. existente după ce Azure Virtual Desktop Classic se retrage?

Cea mai importantă diferență este între serviciul de conexiune retras și infrastructura Azure de bază.

În timp ce conexiunile desktop clasice sunt blocate, mașinile virtuale existente, resursele de stocare și datele aplicațiilor pot rămâne în continuare disponibile.

Mașinile virtuale existente și stocarea pot rămâne disponibile

Mașinile virtuale Azure sunt resurse care sunt gestionate de sine stătător, fără a se baza pe planul de control al serviciului clasic retras. Astfel, mașinile virtuale gazdă de sesiune, discurile gestionate și resursele de rețea care au fost create în abonament ar putea exista în continuare.

Cu toate acestea, ele nu pot fi folosite pentru a restabili brokerul de conexiuni retras. Niciună mașină virtuală creată în noua infrastructură Azure nu este disponibilă pentru a readuce experiența desktop a unei organizații în starea de funcționare.

Administratorii ar trebui să examineze fiecare resursă cu atenție, iar dacă aceasta poate fi reutilizată pentru o configurație suportată, ar trebui să efectueze următorii pași.

Este esențial să verificați dacă sistemul de operare al mașinii virtuale este suportat și dacă aplicațiile și configurațiile de securitate sunt compatibile.

Accesul la aplicații și datele utilizatorului necesită verificări separate

Utilizatorii care s-au conectat prin tipul de sesiune desktop clasic sau RemoteApp nu vor mai putea lansa aplicațiile lor prin acest serviciu.

Rezultatul retragerii serviciului ar putea fi pierderea accesului la desktopuri, aplicații publicate și perturbări ale proceselor de afaceri.

Cu toate acestea, retragerea serviciului nu garantează că datele legate de utilizator sunt șterse.

În cele mai multe cazuri, este probabil ca datele utilizatorilor să fie păstrate pe Azure Files, discuri VM sau alte medii de stocare, dar păstrarea și accesibilitatea acestei informații ar depinde de modul în care a fost configurată, securizată cu permisiuni, salvată, etc…

Prin urmare, înainte de a dezactiva sau migra sistemele implicate, departamentele IT trebuie să se asigure că au păstrat toate datele necesare.

Poate o echipă să migreze în continuare Azure Virtual Desktop Classic după ce acesta se retrage?

Microsoft documentează două căi de migrare pentru tranziția de la Azure Virtual Desktop (clasic) la noul Azure Virtual Desktop integrat ARM: migrare automată și migrare manuală.

Ambele opțiuni au fost concepute pentru a fi viabile până la 30 septembrie 2026.

Deoarece acea dată este în trecut, administratorii nu ar trebui să considere instrumentele descrise în documentație ca fiind gata pentru producție în toate scenariile.

Documentația Microsoft nu oferă îndrumări cu privire la perioada de tranziție.

Prin urmare, organizațiile nu ar trebui să se bazeze pe niciun instrument și proces de tranziție post-retragere.

Opțiunea 1: Migrare automată

procesul de migrare automată al Microsoft utilizează un instrument bazat pe PowerShell pentru a muta configurațiile de servicii clasice eligibile către resurse ARM.

Documentația companiei recomandă utilizatorilor să aibă un abonament Azure activ cu permisiunile necesare și să îndeplinească cerințele de mediu enumerate de modulul de migrare.

De exemplu, liniile directoare ale Microsoft sugerează ca utilizatorii să fie delegați cu permisiuni de Contributor pentru a crea resurse Azure și permisiuni de Administrator al Accesului Utilizatorilor pentru a gestiona apartenența la grupurile de aplicații.

Cu toate acestea, este esențial să recunoaștem că instrumentul nu poate garanta recuperarea datelor după retragere.

Organizațiile cu implementări clasice active ar trebui să consulte suportul Microsoft pentru a confirma dacă procesul de migrare este o opțiune disponibilă pentru mediul lor.

Opțiunea 2: Migrare manuală sau reconstrucție

Migrarea manuală necesită crearea de resurse moderne Azure Virtual Desktop și reconfigurarea configurației serviciului.

În funcție de cazul specific, administratorii ar putea avea nevoie să:

• Creează grupuri de aplicații, piscine de gazde bazate pe ARM și spații de lucru integrate
• Stabiliți sau înlocuiți mașinile virtuale gazdă ale sesiunii
• Înregistrați gazde de sesiune compatibile cu noile grupuri de gazde
• Recreați asocierile utilizatorului și aplicației
• Ajustați configurațiile de identitate, rețea, securitate și profil

Abordarea manuală devine necesară atunci când configurațiile vechi conțin complexitate nedocumentată, personalizare extinsă sau când instrumentele moderne de migrare se dovedesc insuficiente.

În mod notabil, reconstrucția infrastructurii de livrare nu implică întotdeauna înlocuirea completă a aplicațiilor și datelor.

Componentele rămase pot fi adesea reutilizate prin evaluări adecvate de compatibilitate, evaluări de licențiere și audite de securitate.

Decizia ar trebui să se bazeze pe starea actuală a resurselor existente și pe suportul disponibil din partea Microsoft.

Situație	Abordare pentru evaluare
Configurare clasică eligibilă și Microsoft confirmă suportul pentru migrare	Migrare automată
Configurare clasică complexă sau inaccesibilă	Reconstrucție manuală
VM-urile și datele existente rămân disponibile	Reconstruiți serviciile de livrare și evaluați reutilizarea
Sarcinile moștenite nu mai sunt necesare	Decomisionare sigură
Desktopurile găzduite în Azure nu mai sunt necesare	Arhitectură alternativă de livrare

Ce ar trebui să facă echipele IT dacă au ratat termenul limită de pensionare?

Organizațiile care nu și-au finalizat migrarea până la 30 septembrie 2026 ar trebui să prioritizeze conservarea resurselor și restabilirea accesului la aplicațiile de afaceri.

În loc să încerce multiple conexiuni la serviciul retras, administratorii sunt sfătuiți să efectueze un proces de recuperare.

Pasul 1: Evaluarea impactului serviciului

Identificați care utilizatori, desktopuri și aplicații sunt indisponibile.

Aflați dacă este vorba despre un mediu întreg sau despre sarcini de lucru specifice care sunt afectate. Confirmați că problema este legată de o retragere clasică și nu de o altă problemă legată de autentificare, rețea sau gazda sesiunii.

Pasul 2: Păstrați infrastructura și datele

Revizuirea abonamentelor Azure pentru a identifica mașinile virtuale curente, discurile gestionate, conturile de stocare și resursele de rețea

Documentați dependențele și asigurați-vă backup-uri există înainte de a lua orice acțiune. Nu ștergeți resursele până când datele aplicației, profilurile utilizatorilor și informațiile de configurare nu au fost identificate.

Pasul 3: Confirmarea opțiunilor de recuperare cu Microsoft

Contactați suportul Microsoft pentru a vă asigura că există în continuare proceduri de migrare/recuperare suportate disponibile.

Instrucțiunile inițiale de migrare automată/manuală au fost dezvoltate având în vedere data de pensionare și, prin urmare, nu ar trebui să se presupună că se aplică.

În cazul în care configurația clasică nu poate fi migrată, poate fi necesar să reconstruim mediul cu resurse Azure Virtual Desktop acceptate.

Pasul 4: Restaurare livrare aplicație și desktop

Selectați o arhitectură care să susțină aplicațiile și desktopurile de care au nevoie utilizatorii.

Pentru organizațiile care plănuiesc să rămână pe Azure Virtual Desktop, acest lucru implică de obicei configurarea grupurilor de gazde integrate ARM, gazdelor de sesiune acceptate, grupurilor de aplicații și atribuțiilor utilizatorilor.

Unele organizații pot constata că altceva publicarea aplicațiilor sau soluția desktop se potrivește mai bine nevoilor lor.

Scopul este de a restabili accesul, evitând complexitatea și suprasarcina inutilă a configurației anterioare.

Care este modalitatea de validare a unei migrații Azure Virtual Desktop?

Restaurarea infrastructurii nu garantează operațiuni normale ale utilizatorilor.

O migrare sau o reconstrucție trebuie, prin urmare, să fie validată la nivelurile de serviciu și aplicație.

Verificați autentificarea și accesul utilizatorului

Confirmați că utilizatorii se pot autentifica și accesa resursele care le-au fost atribuite.

Verificați Microsoft Entra, autentificarea multifactor, politicile de acces condiționat și atribuțiile Azure RBAC, după caz.

Administratorii ar trebui să confirme că permisiunile sunt aliniate cu principiul privilegiului minim și că nu există modele de acces moștenite care au fost transferate din greșeală.

Testați aplicațiile critice pentru afaceri

Testați aplicațiile și desktopurile publicate utilizând conturi de utilizator reprezentative distincte.

Activitățile de validare ar trebui să includă lansarea aplicației, conexiunile la baza de date, partajările de rețea, imprimarea, redirecționarea clipboard-ului și perifericele necesare, dacă este cazul.

Aplicațiile legate de moștenire trebuie să fie luate în considerare în mod special, deoarece ar putea necesita o configurație specifică a sistemului de operare, un traseu de rețea sau un component al aplicației.

Un exemplu de aplicație moștenită ar putea fi o aplicație ERP care se lansează cu succes, dar nu reușește să se conecteze la baza sa de date din noul gazdă de sesiune.

Validare Profiluri, Performanță și Operațiuni

Companiile care utilizează FSLogix sau orice alte instrumente de profilare ar trebui să se asigure că totul este atașat corect, este persistent și poate fi accesat corespunzător.

Este esențial să-l testați prin conectarea pentru prima dată și verificând dacă totul va funcționa bine atunci când un utilizator deschide o aplicație și în timpul următoarei conectări. De asemenea, este esențial să se asigure că procesele sunt monitorizate, salvate și restaurate.

Migrarea este completă doar când totul este pregătit, inclusiv utilizatorii fiind capabili să acceseze aplicațiile lor. Trebuie să fie posibil să se mențină sistemul în mod corespunzător.

Ar trebui organizațiile să reconsidere arhitectura de livrare a desktop-urilor lor?

Retragerea Azure Virtual Desktop (clasic) este în principal o problemă de ciclu de viață al platformei, dar oferă și o oportunitate de a evalua dacă platforma actuală de livrare a desktop-ului continuă să vă susțină nevoile.

Trecerea la Azure Virtual Desktop modern este alegerea evidentă pentru mulți, în special pentru cei care sunt deja axați pe Azure și utilizează desktopuri găzduite în Azure.

Alte organizații au cerințe mai puțin complexe.

Când are sens Azure Virtual Desktop modern?

Desktop Virtual Modern Azure poate fi o alegere bună pentru organizațiile care necesită desktopuri și aplicații Windows gestionate central, găzduite pe Azure.

Permite modele multisesiune, RemoteApp și instrumente de administrare și ID Microsoft.

Are înțeles pentru întreprinderile care au o prezență existentă în Azure, dar departamentele IT trebuie să se ocupe în continuare de complexitățile cloud-ului, inclusiv licențierea, rețelistică, stocare, administrare și aspecte operaționale.

Când este o altă arhitectură de publicare a aplicațiilor Windows adecvată?

Nu toate organizațiile necesită un mediu de virtualizare desktop complet implementat găzduit în Microsoft Azure.

Unele întreprinderi au nevoie doar de limitat acces la distanță la aplicații Windows specifice, cum ar fi aplicațiile financiare sau ERP sau aplicațiile moștenite de tip linie de afaceri.

Aceste organizații pot lua în considerare publicarea aplicațiilor care sunt găzduite pe servere Windows gestionate central, în loc să implementeze o infrastructură de birou virtualizat (VDI) generalizată.

Modern Azure Virtual Desktop nu este doar despre virtualizarea desktopurilor sau aplicațiilor, ci și despre publicarea aplicațiilor.

Astăzi, este posibil să publicați aplicații Azure folosind metoda RemoteApp.

Realitatea este că nu există o dicotomie în domeniul livrării aplicațiilor, ci mai degrabă un continuum care se întinde de la publicarea aplicațiilor până la virtualizarea desktopului.

Discuția ar trebui să se concentreze pe găsirea celei mai relevante arhitecturi de livrare a aplicațiilor pentru organizația dată și cazurile de utilizare.

De exemplu, dacă există o aplicație de lungă durată găzduită într-un folder Windows Server care este accesată de un set de utilizatori autorizați, organizația nu trebuie să o publice în Azure Virtual Desktop atunci când infrastructura veche funcționează în continuare corect.

În schimb, ar putea fi benefic pentru astfel de întreprinderi să își păstreze locația de găzduire a aplicațiilor la sediu, în timp ce își îmbunătățesc metoda de acces la aplicații.

Ce factori ar trebui să ghideze decizia?

Departamentele IT ar trebui să evalueze alegerea în funcție de criteriile necesităților de implementare, mai degrabă decât de caracteristicile sistemului dezafectat.

Considerație	Întrebare cheie
Găzduire	Trebuie ca sarcinile de lucru să ruleze în Azure?
Experiența utilizatorului	Desktopuri complete sau aplicații selectate?
Compatibilitate	Vor funcționa aplicațiile existente Windows?
Securitate	Cum sunt protejate identitatea și accesul la sesiune?
Management	Cine întreține infrastructura?
Licențiere	Care licențe Microsoft și software se aplică?
Scalabilitate	Câți utilizatori concurenți sunt necesari?
Cost	Care este costul total de proprietate?

Scopul este de a selecta o arhitectură de întreprindere care va satisface cerințele de disponibilitate, securitate și complexitate administrativă redusă.

Cauți o alternativă pentru livrarea aplicațiilor și desktop-ului Windows?

Migrarea la Azure Virtual Desktop modern nu este neapărat cea mai bună opțiune pentru fiecare organizație. Afacerile care au nevoie în principal de acces la aplicațiile Windows existente sau la desktopuri găzduite centralizat pot beneficia de o arhitectură mai simplă, în special atunci când nu necesită un mediu de desktop virtual complet găzduit în Azure.

TSplus Remote Access permite echipelor IT să publice aplicații Windows și desktopuri complete la distanță prin clienți compatibili RDP sau un portal web HTML5. Cu suport pentru servere Windows găzduite local și în cloud, oferă o alternativă practică pentru organizațiile care doresc să își mențină aplicațiile existente în timp ce simplifică livrarea aplicațiilor la distanță.

Concluzie

Pensionarea Azure Virtual Desktop (clasic) face esențială identificarea desfășurărilor afectate, păstrarea resurselor existente și restabilirea accesului prin infrastructura suportată. Echipele IT ar trebui să verifice opțiunile de recuperare disponibile înainte de a încerca migrarea sau reconstrucția.

Indiferent dacă organizațiile continuă cu Azure Virtual Desktop modern sau adoptă o altă arhitectură de livrare, prioritatea rămâne asigurarea unui acces sigur și fiabil la aplicații fără complexitate operațională inutilă.