Azure Virtual Desktop Classic Dihentikan: Langkah Selanjutnya untuk TI

Pengantar

Pensiunnya Azure Virtual Desktop (klasik) menciptakan perbedaan penting antara kehilangan layanan koneksi warisan dan ketersediaan sumber daya Azure yang mendasarinya. Bagi tim TI yang melewatkan tenggat waktu migrasi, memahami perbedaan ini sangat penting untuk merencanakan pemulihan tanpa mengganti infrastruktur yang ada secara tidak perlu. Artikel ini menjelaskan apa arti pensiun bagi sumber daya yang ada, bagaimana cara mengidentifikasi penyebaran klasik, opsi migrasi mana yang masih layak dievaluasi, dan bagaimana memilih arsitektur pengiriman aplikasi yang didukung.

Apa Artinya Ketika Azure Virtual Desktop Classic Dihentikan?

Microsoft secara resmi telah menghentikan Azure Virtual Desktop (klasik) pada 30 September 2026. Berdasarkan dokumentasi resmi Microsoft, "koneksi ke layanan klasik akan diblokir setelah penghentian." Oleh karena itu, penghentian ini berdampak pada jenis layanan tertentu yang terkait dengan pengelolaan desktop virtual dan aplikasi menggunakan model penyebaran Azure Virtual Desktop (klasik).

Namun, proses pensiun tidak berlaku untuk Azure Virtual Desktop modern yang menggunakan Azure Resource Manager (ARM). Oleh karena itu, perhatian utama bagi pengguna yang masih menggunakan sumber daya klasik adalah ketidakmampuan untuk membangun koneksi ke layanan yang sebelumnya berfungsi. Oleh karena itu, pengguna harus sangat memperhatikan manajemen sumber daya klasik karena sumber daya itu sendiri tidak akan menghilang setelah tanggal pensiun.

Apa yang Sebenarnya Dihentikan?

Azure Virtual Desktop (classic), sebelumnya dikenal sebagai Windows Virtual Desktop, memiliki infrastruktur manajemennya yang berbasis pada cmdlet PowerShell khusus, API, dan objek layanan.

Tidak seperti Azure Virtual Desktop modern, kumpulan host klasik dan grup aplikasi tidak didefinisikan sebagai sumber daya manajer sumber daya Azure yang terintegrasi.

Saat ini, komponen-komponen ini dimasukkan ke dalam sistem manajemen sumber daya Azure yang memungkinkan administrator untuk menerapkan kontrol akses berbasis peran Azure (RBAC), mengelola layanan melalui portal Azure, dan menggunakan pola infrastruktur-sebagai-kode modern untuk otomatisasi penyebaran.

Kemampuan	AVD Klasik (pensiun)	AVD Modern
Manajemen	Pesawat kontrol warisan	Azure Resource Manager
portal Azure	Integrasi terbatas	Integrasi asli
Kontrol akses	Peran penyewa warisan	Azure RBAC
Otomatisasi	API Klasik dan PowerShell	ARM, API, Az PowerShell
Pengiriman desktop dan aplikasi	Koneksi diblokir	Didukung
Status layanan	Pensiun	Didukung

Pensiun mewakili perubahan dalam arsitektur layanan yang mendasari, bukan sekadar penggantian nama produk.

Apakah Azure Virtual Desktop Modern Masih Berfungsi?

Ya. Azure Virtual Desktop modern didukung dan terus menawarkan desktop Windows penuh, platform multisession, dan pengiriman aplikasi individu melalui RemoteApp.

Organisasi yang sudah menggunakan host pool terintegrasi Azure Resource Manager (ARM) tidak terpengaruh oleh penghentian layanan klasik.

Manajer TI juga harus memperhatikan perbedaan antara akhir dukungan untuk Azure Virtual Desktop klasik dan akhir dukungan terpisah untuk klien Remote Desktop yang lebih lama. Klien Remote Desktop untuk Windows (MSI) dijadwalkan mencapai akhir dukungan untuk lingkungan cloud publik pada 27 Maret 2026, dan untuk Azure Virtual Desktop (klasik) pada 28 September 2026.

