Azure Virtual Desktop Classic Ditamatkan: Langkah Seterusnya untuk IT

Pengenalan

Persaraan Azure Virtual Desktop (klasik) mencipta perbezaan penting antara kehilangan perkhidmatan sambungan warisan dan ketersediaan berterusan sumber Azure yang mendasari. Bagi pasukan IT yang terlepas tarikh akhir migrasi, memahami perbezaan ini adalah penting untuk merancang pemulihan tanpa menggantikan infrastruktur sedia ada secara tidak perlu. Artikel ini menerangkan apa yang dimaksudkan dengan persaraan bagi sumber sedia ada, bagaimana untuk mengenal pasti penyebaran klasik, pilihan migrasi mana yang masih berbaloi untuk dinilai, dan bagaimana untuk memilih seni bina penghantaran aplikasi yang disokong.

Apa Maksudnya Apabila Azure Virtual Desktop Classic Dihentikan?

Microsoft secara rasmi telah menghentikan Azure Virtual Desktop (klasik) pada 30 September 2026. Berdasarkan dokumentasi rasmi Microsoft, "sambungan ke perkhidmatan klasik akan disekat selepas penghentian." Oleh itu, penghentian ini memberi kesan kepada jenis perkhidmatan tertentu yang berkaitan dengan pengurusan desktop dan aplikasi maya menggunakan model penyebaran Azure Virtual Desktop (klasik).

Namun, proses persaraan tidak terpakai kepada Azure Virtual Desktop moden yang menggunakan Azure Resource Manager (ARM). Oleh itu, kebimbangan utama bagi pengguna yang masih menggunakan sumber klasik adalah ketidakmampuan untuk menjalin sambungan ke perkhidmatan yang sebelum ini berfungsi. Oleh itu, pengguna harus lebih peka terhadap pengurusan sumber klasik kerana sumber itu sendiri tidak akan hilang selepas tarikh persaraan.

Apa yang sebenarnya telah dihentikan?

Azure Virtual Desktop (classic), yang sebelumnya dikenali sebagai Windows Virtual Desktop, mempunyai infrastruktur pengurusannya berdasarkan cmdlet PowerShell khusus, API, dan objek perkhidmatan.

Tidak seperti Azure Virtual Desktop moden, kumpulan hos klasik dan kumpulan aplikasi tidak ditakrifkan sebagai sumber pengurus sumber Azure yang bersatu.

Hari ini, komponen ini disertakan dalam sistem pengurusan sumber Azure yang membolehkan pentadbir untuk menerapkan kawalan akses berasaskan peranan Azure (RBAC), menguruskan perkhidmatan melalui portal Azure, dan menggunakan corak infrastruktur-sebagai-kod moden untuk automasi penyebaran.

Keupayaan	AVD Classic (ditamatkan)	AVD Moden
Pengurusan	Pelan kawalan legasi	Pengurus Sumber Azure
Portal Azure	Integrasi terhad	Integrasi asli
Kawalan akses	Peranan penyewa legasi	Azure RBAC
Automasi	API Klasik dan PowerShell	ARM, API, Az PowerShell
Penghantaran desktop dan aplikasi	Sambungan disekat	Disokong
Status perkhidmatan	Pencen	Disokong

Persaraan mewakili perubahan dalam seni bina perkhidmatan yang mendasari, bukan sekadar penamaan semula produk.

Adakah Desktop Maya Azure Moden Masih Berfungsi?

Ya. Azure Virtual Desktop moden disokong dan terus menawarkan desktop Windows penuh, platform multisession, dan penghantaran aplikasi individu melalui RemoteApp.

Organisasi yang sudah menggunakan kumpulan hos yang terintegrasi dengan Azure Resource Manager (ARM) tidak terjejas oleh penamatan perkhidmatan klasik.

Pengurus IT juga harus mengambil perhatian tentang perbezaan antara akhir sokongan untuk Azure Virtual Desktop klasik dan akhir sokongan yang berasingan untuk klien Remote Desktop yang lebih lama. Klien Remote Desktop untuk Windows (MSI) dijadualkan untuk mencapai akhir sokongan untuk persekitaran awan awam pada 27 Mac 2026, dan untuk Azure Virtual Desktop (klasik) pada 28 September 2026.

