Azure Virtual Desktop Classic Eläkkeelle: Seuraavat askeleet IT:lle

Johdanto

Azure Virtual Desktopin (klassinen) poistaminen luo tärkeän eron perinteisen yhteyspalvelun menettämisen ja taustalla olevien Azure-resurssien jatkuvan saatavuuden välillä. IT-tiimeille, jotka eivät ehtineet siirtymään määräaikaan mennessä, tämän eron ymmärtäminen on olennaista palautumisen suunnittelussa ilman, että olemassa olevaa infrastruktuuria vaihdetaan tarpeettomasti. Tämä artikkeli selittää, mitä poistaminen tarkoittaa olemassa oleville resursseille, kuinka tunnistaa klassiset käyttöönotot, mitkä siirtymisvaihtoehdot ovat edelleen arvioinnin arvoisia ja kuinka valita tuettu sovellustoimitusarkkitehtuuri.

Mitä tarkoittaa, kun Azure Virtual Desktop Classic poistuu käytöstä?

Microsoft on virallisesti eläköittänyt Azure Virtual Desktop (klassinen) 30. syyskuuta 2026 alkaen. Microsoftin virallisen dokumentaation mukaan "yhteydet klassisiin palveluihin estetään eläköittämisen jälkeen." Siksi eläköittäminen vaikuttaa erityisiin palvelutyyppeihin, jotka liittyvät virtuaalisten työpöytien ja sovellusten hallintaan käyttäen Azure Virtual Desktop (klassinen) -käyttömallia.

Kuitenkin eläkeprosessi ei koske modernia Azure Virtual Desktopia, joka käyttää Azure Resource Manageria (ARM). Siksi päähuolenaihe käyttäjille, jotka edelleen käyttävät klassisia resursseja, on kyvyttömyys muodostaa yhteyksiä aiemmin toimineisiin palveluihin. Tästä syystä käyttäjien tulisi olla erityisen tietoisia klassisesta resurssien hallinnasta, sillä itse resurssit eivät katoa eläkeajan jälkeen.

Mitä tarkalleen ottaen poistettiin käytöstä?

Azure Virtual Desktop (classic), aiemmin tunnettu nimellä Windows Virtual Desktop, perusti hallintainfrastruktuurinsa omiin PowerShell cmdlet -komentoihinsa, API:hin ja palvelinobjekteihin.

Toisin kuin moderni Azure Virtual Desktop, klassisia isäntäryhmiä ja sovellusryhmiä ei määritelty yhtenäisiksi Azure-resurssienhallinnan resursseiksi.

Tänään nämä komponentit on sisällytetty Azure-resurssienhallintajärjestelmään, mikä mahdollistaa ylläpitäjien soveltaa Azure-rooliin perustuvaa pääsynhallintaa (RBAC), hallita palvelua Azure-portaalin kautta ja käyttää moderneja infrastruktuuri koodina -malleja käyttöönoton automatisointiin.

Kyky	AVD Classic (eläkkeelle jäänyt)	Moderni AVD
Hallinta	Perinteinen hallintataso	Azure Resource Manager
Azure-portaali	Rajoitettu integraatio	Natiivinen integraatio
Pääsynhallinta	Perinteiset vuokralaisroolit	Azure RBAC
Automaatio	Klassiset API:t ja PowerShell	ARM, API:t, Az PowerShell
Työpöytä- ja sovellustoimitus	Yhteydet estetty	Tuettu
Palvelun tila	Eläkkeellä	Tuettu

Eläköityminen edustaa muutosta taustalla olevassa palveluarkkitehtuurissa, ei vain tuotteen nimeämistä.

Toimiiko Moderni Azure Virtual Desktop edelleen?

Kyllä. Moderni Azure Virtual Desktop on tuettu ja se tarjoaa edelleen täydellisiä Windows-työpöytiä, monikäyttöalustoja ja yksittäisten sovellusten toimitusta RemoteAppin kautta.

Organisaatiot, jotka jo käyttävät Azure Resource Manager (ARM) -integroitua isäntäpoolia, eivät ole vaikuttaneet klassisen palvelun poistamiseen.

IT-päälliköiden tulisi myös huomioida ero klassisen Azure Virtual Desktopin tuen päättymisen ja vanhempien Remote Desktop -asiakkaiden erillisen tuen päättymisen välillä. Windowsin Remote Desktop -asiakkaan (MSI) oli määrä saavuttaa tuen päättyminen julkisissa pilviympäristöissä 27. maaliskuuta 2026 ja Azure Virtual Desktopin (klassinen) 28. syyskuuta 2026.