Bagaimana Tim IT Dapat Mengidentifikasi Penyebaran Azure Virtual Desktop Klasik?

Langkah pertama adalah mengidentifikasi apakah ada beban kerja produksi yang masih bergantung pada arsitektur yang sudah dihentikan.

Ini sangat penting untuk sistem yang telah diproduksi bertahun-tahun yang lalu dan mungkin telah diambil alih oleh administrator baru atau diabaikan dalam dokumentasi infrastruktur saat ini.

Periksa Integrasi Azure Resource Manager

Anda harus mulai dengan memeriksa sumber daya Azure Virtual Desktop di portal Azure. Penyebaran Azure Virtual Desktop modern mengekspos kumpulan host, grup aplikasi, dan ruang kerja sebagai sumber daya Azure dalam langganan dan grup sumber daya. Sebaliknya, penyebaran klasik digunakan untuk mengekspos objek layanan yang dikelola dengan cara yang berbeda.

Kehadiran elemen Azure Virtual Desktop berikut ini menjadi indikator kuat dari penerapan klasik:

• Kumpulan host yang menggunakan modul PowerShell Azure Virtual Desktop klasik
• Referensi sejarah untuk penyewa layanan klasik atau API layanan klasik
• Grup aplikasi yang tidak memiliki sumber daya ARM yang sesuai
• Mesin virtual host sesi yang merujuk pada dokumentasi yang lebih lama

Pada saat yang sama, tidak adanya kumpulan host di portal Azure tidak selalu menunjukkan penerapan klasik. Anda harus selalu memeriksa langganan mana, penyewa Microsoft Entra, dan kontrol akses berbasis peran yang dimiliki pengguna sebelum Anda menganalisis masalah lebih lanjut.

Tinjau Alat Manajemen Warisan dan Ketergantungan

Skrip penyebaran dan repositori otomatisasi dapat berfungsi sebagai sumber bukti tambahan.

Misalnya, keberadaan skrip yang mengandung referensi Microsoft.RDInfra.RDPowerShell atau operasi manajemen tingkat penyewa klasik akan menunjukkan bahwa lingkungan tersebut dikonfigurasi dengan tumpukan manajemen yang lebih lama.

Lingkungan modern akan memanfaatkan antarmuka manajemen yang terintegrasi dengan Azure Resource Manager dan modul Az PowerShell terkait.

Administrator juga harus menginventarisasi semua aplikasi, pengguna, dan sumber daya infrastruktur yang terkait dengan kumpulan host yang mungkin terpengaruh.

Ini mencakup pemeriksaan mesin virtual host sesi, penugasan aplikasi, lokasi penyimpanan profil, ketergantungan otentikasi, konfigurasi jaringan, dan repositori cadangan. Dokumentasi migrasi manual Microsoft mengandung perbandingan mendetail antara model objek layanan klasik dan model sumber daya terintegrasi Azure Resource Manager (ARM).

Apa yang Bisa Terjadi pada Sumber Daya Anda yang Ada Setelah Azure Virtual Desktop Classic Dihentikan?

Perbedaan yang paling penting adalah antara layanan koneksi yang dihentikan dan infrastruktur Azure yang mendasarinya.

Sementara koneksi desktop klasik diblokir, mesin virtual yang ada, sumber daya penyimpanan, dan data aplikasi dapat tetap ada.

Mesin Virtual dan Penyimpanan yang Ada Mungkin Tetap Tersedia

Azure virtual machines adalah sumber daya yang dikelola secara mandiri, tanpa bergantung pada kontrol layanan klasik yang telah dihentikan. Dengan demikian, mesin virtual host sesi, disk yang dikelola, dan sumber daya jaringan yang dibuat dalam langganan mungkin masih ada.