Bagaimana Pasukan IT Boleh Mengenal Pasti Penyebaran Azure Virtual Desktop Classic?

Langkah pertama adalah untuk mengenal pasti jika ada beban kerja pengeluaran yang masih bergantung pada seni bina yang telah ditamatkan.

Ini adalah terutama kritikal untuk sistem yang telah dimasukkan ke dalam pengeluaran bertahun-tahun yang lalu dan mungkin telah diambil alih oleh pentadbir baru atau diabaikan dalam dokumentasi infrastruktur semasa.

Semak Integrasi Pengurus Sumber Azure

Anda harus mula dengan memeriksa sumber Azure Virtual Desktop di portal Azure. Penyebaran Azure Virtual Desktop moden mendedahkan kumpulan hos, kumpulan aplikasi, dan ruang kerja sebagai sumber Azure dalam langganan dan kumpulan sumber. Sebaliknya, penyebaran klasik digunakan untuk mendedahkan objek perkhidmatan yang diuruskan dengan cara yang berbeza.

Kehadiran elemen Azure Virtual Desktop berikut adalah petunjuk yang kuat bagi penyebaran klasik:

• Kumpulan hos yang menggunakan modul PowerShell Azure Virtual Desktop klasik
• Rujukan sejarah kepada penyewa perkhidmatan klasik atau API perkhidmatan klasik
• Kumpulan aplikasi yang tidak mempunyai sumber ARM yang sepadan
• Mesin maya hos sesi yang merujuk kepada dokumentasi lama

Pada masa yang sama, ketiadaan kumpulan hos di portal Azure tidak semestinya menunjukkan penyebaran klasik. Anda harus sentiasa menyemak langganan, penyewa Microsoft Entra, dan kawalan akses berasaskan peranan yang dimiliki pengguna sebelum anda menganalisis masalah tersebut dengan lebih lanjut.

Semak Alat Pengurusan Legasi dan Kebergantungan

Skrip penyebaran dan repositori automasi mungkin berfungsi sebagai sumber bukti tambahan.

Sebagai contoh, kehadiran skrip yang mengandungi rujukan Microsoft.RDInfra.RDPowerShell atau operasi pengurusan tahap penyewa klasik akan menunjukkan bahawa persekitaran telah dikonfigurasi dengan tumpukan pengurusan yang lebih lama.

Persekitaran moden akan memanfaatkan antara muka pengurusan yang terintegrasi dengan Azure Resource Manager dan modul Az PowerShell yang berkaitan.

Pentadbir juga harus menyenaraikan semua aplikasi, pengguna dan sumber infrastruktur yang berkaitan dengan kumpulan hos yang mungkin terjejas.

Ini termasuk memeriksa mesin maya hos sesi, penugasan aplikasi, lokasi penyimpanan profil, kebergantungan pengesahan, konfigurasi rangkaian, dan repositori sandaran. Dokumentasi pemindahan manual Microsoft mengandungi perbandingan terperinci antara model objek perkhidmatan klasik dan model sumber yang terintegrasi dengan Azure Resource Manager (ARM).

Apa yang Boleh Terjadi kepada Sumber Sedia Ada Anda Selepas Azure Virtual Desktop Classic Ditamatkan?

Perbezaan yang paling penting adalah antara perkhidmatan sambungan yang ditamatkan dan infrastruktur Azure yang mendasarinya.

Sementara sambungan desktop klasik disekat, mesin maya sedia ada, sumber penyimpanan dan data aplikasi boleh kekal di tempat.

Mesin Maya dan Penyimpanan Sedia Ada Mungkin Kekal Tersedia

Mesin maya Azure adalah sumber yang diuruskan secara sendiri, tanpa bergantung pada pelan kawalan perkhidmatan klasik yang telah ditamatkan. Oleh itu, mesin maya hos sesi, cakera yang diuruskan, dan sumber rangkaian yang telah dibuat dalam langganan mungkin masih wujud.

