Azure Virtual Desktop Classic Pensioneret: Næste skridt for IT

Introduktion

Pensioneringen af Azure Virtual Desktop (klassisk) skaber en vigtig skelnen mellem tabet af en legacy-forbindelsestjeneste og den fortsatte tilgængelighed af underliggende Azure-ressourcer. For IT-teams, der missede migrationsfristen, er det essentielt at forstå denne skelnen for at planlægge genopretning uden unødvendigt at erstatte eksisterende infrastruktur. Denne artikel forklarer, hvad pensionering betyder for eksisterende ressourcer, hvordan man identificerer klassiske implementeringer, hvilke migrationsmuligheder der stadig er værd at evaluere, og hvordan man vælger en understøttet applikationsleveringsarkitektur.

Hvad betyder det, når Azure Virtual Desktop Classic udfases?

Microsoft har officielt pensioneret Azure Virtual Desktop (klassisk) pr. 30. september 2026. Baseret på Microsofts officielle dokumentation, "vil forbindelser til klassiske tjenester blive blokeret efter pensioneringen." Derfor påvirker pensioneringen den specifikke type tjenester relateret til administrationen af virtuelle desktops og applikationer ved hjælp af Azure Virtual Desktop (klassisk) implementeringsmodel.

Dog, pensionsprocessen gælder ikke for moderne Azure Virtual Desktop, der bruger Azure Resource Manager (ARM). Derfor er den største bekymring for brugerne, der stadig bruger de klassiske ressourcer, manglen på mulighed for at etablere forbindelser til de tidligere fungerende tjenester. Derfor bør brugerne være særligt opmærksomme på den klassiske ressourcehåndtering, da ressourcerne selv ikke vil forsvinde efter pensionsdatoen.

Hvad blev præcist pensioneret?

Azure Virtual Desktop (classic), tidligere kendt som Windows Virtual Desktop, havde sin administrationsinfrastruktur baseret på dedikerede PowerShell cmdlets, API'er og serviceobjekter.

I modsætning til den moderne Azure Virtual Desktop blev de klassiske værtspuljer og applikationsgrupper ikke defineret som enhedlige Azure resource manager-ressourcer.

I dag er disse komponenter integreret i Azure ressourceadministrationssystemet, hvilket giver administratorer mulighed for at anvende Azure rollebaseret adgangskontrol (RBAC), administrere tjenesten gennem Azure-portalen og bruge moderne infrastruktur-som-kode mønstre til automatisering af implementering.

Funktionalitet	AVD Classic (udgået)	Moderne AVD
Ledelse	Legacy kontrolplan	Azure Resource Manager
Azure portal	Begrænset integration	Native integration
Adgangskontrol	Arvige lejerroller	Azure RBAC
Automatisering	Klassiske API'er og PowerShell	ARM, APIs, Az PowerShell
Desktop og app levering	Forbindelser blokeret	Understøttet
Servicestatus	Pensioneret	Understøttet

Pensioneringen repræsenterer en ændring i den underliggende servicearkitektur, ikke blot en produktomdøbning.

Fungerer Modern Azure Virtual Desktop stadig?

Ja. Moderne Azure Virtual Desktop understøttes og fortsætter med at tilbyde fulde Windows-desktops, multisession platforme og individuel app-levering gennem RemoteApp.

Organisationer, der allerede bruger de Azure Resource Manager (ARM)-integrerede værtspuljer, påvirkes ikke af udfasningen af den klassiske tjeneste.

IT-chefer bør også bemærke forskellen mellem slutningen af support for den klassiske Azure Virtual Desktop og den separate slutning af support for ældre Remote Desktop-klienter. Remote Desktop-klienten til Windows (MSI) var planlagt til at nå slutningen af support for offentlige cloud-miljøer den 27. marts 2026 og for Azure Virtual Desktop (klassisk) den 28. september 2026.

Hvordan kan IT-teams identificere Azure Virtual Desktop Classic-implementeringer?

Det første skridt er at identificere, om der stadig er produktionsarbejdsbelastninger, der er afhængige af den udfasede arkitektur.

Dette er især kritisk for systemer, der blev sat i produktion for år siden og muligvis er blevet overtaget af nye administratorer eller ignoreret i den nuværende infrastruktur dokumentation.

Tjek Azure Resource Manager-integration