Miten IT-tiimit voivat tunnistaa Azure Virtual Desktop Classic -asennukset?

Ensimmäinen askel on tunnistaa, ovatko tuotantokuormitukset edelleen riippuvaisia eläkkeelle jääneestä arkkitehtuurista.

Tämä on erityisen tärkeää järjestelmille, jotka otettiin käyttöön vuosia sitten ja joita saattavat olla hallinnoineet uudet ylläpitäjät tai joita on jätetty huomiotta nykyisessä infrastruktuuridokumentaatiossa.

Tarkista Azure Resource Manager -integraatio

Sinun tulisi aloittaa tarkistamalla Azure Virtual Desktop -resurssit Azure-portaalissa. Modernit Azure Virtual Desktop -asennukset altistavat isäntäryhmiä, sovellusryhmiä ja työtiloja Azure-resursseina tilauksessa ja resurssiryhmässä. Sen sijaan klassiset asennukset altistivat palvelinobjekteja, joita hallittiin eri tavoin.

Seuraavien Azure Virtual Desktop -elementtien läsnäolo on vahva merkki klassisesta käyttöönotosta:

• Classic Azure Virtual Desktop PowerShell -moduulia käyttävät isäntäaltaat
• Historialliset viittaukset klassiseen palveluasiakkaaseen tai klassiseen palvelu-API:hin
• Sovellusryhmät, joilta puuttuvat vastaavat ARM-resurssit
• Istuntoisäntä virtuaalikoneet, jotka viittaavat vanhempaan dokumentaatioon

Samaan aikaan Azure-portaalissa isäntäpoolin puuttuminen ei välttämättä tarkoita klassista käyttöönottoa. Sinun tulisi aina tarkistaa, mikä tilaus, Microsoft Entra -vuokraaja ja rooliin perustuva pääsynhallinta käyttäjällä on ennen kuin analysoit ongelmaa tarkemmin.

Arvioi perintöhallintatyökalut ja riippuvuudet

Käyttöönottoskriptit ja automaatioarkistot voivat toimia lisätoimintana todisteiden lähteinä.

Esimerkiksi Microsoft.RDInfra.RDPowerShell-viittauksia tai klassisia vuokralaiskohtaisia hallintatoimia sisältävien skriptien läsnäolo viittaisi siihen, että ympäristö on konfiguroitu vanhemmalla hallintapinoilla.

Modernit ympäristöt hyödyntävät Azure Resource Manager -integroitua hallintaliittymää ja siihen liittyviä Az PowerShell -moduuleja.

Järjestelmänvalvojien tulisi myös inventoida kaikki sovellus-, käyttäjä- ja infrastruktuuriresurssit, jotka liittyvät mahdollisesti vaikuttaviin isäntäryhmiin.

Tämä sisältää istuntoisäntävirtuaalikoneiden, sovellusmääritysten, profiilitallennuspaikkojen, todennusriippuvuuksien, verkkokonfiguraatioiden ja varmuuskopiointivarastojen tarkastamisen. Microsoftin manuaalisen migraation dokumentaatio sisältää yksityiskohtaisia vertailuja klassisen palveluobjektimallin ja Azure Resource Manager (ARM) -integroidun resurssimallin välillä.

Mitä voi tapahtua olemassa oleville resursseillesi Azure Virtual Desktop Classicin lopettamisen jälkeen?

Tärkein ero on eläkkeelle jääneen yhteyspalvelun ja taustalla olevan Azure-infrastruktuurin välillä.

Vaikka klassiset työpöytäkytkennät on estetty, olemassa olevat virtuaalikoneet, tallennusresurssit ja sovellustiedot voivat pysyä paikallaan.

Olemassa olevat virtuaalikoneet ja tallennustila voivat pysyä saatavilla

Azure-virtuaalikoneet ovat resursseja, joita hallitaan itsenäisesti ilman, että luotetaan poistettuun klassiseen palvelun ohjaustasoon. Näin ollen istuntoisäntävirtuaalikoneet, hallitut levyt ja verkkoresurssit, jotka on luotu tilauksessa, saattavat edelleen olla olemassa.