Namun, mereka tidak dapat digunakan untuk mengembalikan broker koneksi yang sudah pensiun. Tidak ada mesin virtual yang dibuat di infrastruktur Azure yang baru tersedia untuk mengembalikan pengalaman desktop organisasi ke keadaan kerja.

Administrator harus memeriksa setiap sumber daya dengan cermat, dan jika dapat digunakan kembali untuk konfigurasi yang didukung, mereka harus melakukan langkah-langkah berikut.

Sangat penting untuk memeriksa apakah sistem operasi dari mesin virtual didukung dan apakah aplikasi serta konfigurasi keamanan kompatibel.

Akses Aplikasi dan Data Pengguna Memerlukan Pemeriksaan Terpisah

Pengguna yang telah terhubung melalui desktop klasik atau jenis sesi RemoteApp tidak akan dapat meluncurkan aplikasi mereka melalui layanan ini.

Hasil dari penghentian layanan dapat berupa kehilangan akses ke desktop, aplikasi yang diterbitkan, dan gangguan pada proses bisnis.

Namun, penghentian layanan tidak menjamin bahwa data terkait pengguna dihapus.

Dalam banyak kasus, kemungkinan data pengguna yang disimpan di Azure Files, disk VM, atau media penyimpanan lainnya, tetapi retensi dan aksesibilitas informasi ini akan bergantung pada bagaimana itu dikonfigurasi, diamankan dengan izin, dicadangkan, dll...

Oleh karena itu, sebelum menonaktifkan atau memigrasi sistem yang terlibat, departemen TI perlu memastikan bahwa mereka telah menyimpan semua data yang diperlukan.

Apakah Tim Masih Dapat Memigrasi Azure Virtual Desktop Classic Setelah Itu Pensiun?

Microsoft mendokumentasikan dua jalur migrasi untuk beralih dari Azure Virtual Desktop (klasik) ke Azure Virtual Desktop yang terintegrasi ARM yang baru: migrasi otomatis dan migrasi manual.

Kedua opsi tersebut dimaksudkan untuk dapat digunakan hingga 30 September 2026.

Karena tanggal tersebut sudah berlalu, administrator sebaiknya tidak menganggap alat yang dijelaskan dalam dokumentasi sebagai siap produksi untuk semua skenario.

Dokumentasi Microsoft tidak memberikan panduan tentang periode transisi.

Oleh karena itu, organisasi tidak boleh mengandalkan alat dan proses transisi pasca-pensiun apa pun.

Opsi 1: Migrasi Otomatis

Proses migrasi otomatis Microsoft memanfaatkan alat berbasis PowerShell untuk memindahkan konfigurasi layanan klasik yang memenuhi syarat ke sumber daya ARM.

Dokumentasi perusahaan merekomendasikan agar pengguna memiliki langganan Azure yang aktif dengan izin yang diperlukan dan memenuhi persyaratan lingkungan yang tercantum oleh modul migrasi.

Misalnya, pedoman Microsoft menyarankan agar pengguna diberikan izin Kontributor untuk membuat sumber daya Azure dan izin Administrator Akses Pengguna untuk mengelola keanggotaan grup aplikasi.

Namun, penting untuk diakui bahwa alat tersebut tidak dapat menjamin pemulihan data setelah pensiun.

Organisasi dengan penyebaran klasik yang aktif harus berkonsultasi dengan dukungan Microsoft untuk mengonfirmasi apakah proses migrasi adalah opsi yang tersedia untuk lingkungan mereka.

Opsi 2: Migrasi Manual atau Rekonstruksi

Migrasi manual memerlukan pembuatan sumber daya Azure Virtual Desktop modern dan reconfigurasi konfigurasi layanan.

Bergantung pada kasus spesifik, administrator mungkin perlu:

• Buat kumpulan host berbasis ARM yang terintegrasi, grup aplikasi, dan ruang kerja
• Mendirikan atau mengganti mesin virtual host sesi
• Daftarkan host sesi yang kompatibel dengan kumpulan host baru
• Membuat ulang asosiasi pengguna dan aplikasi
• Sesuaikan identitas, jaringan, keamanan, dan konfigurasi profil

