Azure Virtual Desktop Classic Gepensioneerd: Volgende Stappen voor IT

Introductie

De beëindiging van Azure Virtual Desktop (klassiek) creëert een belangrijke onderscheid tussen het verlies van een legacy verbindingsdienst en de voortdurende beschikbaarheid van onderliggende Azure-resources. Voor IT-teams die de migratiedeadline hebben gemist, is het begrijpen van dit onderscheid essentieel voor het plannen van herstel zonder onnodig bestaande infrastructuur te vervangen. Dit artikel legt uit wat beëindiging betekent voor bestaande resources, hoe klassieke implementaties te identificeren, welke migratieopties nog de moeite waard zijn om te evalueren, en hoe een ondersteunde applicatiedelivery-architectuur te kiezen.

Wat betekent het wanneer Azure Virtual Desktop Classic wordt beëindigd?

Microsoft heeft officieel Azure Virtual Desktop (klassiek) met ingang van 30 september 2026 beëindigd. Op basis van de officiële documentatie van Microsoft, "zullen verbindingen met klassieke diensten na beëindiging worden geblokkeerd." Daarom heeft de beëindiging invloed op het specifieke type diensten die verband houden met het beheer van virtuele desktops en applicaties met behulp van het Azure Virtual Desktop (klassiek) implementatiemodel.

Echter, het pensioenproces is niet van toepassing op moderne Azure Virtual Desktop die gebruikmaakt van Azure Resource Manager (ARM). Daarom is de belangrijkste zorg voor de gebruikers die nog steeds de klassieke bronnen gebruiken, het onvermogen om verbinding te maken met de eerder werkende diensten. Daarom moeten de gebruikers zich bijzonder bewust zijn van het beheer van klassieke bronnen, aangezien de bronnen zelf niet zullen verdwijnen na de pensioen datum.

Wat werd er precies met pensioen gestuurd?

Azure Virtual Desktop (classic), voorheen bekend als Windows Virtual Desktop, had zijn beheerinfrastructuur gebaseerd op speciale PowerShell-cmdlets, API's en serviceobjecten.

In tegenstelling tot de moderne Azure Virtual Desktop, werden de klassieke hostpools en applicatiegroepen niet gedefinieerd als uniforme Azure-resourcebeheerbronnen.

Vandaag zijn deze componenten geïntegreerd in het Azure-resourcebeheersysteem, waardoor beheerders Azure rolgebaseerde toegangscontrole (RBAC) kunnen toepassen, de service via het Azure-portaal kunnen beheren en moderne infrastructuur-als-code patronen voor implementatieautomatisering kunnen gebruiken.

Capaciteit	AVD Classic (met pensioen)	Moderne AVD
Beheer	Legacy controlepaneel	Azure Resource Manager
Azure-portaal	Beperkte integratie	Native integratie
Toegangscontrole	Legacy tenantrollen	Azure RBAC
Automatisering	Classic API's en PowerShell	ARM, API's, Az PowerShell
Desktop en app levering	Verbonden geblokkeerd	Ondersteund
Service status	Met pensioen	Ondersteund

De pensionering vertegenwoordigt een verandering in de onderliggende service-architectuur, niet simpelweg een productnaamwijziging.

Werkt Modern Azure Virtual Desktop Nog Steeds?

Ja. Moderne Azure Virtual Desktop wordt ondersteund en blijft volledige Windows-desktops, multisessieplatforms en individuele app-levering via RemoteApp aanbieden.

Organisaties die al gebruikmaken van de Azure Resource Manager (ARM)-geïntegreerde host pools, worden niet beïnvloed door de beëindiging van de klassieke service.

IT-managers moeten ook het verschil opmerken tussen het einde van de ondersteuning voor de klassieke Azure Virtual Desktop en het aparte einde van de ondersteuning voor oudere Remote Desktop-clients. De Remote Desktop-client voor Windows (MSI) zou op 27 maart 2026 het einde van de ondersteuning voor publieke cloudomgevingen bereiken en voor Azure Virtual Desktop (klassiek) op 28 september 2026.

Hoe kunnen IT-teams Azure Virtual Desktop Classic-implementaties identificeren?

De eerste stap is om te identificeren of er nog productie-werkbelastingen afhankelijk zijn van de gepensioneerde architectuur.

Dit is vooral cruciaal voor systemen die jaren geleden in productie zijn genomen en mogelijk zijn overgenomen door nieuwe beheerders of genegeerd in de huidige infrastructuurdocumentatie.

Controleer Azure Resource Manager-integratie

