Azure Virtual Desktop Classic Avviklet: Neste steg for IT

Introduksjon

Avviklingen av Azure Virtual Desktop (klassisk) skaper en viktig distinksjon mellom tapet av en eldre tilkoblingstjeneste og den fortsatte tilgjengeligheten av underliggende Azure-ressurser. For IT-team som gikk glipp av migrasjonsfristen, er det avgjørende å forstå denne distinksjonen for å planlegge gjenoppretting uten unødvendig å erstatte eksisterende infrastruktur. Denne artikkelen forklarer hva avvikling betyr for eksisterende ressurser, hvordan man identifiserer klassiske distribusjoner, hvilke migrasjonsalternativer som fortsatt er verdt å vurdere, og hvordan man velger en støttet applikasjonsleveringsarkitektur.

Hva betyr det når Azure Virtual Desktop Classic avvikles?

Microsoft har offisielt pensjonert Azure Virtual Desktop (klassisk) fra 30. september 2026. Basert på Microsofts offisielle dokumentasjon, "vil tilkoblinger til klassiske tjenester bli blokkert etter pensjonering." Derfor påvirker pensjoneringen den spesifikke typen tjenester relatert til administrasjonen av virtuelle skrivebord og applikasjoner som bruker distribusjonsmodellen Azure Virtual Desktop (klassisk).

Imidlertid gjelder ikke pensjoneringsprosessen for moderne Azure Virtual Desktop som bruker Azure Resource Manager (ARM). Dermed er hovedbekymringen for brukerne som fortsatt benytter de klassiske ressursene mangelen på mulighet til å etablere forbindelser til de tidligere fungerende tjenestene. Derfor bør brukerne være spesielt oppmerksomme på den klassiske ressursforvaltningen, siden ressursene selv ikke vil forsvinne etter pensjoneringsdatoen.

Hva ble egentlig pensjonert?

Azure Virtual Desktop (klassisk), tidligere kjent som Windows Virtual Desktop, hadde sin administrasjonsinfrastruktur basert på dedikerte PowerShell cmdlets, API-er og tjenesteobjekter.

I motsetning til den moderne Azure Virtual Desktop, ble de klassiske vertspoolene og applikasjonsgruppene ikke definert som enhetlige Azure ressursbehandlingsressurser.

I dag er disse komponentene integrert i Azure ressursadministrasjonssystemet, som gjør det mulig for administratorer å bruke Azure rollebasert tilgangskontroll (RBAC), administrere tjenesten gjennom Azure-portalen og bruke moderne infrastruktur-som-kode-mønstre for distribusjonsautomatisering.

Evne	AVD Classic (pensjonert)	Moderne AVD
Ledelse	Legacy kontrollplan	Azure Resource Manager
Azure-portalen	Begrenset integrasjon	Nativ integrasjon
Tilgangskontroll	Legacy leietakerroller	Azure RBAC
Automatisering	Klassiske API-er og PowerShell	ARM, API-er, Az PowerShell
Desktop- og applikasjonslevering	Tilkoblinger blokkert	Støttet
Tjenestestatus	Pensjonert	Støttet

Pensjonen representerer en endring i den underliggende tjenestearkitekturen, ikke bare en produktomdøping.

Fungerer Modern Azure Virtual Desktop fortsatt?

Ja. Moderne Azure Virtual Desktop støttes og fortsetter å tilby full Windows-skrivebord, multisession-plattformer og individuell app-levering gjennom RemoteApp.

Organisasjoner som allerede bruker vertspooler integrert med Azure Resource Manager (ARM) påvirkes ikke av avviklingen av den klassiske tjenesten.

IT-ledere bør også merke seg forskjellen mellom slutten av støtte for den klassiske Azure Virtual Desktop og den separate slutten av støtte for eldre Remote Desktop-klienter. Remote Desktop-klienten for Windows (MSI) var planlagt å nå slutten av støtte for offentlige skymiljøer den 27. mars 2026, og for Azure Virtual Desktop (klassisk) den 28. september 2026.

Hvordan kan IT-team identifisere Azure Virtual Desktop Classic-distribusjoner?

Det første steget er å identifisere om noen produksjonsarbeidsbelastninger fortsatt er avhengige av den pensjonerte arkitekturen.

Dette er spesielt kritisk for systemer som ble satt i produksjon for flere år siden og som kan ha blitt overtatt av nye administratorer eller ignorert i den nåværende infrastruktur-dokumentasjonen.

Sjekk Azure Resource Manager-integrasjon