Pendekatan manual menjadi perlu ketika konfigurasi lama mengandung kompleksitas yang tidak terdokumentasi, kustomisasi yang luas, atau ketika alat migrasi modern terbukti tidak memadai.

Perlu dicatat bahwa membangun kembali infrastruktur pengiriman tidak selalu melibatkan penggantian lengkap aplikasi dan data.

Komponen yang tersisa sering kali dapat digunakan kembali melalui penilaian kompatibilitas yang tepat, evaluasi lisensi, dan audit keamanan.

Keputusan harus didasarkan pada keadaan saat ini dari sumber daya yang ada dan dukungan yang tersedia dari Microsoft.

Situasi	Pendekatan untuk mengevaluasi
Konfigurasi klasik yang memenuhi syarat dan Microsoft mengonfirmasi dukungan migrasi	Migrasi otomatis
Konfigurasi klasik yang kompleks atau tidak dapat diakses	Rekonstruksi manual
VM dan data yang ada tetap tersedia	Membangun kembali layanan pengiriman dan menilai penggunaan kembali
Beban kerja warisan tidak lagi diperlukan	Penghapusan yang aman
Desktop yang dihosting di Azure tidak lagi diperlukan	Arsitektur pengiriman alternatif

Apa yang Harus Dilakukan Tim IT Jika Mereka Melewatkan Tenggat Waktu Pensiun?

Organisasi yang belum menyelesaikan migrasi mereka pada 30 September 2026, harus memprioritaskan pelestarian sumber daya dan pemulihan akses aplikasi bisnis.

Alih-alih mencoba beberapa koneksi ke layanan yang dihentikan, administrator disarankan untuk melakukan proses pemulihan.

Langkah 1: Menilai Dampak Layanan

Identifikasi pengguna, desktop, dan aplikasi mana yang tidak tersedia.

Cari tahu apakah itu merupakan seluruh lingkungan atau beban kerja tertentu yang terpengaruh. Konfirmasi bahwa masalah tersebut terkait dengan pensiun klasik dan bukan masalah lain yang berkaitan dengan otentikasi, jaringan, atau host sesi.

Langkah 2: Melindungi Infrastruktur dan Data

Tinjau langganan Azure untuk mengidentifikasi mesin virtual saat ini, disk terkelola, akun penyimpanan, dan sumber daya jaringan

Ketergantungan dokumen dan pastikan cadangan ada sebelum mengambil tindakan apa pun. Jangan menghapus sumber daya sampai data aplikasi, profil pengguna, dan informasi konfigurasi telah diidentifikasi.

Langkah 3: Konfirmasi Opsi Pemulihan Dengan Microsoft

Hubungi dukungan Microsoft untuk memastikan bahwa masih ada prosedur migrasi/pemulihan yang didukung yang tersedia.

Instruksi migrasi otomatis/manual awal dikembangkan dengan mempertimbangkan tanggal pensiun dan oleh karena itu tidak boleh diasumsikan berlaku.

Dalam kasus di mana konfigurasi klasik tidak dapat dimigrasikan, mungkin perlu untuk membangun kembali lingkungan dengan sumber daya Azure Virtual Desktop yang didukung.

Langkah 4: Pulihkan Pengiriman Aplikasi dan Desktop

Pilih arsitektur yang mendukung aplikasi dan desktop yang dibutuhkan pengguna.

Untuk organisasi yang berencana untuk tetap di Azure Virtual Desktop, ini biasanya melibatkan pengaturan kumpulan host terintegrasi ARM, host sesi yang didukung, grup aplikasi, dan penugasan pengguna.

Beberapa organisasi mungkin menemukan bahwa yang lain publikasi aplikasi atau solusi desktop lebih sesuai dengan kebutuhan mereka.

Tujuannya adalah untuk mengembalikan akses sambil menghindari kompleksitas dan beban yang tidak perlu dari pengaturan sebelumnya.