Je moet beginnen met het inspecteren van de Azure Virtual Desktop-resources in het Azure-portaal. Moderne Azure Virtual Desktop-implementaties stellen hostpools, applicatiegroepen en werkruimtes bloot als Azure-resources in een abonnement en resourcegroep. In tegenstelling tot klassieke implementaties die serviceobjecten blootstelden die op verschillende manieren werden beheerd.

De aanwezigheid van de volgende Azure Virtual Desktop-elementen is een sterke indicator van een klassieke implementatie:

• Hostpools die de klassieke Azure Virtual Desktop PowerShell-module gebruiken
• Historische verwijzingen naar een klassieke servicehuurder of klassieke service-API
• Applicatiegroepen zonder bijbehorende ARM-resources
• Virtuele machines voor sessiehosts die verwijzen naar oudere documentatie

Tegelijkertijd is de afwezigheid van een hostpool in het Azure-portaal niet noodzakelijk een indicatie van een klassieke implementatie. U moet altijd controleren welke abonnement, Microsoft Entra-tenant en rolgebaseerde toegangscontrole de gebruiker heeft voordat u het probleem verder analyseert.

Beoordeling van Legacy Management Tools en Afhankelijkheden

Implementatiescripts en automatiseringsrepositories kunnen dienen als aanvullende bewijsbronnen.

Bijvoorbeeld, de aanwezigheid van scripts die Microsoft.RDInfra.RDPowerShell-referenties of klassieke tenant-niveau beheersoperaties bevatten, zou suggereren dat de omgeving was geconfigureerd met de oudere beheerstapel.

Moderne omgevingen zullen gebruikmaken van Azure Resource Manager-geïntegreerde beheersinterfaces en bijbehorende Az PowerShell-modules.

Beheerders moeten ook een inventaris opstellen van alle applicatie-, gebruikers- en infrastructuurbronnen die verband houden met mogelijk getroffen hostpools.

Dit omvat het onderzoeken van virtuele machines voor sessiehosts, applicatie-toewijzingen, opslaglocaties voor profielen, afhankelijkheden van authenticatie, netwerkinstellingen en back-uprepositories. De Microsoft handmatige migratiedocumentatie bevat gedetailleerde vergelijkingen tussen het klassieke service-objectmodel en het geïntegreerde resource-model van Azure Resource Manager (ARM).

Wat kan er gebeuren met uw bestaande middelen nadat Azure Virtual Desktop Classic is beëindigd?

Het belangrijkste verschil is tussen de gepensioneerde verbindingsdienst en de onderliggende Azure-infrastructuur.

Terwijl klassieke desktopverbindingen zijn geblokkeerd, kunnen bestaande virtuele machines, opslagbronnen en applicatiegegevens op hun plaats blijven.

Bestaande Virtuele Machines en Opslag Mogen Beschikbaar Blijven

Azure virtuele machines zijn middelen die zelfstandig worden beheerd, zonder afhankelijk te zijn van het gepensioneerde klassieke servicecontrolepaneel. Daarom kunnen sessiehost virtuele machines, beheerde schijven en netwerkmiddelen die in het abonnement zijn aangemaakt, nog steeds bestaan.

Echter, ze kunnen niet worden gebruikt om de gepensioneerde verbindingsbroker te herstellen. Geen virtuele machines die in de nieuwe Azure-infrastructuur zijn gemaakt, zijn beschikbaar om de desktopervaring van een organisatie terug te brengen naar de werkende staat.

Beheerders moeten elke bron zorgvuldig onderzoeken, en als deze kan worden hergebruikt voor een ondersteunde configuratie, moeten ze de volgende stappen uitvoeren.

Het is essentieel om te controleren of het besturingssysteem van de virtuele machine wordt ondersteund en of de applicaties en beveiligingsconfiguraties compatibel zijn.

Toegang tot applicaties en gebruikersgegevens vereisen aparte controles

Gebruikers die via het klassieke bureaublad of het RemoteApp-sessietype zijn verbonden, kunnen hun toepassingen niet langer via deze service starten.

Het resultaat van het stopzetten van de service kan verlies van toegang tot desktops, gepubliceerde applicaties en verstoringen van bedrijfsprocessen zijn.

Echter, de beëindiging van de service garandeert niet dat gebruikersgerelateerde gegevens worden verwijderd.

In de meeste gevallen zijn het waarschijnlijk de gegevens van gebruikers die worden opgeslagen op Azure Files, VM-schijven of andere opslagmedia, maar de retentie en toegankelijkheid van deze informatie zijn gebaseerd op hoe het is geconfigureerd, beveiligd met machtigingen, geback-upt, enzovoort…