Du bør begynne med å inspisere Azure Virtual Desktop-ressursene i Azure-portalen. Moderne Azure Virtual Desktop-distribusjoner eksponerer vertspooler, applikasjonsgrupper og arbeidsområder som Azure-ressurser i et abonnement og ressursgruppe. I motsetning til dette, brukte klassiske distribusjoner å eksponere tjenesteobjekter som ble administrert på forskjellige måter.

Tilstedeværelsen av følgende Azure Virtual Desktop-elementer er et sterkt tegn på en klassisk distribusjon:

• Vertspooler som bruker den klassiske Azure Virtual Desktop PowerShell-modulen
• Historiske referanser til en klassisk tjenesteleverandør eller klassisk tjeneste-API
• Applikasjonsgrupper som mangler tilsvarende ARM-ressurser
• Sessionvertmaskiner som refererer til eldre dokumentasjon

Samtidig er fraværet av en vertspool i Azure-portalen ikke nødvendigvis en indikasjon på en klassisk distribusjon. Du bør alltid sjekke hvilken abonnement, Microsoft Entra-leietaker og rollebasert tilgangskontroll brukeren har før du analyserer problemet videre.

Vurder verktøy for legacyadministrasjon og avhengigheter

Distribusjonsskript og automatiseringslagre kan fungere som supplerende kilder til bevis.

For eksempel, tilstedeværelsen av skript som inneholder Microsoft.RDInfra.RDPowerShell-referanser eller klassiske leietaker-nivå administrasjonsoperasjoner ville antyde at miljøet var konfigurert med den eldre administrasjonsstakken.

Moderne miljøer vil utnytte Azure Resource Manager-integrerte administrasjonsgrensesnitt og tilknyttede Az PowerShell-moduler.

Administratorer bør også lage en oversikt over alle applikasjoner, brukere og infrastrukturressurser knyttet til potensielt berørte vertspooler.

Dette inkluderer å undersøke virtuelle maskiner for sesjonsverter, applikasjonstildelinger, lagringssteder for profiler, autentiseringsavhengigheter, nettverkskonfigurasjoner og sikkerhetskopieringslagre. Microsoft manuell migrasjonsdokumentasjon inneholder detaljerte sammenligninger mellom den klassiske tjenesteobjektmodellen og den Azure Resource Manager (ARM)-integrerte ressursmodellen.

Hva kan skje med dine eksisterende ressurser etter at Azure Virtual Desktop Classic går ut av drift?

Den viktigste forskjellen er mellom den avviklede tilkoblingstjenesten og den underliggende Azure-infrastrukturen.

Mens klassiske skrivebordsforbindelser er blokkert, kan eksisterende virtuelle maskiner, lagringsressurser og applikasjonsdata forbli på plass.

Eksisterende virtuelle maskiner og lagring kan forbli tilgjengelig

Azure virtuelle maskiner er ressurser som administreres på egen hånd, uten å være avhengige av den avviklede klassiske tjenestekontrollplanen. Dermed kan sesjonsvertmaskiner, administrerte disker og nettverksressurser som ble opprettet i abonnementet fortsatt eksistere.

Imidlertid kan de ikke brukes til å gjenopprette den pensjonerte tilkoblingsmegleren. Ingen virtuelle maskiner opprettet i den nye Azure-infrastrukturen er tilgjengelige for å returnere en organisasjons skrivebordsopplevelse til den fungerende tilstanden.

Administratorer bør undersøke hver ressurs nøye, og hvis den kan gjenbrukes for en støttet konfigurasjon, bør de utføre følgende trinn.

Det er viktig å sjekke om operativsystemet til den virtuelle maskinen er støttet og om applikasjonene og sikkerhetskonfigurasjonene er kompatible.

Applikasjonstilgang og brukerdata krever separate kontroller

Brukere som har koblet til via den klassiske skrivebords- eller RemoteApp-øktstypen vil ikke lenger kunne starte applikasjonene sine gjennom denne tjenesten.

Resultatet av å avvikle tjenesten kan være tap av tilgang til skrivebord, publiserte applikasjoner og forstyrrelser i forretningsprosesser.

Imidlertid garanterer ikke avviklingen av tjenesten at brukerrelaterte data blir slettet.

I de fleste tilfeller er det sannsynlig at brukernes data er lagret på Azure Files, VM-disker eller andre lagringsmedier, men oppbevaring og tilgjengelighet av denne informasjonen vil være basert på hvordan den ble konfigurert, sikret med tillatelser, sikkerhetskopiert, osv...