Kuitenkin niitä ei voida käyttää elvyttämään eläkkeelle jäänyttä yhteysvälittäjää. Uudessa Azure-infrastruktuurissa luotuja virtuaalikoneita ei ole saatavilla palauttamaan organisaation työpöytäkokemusta toimivaan tilaan.

Järjestelmänvalvojien tulisi tarkastella kutakin resurssia huolellisesti, ja jos sitä voidaan käyttää uudelleen tuetussa kokoonpanossa, heidän tulisi suorittaa seuraavat vaiheet.

On tärkeää tarkistaa, onko virtuaalikoneen käyttöjärjestelmä tuettu ja ovatko sovellukset ja turvallisuusasetukset yhteensopivia.

Sovelluksen käyttöoikeus ja käyttäjätiedot vaativat erilliset tarkastukset

Käyttäjät, jotka ovat yhdistäneet klassisen työpöydän tai RemoteApp-istuntotyypin kautta, eivät enää voi käynnistää sovelluksiaan tämän palvelun kautta.

Palvelun lopettamisen seurauksena voi olla pääsyn menettäminen työpöytiin, julkaistuihin sovelluksiin ja häiriöitä liiketoimintaprosesseissa.

Kuitenkin palvelun lopettaminen ei takaa, että käyttäjään liittyvät tiedot poistetaan.

Useimmissa tapauksissa käyttäjätiedot todennäköisesti tallennetaan Azure Filesiin, VM-levyille tai muihin tallennusvälineisiin, mutta tämän tiedon säilytys ja saatavuus riippuvat siitä, miten se on konfiguroitu, suojattu käyttöoikeuksilla, varmuuskopioitu jne.

Ennen järjestelmien poistamista käytöstä tai siirtämistä IT-osastojen on varmistettava, että kaikki tarvittavat tiedot on säilytetty.

Voiko tiimi silti siirtää Azure Virtual Desktop Classicin sen elinkaaren päätyttyä?

Microsoft dokumentoi kaksi siirtymispolkua Azure Virtual Desktopin (klassinen) siirtämiseksi uuteen ARM-integroituun Azure Virtual Desktopiin: automaattinen siirto ja manuaalinen siirto.

Molemmat vaihtoehdot oli tarkoitus olla käyttökelpoisia 30. syyskuuta 2026 asti.

Koska tuo päivämäärä on menneisyydessä, ylläpitäjien ei tulisi pitää asiakirjassa kuvattuja työkaluja tuotantovalmiina kaikissa skenaarioissa.

Microsoftin dokumentaatio ei tarjoa ohjeita siirtymäkaudelle.

Siksi organisaatioiden ei tulisi luottaa mihinkään eläkeiän jälkeisiin siirtymistyökaluihin ja -prosesseihin.

Vaihtoehto 1: Automaattinen siirto

Microsoftin automaattinen siirtoprosessi hyödyntää PowerShell-pohjaista työkalua siirtääkseen kelvolliset klassiset palvelukonfiguraatiot ARM-resursseihin.

Yrityksen dokumentaatio suosittelee, että käyttäjillä on aktiivinen Azure-tilaus, jossa on tarvittavat oikeudet, ja että he täyttävät siirtomoduulin luettelemat ympäristövaatimukset.

Esimerkiksi Microsoftin ohjeet ehdottavat, että käyttäjille annetaan Contributor-oikeudet Azure-resurssien luomiseen ja User Access Administrator -oikeudet sovellusryhmän jäsenyyden hallintaan.

On kuitenkin tärkeää tunnistaa, että työkalu ei voi taata tietojen palauttamista elinkaaren päättymisen jälkeen.

Organisaatioiden, joilla on aktiivisia klassisia käyttöönottoja, tulisi ottaa yhteyttä Microsoftin tukeen varmistaakseen, onko siirtoprosessi saatavilla heidän ympäristössään.

Vaihtoehto 2: Manuaalinen siirto tai uudelleenrakentaminen

Manuaalinen migraatio vaatii nykyaikaisten Azure Virtual Desktop -resurssien luomista ja palvelukonfiguraation uudelleenkonfigurointia.

Riippuen erityistapauksesta, järjestelmänvalvojien on ehkä tarpeen:

• Luo integroituja ARM-pohjaisia isäntäryhmiä, sovellusryhmiä ja työtiloja
• Perusta tai vaihda istuntoisäntä virtuaalikoneet
• Rekisteröi yhteensopivat istuntoisännät uusilla isäntäaltailla
• Luo käyttäjä- ja sovellusassosiaatiot uudelleen
• Säädä identiteetti-, verkko-, turvallisuus- ja profiiliasetuksia