Namun, mereka tidak dapat digunakan untuk mengembalikan broker sambungan yang telah bersara. Tiada mesin maya yang dibuat dalam infrastruktur Azure yang baru tersedia untuk mengembalikan pengalaman desktop organisasi ke keadaan berfungsi.

Pentadbir harus memeriksa setiap sumber dengan teliti, dan jika ia boleh digunakan semula untuk konfigurasi yang disokong, mereka harus melaksanakan langkah-langkah berikut.

Adalah penting untuk memeriksa sama ada sistem pengendalian mesin maya disokong dan jika aplikasi serta konfigurasi keselamatan adalah serasi.

Akses Aplikasi dan Data Pengguna Memerlukan Semakan Berasingan

Pengguna yang telah menyambung melalui desktop klasik atau jenis sesi RemoteApp tidak lagi dapat melancarkan aplikasi mereka melalui perkhidmatan ini.

Hasil daripada menghentikan perkhidmatan boleh menyebabkan kehilangan akses kepada desktop, aplikasi yang diterbitkan, dan gangguan kepada proses perniagaan.

Walau bagaimanapun, pengunduran perkhidmatan tidak menjamin bahawa data berkaitan pengguna dipadamkan.

Dalam kebanyakan kes, ia mungkin data pengguna yang disimpan di Azure Files, cakera VM atau medium penyimpanan lain, tetapi pengekalan dan aksesibiliti maklumat ini akan bergantung kepada cara ia dikonfigurasikan, dilindungi dengan kebenaran, disandarkan, dan sebagainya…

Oleh itu, sebelum mematikan atau memindahkan sistem yang terlibat, jabatan IT perlu memastikan bahawa mereka telah menyimpan semua data yang diperlukan.

Bolehkah sebuah pasukan masih memindahkan Azure Virtual Desktop Classic selepas ia bersara?

Microsoft mendokumenkan dua laluan migrasi untuk beralih dari Azure Virtual Desktop (klasik) ke Azure Virtual Desktop yang baru berintegrasi ARM: migrasi automatik dan migrasi manual.

Kedua-dua pilihan itu dirancang untuk menjadi boleh dilaksanakan sehingga 30 September 2026.

Oleh kerana tarikh itu adalah pada masa lalu, pentadbir tidak seharusnya menganggap alat yang diterangkan dalam dokumentasi sebagai sedia untuk pengeluaran untuk semua senario.

Dokumentasi Microsoft tidak memberikan panduan mengenai tempoh peralihan.

Oleh itu, organisasi tidak seharusnya bergantung kepada sebarang alat dan proses peralihan pasca-persaraan.

Pilihan 1: Migrasi Automatik

Proses migrasi automatik Microsoft menggunakan alat berasaskan PowerShell untuk memindahkan konfigurasi perkhidmatan klasik yang layak ke sumber ARM.

Dokumentasi syarikat mengesyorkan agar pengguna mempunyai langganan Azure yang aktif dengan kebenaran yang diperlukan dan memenuhi keperluan persekitaran yang disenaraikan oleh modul migrasi.

Sebagai contoh, garis panduan Microsoft mencadangkan agar pengguna diberikan kebenaran Penyumbang untuk mencipta sumber Azure dan kebenaran Pentadbir Akses Pengguna untuk mengurus keanggotaan kumpulan aplikasi.

Namun, adalah penting untuk mengakui bahawa alat tersebut tidak dapat menjamin pemulihan data selepas persaraan.

Organisasi dengan penyebaran klasik yang aktif harus berunding dengan sokongan Microsoft untuk mengesahkan jika proses migrasi adalah pilihan yang tersedia untuk persekitaran mereka.

Pilihan 2: Migrasi Manual atau Pembinaan Semula

Migrasi manual memerlukan penciptaan sumber Azure Virtual Desktop moden dan penyusunan semula konfigurasi perkhidmatan.

Bergantung pada kes tertentu, pentadbir mungkin perlu:

