Azure Virtual Desktop Classic Avslutad: Nästa steg för IT

Introduktion

Pensioneringen av Azure Virtual Desktop (klassisk) skapar en viktig åtskillnad mellan förlusten av en gammal anslutningstjänst och den fortsatta tillgången till underliggande Azure-resurser. För IT-team som missade migrationsfristen är det avgörande att förstå denna åtskillnad för att planera återhämtning utan att onödigt ersätta befintlig infrastruktur. Denna artikel förklarar vad pensionering innebär för befintliga resurser, hur man identifierar klassiska distributioner, vilka migrationsalternativ som fortfarande är värda att utvärdera och hur man väljer en stödd applikationsleveransarkitektur.

Vad betyder det när Azure Virtual Desktop Classic avvecklas?

Microsoft har officiellt avvecklat Azure Virtual Desktop (klassisk) från och med den 30 september 2026. Enligt Microsofts officiella dokumentation kommer "anslutningar till klassiska tjänster att blockeras efter avvecklingen." Därför påverkar avvecklingen den specifika typen av tjänster relaterade till hanteringen av virtuella skrivbord och applikationer som använder Azure Virtual Desktop (klassisk) distributionsmodell.

Dock gäller inte avvecklingsprocessen för moderna Azure Virtual Desktop som använder Azure Resource Manager (ARM). Därför är den största oro för användarna som fortfarande använder de klassiska resurserna oförmågan att etablera anslutningar till de tidigare fungerande tjänsterna. Därför bör användarna vara särskilt medvetna om hanteringen av klassiska resurser eftersom resurserna själva inte kommer att försvinna efter avvecklingsdatumet.

Vad exakt blev pensionerat?

Azure Virtual Desktop (klassisk), tidigare känd som Windows Virtual Desktop, hade sin hanteringsinfrastruktur baserad på dedikerade PowerShell cmdlets, API:er och tjänsteobjekt.

Till skillnad från den moderna Azure Virtual Desktop definierades inte de klassiska värdpoolerna och applikationsgrupperna som enhetliga Azure-resursförvaltningsresurser.

Idag är dessa komponenter integrerade i Azure-resurshanteringssystemet, vilket gör det möjligt för administratörer att tillämpa Azure rollbaserad åtkomstkontroll (RBAC), hantera tjänsten genom Azure-portalen och använda moderna infrastruktur-som-kod-mönster för distributionsautomatisering.

Kapabilitet	AVD Classic (pensionerad)	Modern AVD
Förvaltning	Arvkontrollplan	Azure Resource Manager
Azure-portalen	Begränsad integration	Inbyggd integration
Åtkomstkontroll	Arvtenantroller	Azure RBAC
Automation	Klassiska API:er och PowerShell	ARM, API:er, Az PowerShell
Skrivbord och appleverans	Anslutningar blockerade	Stödd
Tjänstestatus	Pensionerad	Stödd

Pensioneringen representerar en förändring i den underliggande tjänstarkitekturen, inte bara en produktomdöpning.

Fungerar Modern Azure Virtual Desktop fortfarande?

Ja. Modern Azure Virtual Desktop stöds och fortsätter att erbjuda fullständiga Windows-skrivbord, multisessionplattformar och individuell appleverans genom RemoteApp.

Organisationer som redan använder de Azure Resource Manager (ARM)-integrerade värdpoolerna påverkas inte av avvecklingen av den klassiska tjänsten.

IT-chefer bör också notera skillnaden mellan slutet av support för den klassiska Azure Virtual Desktop och det separata slutet av support för äldre Remote Desktop-klienter. Remote Desktop-klienten för Windows (MSI) var planerad att nå slutet av support för offentliga molnmiljöer den 27 mars 2026, och för Azure Virtual Desktop (klassisk) den 28 september 2026.

Hur kan IT-team identifiera Azure Virtual Desktop Classic-distributioner?

Det första steget är att identifiera om några produktionsarbetsbelastningar fortfarande är beroende av den avvecklade arkitekturen.

Detta är särskilt kritiskt för system som sattes i produktion för flera år sedan och som kan ha återtagits av nya administratörer eller ignorerats i den aktuella infrastrukturens dokumentation.