Som sådan, før avvikling eller migrering av de involverte systemene, må IT-avdelinger sørge for at de har bevart all nødvendig data.

Kan et team fortsatt migrere Azure Virtual Desktop Classic etter at det er pensjonert?

Microsoft dokumenterer to migrasjonsveier for overgangen fra Azure Virtual Desktop (klassisk) til den nye ARM-integrerte Azure Virtual Desktop: automatisk migrasjon og manuell migrasjon.

Begge alternativene var ment å være levedyktige frem til 30. september 2026.

Siden den datoen er i fortiden, bør administratorer ikke betrakte verktøyene beskrevet i dokumentasjonen som produksjonsklare for alle scenarier.

Microsofts dokumentasjon gir ikke veiledning om overgangsperioden.

Derfor bør organisasjoner ikke stole på noen verktøy og prosesser for overgang etter pensjonering.

Alternativ 1: Automatisk migrering

Microsofts automatiske migrasjonsprosess utnytter et PowerShell-basert verktøy for å flytte kvalifiserte klassiske tjenestekonfigurasjoner til ARM-ressurser.

Selskapets dokumentasjon anbefaler at brukere har et aktivt Azure-abonnement med nødvendige tillatelser og oppfyller miljøkravene som er oppført av migrasjonsmodulen.

For eksempel foreslår Microsofts retningslinjer at brukere får tildelt bidragsyterrettigheter for å opprette Azure-ressurser og brukeradministratortillatelser for å administrere medlemskap i applikasjonsgrupper.

Det er imidlertid viktig å erkjenne at verktøyet ikke kan garantere datagjenoppretting etter avvikling.

Organisasjoner med aktive klassiske distribusjoner bør kontakte Microsoft-support for å bekrefte om migrasjonsprosessen er et tilgjengelig alternativ for deres miljø.

Alternativ 2: Manuell migrering eller rekonstruksjon

Manuell migrering krever opprettelse av moderne Azure Virtual Desktop-ressurser og omkonfigurering av tjenestekonfigurasjonen.

Avhengig av den spesifikke saken, kan administratorer måtte:

• Opprett integrerte ARM-baserte vertspooler, applikasjonsgrupper og arbeidsområder
• Etabler eller erstatt vertmaskiner for sesjonshosting
• Registrer kompatible sesjonsverter med de nye vertspoolene
• Gjenopprett bruker- og applikasjonsassosiasjoner
• Juster identitet, nettverk, sikkerhet og profilkonfigurasjoner

Den manuelle tilnærmingen blir nødvendig når eldre konfigurasjoner inneholder udokumentert kompleksitet, omfattende tilpasning, eller når moderne migrasjonsverktøy viser seg å være utilstrekkelige.

Merk at rekonstruksjon av leveringsinfrastrukturen ikke alltid innebærer fullstendig utskifting av applikasjoner og data.

Gjenstående komponenter kan ofte gjenbrukes gjennom passende kompatibilitetsvurderinger, lisensvurderinger og sikkerhetsrevisjoner.

Beslutningen bør baseres på den nåværende tilstanden til eksisterende ressurser og tilgjengelig støtte fra Microsoft.

Situasjon	Tilnærming for evaluering
Klassisk konfigurasjon som kvalifiserer og Microsoft bekrefter migrasjonsstøtte	Automatisk migrering
Kompleks eller utilgjengelig klassisk konfigurasjon	Manuell rekonstruksjon
Eksisterende VM-er og data forblir tilgjengelige	Gjenoppbygging av leveringstjenester og vurdering av gjenbruk
Legacy arbeidsmengder er ikke lenger nødvendig	Sikker avvikling
Azure-hostede skrivebord er ikke lenger nødvendig	Alternativ leveringsarkitektur

Hva bør IT-team gjøre hvis de gikk glipp av pensjonsfristen?

Organisasjoner som ikke har fullført migreringen sin innen 30. september 2026, bør prioritere bevaring av ressurser og gjenoppretting av tilgang til forretningsapplikasjoner.

I stedet for å forsøke flere tilkoblinger til den avviklede tjenesten, anbefales administratorer å utføre en gjenopprettingsprosess.

Steg 1: Vurder tjenesteinnvirkningen

Identifiser hvilke brukere, skrivebord og applikasjoner som ikke er tilgjengelige.

Finn ut om det er et helt miljø eller spesifikke arbeidsbelastninger som er berørt. Bekreft at problemet er relatert til en klassisk pensjonering og ikke et annet autentiserings-, nettverks- eller sesjonsvert-relatert problem.