• Cipta kumpulan hos berasaskan ARM, kumpulan aplikasi dan ruang kerja yang terintegrasi
• Menetapkan atau menggantikan mesin maya hos sesi
• Daftar hos sesi yang serasi dengan kolam hos baharu
• Cipta semula persatuan pengguna dan aplikasi
• Sesuaikan identiti, rangkaian, keselamatan, dan konfigurasi profil

Pendekatan manual menjadi perlu apabila konfigurasi lama mengandungi kerumitan yang tidak didokumentasikan, penyesuaian yang meluas, atau apabila alat migrasi moden terbukti tidak mencukupi.

Perlu diingat, membina semula infrastruktur penghantaran tidak selalu melibatkan penggantian lengkap aplikasi dan data.

Komponen yang tinggal sering kali boleh digunakan semula melalui penilaian kesesuaian yang sesuai, penilaian pelesenan, dan audit keselamatan.

Keputusan harus berdasarkan keadaan semasa sumber yang ada dan sokongan yang tersedia daripada Microsoft.

Situasi	Pendekatan untuk menilai
Konfigurasi klasik yang layak dan Microsoft mengesahkan sokongan migrasi	Migrasi automatik
Konfigurasi klasik yang kompleks atau sukar diakses	Rekonstruksi manual
VM dan data sedia ada kekal tersedia	Membina semula perkhidmatan penghantaran dan menilai penggunaan semula
Beban kerja legasi tidak lagi diperlukan	Penghapusan yang selamat
Desktop yang dihoskan di Azure tidak lagi diperlukan	Arsitektur penghantaran alternatif

Apa yang Perlu Dilakukan oleh Pasukan IT Jika Mereka Melewatkan Tarikh Akhir Persaraan?

Organisasi yang belum menyelesaikan migrasi mereka sebelum 30 September 2026, harus mengutamakan pemeliharaan sumber daya dan pemulihan akses aplikasi perniagaan.

Sebagai ganti mencuba pelbagai sambungan ke perkhidmatan yang telah ditamatkan, pentadbir dinasihatkan untuk melaksanakan proses pemulihan.

Langkah 1: Menilai Kesan Perkhidmatan

Kenal pasti pengguna, desktop dan aplikasi yang tidak tersedia.

Ketahui sama ada ia adalah keseluruhan persekitaran atau beban kerja tertentu yang terjejas. Sahkan bahawa isu tersebut berkaitan dengan persaraan klasik dan bukan masalah pengesahan, rangkaian, atau hos sesi yang lain.

Langkah 2: Memelihara Infrastruktur dan Data

Semak langganan Azure untuk mengenal pasti mesin maya semasa, cakera terurus, akaun penyimpanan, dan sumber rangkaian.

Kebergantungan dokumen dan pastikan salinan sandaran wujud sebelum mengambil sebarang tindakan. Jangan padam sumber sehingga data aplikasi, profil pengguna dan maklumat konfigurasi telah dikenalpasti.

Langkah 3: Sahkan Pilihan Pemulihan Dengan Microsoft

Hubungi sokongan Microsoft untuk memastikan bahawa masih terdapat prosedur pemindahan/pemulihan yang disokong yang tersedia.

Arahan migrasi automatik/manual awal dibangunkan dengan tarikh persaraan dalam fikiran dan oleh itu tidak seharusnya dianggap sebagai terpakai.

Dalam kes di mana konfigurasi klasik tidak dapat dipindahkan, mungkin perlu untuk membina semula persekitaran dengan sumber Azure Virtual Desktop yang disokong.

Langkah 4: Pulihkan Penghantaran Aplikasi dan Desktop

Pilih seni bina yang menyokong aplikasi dan desktop yang diperlukan oleh pengguna.

Bagi organisasi yang merancang untuk kekal di Azure Virtual Desktop, ini biasanya melibatkan penetapan kumpulan hos terintegrasi ARM, hos sesi yang disokong, kumpulan aplikasi, dan penugasan pengguna.

Beberapa organisasi mungkin mendapati bahawa yang lain penerbitan aplikasi atau penyelesaian desktop lebih sesuai dengan keperluan mereka.

Matlamatnya adalah untuk mengembalikan akses sambil mengelakkan kerumitan dan beban yang tidak perlu dari penyediaan sebelumnya.