Kontrollera Azure Resource Manager-integration

Du bör börja med att inspektera Azure Virtual Desktop-resurserna i Azure-portalen. Moderna Azure Virtual Desktop-distributioner exponerar värdpooler, applikationsgrupper och arbetsytor som Azure-resurser i en prenumeration och resursgrupp. I kontrast användes klassiska distributioner för att exponera tjänsteobjekt som hanterades på olika sätt.

Närvaron av följande Azure Virtual Desktop-element är en stark indikator på en klassisk distribution:

• Hostpooler som använder den klassiska Azure Virtual Desktop PowerShell-modulen
• Historiska referenser till en klassisk tjänsteanvändare eller klassisk tjänste-API
• Applikationsgrupper som saknar motsvarande ARM-resurser
• Sessionvärd virtuella maskiner som hänvisar till äldre dokumentation

Samtidigt är avsaknaden av en värdpool i Azure-portalen inte nödvändigtvis en indikation på en klassisk distribution. Du bör alltid kontrollera vilken prenumeration, Microsoft Entra-tenant och rollbaserad åtkomstkontroll användaren har innan du analyserar problemet vidare.

Granska Legacy Management-verktyg och beroenden

Distribueringsskript och automatiseringsförråd kan fungera som kompletterande beviskällor.

Till exempel skulle närvaron av skript som innehåller Microsoft.RDInfra.RDPowerShell-referenser eller klassiska hanteringsoperationer på hyresgätsnivå tyda på att miljön var konfigurerad med den äldre hanteringsstacken.

Moderna miljöer kommer att utnyttja Azure Resource Manager-integrerade hanteringsgränssnitt och tillhörande Az PowerShell-moduler.

Administratörer bör också inventera alla applikationer, användare och infrastrukturresurser som är kopplade till potentiellt påverkade värdpooler.

Detta inkluderar att granska session värd virtuella maskiner, applikationstilldelningar, profil lagringsplatser, autentisering beroenden, nätverkskonfigurationer och backup-repositorier. Den Microsoft manuell migreringsdokumentation innehåller detaljerade jämförelser mellan den klassiska tjänsteobjektmodellen och den Azure Resource Manager (ARM)-integrerade resursmodellen.

Vad kan hända med dina befintliga resurser efter att Azure Virtual Desktop Classic avvecklas?

Den viktigaste skillnaden är mellan den avvecklade anslutningstjänsten och den underliggande Azure-infrastrukturen.

Medan klassiska skrivbordsanslutningar är blockerade kan befintliga virtuella maskiner, lagringsresurser och applikationsdata förbli på plats.

Befintliga virtuella maskiner och lagring kan förbli tillgängliga

Azure virtuella maskiner är resurser som hanteras på egen hand, utan att förlita sig på den avvecklade klassiska tjänstkontrollplanen. Därför kan session värd virtuella maskiner, hanterade diskar och nätverksresurser som skapades i prenumerationen fortfarande existera.

Dock kan de inte användas för att återställa den pensionerade anslutningsmäklaren. Inga virtuella maskiner som skapats i den nya Azure-infrastrukturen är tillgängliga för att återföra en organisations skrivbordserfarenhet till det fungerande tillståndet.

Administratörer bör noggrant granska varje resurs, och om den kan återanvändas för en stödd konfiguration, bör de utföra följande steg.

Det är viktigt att kontrollera om operativsystemet för den virtuella maskinen stöds och om applikationerna och säkerhetskonfigurationerna är kompatibla.

Applikationsåtkomst och användardata kräver separata kontroller

Användare som har anslutit via den klassiska skrivbordet eller RemoteApp-sessionstypen kommer inte längre att kunna starta sina applikationer genom denna tjänst.

Resultatet av att avveckla tjänsten kan vara förlust av åtkomst till skrivbord, publicerade applikationer och störningar i affärsprocesser.

Dock garanterar inte avvecklingen av tjänsten att användarrelaterad data raderas.

I de flesta fall är det troligt att användardata lagras på Azure Files, VM-diskar eller andra lagringsmedier, men bevarande och tillgänglighet av denna information skulle baseras på hur den konfigurerades, säkrades med behörigheter, säkerhetskopierades, etc.