Du bør starte med at inspicere Azure Virtual Desktop-ressourcerne i Azure-portalen. Moderne Azure Virtual Desktop-implementeringer eksponerer værtspools, applikationsgrupper og arbejdsområder som Azure-ressourcer i et abonnement og en ressourcegruppe. I modsætning hertil brugte klassiske implementeringer at eksponere serviceobjekter, der blev administreret på forskellige måder.

Tilstedeværelsen af de følgende Azure Virtual Desktop-elementer er en stærk indikator for en klassisk implementering:

• Værtspuljer, der bruger det klassiske Azure Virtual Desktop PowerShell-modul
• Historiske referencer til en klassisk servicelejer eller klassisk service-API
• Applikationsgrupper, der mangler tilsvarende ARM-ressourcer
• Session vært virtuelle maskiner, der henviser til ældre dokumentation

Samtidig er fraværet af en værtspool i Azure-portalen ikke nødvendigvis en indikation af en klassisk implementering. Du bør altid kontrollere, hvilken abonnement, Microsoft Entra-lejer og rollebaseret adgangskontrol brugeren har, før du analyserer problemet nærmere.

Gennemgå Legacy Management Værktøjer og Afhængigheder

Implementeringsscripts og automatiseringslagre kan fungere som supplerende kilder til beviser.

For eksempel ville tilstedeværelsen af scripts, der indeholder Microsoft.RDInfra.RDPowerShell-referencer eller klassiske administrationsoperationer på lejer-niveau, antyde, at miljøet var konfigureret med den ældre administrationsstak.

Moderne miljøer vil udnytte Azure Resource Manager-integrerede administrationsgrænseflader og tilknyttede Az PowerShell-moduler.

Administratorer bør også optegne alle applikationer, brugere og infrastrukturressourcer, der er forbundet med potentielt berørte værtspuljer.

Dette inkluderer undersøgelse af session vært virtuelle maskiner, applikation tildelinger, profil lagringssteder, autentificeringsafhængigheder, netværkskonfigurationer og backup-repositorier. Microsoft manuel migrationsdokumentation indeholder detaljerede sammenligninger mellem den klassiske serviceobjektmodel og Azure Resource Manager (ARM)-integrerede ressource model.

Hvad kan der ske med dine eksisterende ressourcer, efter at Azure Virtual Desktop Classic udfases?

Den vigtigste forskel er mellem den pensionerede forbindelsestjeneste og den underliggende Azure-infrastruktur.

Mens klassiske desktop-forbindelser er blokeret, kan eksisterende virtuelle maskiner, lagerressourcer og applikationsdata forblive på plads.

Eksisterende virtuelle maskiner og lager kan forblive tilgængelige

Azure virtuelle maskiner er ressourcer, der administreres på egen hånd, uden at være afhængige af den udfasede klassiske servicekontrolplan. Således kan session vært virtuelle maskiner, administrerede diske og netværksressourcer, der blev oprettet i abonnementet, stadig eksistere.

Dog kan de ikke bruges til at genoprette den pensionerede forbindelsesbroker. Ingen virtuelle maskiner oprettet i den nye Azure-infrastruktur er tilgængelige for at returnere en organisations desktopoplevelse til den fungerende tilstand.

Administratorer bør nøje gennemgå hver ressource, og hvis den kan genbruges til en understøttet konfiguration, bør de udføre følgende trin.

Det er vigtigt at kontrollere, om operativsystemet for den virtuelle maskine er understøttet, og om applikationerne og sikkerhedskonfigurationerne er kompatible.

Applikationsadgang og brugerdata kræver separate kontroller

Brugere, der har oprettet forbindelse via den klassiske desktop- eller RemoteApp-sessionstype, vil ikke længere kunne starte deres applikationer gennem denne tjeneste.

Resultatet af at nedlægge tjenesten kan være tab af adgang til skriveborde, publicerede applikationer og forstyrrelser i forretningsprocesser.

Dog garanterer pensioneringen af tjenesten ikke, at brugerrelaterede data slettes.

I de fleste tilfælde er det sandsynligvis brugernes data, der er gemt på Azure Files, VM-diske eller andre lagermedier, men opbevaringen og tilgængeligheden af disse oplysninger ville være baseret på, hvordan det blev konfigureret, sikret med tilladelser, sikkerhedskopieret osv...