Apakah Cara untuk Mengesahkan Pindahan Azure Virtual Desktop?

Memulihkan infrastruktur tidak menjamin operasi pengguna yang normal.

Migrasi atau pembinaan semula oleh itu mesti disahkan pada tahap perkhidmatan dan aplikasi.

Sahkan Pengesahan dan Akses Pengguna

Sahkan bahawa pengguna boleh mengesahkan dan mengakses sumber yang telah diberikan kepada mereka.

Semak Microsoft Entra, pengesahan pelbagai faktor, dasar Akses Bersyarat dan penugasan Azure RBAC yang berkaitan.

Pentadbir harus mengesahkan bahawa kebenaran selaras dengan prinsip hak minimum dan bahawa tiada corak akses warisan yang telah dibawa ke hadapan secara tidak sengaja.

Uji Aplikasi Kritikal Perniagaan

Uji aplikasi dan desktop yang diterbitkan dengan memanfaatkan akaun pengguna wakil yang berbeza.

Aktiviti pengesahan harus merangkumi pelancaran aplikasi, sambungan pangkalan data, perkongsian rangkaian, pencetakan, pengalihan papan klip, dan periferal yang diperlukan jika ada.

Aplikasi legasi perlu diambil kira dengan teliti kerana ia mungkin memerlukan konfigurasi OS tertentu, laluan rangkaian, atau komponen aplikasi.

Contoh aplikasi warisan mungkin adalah aplikasi ERP yang dilancarkan dengan jayanya tetapi gagal untuk menyambung ke pangdatanya dari hos sesi baru.

Sahkan Profil, Prestasi dan Operasi

Syarikat yang menggunakan FSLogix atau mana-mana alat pemprofilan lain harus memastikan bahawa semuanya dilampirkan dengan betul, bersifat kekal, dan boleh diakses dengan baik.

Adalah penting untuk mengujinya dengan mendaftar masuk buat pertama kali dan memeriksa jika semuanya akan berfungsi dengan baik apabila pengguna membuka aplikasi dan semasa pendaftaran masuk seterusnya. Ia juga penting untuk memastikan bahawa proses dipantau, disandarkan, dan dipulihkan.

Migrasi hanya lengkap apabila segala-galanya sudah siap, termasuk pengguna dapat mengakses aplikasi mereka. Ia mesti mungkin untuk mengekalkan sistem dengan betul.

Adakah Organisasi Perlu Mempertimbangkan Semula Seni Bina Penghantaran Desktop Mereka?

Persaraan Azure Virtual Desktop (klasik) terutamanya merupakan isu kitaran hayat platform, tetapi ia juga memberikan peluang untuk menilai sama ada platform penghantaran desktop semasa terus menyokong keperluan anda.

Peralihan ke Azure Virtual Desktop moden adalah pilihan yang jelas bagi ramai, terutamanya bagi mereka yang sudah mengutamakan Azure dan menggunakan desktop yang dihoskan di Azure.

Organisasi lain mempunyai keperluan yang kurang kompleks.

Bila Azure Virtual Desktop Moden Masuk Akal?

Desktop Maya Azure Moden mungkin sesuai untuk organisasi yang memerlukan desktop dan aplikasi Windows yang diurus secara pusat, dihoskan di Azure.

Ia membolehkan model multisession, RemoteApp, dan alat ID serta pentadbiran Microsoft.

Ia masuk akal untuk perusahaan yang mempunyai jejak Azure yang sedia ada, tetapi jabatan IT masih perlu menangani kerumitan awan, termasuk pelesenan, rangkaian, penyimpanan, pentadbiran, dan aspek operasi.

Bilakah Arsitektur Penerbitan Aplikasi Windows Lain Sesuai?

Tidak semua organisasi memerlukan persekitaran virtualisasi desktop yang sepenuhnya dilaksanakan yang dihoskan di Microsoft Azure.

Beberapa perusahaan hanya memerlukan yang terhad Akses jauh kepada aplikasi Windows tertentu, seperti aplikasi kewangan atau aplikasi ERP atau aplikasi perniagaan warisan.