Steg 2: Bevar infrastruktur og data

Gå gjennom Azure-abonnementer for å identifisere nåværende virtuelle maskiner, administrerte disker, lagringskontoer og nettverksressurser

Dokumentavhengigheter og sikre sikkerhetskopier eksistere før du tar noen tiltak. Ikke slett ressurser før applikasjonsdata, brukerprofiler og konfigurasjonsinformasjon er blitt identifisert.

Steg 3: Bekreft gjenopprettingsalternativer med Microsoft

Kontakt Microsofts support for å sikre at det fortsatt finnes støttede migrerings-/gjenopprettingsprosedyrer tilgjengelig.

De innledende automatiske/manuelle migrasjonsinstruksjonene ble utviklet med pensjonsdatoen i tankene, og bør derfor ikke antas å gjelde.

I tilfelle den klassiske konfigurasjonen ikke kan migreres, kan det være nødvendig å gjenoppbygge miljøet med støttede Azure Virtual Desktop-ressurser.

Steg 4: Gjenopprett applikasjon og skrivebordslevering

Velg en arkitektur som støtter de applikasjonene og skrivebordene som brukerne trenger.

For organisasjoner som planlegger å bli på Azure Virtual Desktop, innebærer dette vanligvis å sette opp ARM-integrerte vertspooler, støttede sesjonsverter, applikasjonsgrupper og brukeroppgaver.

Noen organisasjoner kan oppdage at en annen applikasjonspublisering eller desktop-løsning bedre passer deres behov.

Målet er å gjenopprette tilgangen samtidig som man unngår kompleksiteten og unødvendig overhead fra den forrige oppsettet.

Hva er måten å validere en Azure Virtual Desktop-migrering på?

Gjenoppretting av infrastruktur garanterer ikke normale brukeroperasjoner.

En migrasjon eller rekonstruksjon må derfor valideres på tjeneste- og applikasjonsnivåer.

Bekreft autentisering og brukeradgang

Bekreft at brukere kan autentisere seg og få tilgang til ressursene som har blitt tildelt dem.

Sjekk Microsoft Entra, multifaktorautentisering, betingede tilgangspolicyer og Azure RBAC-oppgaver der det er aktuelt.

Administratorer bør bekrefte at tillatelser er i samsvar med prinsippet om minst privilegium, og at det ikke finnes gamle tilgangsmønstre som har blitt videreført utilsiktet.

Test av forretningskritiske applikasjoner

Test publiserte applikasjoner og skrivebord ved å bruke distinkte representativ bruker-kontoer.

Valideringsaktiviteter bør inkludere applikasjonslansering, databaseforbindelser, nettverksandeler, utskrift, utklippstavleredireksjon og nødvendige periferiutstyr hvis aktuelt.

Legacy-applikasjoner må tas i spesiell betraktning, da de kan kreve en spesifikk OS-konfigurasjon, nettverksbane eller applikasjonskomponent.

Et eksempel på en eldre applikasjon kan være en ERP-applikasjon som starter vellykket, men som ikke klarer å koble til databasen sin fra den nye sesjonsverten.

Valider profiler, ytelse og drift

Selskaper som bruker FSLogix eller noen av de andre profileringsverktøyene bør sørge for at alt er riktig festet, er vedvarende og kan nås på riktig måte.

Det er viktig å teste det ved å logge inn for første gang og sjekke om alt vil fungere bra når en bruker åpner en applikasjon og under neste innlogging. Det er også essensielt å sikre at prosessene overvåkes, sikkerhetskopieres og gjenopprettes.

Migrasjonen er fullført først når alt er klart, inkludert at brukerne kan få tilgang til applikasjonene sine. Det må være mulig å vedlikeholde systemet på riktig måte.

Bør organisasjoner revurdere sin desktop-leveringsarkitektur?

Azure Virtual Desktop (classic) pensjonering er hovedsakelig et plattformlivssyklusproblem, men det gir også en mulighet til å vurdere om den nåværende skrivebordsleveringsplattformen fortsatt støtter dine behov.

Overgangen til moderne Azure Virtual Desktop er det åpenbare valget for mange, spesielt de som allerede er Azure-først og bruker Azure-hostede skrivebord.

Andre organisasjoner har færre komplekse krav.

Når gir moderne Azure Virtual Desktop mening?

Moderne Azure Virtual Desktop kan være en god løsning for organisasjoner som krever sentralt administrerte Windows-skrivebord og apper, vert på Azure.