Apa Cara untuk Memvalidasi Migrasi Azure Virtual Desktop?

Memulihkan infrastruktur tidak menjamin operasi pengguna yang normal.

Migrasi atau rekonstruksi harus divalidasi pada tingkat layanan dan aplikasi.

Verifikasi Autentikasi dan Akses Pengguna

Konfirmasi bahwa pengguna dapat mengautentikasi dan mengakses sumber daya yang telah ditugaskan kepada mereka.

Periksa Microsoft Entra, otentikasi multifaktor, kebijakan Akses Bersyarat, dan penugasan Azure RBAC sesuai kebutuhan.

Administrator harus memastikan bahwa izin sesuai dengan prinsip hak akses minimal dan bahwa tidak ada pola akses lama yang telah diteruskan secara tidak sengaja.

Uji Aplikasi Kritis Bisnis

Uji aplikasi dan desktop yang diterbitkan dengan memanfaatkan akun pengguna perwakilan yang berbeda.

Kegiatan validasi harus mencakup peluncuran aplikasi, koneksi basis data, berbagi jaringan, pencetakan, pengalihan clipboard, dan perangkat keras yang diperlukan jika ada.

Aplikasi warisan harus diperhatikan secara khusus karena mungkin memerlukan konfigurasi OS tertentu, jalur jaringan, atau komponen aplikasi.

Contoh aplikasi warisan mungkin adalah aplikasi ERP yang diluncurkan dengan sukses tetapi gagal terhubung ke basis datanya dari host sesi baru.

Validasi Profil, Kinerja, dan Operasi

Perusahaan yang menggunakan FSLogix atau alat profil lainnya harus memastikan bahwa semuanya terpasang dengan benar, bersifat persisten, dan dapat diakses dengan baik.

Sangat penting untuk mengujinya dengan masuk untuk pertama kali dan memeriksa apakah semuanya akan berjalan dengan baik ketika pengguna membuka aplikasi dan selama masuk berikutnya. Juga penting untuk memastikan bahwa proses dipantau, dicadangkan, dan dipulihkan.

Migrasi hanya selesai ketika semuanya siap, termasuk pengguna dapat mengakses aplikasi mereka. Sistem harus dapat dipelihara dengan baik.

Haruskah Organisasi Mempertimbangkan Kembali Arsitektur Pengiriman Desktop Mereka?

Pensiun Azure Virtual Desktop (klasik) terutama merupakan masalah siklus hidup platform, tetapi juga memberikan kesempatan untuk menilai apakah platform pengiriman desktop saat ini terus mendukung kebutuhan Anda.

Peralihan ke Azure Virtual Desktop modern adalah pilihan yang jelas bagi banyak orang, terutama bagi mereka yang sudah mengutamakan Azure dan memanfaatkan desktop yang dihosting di Azure.

Organisasi lain memiliki persyaratan yang kurang kompleks.

Kapan Azure Virtual Desktop Modern Masuk Akal?

Desktop Virtual Modern Azure mungkin cocok untuk organisasi yang memerlukan desktop dan aplikasi Windows yang dikelola secara terpusat, dihosting di Azure.

Ini memungkinkan multisession, model RemoteApp, serta alat ID dan administrasi Microsoft.

Ini masuk akal bagi perusahaan yang memiliki jejak Azure yang ada, tetapi departemen TI masih harus menghadapi kompleksitas cloud, termasuk lisensi, jaringan, penyimpanan, administrasi, dan aspek operasional.

Kapan Arsitektur Penerbitan Aplikasi Windows Lainnya Tepat?

Tidak semua organisasi memerlukan lingkungan virtualisasi desktop yang sepenuhnya diimplementasikan yang dihosting di Microsoft Azure.

Beberapa perusahaan hanya membutuhkan terbatas remote access ke aplikasi Windows tertentu, seperti aplikasi keuangan atau aplikasi ERP atau aplikasi bisnis lama.