Organisasi-organisasi ini boleh mempertimbangkan untuk menerbitkan aplikasi yang dihoskan di pelayan Windows yang diurus secara pusat daripada melaksanakan infrastruktur desktop maya (VDI) yang umum.

Azure Virtual Desktop moden bukan hanya tentang virtualisasi desktop atau aplikasi, tetapi juga tentang penerbitan aplikasi.

Hari ini, adalah mungkin untuk menerbitkan aplikasi Azure menggunakan kaedah RemoteApp.

Realitinya adalah bahawa tiada dikotomi dalam ruang penghantaran aplikasi, tetapi sebaliknya satu kesinambungan yang berjalan dari penerbitan aplikasi hingga kepada virtualisasi desktop.

Perbincangan harus memberi tumpuan kepada mencari seni bina penghantaran aplikasi yang paling relevan untuk organisasi dan kes penggunaan yang diberikan.

Sebagai contoh, jika terdapat aplikasi yang telah lama berkhidmat yang dihoskan dalam folder Windows Server yang diakses oleh sekumpulan pengguna yang diberi kuasa, organisasi tidak perlu menerbitkannya dalam Azure Virtual Desktop apabila infrastruktur lama masih berfungsi dengan baik.

Sebaliknya, mungkin bermanfaat bagi perusahaan-perusahaan tersebut untuk meninggalkan lokasi penghosan aplikasi mereka di premis sambil meningkatkan kaedah akses aplikasi mereka.

Apa Faktor yang Harus Membimbing Keputusan?

Jabatan IT harus menilai pilihan tersebut berdasarkan kriteria keperluan penyebaran, bukannya ciri-ciri sistem yang telah dihentikan.

Pertimbangan	Soalan utama
Penyewaan	Adakah beban kerja mesti dijalankan di Azure?
Pengalaman pengguna	Desktop penuh atau aplikasi terpilih?
Keserasian	Adakah aplikasi Windows sedia ada akan berfungsi?
Keselamatan	Bagaimana identiti dan akses sesi dilindungi?
Pengurusan	Siapa yang menyelenggarakan infrastruktur?
Pelesenan	Lisensi Microsoft dan perangkat lunak mana yang berlaku?
Keskalabilitan	Berapa banyak pengguna serentak yang diperlukan?
Kos	Apakah jumlah kos pemilikan?

Tujuannya adalah untuk memilih seni bina perusahaan yang akan memenuhi keperluan ketersediaan, keselamatan, dan pengurangan kompleksiti pentadbiran.

Mencari Alternatif untuk Penghantaran Aplikasi dan Desktop Windows?

Migrasi ke Azure Virtual Desktop moden tidak semestinya pilihan terbaik untuk setiap organisasi. Perniagaan yang terutama memerlukan akses kepada aplikasi Windows yang sedia ada atau desktop yang dihoskan secara pusat mungkin mendapat manfaat daripada seni bina yang lebih sederhana, terutamanya apabila mereka tidak memerlukan persekitaran desktop maya yang sepenuhnya dihoskan di Azure.

TSplus Remote Access membolehkan pasukan IT menerbitkan aplikasi Windows dan desktop jauh penuh melalui klien yang serasi dengan RDP atau portal web HTML5. Dengan sokongan untuk pelayan Windows yang dihoskan di premis dan awan, ia menawarkan alternatif praktikal bagi organisasi yang ingin mengekalkan aplikasi sedia ada mereka sambil memudahkan penghantaran aplikasi jauh.

Kesimpulan

Pemberhentian Azure Virtual Desktop (klasik) menjadikannya penting untuk mengenal pasti penyebaran yang terjejas, memelihara sumber sedia ada dan memulihkan akses melalui infrastruktur yang disokong. Pasukan IT harus mengesahkan pilihan pemulihan yang tersedia sebelum mencuba migrasi atau pembinaan semula.

Sama ada organisasi meneruskan dengan Azure Virtual Desktop moden atau mengadopsi seni bina penghantaran lain, keutamaan tetap memastikan akses aplikasi yang selamat dan boleh dipercayai tanpa kerumitan operasi yang tidak perlu.