Als zodanig moeten IT-afdelingen, voordat ze de betrokken systemen buiten gebruik stellen of migreren, ervoor zorgen dat ze alle benodigde gegevens hebben bewaard.

Kan een team nog steeds migreren naar Azure Virtual Desktop Classic nadat het is beëindigd?

Microsoft documenteert twee migratiepaden voor de overgang van Azure Virtual Desktop (klassiek) naar de nieuwe ARM-geïntegreerde Azure Virtual Desktop: automatische migratie en handmatige migratie.

Beide opties waren bedoeld om levensvatbaar te zijn tot 30 september 2026.

Aangezien die datum in het verleden ligt, zouden beheerders de in de documentatie beschreven tools niet als productieklare oplossingen voor alle scenario's moeten beschouwen.

De documentatie van Microsoft biedt geen richtlijnen voor de overgangsperiode.

Daarom zouden organisaties niet moeten vertrouwen op enige tools en processen voor overgang na pensionering.

Optie 1: Automatische Migratie

Microsoft's automatische migratieproces maakt gebruik van een op PowerShell gebaseerd hulpmiddel om in aanmerking komende klassieke serviceconfiguraties naar ARM-resources te verplaatsen.

De documentatie van het bedrijf raadt aan dat gebruikers een actieve Azure-abonnement hebben met de nodige machtigingen en voldoen aan de omgevingsvereisten die door de migratiemodule zijn vermeld.

Bijvoorbeeld, de richtlijnen van Microsoft suggereren dat gebruikers worden gedelegeerd met bijdragerrechten om Azure-resources te creëren en gebruikers toegangsbeheerderrechten om het lidmaatschap van applicatiegroepen te beheren.

Het is echter essentieel om te erkennen dat de tool geen garantie kan bieden voor gegevensherstel na beëindiging.

Organisaties met actieve klassieke implementaties moeten Microsoft-ondersteuning raadplegen om te bevestigen of het migratieproces een beschikbare optie is voor hun omgeving.

Optie 2: Handmatige Migratie of Reconstructie

Handmatige migratie vereist de creatie van moderne Azure Virtual Desktop-resources en de herconfiguratie van de serviceconfiguratie.

Afhankelijk van het specifieke geval, moeten beheerders mogelijk:

• Maak geïntegreerde ARM-gebaseerde hostpools, applicatiegroepen en werkruimtes
• Sessiehost virtuele machines instellen of vervangen
• Registreer compatibele sessiehosts met de nieuwe hostpools
• Herstel gebruikers- en applicatie-associaties
• Pas identiteit, netwerk, beveiliging en profielconfiguraties aan

De handmatige aanpak wordt noodzakelijk wanneer legacy-configuraties ongedocumenteerde complexiteit, uitgebreide aanpassingen bevatten, of wanneer moderne migratietools onvoldoende blijken te zijn.

Opmerkelijk is dat het reconstrueren van de leveringsinfrastructuur niet altijd een volledige vervanging van applicaties en gegevens met zich meebrengt.

Overgebleven componenten kunnen vaak opnieuw worden gebruikt door middel van geschikte compatibiliteitsbeoordelingen, licentie-evaluaties en beveiligingsaudits.

De beslissing moet gebaseerd zijn op de huidige staat van bestaande middelen en beschikbare ondersteuning van Microsoft.

Situatie	Benadering om te evalueren
In aanmerking komende klassieke configuratie en Microsoft bevestigt migratieondersteuning	Automatische migratie
Complexe of ontoegankelijke klassieke configuratie	Handleiding reconstructie
Bestaande VM's en gegevens blijven beschikbaar	Herbouw leveringsdiensten en evalueer hergebruik
Legacy workloads zijn niet langer vereist	Veilige ontmanteling
Azure-gehoste desktops zijn niet langer nodig	Alternatieve leveringsarchitectuur

Wat moeten IT-teams doen als ze de pensioendeadline hebben gemist?

Organisaties die hun migratie niet voor 30 september 2026 hebben voltooid, moeten prioriteit geven aan het behoud van middelen en het herstel van de toegang tot zakelijke applicaties.

In plaats van meerdere verbindingen met de gepensioneerde service te proberen, wordt beheerders geadviseerd een herstelproces uit te voeren.

Stap 1: Beoordeel de impact op de service

Identificeer welke gebruikers, desktops en applicaties niet beschikbaar zijn.

Ontdek of het een volledige omgeving of specifieke werklasten zijn die zijn getroffen. Bevestig dat het probleem verband houdt met een klassieke beëindiging en niet met een ander probleem met authenticatie, netwerken of sessiehosts.