Organisasi-organisasi ini dapat mempertimbangkan untuk menerbitkan aplikasi yang dihosting di server Windows yang dikelola secara terpusat alih-alih menerapkan infrastruktur desktop virtual (VDI) yang umum.

Modern Azure Virtual Desktop tidak hanya tentang virtualisasi desktop atau aplikasi, tetapi juga tentang penerbitan aplikasi.

Hari ini, dimungkinkan untuk menerbitkan aplikasi Azure menggunakan metode RemoteApp.

Realitasnya adalah bahwa tidak ada dikotomi dalam ruang pengiriman aplikasi, melainkan sebuah kontinum yang berjalan dari penerbitan aplikasi hingga virtualisasi desktop.

Diskusi harus fokus pada menemukan arsitektur pengiriman aplikasi yang paling relevan untuk organisasi dan kasus penggunaan yang diberikan.

Misalnya, jika ada aplikasi yang telah lama berjalan yang dihosting di folder Windows Server yang diakses oleh sekelompok pengguna yang berwenang, organisasi tidak perlu menerbitkannya di Azure Virtual Desktop ketika infrastruktur lama masih berfungsi dengan baik.

Sebagai gantinya, mungkin bermanfaat bagi perusahaan-perusahaan tersebut untuk mempertahankan lokasi hosting aplikasi mereka di tempat sambil meningkatkan metode akses aplikasi mereka.

Faktor Apa yang Harus Menjadi Panduan dalam Pengambilan Keputusan?

Departemen IT harus mengevaluasi pilihan tersebut berdasarkan kriteria kebutuhan penerapan, bukan pada fitur sistem yang dihentikan.

Pertimbangan	Pertanyaan kunci
Hosting	Apakah beban kerja harus dijalankan di Azure?
Pengalaman pengguna	Desktop penuh atau aplikasi yang dipilih?
Kompatibilitas	Apakah aplikasi Windows yang ada akan berfungsi?
Keamanan	Bagaimana identitas dan akses sesi dilindungi?
Manajemen	Siapa yang memelihara infrastruktur?
Lisensi	Lisensi Microsoft dan perangkat lunak mana yang berlaku?
Kemampuan Skalabilitas	Berapa banyak pengguna bersamaan yang diperlukan?
Biaya	Apa total biaya kepemilikan?

Tujuannya adalah untuk memilih arsitektur perusahaan yang akan memenuhi persyaratan ketersediaan, keamanan, dan pengurangan kompleksitas administratif.

Mencari Alternatif untuk Pengiriman Aplikasi dan Desktop Windows?

Migrasi ke Azure Virtual Desktop modern tidak selalu menjadi pilihan terbaik untuk setiap organisasi. Bisnis yang terutama membutuhkan akses ke aplikasi Windows yang ada atau desktop yang dihosting secara terpusat mungkin mendapatkan manfaat dari arsitektur yang lebih sederhana, terutama ketika mereka tidak memerlukan lingkungan desktop virtual yang sepenuhnya dihosting di Azure.

TSplus Remote Access memungkinkan tim TI untuk menerbitkan aplikasi Windows dan desktop jarak jauh penuh melalui klien yang kompatibel dengan RDP atau portal web HTML5. Dengan dukungan untuk server Windows yang dihosting di tempat dan di cloud, ini menawarkan alternatif praktis bagi organisasi yang ingin mempertahankan aplikasi yang ada sambil menyederhanakan pengiriman aplikasi jarak jauh.

Kesimpulan

Pensiun Azure Virtual Desktop (klasik) membuat penting untuk mengidentifikasi penyebaran yang terpengaruh, mempertahankan sumber daya yang ada, dan memulihkan akses melalui infrastruktur yang didukung. Tim TI harus memverifikasi opsi pemulihan yang tersedia sebelum mencoba migrasi atau rekonstruksi.

Apakah organisasi melanjutkan dengan Azure Virtual Desktop modern atau mengadopsi arsitektur pengiriman lain, prioritasnya tetap memastikan akses aplikasi yang aman dan andal tanpa kompleksitas operasional yang tidak perlu.