Manuaalinen lähestymistapa tulee tarpeelliseksi, kun vanhat kokoonpanot sisältävät dokumentoimatonta monimutkaisuutta, laajaa mukauttamista tai kun nykyaikaiset siirtotyökalut osoittautuvat riittämättömiksi.

On huomattava, että toimitusinfrastruktuurin uudelleenrakentaminen ei aina tarkoita sovellusten ja tietojen täydellistä korvaamista.

Jäljelle jääviä komponentteja voidaan usein käyttää uudelleen asianmukaisten yhteensopivuusarviointien, lisensointiarvioiden ja turvallisuusauditointien kautta.

Päätöksen tulisi perustua olemassa olevien resurssien nykytilaan ja Microsoftilta saatavilla olevaan tukeen.

Tilanne	Lähestymistapa arvioimiseen
Kelvollinen klassinen kokoonpano ja Microsoft vahvistaa siirtotuen	Automaattinen siirto
Monimutkainen tai vaikeasti saavutettava klassinen kokoonpano	Manuaalinen uudelleenrakentaminen
Olemassa olevat VM:t ja tiedot pysyvät saatavilla	Uudelleenrakentaa toimituspalvelut ja arvioida uudelleenkäyttöä
Perinteisiä työkuormia ei enää vaadita	Turvallinen poistaminen
Azure-pohjaiset työpöydät eivät enää ole tarpeen	Vaihtoehtoinen toimitusarkkitehtuuri

Mitä IT-tiimien tulisi tehdä, jos he ovat myöhästyneet eläkeajan määräajasta?

Organisaatioiden, jotka eivät ole saaneet muutostaan päätökseen 30. syyskuuta 2026 mennessä, tulisi priorisoida resurssien säilyttämistä ja liiketoimintasovellusten pääsyn palauttamista.

Sen sijaan, että yritetään useita yhteyksiä poistettuun palveluun, järjestelmänvalvojia kehotetaan suorittamaan palautusprosessi.

Vaihe 1: Arvioi palvelun vaikutus

Tunnista, mitkä käyttäjät, työpöydät ja sovellukset eivät ole käytettävissä.

Selvitä, onko kyseessä koko ympäristö vai tietyt työkuormat, joita asia koskee. Vahvista, että ongelma liittyy klassiseen eläkkeelle siirtymiseen eikä johonkin muuhun todennukseen, verkottumiseen tai istuntoisäntäongelmaan.

Vaihe 2: Säilytä infrastruktuuri ja tiedot

Tarkista Azure-tilaukset tunnistaaksesi nykyiset virtuaalikoneet, hallinnoidut levyt, tallennustilit ja verkkoresurssit

Dokumentin riippuvuudet ja varmista varmuuskopiot ole olemassa ennen kuin teet mitään toimenpiteitä. Älä poista resursseja ennen kuin sovellustiedot, käyttäjäprofiilit ja konfiguraatiotiedot on tunnistettu.

Vaihe 3: Vahvista palautusvaihtoehdot Microsoftin kanssa

Ota yhteyttä Microsoftin tukeen varmistaaksesi, että tuettuja siirto-/palautusmenettelyjä on edelleen saatavilla.

Alkuperäiset automaattiset/käsin tehtävät siirtosäännöt kehitettiin eläköitymispäivämäärä mielessä, joten niiden ei pitäisi olettaa olevan voimassa.

Mikäli klassista konfiguraatiota ei voida siirtää, ympäristön uudelleenrakentaminen tuetuilla Azure Virtual Desktop -resursseilla saattaa olla tarpeen.

Vaihe 4: Palauta sovelluksen ja työpöydän toimitus

Valitse arkkitehtuuri, joka tukee sovelluksia ja työpöytiä, joita käyttäjät tarvitsevat.

Organisaatioille, jotka aikovat pysyä Azure Virtual Desktopissa, tämä yleensä tarkoittaa ARM-integroitujen isäntäryhmien, tuettujen istuntoisäntien, sovellusryhmien ja käyttäjäoikeuksien määrittämistä.

Jotkut organisaatiot saattavat huomata, että toinen sovellusten julkaiseminen tai työpöyratkaisu sopii paremmin heidän tarpeisiinsa.

Tavoitteena on palauttaa pääsy samalla välttäen aiemman asetuksen monimutkaisuus ja tarpeeton ylikuormitus.