Innan avveckling eller migrering av de involverade systemen behöver IT-avdelningar säkerställa att de har bevarat all nödvändig data.

Kan ett team fortfarande migrera Azure Virtual Desktop Classic efter att det har pensionerats?

Microsoft dokumenterar två migrationsvägar för att övergå från Azure Virtual Desktop (klassisk) till den nya ARM-integrerade Azure Virtual Desktop: automatisk migration och manuell migration.

Båda alternativen var avsedda att vara genomförbara fram till den 30 september 2026.

Eftersom det datumet ligger i det förflutna bör administratörer inte betrakta verktyg som beskrivs i dokumentationen som produktionsklara för alla scenarier.

Microsofts dokumentation ger ingen vägledning om övergångsperioden.

Därför bör organisationer inte förlita sig på några verktyg och processer för övergång efter pensionering.

Alternativ 1: Automatisk migrering

Microsofts automatiska migrationsprocess använder ett PowerShell-baserat verktyg för att flytta berättigade klassiska tjänstkonfigurationer till ARM-resurser.

Företagets dokumentation rekommenderar att användare har en aktiv Azure-prenumeration med nödvändiga behörigheter och uppfyller miljökraven som anges av migrationsmodulen.

Till exempel föreslår Microsofts riktlinjer att användare ska delegeras med bidragsgivartillstånd för att skapa Azure-resurser och användartillgångsadministratörstillstånd för att hantera medlemskap i applikationsgrupper.

Det är dock viktigt att erkänna att verktyget inte kan garantera dataräddning efter avveckling.

Organisationer med aktiva klassiska distributioner bör kontakta Microsoft-supporten för att bekräfta om migrationsprocessen är ett tillgängligt alternativ för deras miljö.

Alternativ 2: Manuell migrering eller rekonstruktion

Manuell migrering kräver skapandet av moderna Azure Virtual Desktop-resurser och omkonfigurering av tjänstekonfigurationen.

Beroende på det specifika fallet kan administratörer behöva:

• Skapa integrerade ARM-baserade värdpooler, applikationsgrupper och arbetsytor
• Skapa eller ersätt session värd virtuella maskiner
• Registrera kompatibla sessionsvärdar med de nya värdpoolerna
• Återskapa användar- och applikationskopplingar
• Justera identitets-, nätverks-, säkerhets- och profilkonfigurationer

Den manuella metoden blir nödvändig när äldre konfigurationer innehåller odokumenterad komplexitet, omfattande anpassning, eller när moderna migrationsverktyg visar sig vara otillräckliga.

Det är värt att notera att ombyggnaden av leveransinfrastrukturen inte alltid innebär en fullständig ersättning av applikationer och data.

Återstående komponenter kan ofta återanvändas genom lämpliga kompatibilitetsbedömningar, licensutvärderingar och säkerhetsrevisioner.

Beslutet bör baseras på det aktuella tillståndet av befintliga resurser och tillgängligt stöd från Microsoft.

Situation	Tillvägagångssätt för utvärdering
Berättigad klassisk konfiguration och Microsoft bekräftar migreringsstöd	Automatisk migrering
Komplex eller otillgänglig klassisk konfiguration	Manuell rekonstruktion
Befintliga virtuella maskiner och data förblir tillgängliga	Återuppbygg tjänster för leverans och bedöm återanvändning
Legacy-arbetsbelastningar krävs inte längre	Säker avveckling
Azure-hosted skrivbord är inte längre nödvändiga	Alternativ leveransarkitektur

Vad bör IT-team göra om de missade pensionsfristen?

Organisationer som inte har slutfört sin migrering senast den 30 september 2026 bör prioritera bevarandet av resurser och återställandet av åtkomst till affärsapplikationer.

Istället för att försöka med flera anslutningar till den avvecklade tjänsten, rekommenderas administratörer att utföra en återställningsprocess.

Steg 1: Bedöm tjänstepåverkan

Identifiera vilka användare, skrivbord och applikationer som inte är tillgängliga.

Ta reda på om det är en hel miljö eller specifika arbetsbelastningar som påverkas. Bekräfta att problemet är relaterat till en klassisk pensionering och inte något annat problem relaterat till autentisering, nätverk eller sessionsvärd.