Som sådan, før nedlæggelse eller migrering af de involverede systemer, skal IT-afdelingerne sikre, at de har bevaret alle nødvendige data.

Kan et team stadig migrere Azure Virtual Desktop Classic, efter det er blevet pensioneret?

Microsoft dokumenterer to migrationsveje for overgangen fra Azure Virtual Desktop (klassisk) til den nye ARM-integrerede Azure Virtual Desktop: automatisk migration og manuel migration.

Begge muligheder var beregnet til at være levedygtige indtil den 30. september 2026.

Da den dato er i fortiden, bør administratorer ikke betragte værktøjer beskrevet i dokumentationen som produktionsklare til alle scenarier.

Microsofts dokumentation giver ikke vejledning om overgangsperioden.

Derfor bør organisationer ikke stole på nogen værktøjer og processer til overgangen efter pensionering.

Mulighed 1: Automatisk migrering

Microsofts automatiske migrationsproces udnytter et PowerShell-baseret værktøj til at flytte berettigede klassiske servicekonfigurationer til ARM-ressourcer.

Virksomhedens dokumentation anbefaler, at brugerne har et aktivt Azure-abonnement med de nødvendige tilladelser og opfylder de miljøkrav, der er angivet af migrationsmodulet.

For eksempel foreslår Microsofts retningslinjer, at brugere tildeles bidragyderrettigheder til at oprette Azure-ressourcer og brugeradgangsadministratorrettigheder til at administrere medlemskab af applikationsgrupper.

Det er dog vigtigt at anerkende, at værktøjet ikke kan garantere datagendannelse efter pensionering.

Organisationer med aktive klassiske implementeringer bør kontakte Microsoft-support for at bekræfte, om migrationsprocessen er en tilgængelig mulighed for deres miljø.

Mulighed 2: Manuel migration eller rekonstruktion

Manuel migration kræver oprettelse af moderne Azure Virtual Desktop-ressourcer og omkonfiguration af servicekonfiguration.

Afhængigt af den specifikke sag kan administratorer have brug for at:

• Opret integrerede ARM-baserede værtspuljer, applikationsgrupper og arbejdsområder
• Opret eller erstat session vært virtuelle maskiner
• Registrer kompatible sessionsværter med de nye værtspuljer
• Genskab bruger- og applikationsforbindelser
• Juster identitets-, netværks-, sikkerheds- og profilkonfigurationer

Den manuelle tilgang bliver nødvendig, når ældre konfigurationer indeholder udocumenteret kompleksitet, omfattende tilpasning eller når moderne migrationsværktøjer viser sig at være utilstrækkelige.

Bemærkelsesværdigt involverer rekonstruktion af leveringsinfrastrukturen ikke altid en fuldstændig udskiftning af applikationer og data.

De resterende komponenter kan ofte genbruges gennem passende kompatibilitetsvurderinger, licensvurderinger og sikkerhedsrevisioner.

Beslutningen bør baseres på den nuværende tilstand af eksisterende ressourcer og tilgængelig support fra Microsoft.

Situation	Tilgang til evaluering
Berettiget klassisk konfiguration og Microsoft bekræfter migrationssupport	Automatisk migration
Kompleks eller utilgængelig klassisk konfiguration	Manuel rekonstruktion
Eksisterende VMs og data forbliver tilgængelige	Genopbyg leveringstjenester og vurder genbrug
Legacy arbejdsbelastninger er ikke længere nødvendige	Sikker afvikling
Azure-hostede desktops er ikke længere nødvendige	Alternativ leveringsarkitektur

Hvad skal IT-teams gøre, hvis de har overset pensionsfristen?

Organisationer, der ikke har afsluttet deres migration inden den 30. september 2026, bør prioritere bevarelsen af ressourcer og genoprettelsen af adgangen til forretningsapplikationer.

I stedet for at forsøge flere forbindelser til den nedlagte tjeneste, anbefales det, at administratorer udfører en genoprettelsesproces.

Trin 1: Vurder servicepåvirkningen

Identificer hvilke brugere, skriveborde og applikationer der ikke er tilgængelige.

Find ud af, om det er et helt miljø eller specifikke arbejdsbelastninger, der er påvirket. Bekræft, at problemet er relateret til en klassisk pensionering og ikke et andet problem med autentificering, netværk eller session vært.

