Pakilala
Ang pagreretiro ng Azure Virtual Desktop (classic) ay lumilikha ng isang mahalagang pagkakaiba sa pagitan ng pagkawala ng isang legacy connection service at ang patuloy na pagkakaroon ng mga pangunahing Azure resources. Para sa mga IT team na hindi nakasunod sa takdang panahon ng migrasyon, ang pag-unawa sa pagkakaibang ito ay mahalaga sa pagpaplano ng pagbawi nang hindi kinakailangang palitan ang umiiral na imprastruktura. Ipinaliwanag ng artikulong ito kung ano ang ibig sabihin ng pagreretiro para sa mga umiiral na resources, kung paano matukoy ang mga classic deployments, aling mga opsyon sa migrasyon ang nananatiling sulit suriin, at kung paano pumili ng suportadong application delivery architecture.
Ano ang Ibig Sabihin Kapag Nagretiro ang Azure Virtual Desktop Classic?
Opisyal nang inalis ng Microsoft ang Azure Virtual Desktop (classic) simula Setyembre 30, 2026. Batay sa opisyal na dokumentasyon ng Microsoft, “ang mga koneksyon sa mga klasikong serbisyo ay mahaharang pagkatapos ng pag-alis.” Samakatuwid, ang pag-alis ay nakakaapekto sa tiyak na uri ng mga serbisyo na may kaugnayan sa pamamahala ng mga virtual desktop at aplikasyon gamit ang modelo ng deployment ng Azure Virtual Desktop (classic).
Gayunpaman, ang proseso ng pagreretiro ay hindi nalalapat sa modernong Azure Virtual Desktop na gumagamit ng Azure Resource Manager (ARM). Kaya, ang pangunahing alalahanin para sa mga gumagamit na patuloy na gumagamit ng mga klasikong mapagkukunan ay ang kawalang-kakayahang makapag-establisa ng mga koneksyon sa mga serbisyong dati nang gumagana. Samakatuwid, ang mga gumagamit ay dapat na partikular na maging maalam sa pamamahala ng klasikong mapagkukunan dahil ang mga mapagkukunan mismo ay hindi mawawala pagkatapos ng petsa ng pagreretiro.
Ano ang Eksaktong Nawala?
Azure Virtual Desktop (classic), na kilala dati bilang Windows Virtual Desktop, ay may imprastruktura ng pamamahala na batay sa mga nakalaang PowerShell cmdlets, APIs, at mga service object.
Hindi tulad ng modernong Azure Virtual Desktop, ang mga klasikong host pool at application group ay hindi tinukoy bilang pinagsamang mga mapagkukunan ng Azure resource manager.
Ngayon, ang mga komponent na ito ay isinama sa sistema ng pamamahala ng mapagkukunan ng Azure na nagpapahintulot sa mga administrador na mag-aplay ng Azure role-based access control (RBAC), pamahalaan ang serbisyo sa pamamagitan ng Azure portal, at gumamit ng mga modernong pattern ng infrastructure-as-code para sa automation ng deployment.
| Kakayahan | AVD Classic (retired) | Modern AVD |
|---|---|---|
| Pamamahala | Nakatatandang control plane | Azure Resource Manager |
| Azure portal | Limitadong integrasyon | Katutubong integrasyon |
| Kontrol ng access | Mga tungkulin ng legacy tenant | Azure RBAC |
| Automation | Classic APIs at PowerShell | ARM, APIs, Az PowerShell |
| Paghahatid ng Desktop at app | Nakatigil ang mga koneksyon | Suportado |
| Katayuan ng serbisyo | Nakapag-pagliban | Suportado |
Ang pagreretiro ay kumakatawan sa isang pagbabago sa pangunahing arkitektura ng serbisyo, hindi lamang isang pagpapalit ng pangalan ng produkto.
Gumagana pa ba ang Modern Azure Virtual Desktop?
Oo. Sinusuportahan ang Modern Azure Virtual Desktop at patuloy na nag-aalok ng buong Windows desktops, multisession platforms, at indibidwal na paghahatid ng app sa pamamagitan ng RemoteApp.
Ang mga organisasyon na gumagamit na ng Azure Resource Manager (ARM)-integrated host pools ay hindi naapektuhan ng pag-alis ng klasikong serbisyo.
Dapat ding tandaan ng mga IT manager ang pagkakaiba sa pagtatapos ng suporta para sa klasikong Azure Virtual Desktop at ang hiwalay na pagtatapos ng suporta para sa mga mas lumang Remote Desktop client. Ang Remote Desktop client para sa Windows (MSI) ay nakatakdang umabot sa pagtatapos ng suporta para sa mga pampublikong cloud environment sa Marso 27, 2026, at para sa Azure Virtual Desktop (klasiko) sa Setyembre 28, 2026.
Paano Makikilala ng mga IT Team ang Azure Virtual Desktop Classic Deployments?
Ang unang hakbang ay tukuyin kung ang anumang mga workload ng produksyon ay patuloy na umaasa sa retiradong arkitektura.
Ito ay lalong mahalaga para sa mga sistema na inilagay sa produksyon taon na ang nakalipas at maaaring na-reposess ng mga bagong administrador o hindi pinansin sa kasalukuyang dokumentasyon ng imprastruktura.
Suriin ang Integrasyon ng Azure Resource Manager
Dapat mong simulan ang pagsusuri sa mga mapagkukunan ng Azure Virtual Desktop sa Azure portal. Ang mga modernong deployment ng Azure Virtual Desktop ay naglalantad ng mga host pool, application group, at workspace bilang mga mapagkukunan ng Azure sa isang subscription at resource group. Sa kabaligtaran, ang mga klasikong deployment ay ginagamit upang ilantad ang mga service object na pinamamahalaan sa iba't ibang paraan.
Ang presensya ng mga sumusunod na elemento ng Azure Virtual Desktop ay nagsisilbing isang malakas na tagapagpahiwatig ng isang klasikong deployment:
- Mga host pool na gumagamit ng klasikong Azure Virtual Desktop PowerShell module
- Mga makasaysayang sanggunian sa isang klasikong serbisyo ng nangungupahan o klasikong serbisyo ng API
- Mga grupo ng aplikasyon na walang katugmang ARM na mapagkukunan
- Mga virtual machine ng session host na tumutukoy sa mas lumang dokumentasyon
Kasabay nito, ang kawalan ng host pool sa Azure portal ay hindi kinakailangang indikasyon ng isang klasikong deployment. Dapat mong laging suriin kung aling subscription, Microsoft Entra tenant, at role-based access control ang mayroon ang gumagamit bago mo masusing suriin ang problema.
Suriin ang mga Legacy Management Tools at Dependencies
Maaaring magsilbing karagdagang mapagkukunan ng ebidensya ang mga script ng deployment at mga repository ng automation.
Halimbawa, ang pagkakaroon ng mga script na naglalaman ng mga sanggunian sa Microsoft.RDInfra.RDPowerShell o mga klasikong operasyon ng pamamahala sa antas ng nangungupahan ay magmumungkahi na ang kapaligiran ay na-configure gamit ang mas lumang pamamahala.
Ang mga modernong kapaligiran ay gagamit ng mga interface ng pamamahala na naka-integrate sa Azure Resource Manager at mga kaugnay na module ng Az PowerShell.
Dapat ding i-inventory ng mga administrador ang lahat ng aplikasyon, gumagamit, at mga mapagkukunan ng imprastruktura na nauugnay sa mga potensyal na naapektuhang host pool.
Ito ay kinabibilangan ng pagsusuri ng mga virtual machine ng session host, mga itinalagang aplikasyon, mga lokasyon ng imbakan ng profile, mga dependency ng pagpapatotoo, mga configuration ng networking, at mga repository ng backup. Ang Dokumentasyon ng manu-manong migrasyon ng Microsoft naglalaman ng detalyadong paghahambing sa pagitan ng klasikong modelo ng serbisyo ng bagay at modelo ng mapagkukunan na pinagsama sa Azure Resource Manager (ARM).
Ano ang Maaaring Mangyari sa Iyong Umiiral na Mga Mapagkukunan Matapos Magretiro ang Azure Virtual Desktop Classic?
Ang pinakamahalagang pagkakaiba ay nasa pagitan ng retiradong serbisyo ng koneksyon at ang nakapailalim na imprastruktura ng Azure.
Habang ang mga klasikong koneksyon sa desktop ay naka-block, ang mga umiiral na virtual machine, mga mapagkukunan ng imbakan at data ng aplikasyon ay maaaring manatili sa lugar.
Maaaring manatiling available ang mga umiiral na Virtual Machines at Storage
Ang mga Azure virtual machine ay mga mapagkukunan na pinamamahalaan nang mag-isa, nang hindi umaasa sa retiradong klasikong serbisyo ng control plane. Kaya, ang mga session host virtual machine, mga pinamamahalaang disk, at mga mapagkukunan ng networking na nilikha sa subscription ay maaaring umiiral pa rin.
Gayunpaman, hindi ito maaaring gamitin upang ibalik ang retiradong connection broker. Walang mga virtual machine na nilikha sa bagong Azure infrastructure na magagamit upang ibalik ang karanasan sa desktop ng isang organisasyon sa nagtatrabaho na estado.
Dapat suriin ng mga administrador ang bawat mapagkukunan nang maingat, at kung maaari itong magamit muli para sa isang suportadong configuration, dapat nilang isagawa ang mga sumusunod na hakbang.
Mahalagang suriin kung ang operating system ng virtual machine ay sinusuportahan at kung ang mga aplikasyon at mga configuration ng seguridad ay tugma.
Ang Pag-access sa Aplikasyon at Data ng Gumagamit ay Nangangailangan ng Hiwalay na Pagsusuri
Ang mga gumagamit na kumonekta sa pamamagitan ng klasikong desktop o uri ng sesyon ng RemoteApp ay hindi na makakapag-launch ng kanilang mga aplikasyon sa pamamagitan ng serbisyong ito.
Ang resulta ng pagtigil ng serbisyo ay maaaring pagkawala ng access sa mga desktop, na-publish na mga aplikasyon, at mga pagkaabala sa mga proseso ng negosyo.
Gayunpaman, ang pagreretiro ng serbisyo ay hindi ginagarantiyahan na ang mga datos na may kaugnayan sa gumagamit ay mabubura.
Sa karamihan ng mga kaso, malamang na ang data ng mga gumagamit ang nananatili sa Azure Files, VM disks o iba pang mga storage medium, ngunit ang pagpapanatili at accessibility ng impormasyong ito ay nakabatay sa kung paano ito na-configure, na-secure gamit ang mga pahintulot, na-backup, atbp…
Bilang ganon, bago ang pag-decommission o paglipat ng mga sistemang kasangkot, kailangan ng mga departamento ng IT na tiyakin na naitago nila ang lahat ng kinakailangang data.
Maaari pa bang ilipat ng isang koponan ang Azure Virtual Desktop Classic pagkatapos itong magretiro?
Microsoft ay nagdodokumento ng dalawang landas ng migrasyon para sa paglipat mula sa Azure Virtual Desktop (classic) patungo sa bagong ARM-integrated Azure Virtual Desktop: awtomatikong migrasyon at manwal na migrasyon.
Parehong opsyon ay nilayon na maging magagamit hanggang Setyembre 30, 2026.
Dahil ang petsang iyon ay nasa nakaraan, hindi dapat isaalang-alang ng mga administrador ang mga tool na inilarawan sa dokumentasyon bilang handa na para sa produksyon sa lahat ng senaryo.
Ang dokumentasyon ng Microsoft ay hindi nagbibigay ng gabay sa panahon ng paglipat.
Samakatuwid, hindi dapat umasa ang mga organisasyon sa anumang mga tool at proseso para sa paglipat pagkatapos ng pagreretiro.
Opsyon 1: Awtomatikong Migrasyon
awtomatikong proseso ng migrasyon ng Microsoft gumagamit ng tool na batay sa PowerShell upang ilipat ang mga karapat-dapat na klasikong configuration ng serbisyo sa mga mapagkukunan ng ARM.
Inirerekomenda ng dokumentasyon ng kumpanya na ang mga gumagamit ay may aktibong Azure subscription na may kinakailangang mga pahintulot at nakakatugon sa mga kinakailangan sa kapaligiran na nakalista ng migration module.
Halimbawa, ang mga alituntunin ng Microsoft ay nagmumungkahi na ang mga gumagamit ay bigyan ng mga pahintulot ng Contributor upang lumikha ng mga mapagkukunan ng Azure at mga pahintulot ng User Access Administrator upang pamahalaan ang pagiging miyembro ng grupo ng aplikasyon.
Gayunpaman, mahalagang kilalanin na ang tool ay hindi makapagbibigay ng garantiya sa pagbawi ng data pagkatapos ng pagreretiro.
Ang mga organisasyon na may aktibong klasikong deployment ay dapat kumonsulta sa suporta ng Microsoft upang kumpirmahin kung ang proseso ng migrasyon ay isang magagamit na opsyon para sa kanilang kapaligiran.
Opsyon 2: Manwal na Migrasyon o Rekonstruksyon
Ang manu-manong migrasyon ay nangangailangan ng paglikha ng mga modernong Azure Virtual Desktop na mapagkukunan at ang muling pagsasaayos ng configuration ng serbisyo.
Depende sa tiyak na kaso, maaaring kailanganin ng mga administrador na:
- Lumikha ng pinagsamang ARM-based na host pools, application groups at workspaces
- Itakda o palitan ang mga virtual machine ng session host
- Magrehistro ng mga katugmang session host sa mga bagong host pool
- Muling likhain ang mga ugnayan ng gumagamit at aplikasyon
- Ayusin ang pagkakakilanlan, network, seguridad, at mga configuration ng profile
Nagiging kinakailangan ang manu-manong pamamaraan kapag ang mga legacy na configuration ay naglalaman ng undocumented na kumplikado, malawak na pag-customize, o kapag ang mga modernong tool sa migrasyon ay napatunayang hindi sapat.
Mahalaga, ang muling pagtatayo ng imprastruktura ng paghahatid ay hindi palaging nangangailangan ng ganap na pagpapalit ng mga aplikasyon at data.
Ang natitirang mga bahagi ay madalas na maaaring magamit muli sa pamamagitan ng angkop na pagsusuri ng pagiging tugma, pagsusuri ng lisensya, at mga audit ng seguridad.
Ang desisyon ay dapat batay sa kasalukuyang estado ng umiiral na mga mapagkukunan at magagamit na suporta mula sa Microsoft.
| Sitwasyon | Pamamaraan upang suriin |
|---|---|
| Karapat-dapat na klasikong configuration at kinukumpirma ng Microsoft ang suporta sa migrasyon | Awtomatikong migrasyon |
| Kumplikado o hindi maaabot na klasikong pagsasaayos | Manwal na muling pagtatayo |
| Ang mga umiiral na VM at data ay mananatiling available | Muling buuin ang mga serbisyo ng paghahatid at suriin ang muling paggamit |
| Hindi na kinakailangan ang mga legacy workload. | Ligtas na pag-aalis |
| Hindi na kinakailangan ang mga desktop na naka-host sa Azure. | Alternatibong arkitektura ng paghahatid |
Ano ang Dapat Gawin ng mga IT Team Kung Sila ay Nakaligtaan ang Takdang Panahon ng Pagreretiro?
Ang mga organisasyon na hindi nakatapos ng kanilang migrasyon bago ang Setyembre 30, 2026, ay dapat bigyang-priyoridad ang pagpapanatili ng mga mapagkukunan at ang pagbabalik ng access sa mga aplikasyon ng negosyo.
Sa halip na subukan ang maraming koneksyon sa retiradong serbisyo, pinapayuhan ang mga administrador na magsagawa ng proseso ng pagbawi.
Hakbang 1: Suriin ang Epekto ng Serbisyo
Tukuyin kung aling mga gumagamit, desktop at aplikasyon ang hindi magagamit.
Alamin kung ito ay isang buong kapaligiran o mga tiyak na workload na naapektuhan. Kumpirmahin na ang isyu ay may kaugnayan sa isang klasikong pagreretiro at hindi sa ibang problema na may kaugnayan sa pagpapatotoo, networking, o session host.
Hakbang 2: Panatilihin ang Inprastruktura at Datos
Suriin ang mga subscription ng Azure upang tukuyin ang mga kasalukuyang virtual machine, pinamamahalaang disk, mga account sa imbakan, at mga mapagkukunan ng networking.
Tiyakin ang mga dependency ng dokumento at mga backup umiiral bago gumawa ng anumang aksyon. Huwag tanggalin ang mga mapagkukunan hanggang ang data ng aplikasyon, mga profile ng gumagamit at impormasyon ng configuration ay natukoy.
Hakbang 3: Kumpirmahin ang Mga Opsyon sa Pagbawi sa Microsoft
Makipag-ugnayan sa suporta ng Microsoft upang matiyak na may mga suportadong pamamaraan ng migrasyon/pagbawi na magagamit pa.
Ang mga paunang awtomatikong/manwal na tagubilin sa migrasyon ay binuo na isinasaalang-alang ang petsa ng pagreretiro at samakatuwid ay hindi dapat ipagpalagay na naaangkop.
Sa kaso kung saan ang klasikong configuration ay hindi ma-migrate, maaaring kinakailangan na muling itayo ang kapaligiran gamit ang suportadong mga mapagkukunan ng Azure Virtual Desktop.
Hakbang 4: Ibalik ang Paghahatid ng Aplikasyon at Desktop
Pumili ng isang arkitektura na sumusuporta sa mga aplikasyon at desktop na kailangan ng mga gumagamit.
Para sa mga organisasyon na nagplano na manatili sa Azure Virtual Desktop, karaniwang kasama rito ang pag-set up ng mga host pool na naka-integrate sa ARM, mga suportadong session host, mga grupo ng aplikasyon, at mga pagtatalaga ng gumagamit.
Maaaring makita ng ilang mga organisasyon na ang isa pang pag-publish ng aplikasyon o mas angkop na solusyon sa desktop para sa kanilang mga pangangailangan.
Ang layunin ay muling maitaguyod ang access habang iniiwasan ang kumplikado at hindi kinakailangang labis ng nakaraang setup.
Ano ang Paraan upang Beripikahin ang Isang Azure Virtual Desktop Migration?
Ang pagpapanumbalik ng imprastruktura ay hindi ginagarantiyahan ang normal na operasyon ng gumagamit.
Kaya't ang isang migrasyon o muling pagtatayo ay dapat na ma-validate sa antas ng serbisyo at aplikasyon.
Suriin ang Pagpapatotoo at Pag-access ng Gumagamit
Kumpirmahin na ang mga gumagamit ay makakapag-authenticate at makaka-access sa mga mapagkukunan na naitalaga sa kanila.
Suriin ang Microsoft Entra, multifactor authentication, mga patakaran sa Conditional Access at mga itinalagang Azure RBAC kung naaangkop.
Dapat tiyakin ng mga administrador na ang mga pahintulot ay nakaayon sa prinsipyo ng pinakamababang pribilehiyo at na walang mga lumang pattern ng pag-access na hindi sinasadyang naipasa.
Subukan ang mga Aplikasyong Kritikal sa Negosyo
Subukan ang mga na-publish na aplikasyon at desktop sa pamamagitan ng paggamit ng mga natatanging kinatawan na mga account ng gumagamit.
Ang mga Aktibidad ng Pagpapatunay ay dapat kabilang ang paglulunsad ng aplikasyon, mga koneksyon sa database, mga network share, pag-print, redirection ng clipboard, at mga kinakailangang peripheral kung mayroon man.
Ang mga legacy na aplikasyon ay kailangang bigyang-pansin dahil maaari silang mangailangan ng tiyak na configuration ng OS, landas ng network, o bahagi ng aplikasyon.
Isang halimbawa ng isang legacy application ay maaaring isang ERP application na matagumpay na naglulunsad ngunit nabibigo na kumonekta sa kanyang database mula sa bagong session host.
Tiyakin ang mga Profile, Pagganap at Operasyon
Ang mga kumpanya na gumagamit ng FSLogix o alinman sa iba pang mga profiling tool ay dapat tiyakin na ang lahat ay tama ang pagkaka-attach, ay persistent, at maayos na ma-access.
Mahalagang subukan ito sa pamamagitan ng pag-sign in sa unang pagkakataon at suriin kung maayos ang lahat kapag nagbukas ang isang gumagamit ng aplikasyon at sa susunod na pag-sign in. Mahalaga ring tiyakin na ang mga proseso ay minomonitor, naka-backup, at naibabalik.
Ang migrasyon ay kumpleto lamang kapag ang lahat ay handa na, kabilang ang kakayahan ng mga gumagamit na ma-access ang kanilang mga aplikasyon. Dapat posible na mapanatili ang sistema nang maayos.
Dapat bang muling isaalang-alang ng mga Organisasyon ang Kanilang Arkitektura ng Paghahatid ng Desktop?
Ang pagreretiro ng Azure Virtual Desktop (classic) ay pangunahing isyu sa lifecycle ng platform, ngunit nag-aalok din ito ng pagkakataon na suriin kung ang kasalukuyang platform ng paghahatid ng desktop ay patuloy na sumusuporta sa iyong mga pangangailangan.
Ang paglipat sa modernong Azure Virtual Desktop ay ang halatang pagpipilian para sa marami, lalo na ang mga nasa Azure-first na at gumagamit ng mga desktop na naka-host sa Azure.
Iba pang mga organisasyon ay may mas kaunting kumplikadong mga kinakailangan.
Kailan Nagiging Makabuluhan ang Modern Azure Virtual Desktop?
Modern Azure Virtual Desktop maaaring maging angkop para sa mga organisasyon na nangangailangan ng sentral na pinamamahalaang Windows desktop at mga app, na naka-host sa Azure.
Pinapagana nito ang multisession, mga modelo ng RemoteApp, at mga tool ng Microsoft ID at administrasyon.
May katuturan ito para sa mga negosyo na may umiiral na Azure footprint, ngunit kailangan pa ring harapin ng mga departamento ng IT ang mga kumplikadong aspeto ng cloud, kabilang ang licensing, networking, storage, administrasyon, at mga operational na aspeto.
Kailan Ang Isa Pang Windows Application Publishing Architecture Ay Angkop?
Hindi lahat ng organisasyon ay nangangailangan ng ganap na naipatupad na desktop virtualization environment na naka-host sa Microsoft Azure.
Kailangan lamang ng ilang mga negosyo ng limitadong remote access sa mga tiyak na aplikasyon ng Windows, tulad ng mga pinansyal o ERP na aplikasyon o mga legacy na aplikasyon ng linya ng negosyo.
Maaaring isaalang-alang ng mga organisasyong ito ang pag-publish ng mga aplikasyon na naka-host sa sentral na pinamamahalaang mga Windows server sa halip na mag-deploy ng isang pangkalahatang virtual desktop infrastructure (VDI).
Ang Modern Azure Virtual Desktop ay hindi lamang tungkol sa virtualization ng desktop o mga aplikasyon, kundi pati na rin sa pag-publish ng aplikasyon.
Ngayon, posible nang ilathala ang mga Azure application gamit ang pamamaraang RemoteApp.
Ang katotohanan ay walang dichotomy sa larangan ng application delivery, kundi isang continuum na umaabot mula sa pag-publish ng application hanggang sa desktop virtualization.
Dapat nakatuon ang talakayan sa paghahanap ng pinaka-angkop na arkitektura ng paghahatid ng aplikasyon para sa ibinigay na organisasyon at mga kaso ng paggamit.
Halimbawa, kung mayroong isang matagal nang aplikasyon na naka-host sa isang folder ng Windows Server na ina-access ng isang set ng mga awtorisadong gumagamit, hindi na kailangang ilathala ito sa Azure Virtual Desktop kapag ang legacy infrastructure ay maayos pa ring gumagana.
Sa halip, maaaring maging kapaki-pakinabang para sa mga ganitong negosyo na iwanan ang kanilang lokasyon ng pagho-host ng aplikasyon sa premises habang ina-upgrade ang kanilang paraan ng pag-access sa aplikasyon.
Ano ang mga salik na dapat magturo sa desisyon?
Dapat suriin ng mga departamento ng IT ang pagpili batay sa mga pamantayan ng mga pangangailangan sa pag-deploy, sa halip na sa mga tampok ng tinanggal na sistema.
| Pagsasaalang-alang | Pangunahing tanong |
|---|---|
| Paghahatid | Dapat bang tumakbo ang mga workload sa Azure? |
| Karanasan ng gumagamit | Buong mga desktop o napiling mga aplikasyon? |
| Pagkakatugma | Gagana ba ang mga umiiral na aplikasyon ng Windows? |
| Seguridad | Paano pinoprotektahan ang pagkakakilanlan at pag-access sa sesyon? |
| Pamamahala | Sino ang namamahala sa imprastruktura? |
| Lisensya | Aling mga lisensya ng Microsoft at software ang naaangkop? |
| Kakayahang palakihin | Gaano karaming sabay-sabay na gumagamit ang kinakailangan? |
| Gastos | Ano ang kabuuang halaga ng pagmamay-ari? |
Ang layunin ay pumili ng isang arkitekturang pang-empresa na tutugon sa mga kinakailangan ng pagkakaroon, seguridad, at nabawasang kumplikadong administratibo.
Naghahanap ng Alternatibo para sa Windows Application at Desktop Delivery?
Ang paglipat sa modernong Azure Virtual Desktop ay hindi kinakailangang pinakamainam na opsyon para sa bawat organisasyon. Ang mga negosyo na pangunahing nangangailangan ng access sa umiiral na mga aplikasyon ng Windows o sentral na naka-host na mga desktop ay maaaring makinabang mula sa mas simpleng arkitektura, lalo na kung hindi nila kailangan ng ganap na Azure-hosted na virtual desktop na kapaligiran.
TSplus Remote Access nagbibigay-daan sa mga koponan ng IT na ilathala ang mga Windows application at buong remote desktop sa pamamagitan ng mga RDP-compatible na kliyente o isang HTML5 web portal. Sa suporta para sa mga on-premises at cloud-hosted na Windows server, nag-aalok ito ng praktikal na alternatibo para sa mga organisasyon na naghahanap na mapanatili ang kanilang umiiral na mga application habang pinadali ang paghahatid ng remote application.
Wakas
Ang pagreretiro ng Azure Virtual Desktop (classic) ay ginagawang mahalaga na tukuyin ang mga naapektuhang deployment, panatilihin ang mga umiiral na mapagkukunan at ibalik ang access sa pamamagitan ng suportadong imprastruktura. Dapat tiyakin ng mga IT team ang mga magagamit na opsyon sa pagbawi bago subukan ang migrasyon o muling pagtatayo.
Kung ang mga organisasyon ay magpapatuloy sa modernong Azure Virtual Desktop o tatanggap ng ibang arkitektura ng paghahatid, ang prayoridad ay nananatiling tiyakin ang ligtas, maaasahang pag-access sa aplikasyon nang walang hindi kinakailangang kumplikadong operasyon.
TSplus Libreng Pagsubok ng Remote Access
Pinakamahusay na alternatibo sa Citrix/RDS para sa pag-access ng desktop/app. Ligtas, cost-effective, on-premises/cloud