Steg 2: Bevara infrastruktur och data

Granska Azure-prenumerationer för att identifiera aktuella virtuella maskiner, hanterade diskar, lagringskonton och nätverksresurser.

Dokumentera beroenden och säkerställ säkerhetskopior exist innan några åtgärder vidtas. Ta inte bort resurser förrän applikationsdata, användarprofiler och konfigurationsinformation har identifierats.

Steg 3: Bekräfta återställningsalternativ med Microsoft

Kontakta Microsoft-supporten för att säkerställa att det fortfarande finns stöd för migrations-/återställningsprocedurer tillgängliga.

De initiala automatiska/manuella migrationsanvisningarna utvecklades med pensionsdatumet i åtanke och bör därför inte antas gälla.

I de fall där den klassiska konfigurationen inte kan migreras kan det vara nödvändigt att återskapa miljön med stödda Azure Virtual Desktop-resurser.

Steg 4: Återställ applikation och skrivbordleverans

Välj en arkitektur som stöder de applikationer och skrivbord som användarna behöver.

För organisationer som planerar att stanna på Azure Virtual Desktop innebär detta vanligtvis att man sätter upp ARM-integrerade värdpooler, stödda sessionsvärdar, applikationsgrupper och användartilldelningar.

Vissa organisationer kan upptäcka att en annan applikationspublicering eller skrivbordslösning passar bättre deras behov.

Målet är att återställa åtkomst samtidigt som man undviker komplexiteten och onödig overhead från den tidigare konfigurationen.

Vad är sättet att validera en Azure Virtual Desktop-migrering?

Återställning av infrastruktur garanterar inte normala användaroperationer.

En migration eller rekonstruktion måste därför valideras på tjänst- och applikationsnivåer.

Verifiera autentisering och användartillgång

Bekräfta att användare kan autentisera sig och få tillgång till de resurser som har tilldelats dem.

Kontrollera Microsoft Entra, multifaktorautentisering, villkorliga åtkomstpolicyer och Azure RBAC-tilldelningar om tillämpligt.

Administratörer bör bekräfta att behörigheterna är i linje med principen om minimiåtkomst och att det inte finns några gamla åtkomstmönster som oavsiktligt har förts vidare.

Testa affärskritiska applikationer

Testa publicerade applikationer och skrivbord genom att använda olika representativa användarkonton.

Valideringsaktiviteter bör inkludera applikationslansering, databasanslutningar, nätverksdelningar, utskrift, urklippsomdirigering och nödvändiga perifera enheter om några.

Legacy-applikationer måste beaktas särskilt eftersom de kan kräva en specifik OS-konfiguration, nätverksväg eller applikationskomponent.

Ett exempel på en gammal applikation kan vara en ERP-applikation som startar framgångsrikt men misslyckas med att ansluta till sin databas från den nya sessionsvärden.

Validera profiler, prestanda och drift

Företag som använder FSLogix eller något av de andra profileringsverktygen bör säkerställa att allt är korrekt kopplat, är beständigt och kan nås på rätt sätt.

Det är viktigt att testa det genom att logga in för första gången och kontrollera om allt fungerar bra när en användare öppnar en applikation och under nästa inloggning. Det är också avgörande att säkerställa att processerna övervakas, säkerhetskopieras och återställs.

Migreringen är komplett först när allt är klart, inklusive att användarna kan få tillgång till sina applikationer. Det måste vara möjligt att underhålla systemet på rätt sätt.

Bör organisationer ompröva sin skrivbordsleveransarkitektur?

Azure Virtual Desktop (classic) pensionering är främst en plattforms livscykelfråga, men det ger också en möjlighet att bedöma om den nuvarande skrivbordleveransplattformen fortsätter att stödja dina behov.

Övergången till moderna Azure Virtual Desktop är det uppenbara valet för många, särskilt de som redan är Azure-först och använder Azure-hostade skrivbord.

Andra organisationer har färre komplexa krav.

När gör det mening med Modern Azure Virtual Desktop?

Modern Azure Virtual Desktop kan vara en bra lösning för organisationer som kräver centralt hanterade Windows-skrivbord och appar, som är värd på Azure.