Det muliggjør multisession, RemoteApp-modeller og Microsoft ID og administrasjonsverktøy.

Det gir mening for bedrifter som har et eksisterende Azure-fotavtrykk, men IT-avdelinger må fortsatt håndtere kompleksiteten i skyen, inkludert lisensiering, nettverk, lagring, administrasjon og driftsaspekter.

Når er en annen publiseringsarkitektur for Windows-applikasjoner passende?

Ikke alle organisasjoner krever et fullt implementert skrivebordsvirtualiseringsmiljø som er vert i Microsoft Azure.

Noen bedrifter trenger bare begrenset fjernaksess til spesifikke Windows-applikasjoner, som finansielle eller ERP-applikasjoner eller eldre forretningsapplikasjoner.

Disse organisasjonene kan vurdere å publisere applikasjoner som er vert på sentralt administrerte Windows-servere i stedet for å implementere en generell virtuell skrivebordsinfrastruktur (VDI).

Moderne Azure Virtual Desktop handler ikke bare om virtualisering av skrivebord eller applikasjoner, men også om publisering av applikasjoner.

I dag er det mulig å publisere Azure-applikasjoner ved hjelp av RemoteApp-metoden.

Virkeligheten er at det ikke finnes en dikotomi i applikasjonsleveringsområdet, men snarere et kontinuum som går fra applikasjonspublisering til skrivebordsvirtualisering.

Diskusjonen bør fokusere på å finne den mest relevante applikasjonsleveringsarkitekturen for den gitte organisasjonen og bruksområdene.

For eksempel, hvis det er en langvarig applikasjon som er vert i en Windows Server-mappe som blir tilganget av et sett med autoriserte brukere, trenger ikke organisasjonen å publisere den i Azure Virtual Desktop når den eldre infrastrukturen fortsatt fungerer som den skal.

I stedet kan det være gunstig for slike virksomheter å la sin applikasjonsvert være lokalt mens de oppgraderer sin applikasjonstilgangsmetode.

Hvilke faktorer bør veilede beslutningen?

IT-avdelinger bør vurdere valget mot kriteriene for distribusjonsbehov, snarere enn funksjonene til det avviklede systemet.

Vurdering	Nøkkelspørsmål
Hosting	Må arbeidsmengder kjøre i Azure?
Brukeropplevelse	Full skrivebord eller utvalgte applikasjoner?
Kompatibilitet	Vil eksisterende Windows-applikasjoner fungere?
Sikkerhet	Hvordan er identitet og sesjonstilgang beskyttet?
Ledelse	Hvem vedlikeholder infrastrukturen?
Lisensiering	Hvilke Microsoft- og programvarelisenser gjelder?
Skalerbarhet	Hvor mange samtidige brukere kreves?
Kostnad	Hva er den totale eierkostnaden?

Formålet er å velge en bedriftsarkitektur som vil tilfredsstille kravene til tilgjengelighet, sikkerhet og redusert administrativ kompleksitet.

Ser du etter et alternativ for levering av Windows-applikasjoner og skrivebord?

Migrering til moderne Azure Virtual Desktop er ikke nødvendigvis det beste alternativet for hver organisasjon. Bedrifter som primært trenger tilgang til eksisterende Windows-applikasjoner eller sentralt hostede skrivebord kan ha nytte av en enklere arkitektur, spesielt når de ikke krever et fullt Azure-hostet virtuelt skrivebordsmiljø.

TSplus Remote Access muliggjør IT-team å publisere Windows-applikasjoner og fullstendige eksterne skrivebord gjennom RDP-kompatible klienter eller en HTML5-nettportal. Med støtte for lokale og skybaserte Windows-servere, tilbyr det et praktisk alternativ for organisasjoner som ønsker å opprettholde sine eksisterende applikasjoner samtidig som de forenkler levering av eksterne applikasjoner.

Konklusjon

Avviklingen av Azure Virtual Desktop (klassisk) gjør det viktig å identifisere berørte distribusjoner, bevare eksisterende ressurser og gjenopprette tilgang gjennom støttet infrastruktur. IT-team bør verifisere tilgjengelige gjenopprettingsalternativer før de prøver migrering eller rekonstruksjon.

Enten organisasjoner fortsetter med moderne Azure Virtual Desktop eller adopterer en annen leveringsarkitektur, forblir prioriteten å sikre sikker, pålitelig applikasjonstilgang uten unødvendig driftskompleksitet.