Trin 2: Bevar infrastruktur og data

Gennemgå Azure-abonnementer for at identificere nuværende virtuelle maskiner, administrerede diske, lagerkonti og netværksressourcer

Dokumentafhængigheder og sikring sikkerhedskopier eksistere før der træffes nogen handling. Slet ikke ressourcer, før applikationsdata, brugerprofiler og konfigurationsoplysninger er blevet identificeret.

Trin 3: Bekræft gendannelsesmuligheder med Microsoft

Kontakt Microsoft-support for at sikre, at der stadig er understøttede migrations-/gendannelsesprocedurer tilgængelige.

De indledende automatiske/manuelle migrationsinstruktioner blev udviklet med pensionsdatoen i tankerne og bør derfor ikke antages at gælde.

I tilfælde hvor den klassiske konfiguration ikke kan migreres, kan det være nødvendigt at genopbygge miljøet med understøttede Azure Virtual Desktop-ressourcer.

Trin 4: Gendan applikation og desktop levering

Vælg en arkitektur, der understøtter de applikationer og skriveborde, som brugerne har brug for.

For organisationer, der planlægger at forblive på Azure Virtual Desktop, involverer dette normalt opsætning af ARM-integrerede værtsgrupper, understøttede sessionsværter, applikationsgrupper og brugeropgaver.

Nogle organisationer kan finde, at en anden applikationsudgivelse eller desktopløsning bedre opfylder deres behov.

Målet er at genoprette adgangen, mens man undgår kompleksiteten og unødvendigt overhead fra den tidligere opsætning.

Hvad er måden at validere en Azure Virtual Desktop-migrering på?

Gendannelse af infrastruktur garanterer ikke normale brugeroperationer.

En migration eller rekonstruktion skal derfor valideres på service- og applikationsniveauerne.

Bekræft godkendelse og brugeradgang

Bekræft, at brugerne kan autentificere sig og få adgang til de ressourcer, der er tildelt dem.

Tjek Microsoft Entra, multifaktorautentifikation, betingede adgangspolitikker og Azure RBAC-tildelinger efter behov.

Administratorer bør bekræfte, at tilladelser er i overensstemmelse med princippet om mindst privilegium, og at der ikke er nogen gamle adgangsmønstre, der er blevet videreført utilsigtet.

Test forretningskritiske applikationer

Test publicerede applikationer og skriveborde ved at udnytte forskellige repræsentative brugerkonti.

Valideringsaktiviteter bør omfatte applikationsstart, databaseforbindelser, netværksdrev, udskrivning, udklipshåndtering og nødvendige perifere enheder, hvis der er nogen.

Legacy-applikationer skal tages i særlig betragtning, da de muligvis kræver en specifik OS-konfiguration, netværkssti eller applikationskomponent.

Et eksempel på en legacy-applikation kunne være en ERP-applikation, der starter korrekt, men ikke kan oprette forbindelse til sin database fra den nye session vært.

Valider profiler, ydeevne og drift

Virksomheder, der bruger FSLogix eller nogen af de andre profileringsværktøjer, bør sikre, at alt er korrekt vedhæftet, er vedholdende og kan tilgås korrekt.

Det er vigtigt at teste det ved at logge ind for første gang og kontrollere, om alt vil fungere korrekt, når en bruger åbner en applikation og under den næste indlogning. Det er også essentielt at sikre, at processerne overvåges, sikkerhedskopieres og gendannes.

Migreringen er kun fuldført, når alt er klar, herunder at brugerne kan få adgang til deres applikationer. Det skal være muligt at vedligeholde systemet korrekt.

Skal organisationer genoverveje deres desktop-leveringsarkitektur?

Azure Virtual Desktop (classic) pensionering er primært et spørgsmål om platformens livscyklus, men det giver også en mulighed for at vurdere, om den nuværende desktopleveringsplatform fortsat opfylder dine behov.

Overgangen til moderne Azure Virtual Desktop er det åbenlyse valg for mange, især dem der allerede er Azure-først og bruger Azure-hostede desktops.

Andre organisationer har færre komplekse krav.

Hvornår giver moderne Azure Virtual Desktop mening?

Moderne Azure Virtual Desktop kan være en god løsning for organisationer, der kræver centralt administrerede Windows-skriveborde og apps, der er hostet på Azure.