Det möjliggör multisession, RemoteApp-modeller och Microsoft ID samt administrationsverktyg.

Det är meningsfullt för företag som har en befintlig Azure-närvaro, men IT-avdelningar måste fortfarande hantera komplexiteten i molnet, inklusive licensiering, nätverk, lagring, administration och operativa aspekter.

När är en annan publiceringsarkitektur för Windows-applikationer lämplig?

Inte alla organisationer kräver en fullt implementerad skrivbordsvirtualiseringsmiljö som är värd i Microsoft Azure.

Vissa företag behöver endast begränsad fjärråtkomst till specifika Windows-applikationer, såsom finansiella eller ERP-applikationer eller äldre affärsapplikationer.

Dessa organisationer kan överväga att publicera applikationer som är värd på centralt hanterade Windows-servrar istället för att implementera en generell virtuell skrivbordsinfrastruktur (VDI).

Modern Azure Virtual Desktop handlar inte bara om virtualisering av skrivbord eller applikationer, utan också om publicering av applikationer.

I dag är det möjligt att publicera Azure-applikationer med hjälp av RemoteApp-metoden.

Verkligheten är att det inte finns någon dikotomi inom applikationsleveransområdet, utan snarare ett kontinuum som sträcker sig från applikationspublicering till skrivbordsvirtualisering.

Diskussionen bör fokusera på att hitta den mest relevanta applikationsleveransarkitekturen för den givna organisationen och användningsfallen.

Till exempel, om det finns en långvarig applikation som är värd i en Windows Server-mapp som nås av en uppsättning auktoriserade användare, behöver organisationen inte publicera den i Azure Virtual Desktop när den äldre infrastrukturen fortfarande fungerar korrekt.

Istället kan det vara fördelaktigt för sådana företag att lämna sin applikationshosting på plats samtidigt som de uppgraderar sin applikationsåtkomstmetod.

Vilka faktorer bör styra beslutet?

IT-avdelningar bör utvärdera valet utifrån kriterierna för distributionsbehov, snarare än funktionerna hos det avvecklade systemet.

Övervägande	Nyckelfråga
Hosting	Måste arbetsbelastningar köras i Azure?
Användarupplevelse	Fullständiga skrivbord eller valda applikationer?
Kompatibilitet	Kommer befintliga Windows-applikationer att fungera?
Säkerhet	Hur skyddas identitet och sessionsåtkomst?
Förvaltning	Vem underhåller infrastrukturen?
Licensiering	Vilka Microsoft- och programvarulicenser gäller?
Skalbarhet	Hur många samtidiga användare krävs?
Kostnad	Vad är den totala ägandekostnaden?

Syftet är att välja en företagsarkitektur som uppfyller kraven på tillgänglighet, säkerhet och minskad administrativ komplexitet.

Letar du efter ett alternativ för leverans av Windows-applikationer och skrivbord?

Att migrera till moderna Azure Virtual Desktop är inte nödvändigtvis det bästa alternativet för varje organisation. Företag som främst behöver åtkomst till befintliga Windows-applikationer eller centralt värdade skrivbord kan dra nytta av en enklare arkitektur, särskilt när de inte kräver en helt Azure-värdad virtuell skrivbords miljö.

TSplus Remote Access möjliggör för IT-team att publicera Windows-applikationer och fullständiga fjärrskrivbord genom RDP-kompatibla klienter eller en HTML5-webbportal. Med stöd för lokala och molnbaserade Windows-servrar erbjuder det ett praktiskt alternativ för organisationer som vill behålla sina befintliga applikationer samtidigt som de förenklar leveransen av fjärrapplikationer.

Slutsats

Avvecklingen av Azure Virtual Desktop (klassisk) gör det nödvändigt att identifiera påverkade distributioner, bevara befintliga resurser och återställa åtkomst genom stödd infrastruktur. IT-team bör verifiera tillgängliga återställningsalternativ innan de försöker migrera eller rekonstruera.

Oavsett om organisationer fortsätter med moderna Azure Virtual Desktop eller antar en annan leveransarkitektur, förblir prioriteten att säkerställa säker och pålitlig applikationstillgång utan onödig operationell komplexitet.