Stap 2: Behoud Infrastructuur en Gegevens

Beoordeel Azure-abonnementen om huidige virtuele machines, beheerde schijven, opslagaccounts en netwerkmiddelen te identificeren.

Documentafhankelijkheden en zorg ervoor back-ups bestaan voordat u actie onderneemt. Verwijder geen middelen totdat applicatiegegevens, gebruikersprofielen en configuratie-informatie zijn geïdentificeerd.

Stap 3: Bevestig Herstelopties Met Microsoft

Neem contact op met de Microsoft-ondersteuning om ervoor te zorgen dat er nog steeds ondersteunde migratie/herstelprocedures beschikbaar zijn.

De initiële automatische/handmatige migratie-instructies zijn ontwikkeld met de pensioendatum in gedachten en moeten daarom niet als van toepassing worden aangenomen.

In het geval dat de klassieke configuratie niet kan worden gemigreerd, kan het nodig zijn om de omgeving opnieuw op te bouwen met ondersteunde Azure Virtual Desktop-resources.

Stap 4: Herstel van Toepassing en Desktop Levering

Selecteer een architectuur die de applicaties en desktops ondersteunt die gebruikers nodig hebben.

Voor organisaties die van plan zijn om op Azure Virtual Desktop te blijven, houdt dit meestal in dat ARM-geïntegreerde hostpools, ondersteunde sessiehosts, applicatiegroepen en gebruikerstoewijzingen worden ingesteld.

Sommige organisaties kunnen ontdekken dat een andere toepassing publicatie of desktopoplossing beter aansluit bij hun behoeften.

Het doel is om de toegang te herstellen terwijl de complexiteit en onnodige overhead van de vorige opzet worden vermeden.

Wat is de manier om een Azure Virtual Desktop-migratie te valideren?

Het herstellen van de infrastructuur garandeert geen normale gebruikersoperaties.

Een migratie of reconstructie moet daarom op de service- en applicatieniveaus worden gevalideerd.

Verifieer authenticatie en gebruikerstoegang

Bevestig dat gebruikers zich kunnen authentiseren en toegang hebben tot de middelen die aan hen zijn toegewezen.

Controleer Microsoft Entra, multifactor-authenticatie, voorwaardelijke toegangsbeleid en Azure RBAC-toewijzingen indien van toepassing.

Beheerders moeten bevestigen dat de machtigingen in overeenstemming zijn met het principe van de minste privileges en dat er geen verouderde toegangsmodellen zijn die per ongeluk zijn doorgegeven.

Test zakelijke kritieke toepassingen

Test gepubliceerde applicaties en desktops door gebruik te maken van verschillende representatieve gebruikersaccounts.

Validatieactiviteiten moeten het starten van applicaties, databaseverbindingen, netwerkschijven, afdrukken, klembordomleiding en vereiste randapparatuur indien aanwezig omvatten.

Legacy-applicaties moeten speciaal in overweging worden genomen, aangezien ze mogelijk een specifieke OS-configuratie, netwerkpad of applicatiecomponent vereisen.

Een voorbeeld van een legacy-applicatie kan een ERP-applicatie zijn die succesvol wordt gestart, maar niet kan verbinden met zijn database vanaf de nieuwe sessiehost.

Valideer Profielen, Prestaties en Operaties

Bedrijven die FSLogix of een van de andere profileringshulpmiddelen gebruiken, moeten ervoor zorgen dat alles correct is gekoppeld, persistent is en op de juiste manier toegankelijk kan worden.

Het is van vitaal belang om het te testen door voor de eerste keer in te loggen en te controleren of alles goed werkt wanneer een gebruiker een applicatie opent en tijdens de volgende aanmelding. Het is ook essentieel om ervoor te zorgen dat de processen worden gemonitord, geback-upt en hersteld.

De migratie is pas compleet wanneer alles gereed is, inclusief dat gebruikers toegang hebben tot hun applicaties. Het moet mogelijk zijn om het systeem goed te onderhouden.

Moeten organisaties hun desktopleveringsarchitectuur heroverwegen?

Azure Virtual Desktop (classic) pensioen is voornamelijk een kwestie van de levenscyclus van het platform, maar het biedt ook een kans om te beoordelen of het huidige desktopleveringsplatform blijft voldoen aan uw behoeften.

De overstap naar moderne Azure Virtual Desktop is de voor de hand liggende keuze voor velen, vooral voor degenen die al Azure-first zijn en gebruikmaken van Azure-gehoste desktops.

Andere organisaties hebben minder complexe vereisten.

Wanneer is Modern Azure Virtual Desktop zinvol?