Det muliggør multisession, RemoteApp-modeller og Microsoft ID samt administrationsværktøjer.

Det giver mening for virksomheder, der har et eksisterende Azure-fodaftryk, men IT-afdelingerne skal stadig håndtere kompleksiteten ved cloud, herunder licensering, netværk, opbevaring, administration og driftsaspekter.

Hvornår er en anden Windows-applikationspubliseringsarkitektur passende?

Ikke alle organisationer kræver et fuldt implementeret desktopvirtualiseringsmiljø hostet i Microsoft Azure.

Nogle virksomheder har kun brug for begrænsede fjernadgang til specifikke Windows-applikationer, såsom finansielle eller ERP-applikationer eller ældre forretningsapplikationer.

Disse organisationer kan overveje at offentliggøre applikationer, der er hostet på centralt administrerede Windows-servere i stedet for at implementere en generaliseret virtuel desktop-infrastruktur (VDI).

Moderne Azure Virtual Desktop handler ikke kun om desktop- eller applikationsvirtualisering, men også om applikationsudgivelse.

I dag er det muligt at offentliggøre Azure-applikationer ved hjælp af RemoteApp-metoden.

Virkeligheden er, at der ikke er nogen dikotomi inden for applikationsleveringsområdet, men snarere et kontinuum, der strækker sig fra applikationspublisering til desktopvirtualisering.

Diskussionen bør fokusere på at finde den mest relevante applikationsleveringsarkitektur for den givne organisation og brugssager.

For eksempel, hvis der er en langvarig applikation, der er hostet i en Windows Server-mappe, som tilgås af et sæt autoriserede brugere, behøver organisationen ikke at offentliggøre den i Azure Virtual Desktop, når den ældre infrastruktur stadig fungerer korrekt.

I stedet kan det være gavnligt for sådanne virksomheder at lade deres applikationshostingsted være lokalt, mens de opgraderer deres applikationsadgangsmetode.

Hvilke faktorer bør vejlede beslutningen?

IT-afdelinger bør evaluere valget i forhold til kriterierne for implementeringsbehov, snarere end funktionerne i det udfasede system.

Overvejelse	Nøglespørgsmål
Hosting	Skal arbejdsbelastninger køre i Azure?
Brugeroplevelse	Fulde skriveborde eller udvalgte applikationer?
Kompatibilitet	Vil eksisterende Windows-applikationer fungere?
Sikkerhed	Hvordan beskyttes identitet og sessionstilgang?
Ledelse	Hvem vedligeholder infrastrukturen?
Licensering	Hvilke Microsoft- og softwarelicenser gælder?
Skalerbarhed	Hvor mange samtidige brugere er nødvendige?
Omkostninger	Hvad er de samlede ejeromkostninger?

Formålet er at vælge en virksomhedsarkitektur, der vil opfylde kravene til tilgængelighed, sikkerhed og reduceret administrativ kompleksitet.

Leder du efter et alternativ til Windows-applikation og desktoplevering?

At migrere til moderne Azure Virtual Desktop er ikke nødvendigvis den bedste løsning for hver organisation. Virksomheder, der primært har brug for adgang til eksisterende Windows-applikationer eller centralt hostede skriveborde, kan have gavn af en enklere arkitektur, især når de ikke har brug for et fuldt Azure-hostet virtuelt skrivebords miljø.

TSplus Remote Access muliggør IT-teams at offentliggøre Windows-applikationer og fulde fjernskriveborde gennem RDP-kompatible klienter eller en HTML5-webportal. Med support til lokale og cloud-hostede Windows-servere tilbyder det et praktisk alternativ for organisationer, der ønsker at opretholde deres eksisterende applikationer, samtidig med at de forenkler levering af fjernapplikationer.

Konklusion

Afviklingen af Azure Virtual Desktop (klassisk) gør det nødvendigt at identificere berørte implementeringer, bevare eksisterende ressourcer og genoprette adgang gennem understøttet infrastruktur. IT-teams bør verificere tilgængelige genoprettelsesmuligheder, før de forsøger migration eller rekonstruktion.

Uanset om organisationer fortsætter med moderne Azure Virtual Desktop eller adopterer en anden leveringsarkitektur, forbliver prioriteten at sikre sikker, pålidelig applikationsadgang uden unødig driftskompleksitet.