Miten validoidaan Azure Virtual Desktop -siirto?

Infrastruktuurin palauttaminen ei takaa normaaleja käyttäjätoimintoja.

Siirtäminen tai uudelleenrakentaminen on siten vahvistettava palvelu- ja sovellustasoilla.

Vahvista todennus ja käyttäjäoikeudet

Vahvista, että käyttäjät voivat todentaa itsensä ja käyttää heille myönnettyjä resursseja.

Tarkista Microsoft Entra, monivaiheinen todennus, ehdolliset käyttöoikeuspolitiikat ja Azure RBAC -määritykset tarpeen mukaan.

Järjestelmänvalvojien tulisi varmistaa, että käyttöoikeudet ovat linjassa vähimmäisoikeuden periaatteen kanssa ja että ei ole olemassa perintökäyttöoikeusmalleja, jotka on siirretty vahingossa eteenpäin.

Testaa liiketoimintakriittisiä sovelluksia

Testaa julkaistuja sovelluksia ja työpöytiä hyödyntämällä erillisiä edustavia käyttäjätiliä.

Validointitoimintojen tulisi sisältää sovelluksen käynnistys, tietokantayhteydet, verkkohakemistot, tulostaminen, leikepöydän uudelleenohjaus ja tarvittavat oheislaitteet, jos sellaisia on.

Perinteiset sovellukset on otettava erityisesti huomioon, sillä ne saattavat vaatia erityisen käyttöjärjestelmäkonfiguraation, verkkopolun tai sovelluskomponentin.

Esimerkki perinteisestä sovelluksesta voisi olla ERP-sovellus, joka käynnistyy onnistuneesti, mutta ei onnistu yhdistämään tietokantaansa uudelta istuntopalvelimelta.

Vahvista profiilit, suorituskyky ja toiminnot

Yritysten, jotka käyttävät FSLogixia tai muita profiilointityökaluja, tulisi varmistaa, että kaikki on oikein liitetty, pysyvää ja että siihen voidaan päästä asianmukaisesti.

On tärkeää testata se kirjautumalla ensimmäistä kertaa ja tarkistamalla, toimiiko kaikki hyvin, kun käyttäjä avaa sovelluksen ja seuraavassa kirjautumisessa. On myös olennaista varmistaa, että prosesseja valvotaan, varmuuskopioidaan ja palautetaan.

Muutto on valmis vasta, kun kaikki on valmista, mukaan lukien käyttäjien mahdollisuus käyttää sovelluksiaan. Järjestelmän ylläpitäminen oikein on oltava mahdollista.

Should Organizations Reconsider Their Desktop Delivery Architecture?

Azure Virtual Desktop (classic) -eläkkeelle siirtyminen on pääasiassa alustan elinkaarikysymys, mutta se tarjoaa myös mahdollisuuden arvioida, tukevatko nykyinen työpöytäjakelualusta edelleen tarpeitasi.

Siirtyminen moderniin Azure Virtual Desktopiin on monille ilmeinen valinta, erityisesti niille, jotka ovat jo Azure-ensimmäisiä ja käyttävät Azure-isännöityjä työpöytiä.

Muiden organisaatioiden vaatimukset ovat vähemmän monimutkaisia.

Milloin moderni Azure Virtual Desktop on järkevää?

Moderni Azure Virtual Desktop voi olla hyvä vaihtoehto organisaatioille, jotka tarvitsevat keskitetysti hallittuja Windows-työpöytiä ja sovelluksia, jotka on isännöity Azuren avulla.

Se mahdollistaa monikäyttöisyyden, RemoteApp-mallit sekä Microsoft ID- ja hallintatyökalut.

On järkevää yrityksille, joilla on olemassa oleva Azure-jalanjälki, mutta IT-osastojen on silti käsiteltävä pilven monimutkaisuuksia, mukaan lukien lisensointi, verkottuminen, tallennus, hallinta ja operatiiviset näkökohdat.

Milloin toinen Windows-sovelluksen julkaisuarkkitehtuuri on sopiva?

Kaikki organisaatiot eivät vaadi täysin toteutettua työpöytävirtualisointiympäristöä, joka on isännöity Microsoft Azuren palvelimilla.

Jotkut yritykset tarvitsevat vain rajallisesti etäkäyttö tiettyihin Windows-sovelluksiin, kuten talous- tai ERP-sovelluksiin tai vanhempiin liiketoimintasovelluksiin.