Moderne Azure Virtual Desktop kan een goede keuze zijn voor organisaties die centraal beheerde Windows-desktops en apps vereisen, gehost op Azure.

Het stelt multisessie, RemoteApp-modellen en Microsoft ID- en beheertools in staat.

Het is logisch voor bedrijven die al een Azure-voetafdruk hebben, maar IT-afdelingen moeten nog steeds omgaan met de complexiteit van de cloud, inclusief licenties, netwerken, opslag, administratie en operationele aspecten.

Wanneer is een andere Windows-toepassingspublicatiearchitectuur geschikt?

Niet alle organisaties hebben een volledig geïmplementeerde desktopvirtualisatieomgeving nodig die gehost wordt in Microsoft Azure.

Sommige bedrijven hebben slechts beperkte nodig Externe toegang voor specifieke Windows-toepassingen, zoals financiële of ERP-toepassingen of verouderde bedrijfstoepassingen.

Deze organisaties kunnen overwegen om applicaties te publiceren die worden gehost op centraal beheerde Windows-servers in plaats van een gegeneraliseerde virtuele desktopinfrastructuur (VDI) uit te rollen.

Moderne Azure Virtual Desktop gaat niet alleen over desktop- of applicatievirtualisatie, maar ook over applicatiepublicatie.

Vandaag is het mogelijk om Azure-toepassingen te publiceren met de RemoteApp-methode.

De realiteit is dat er geen dichotomie is in de applicatieleveringsruimte, maar eerder een continuüm dat loopt van applicatiepublicatie tot desktopvirtualisatie.

De discussie moet zich richten op het vinden van de meest relevante applicatieleveringsarchitectuur voor de gegeven organisatie en gebruikssituaties.

Bijvoorbeeld, als er een langlopende applicatie is die gehost wordt in een Windows Server-map en die toegankelijk is voor een groep geautoriseerde gebruikers, hoeft de organisatie deze niet te publiceren in Azure Virtual Desktop wanneer de legacy-infrastructuur nog steeds goed functioneert.

In plaats daarvan kan het voordelig zijn voor dergelijke ondernemingen om hun applicatiehostinglocatie on-premises te laten terwijl ze hun applicatie-toegangsmethode upgraden.

Welke factoren moeten de beslissing begeleiden?

IT-afdelingen moeten de keuze evalueren aan de hand van de criteria van implementatiebehoeften, in plaats van de functies van het buitengebruik gestelde systeem.

Overweging	Kernvraag
Hosting	Moeten workloads in Azure draaien?
Gebruikerservaring	Volledige desktops of geselecteerde applicaties?
Compatibiliteit	Zullen bestaande Windows-toepassingen werken?
Beveiliging	Hoe worden identiteit en sessietoegang beschermd?
Beheer	Wie onderhoudt de infrastructuur?
Licenties	Welke Microsoft- en softwarelicenties zijn van toepassing?
Schaalbaarheid	Hoeveel gelijktijdige gebruikers zijn vereist?
Kosten	Wat zijn de totale eigendomskosten?

Het doel is om een enterprise-architectuur te selecteren die zal voldoen aan de vereisten van beschikbaarheid, beveiliging en verminderde administratieve complexiteit.

Zoekt u een alternatief voor Windows-toepassingen en desktoplevering?

Migreren naar een moderne Azure Virtual Desktop is niet per se de beste optie voor elke organisatie. Bedrijven die voornamelijk toegang nodig hebben tot bestaande Windows-toepassingen of centraal gehoste desktops, kunnen profiteren van een eenvoudigere architectuur, vooral wanneer ze geen volledig Azure-gehoste virtuele desktopomgeving nodig hebben.

TSplus Remote Access maakt het IT-teams mogelijk om Windows-toepassingen en volledige externe desktops te publiceren via RDP-compatibele clients of een HTML5-webportaal. Met ondersteuning voor on-premises en cloud-gehoste Windows-servers biedt het een praktische alternatieve oplossing voor organisaties die hun bestaande toepassingen willen behouden terwijl ze de levering van externe toepassingen vereenvoudigen.

Conclusie

De beëindiging van Azure Virtual Desktop (klassiek) maakt het essentieel om getroffen implementaties te identificeren, bestaande middelen te behouden en toegang te herstellen via ondersteunde infrastructuur. IT-teams moeten beschikbare herstelopties verifiëren voordat ze migratie of reconstructie proberen.

Of organisaties doorgaan met moderne Azure Virtual Desktop of een andere leveringsarchitectuur aannemen, blijft de prioriteit het waarborgen van veilige, betrouwbare applicatie-toegang zonder onnodige operationele complexiteit.