Nämä organisaatiot voivat harkita sovellusten julkaisemista, jotka on isännöity keskitetysti hallituissa Windows-palvelimissa sen sijaan, että ne käyttävät yleistä virtuaalista työpöytäinfrastruktuuria (VDI).

Modern Azure Virtual Desktop ei ole vain työpöydän tai sovellusten virtualisointia, vaan myös sovellusten julkaisemista.

Tänään on mahdollista julkaista Azure-sovelluksia RemoteApp-menetelmää käyttäen.

Todellisuus on se, että sovellusten toimitustilassa ei ole dikotomiaa, vaan pikemminkin jatkuvuus, joka ulottuu sovellusten julkaisemisesta työpöytävirtualisointiin.

Keskustelun tulisi keskittyä löytämään sovellusten toimitusarkkitehtuuri, joka on kaikkein relevantti annettavalle organisaatiolle ja käyttötapauksille.

Esimerkiksi, jos Windows Server -kansiossa on pitkäaikainen sovellus, jota käyttää joukko valtuutettuja käyttäjiä, organisaation ei tarvitse julkaista sitä Azure Virtual Desktopissa, kun perinteinen infrastruktuuri toimii edelleen oikein.

Sen sijaan voi olla hyödyllistä, että tällaiset yritykset pitävät sovellusten isännöintipaikan omassa ympäristössään samalla kun ne päivittävät sovellusten käyttömenetelmäänsä.

Mitä tekijöitä tulisi ottaa huomioon päätöksenteossa?

IT-osastojen tulisi arvioida valintaa käyttöönoton tarpeiden kriteerien mukaan, eikä poistettavan järjestelmän ominaisuuksien perusteella.

Harkinta	Avainkysymys
Isännöinti	Onko työkuormien pakko toimia Azuren ympäristössä?
Käyttäjäkokemus	Koko työpöydät vai valitut sovellukset?
Yhteensopivuus	Toimiiko olemassa olevat Windows-sovellukset?
Turvallisuus	Miten identiteetti ja istuntopääsy ovat suojattuja?
Hallinta	Kuka ylläpitää infrastruktuuria?
Lisensointi	Mitkä Microsoftin ja ohjelmistolisenssit koskevat?
Laajennettavuus	Kuinka monta samanaikaista käyttäjää tarvitaan?
Kustannus	Mikä on kokonaisomistuskustannus?

Tavoitteena on valita yritysarkkitehtuuri, joka täyttää saatavuuden, turvallisuuden ja vähennetyn hallinnollisen monimutkaisuuden vaatimukset.

Etsitkö vaihtoehtoa Windows-sovellusten ja työpöytäjakelun varten?

Siirtyminen moderniin Azure Virtual Desktopiin ei välttämättä ole paras vaihtoehto jokaiselle organisaatiolle. Yritykset, jotka tarvitsevat ensisijaisesti pääsyä olemassa oleviin Windows-sovelluksiin tai keskitetysti isännöityihin työpöytiin, voivat hyötyä yksinkertaisemmasta arkkitehtuurista, erityisesti kun he eivät vaadi täysin Azure-isännöityä virtuaalista työpöytäympäristöä.

TSplus Etäyhteys mahdollistaa IT-tiimien julkaista Windows-sovelluksia ja täydellisiä etätyöpöytiä RDP-yhteensopivien asiakasohjelmien tai HTML5-verkkoportaalin kautta. Paikallisten ja pilvipohjaisten Windows-palvelimien tuella se tarjoaa käytännöllisen vaihtoehdon organisaatioille, jotka haluavat säilyttää olemassa olevat sovelluksensa samalla kun yksinkertaistavat etäsovellusten toimitusta.

Päätelmä

Azure Virtual Desktop (classic) -palvelun lopettaminen tekee välttämättömäksi tunnistaa vaikuttavat käyttöönotot, säilyttää olemassa olevat resurssit ja palauttaa pääsy tuetun infrastruktuurin kautta. IT-tiimien tulisi tarkistaa käytettävissä olevat palautusvaihtoehdot ennen siirron tai uudelleenrakentamisen yrittämistä.

Olipa organisaatioilla käytössä moderni Azure Virtual Desktop tai jokin muu toimitusarkkitehtuuri, prioriteetti pysyy turvallisen ja luotettavan sovelluskäytön varmistamisessa ilman tarpeetonta operatiivista monimutkaisuutta.