Dari Group Policy ke Intune — panduan migrasi manajemen perangkat untuk usaha kecil dan menengah

“Jendela dukungan server habis, jadi kami merencanakan penggantian. Tetapi kami kehilangan keyakinan bahwa kami harus membeli server AD lagi dan menjalankan domain serta Group Policy untuk satu siklus lagi (lima tahun).” “Group Policy yang kami putuskan di kantor tidak pernah diterapkan pada laptop yang dipakai untuk kerja jarak jauh. Jika ia hanya diterapkan ketika mereka tersambung ke VPN, dapatkah kami benar-benar berkata kami mengelolanya?” — Beberapa tahun terakhir, konsultasi semacam ini dari pelanggan usaha kecil dan menengah terus meningkat.

Latar belakangnya adalah perubahan cara orang bekerja. Active Directory (AD) on-premises dan Group Policy (GPO) adalah mekanisme yang mengasumsikan “PC ada di LAN perusahaan dan selalu dapat menjangkau domain controller”. Kini PC yang dibawa pulang dan kerja jarak jauh menjadi norma, asumsi itulah yang pecah. Di atas itu, WSUS — lama menjadi default untuk manajemen pembaruan — dihentikan pengembangannya pada September 2024,¹ dan pusat gravitasi manajemen perangkat Microsoft telah pindah ke Entra ID plus Intune (MDM).

flowchart TB
        accTitle: Asumsi yang pecah dan pergeseran pusat gravitasi
        accDescr: AD dan GPO mengasumsikan PC ada di LAN perusahaan dan selalu dapat menjangkau domain controller, tetapi PC yang dibawa pulang dan kerja jarak jauh sebagai norma telah memecah asumsi itu, dan dengan WSUS dihentikan pusat gravitasi manajemen telah pindah ke Entra ID dan Intune
        adgpo["AD on-prem dan GPO"] -.-> premise["Asumsi: DC selalu dapat dijangkau"]
        work["PC dibawa pulang dan kerja jarak jauh sebagai norma"] --> broken["Asumsinya yang pecah"]
        premise --> broken
        wsus["WSUS dihentikan"] --> shift["Pusat gravitasi pindah ke Entra ID+Intune"]
        broken --> shift

Gambar 1: Asumsi AD+GPO bahwa “PC ada di LAN perusahaan” pecah seiring cara bekerja berubah, dan pusat gravitasi manajemen pindah ke Entra ID+Intune.

Meski begitu, migrasi bukan semua-atau-tidak-sama-sekali. PC yang dikelola dengan Entra join plus Intune dan PC yang AD domain-joined plus GPO dapat hidup berdampingan di perusahaan yang sama,² dan migrasi bertahap dimungkinkan: biarkan AD tetap ada untuk file server, dan alihkan PC baru ke pengelolaan Intune. Ditujukan kepada staf IT dan pemilik usaha di usaha kecil dan menengah, artikel ini menata — berpijak pada sumber primer seperti Microsoft Learn per Agustus 2026 — perbedaan cara GPO dan MDM bekerja, konfigurasi prasyarat, lisensi, cara menginventarisasi GPO saat ini, skenario migrasi bertahap, dan jebakannya.

1. Kesimpulan lebih dulu

• GPO diterapkan ketika PC tersambung ke jaringan domain; Intune (MDM) menyinkronkan lewat internet. Masalah “pengaturan tidak pernah sampai ke PC rumah” secara struktural tidak muncul dengan MDM. Sinkron keadaan tunak kira-kira setiap 8 jam, dan sinkron yang dipicu notifikasi juga berjalan ketika kebijakan berubah.³
• Migrasi bukan semua-atau-tidak-sama-sekali; migrasi bertahap yang mengasumsikan koeksistensi adalah jawaban realistis. Microsoft sendiri merekomendasikan Entra-join PC baru, dan membiarkan PC domain-joined yang ada sebagai hybrid join serta menggantinya pada siklus penyegaran perangkat keras.²
• Anda dapat berlangganan Intune secara mandiri, tetapi untuk usaha kecil dan menengah jalur realistis adalah memakai Intune Plan 1 yang termasuk di Microsoft 365 Business Premium (per Agustus 2026). Komposisi paket terus berubah, jadi selalu konfirmasi sumber primer sebelum menandatangani.⁴⁵
• Untuk menginventarisasi GPO saat ini, pakai Group Policy analytics bawaan Intune. Impor ekspor XML GPO dan setiap pengaturan diklasifikasikan menurut apakah ia dapat bermigrasi; pengaturan yang punya padanan dapat dikonversi menjadi kebijakan Settings catalog.⁶
• Pekerjaan utama era GPO hampir semuanya punya padanan Intune. Administrative Templates memetakan ke Settings catalog,⁷ WSUS ke Windows Update for Business, kunci pemulihan BitLocker ke penyimpanan di Entra ID,⁸ kata sandi administrator lokal ke Windows LAPS,⁹ dan penyebaran aplikasi ke aplikasi Win32 (.intunewin)¹⁰ dan aplikasi Microsoft Store (berbasis winget).¹¹
• Hal klasik yang tidak pindah apa adanya adalah skrip logon, pemetaan drive, dan penyebaran printer. Anda menggantinya dengan penyebaran skrip PowerShell,¹² Remediations (dulu Proactive remediations),¹³ mengubah pekerjaan menjadi aplikasi, atau “menghentikan praktik itu”.
• Jangan sebar pengaturan yang sama dari GPO dan MDM. Secara default GPO menang pada konflik. Menyetel MDMWinsOverGP ke 1 membuat MDM menang, tetapi hanya berlaku untuk pengaturan Policy CSP.¹⁴
• Mesin domain-joined dan mesin Entra-joined dapat hidup berdampingan, dan mesin Entra-joined dapat mengakses file server on-premises. Penonaktifan AD segera bukan syarat migrasi.²

Dalam satu kalimat: pertanyaan “haruskah kita mengganti server AD untuk satu siklus lagi” harus dirumuskan ulang sebagai “untuk lima tahun ke depan, apa yang akan kita pakai untuk mengelola PC yang duduk di luar kantor” dan diputuskan atas dasar itu.

flowchart LR
        accTitle: Merumuskan ulang pertanyaan yang harus Anda putuskan
        accDescr: Pertanyaan apakah mengganti server AD untuk satu siklus lagi harus dirumuskan ulang sebagai pertanyaan apa yang akan Anda pakai untuk mengelola PC di luar kantor selama lima tahun ke depan
        q1["Ganti server AD untuk satu siklus lagi?"] -->|Rumuskan ulang| q2["Untuk 5 tahun ke depan, apa yang mengelola PC di luar kantor?"]

Gambar 2: Rumuskan ulang pertanyaan penggantian server sebagai “untuk lima tahun ke depan, apa yang akan kita pakai untuk mengelola PC yang duduk di luar kantor” dan putuskan atas dasar itu.

2. Bagaimana GPO dan MDM berbeda — membandingkan mekanisme penerapan

Pertama, bandingkan keduanya di lapangan yang sama. Mekanisme GPO itu sendiri (urutan penerapan LSDOU, cara mengonfirmasi dengan gpupdate/gpresult) dibahas mendalam di “Panduan praktis Group Policy (GPO)”, jadi di sini kita mempersempit ke perbedaan yang penting untuk keputusan migrasi.

Baris paling penting untuk keputusan migrasi adalah yang pertama dan yang ketiga. GPO tidak sampai ke PC rumah bukan bug — itu karena asumsi desain “PC duduk di tempat ia dapat menjangkau domain controller” tidak lagi cocok dengan cara orang bekerja hari ini. Anda dapat menjaga GPO tetap hidup dengan memaksa always-on VPN pada setiap karyawan, tetapi itu juga pilihan untuk menanggung pemeliharaan potongan infrastruktur terpisah: platform VPN.

flowchart TB
        accTitle: Pilihan antara menjaga GPO tetap hidup dan migrasi ke MDM
        accDescr: GPO tidak sampai ke PC rumah karena asumsi desain tidak lagi cocok dengan cara orang bekerja hari ini, dan jalur memaksa always-on VPN untuk menjaga GPO tetap hidup adalah pilihan untuk menanggung pemeliharaan potongan infrastruktur terpisah, platform VPN
        gap["Asumsi desain tidak lagi cocok dengan cara orang bekerja"] --> sel{"Bagaimana Anda merespons?"}
        sel -->|Jaga tetap hidup dengan always-on VPN| vpn["Lanjutkan GPO"]
        sel -->|Migrasi ke MDM| mdm["Kelola lewat internet"]
        vpn --> cost["Anda menanggung pemeliharaan infrastruktur lain"]

Gambar 3: Jalur menjaga GPO tetap hidup dengan always-on VPN juga adalah pilihan untuk menanggung pemeliharaan potongan infrastruktur terpisah: platform VPN.

Di sisi lain, interval sinkron MDM (sekitar 8 jam) lebih kasar daripada penyegaran berkala GPO (sekitar 90 menit), dan rasa “sebar dan ia diterapkan segera” tidak ikut. Ketika Anda menugaskan atau mengubah kebijakan, notifikasi dikirim ke perangkat dan ia menyinkronkan relatif segera,³ tetapi kontrol yang mensyaratkan kesegeraan (blok darurat, dan sejenisnya) perlu dirancang di sekitar interval sinkron.

flowchart TB
        accTitle: Bagaimana GPO dan MDM menerapkan kebijakan
        accDescr: GPO hanya diterapkan ketika PC dapat tersambung ke domain controller internal, jadi PC rumah bergantung pada VPN; Intune menyinkronkan lewat internet kira-kira setiap 8 jam dan juga menyinkronkan pada notifikasi ketika kebijakan berubah, jadi ia menjangkau PC di mana pun ia berada
        officepc["PC internal"] --> dc["Domain controller"]
        officepc -.-> when["Startup dan masuk"]
        when -.-> when2["plus penyegaran berkala"]
        homepc["PC rumah"] --> vpn{"Jangkau DC lewat VPN?"}
        vpn -->|Ya| dc
        vpn -->|Tidak| miss["Kebijakan tidak pernah sampai"]
        anypc["PC di mana pun ia berada"] --> intune["Layanan Intune"]
        anypc -.-> every["Sinkron sekitar setiap 8 jam"]
        intune -.-> notify["Perubahan yang dipicu notifikasi"]
        dc ~~~ homepc
        miss ~~~ anypc

Gambar 4: GPO hanya diterapkan ketika PC dapat menjangkau domain controller; Intune menyinkronkan lewat internet terlepas dari lokasi.

3. Menata prasyarat — tiga bentuk: Domain Join, Hybrid Join, dan Entra Join

Ada tiga bentuk “cara PC Windows bergabung ke perusahaan”, dan yang Anda pilih menentukan alat pengelolaan mana yang dapat Anda pakai.²

Hybrid join adalah bentuk untuk “memberi PC domain-joined yang ada sebuah identitas cloud”, dan memungkinkan Anda mulai memakai Intune dan Conditional Access sambil menjaga aset yang ada. Microsoft, walaupun, merekomendasikan untuk tidak menjadikan hybrid join sebagai tujuan akhir, dan Entra-join PC baru serta pengganti.²

Ada satu kendala yang harus dipahami di sini. Tidak ada cara yang didukung Microsoft untuk mengonversi PC domain-joined yang ada (termasuk hybrid join) menjadi Entra join; reset Windows (wipe) diperlukan. Itulah mengapa Microsoft juga merekomendasikan pindah ke Entra join pada saat penyegaran perangkat keras atau instal ulang OS.²

flowchart TB
        accTitle: Tiga bentuk join dan jalur migrasi
        accDescr: PC hanya-AD-domain-join dapat didaftarkan di Entra ID juga dan menjadi hybrid join, tetapi tidak ada cara untuk mengonversinya langsung ke Entra join dan wipe diperlukan, jadi Entra-join PC baru dan pengganti direkomendasikan
        adonly["Hanya AD domain join（GPO）"] -->|Daftarkan juga di Entra ID| hybrid["hybrid join（GPO dan Intune）"]
        hybrid -.->|Tidak ada jalur konversi langsung| wipe["Wipe（reset） diperlukan"]
        wipe --> entra["Entra join（Intune）"]
        newpc["PC baru dan pengganti"] -->|Direkomendasikan| entra

Gambar 5: Tidak ada cara yang didukung untuk mengonversi mesin domain-joined yang ada menjadi Entra join; pola yang mapan adalah beralih dari PC baru dan pengganti.

Dari hal di atas, tujuan realistis untuk usaha kecil atau menengah dapat dinyatakan sebagai berikut.

1. Kelola PC baru dan pengganti dengan Entra join plus Intune
2. Biarkan PC domain-joined yang ada dan biarkan mereka diganti secara alami pada siklus penyegaran perangkat keras
3. Biarkan AD tetap ada untuk sementara bagi peran tersisa seperti autentikasi file server, dan kosongkan isi GPO secara bertahap

flowchart TB
        accTitle: Konfigurasi koeksistensi selama migrasi bertahap
        accDescr: Mesin Entra-joined dan mesin domain-joined dapat hidup berdampingan di lingkungan perusahaan yang sama; yang pertama dikelola dengan Intune dan yang kedua dengan GPO, sementara AD dibiarkan tetap ada untuk peran tersisa dan hanya isi GPO yang dikosongkan secara bertahap
        env["Lingkungan perusahaan yang sama"] --> ejoin["Mesin Entra-joined"]
        env --> djoin["Mesin domain-joined"]
        ejoin --> intune["Dikelola dengan Intune"]
        djoin --> gpo["Dikelola dengan GPO"]
        gpo -.-> shrink["Kosongkan isinya secara bertahap"]
        env -.-> ad["Biarkan AD untuk peran tersisa"]

Gambar 6: Mesin Entra-joined dan mesin domain-joined dapat hidup berdampingan di lingkungan perusahaan yang sama, dan AD dibiarkan tetap ada untuk sementara bagi peran tersisa.

Mesin Entra-joined dan mesin domain-joined dapat hidup berdampingan di lingkungan yang sama, dan mesin Entra-joined dapat mengakses aset internal seperti file server on-premises.² Single sign-on itu, walaupun, punya dua prasyarat. (1) Pengguna adalah identitas hybrid yang disinkronkan dari AD on-prem dengan Entra Connect (atau Cloud Sync) (pengguna yang hanya ada di cloud tidak dapat memperoleh kredensial Kerberos/NTLM AD), dan (2) PC punya jangkauan jaringan ke domain controller (dari luar kantor, VPN atau sejenisnya diperlukan).¹⁵ Dalam rencana migrasi, konfirmasi dulu bahwa tidak ada pengguna atau skenario pemakaian yang gagal pada dua poin ini.

flowchart TB
        accTitle: Prasyarat SSO dari mesin Entra-joined ke aset on-premises
        accDescr: Untuk mengakses file server on-premises dari mesin Entra-joined, dua prasyarat harus dipenuhi: identitas hybrid yang disinkronkan dengan Entra Connect atau sejenisnya, dan jangkauan ke domain controller
        pc["Mesin Entra-joined"] --> cond1{"Identitas hybrid?"}
        cond1 -->|Ya| cond2{"Dapatkah ia menjangkau DC?"}
        cond1 -->|Tidak| ng1["Tidak dapat memperoleh kredensial AD"]
        cond2 -->|Ya| ok["SSO ke file server"]
        cond2 -->|Tidak| ng2["Dari luar kantor, VPN atau sejenisnya diperlukan"]

Gambar 7: SSO dari mesin Entra-joined ke aset on-premises punya dua prasyarat: identitas hybrid dan jangkauan ke domain controller.

4. Lisensi dan biaya — paket mana yang mencakup Intune (per Agustus 2026)

Lisensi Intune dasar adalah Microsoft Intune Plan 1, ditawarkan baik sebagai langganan mandiri maupun dibundel ke berbagai paket Microsoft 365.⁴

Yang penting untuk usaha kecil dan menengah adalah bahwa Microsoft 365 Business Premium, untuk hingga 300 pengguna, mencakup Intune Plan 1.⁵ Business Premium juga mencakup Microsoft Entra ID P1 dan Microsoft Defender for Business, jadi konfigurasi kebijakan kepatuhan plus Conditional Access yang dijelaskan kemudian dapat diselesaikan di dalam paket ini. Business Standard/Basic, di sisi lain, tidak mencakup Intune. Ketika Anda melangkah dari kontrak hanya-surel-dan-Office ke manajemen perangkat, biaya peningkatan ke Business Premium adalah biaya efektif memperkenalkan Intune.

flowchart TB
        accTitle: Bagaimana paket UKM berhubungan dengan Intune
        accDescr: Business Premium untuk hingga 300 pengguna mencakup Intune Plan 1, Entra ID P1, dan Defender for Business serta menyelesaikan sampai Conditional Access, tetapi Business Standard/Basic tidak mencakup Intune
        bp["Business Premium"] -.-> cap["Hingga 300 pengguna"]
        bp --> intune["Intune Plan 1"]
        bp --> p1["Entra ID P1"]
        bp --> dfb["Defender for Business"]
        p1 --> ca["Menyelesaikan sampai Conditional Access"]
        dfb ~~~ std["Business Standard/Basic"]
        std --> noint["Tidak mencakup Intune"]

Gambar 8: Business Premium mencakup Intune Plan 1 dan Entra ID P1; Business Standard/Basic tidak mencakup Intune.

Ada dua catatan.

• Komposisi paket sering berubah. Bahkan sampai 2026, perubahan yang memindahkan fitur Intune Suite ke paket Microsoft 365 yang lebih tinggi (E3/E5 dan sejenisnya) telah berlangsung, dan tinjauan apa yang dibundel berlanjut.⁴ Perlakukan bagian ini per Agustus 2026, dan sebelum menandatangani selalu konfirmasi informasi terbaru di halaman lisensi dan harga Microsoft.
• Beberapa fitur yang dapat Anda buka dari UI Intune mensyaratkan lisensi terpisah. Contoh representatif adalah Remediations, yang dijelaskan kemudian: ia mensyaratkan lisensi kelas Windows Enterprise E3/E5 (dibundel di Microsoft 365 E3/E5 dan sejenisnya) dan tidak tersedia dalam cakupan Business Premium.¹³

Perbandingan biaya bukan “biaya langganan Intune” versus “nol”. Di sisi GPO Anda sudah membayar penggantian perangkat keras server AD, lisensi Windows Server dan CAL, biaya pembangunan, lima tahun pemeliharaan, cadangan, dan respons insiden. Perbandingan yang benar adalah meletakkan kutipan penggantian server di samping lima tahun Business Premium, lalu memasukkan perbedaan kemampuan “apakah pengelolaan menjangkau PC di luar kantor”.

flowchart TB
        accTitle: Cara yang benar memikirkan perbandingan biaya
        accDescr: Sisi GPO juga menanggung biaya seperti penggantian server AD, lisensi, dan lima tahun pemeliharaan, jadi letakkan kutipan penggantian server di samping lima tahun Business Premium lalu putuskan dengan perbedaan kemampuan apakah pengelolaan menjangkau PC di luar kantor dimasukkan
        gpocost["Biaya melanjutkan GPO"] --> hw["Penggantian server, lisensi, CAL"]
        gpocost --> ops["Pembangunan, pemeliharaan, cadangan"]
        bpcost["Biaya migrasi ke Intune"] --> sub["Lima tahun Business Premium"]
        hw --> diff["Letakkan perbedaan lima tahun berdampingan"]
        ops --> diff
        sub --> diff
        diff --> ability["Masukkan apakah pengelolaan menjangkau PC di luar kantor"]

Gambar 9: Letakkan kutipan penggantian server di samping lima tahun Business Premium, dan putuskan dengan perbedaan kemampuan mengelola PC di luar kantor dimasukkan.

5. Cara melakukan di Intune apa yang dulu Anda lakukan dengan GPO

Untuk setiap pekerjaan utama operasi GPO, padanan Intune ditampilkan dalam tabel pemetaan.

Beberapa catatan.

• Settings catalog adalah layar yang berkorespondensi dengan “edisi cloud editor GPO”, dan Microsoft sendiri memosisikannya sebagai “tujuan migrasi alami ketika Anda ingin mengonfigurasi dengan cara yang sama terperincinya seperti GPO on-premises”. Ia mencakup kebijakan yang didukung ADMX (edisi MDM dari pengaturan yang didefinisikan di ADMX), dan ada juga fitur (pratinjau) untuk mengimpor ADMX pihak ketiga.⁷
• Kebijakan kepatuhan plus Conditional Access adalah gagasan yang tidak dimiliki GPO. Anda mendefinisikan syarat kepatuhan seperti “BitLocker aktif, OS mutakhir, Defender berjalan” dan dapat memblokir akses Microsoft 365 dari perangkat yang tidak memenuhinya. Conditional Access adalah fitur Entra ID P1 dan termasuk di Business Premium.¹⁶
• Remediations telah diganti namanya dari Proactive remediations. Ia adalah mekanisme yang secara berkala menjalankan pasangan detect-script plus remediate-script, dan dapat menggantikan jenis operasi GPO yang “memperbaiki sesuatu di setiap logon”, tetapi sebagaimana dicatat ia mensyaratkan lisensi kelas Windows Enterprise E3/E5.¹³ Dalam cakupan Business Premium, pengganti realistis adalah menggabungkan platform scripts (dijalankan ketika skrip atau penugasan berubah, dan dicoba ulang saat gagal)¹² dengan aturan deteksi aplikasi Win32.
• Pilihan terperinci untuk manajemen pembaruan (memutuskan di antara WUfB, Autopatch, dan melanjutkan WSUS) dibahas di “Manajemen Windows Update setelah penghentian WSUS”, dan desain BitLocker serta LAPS di “Panduan praktis BitLocker” dan “Panduan praktis Windows LAPS” masing-masing.

flowchart TB
        accTitle: Alur kebijakan kepatuhan dan Conditional Access
        accDescr: Kebijakan kepatuhan hanya menilai keadaan kepatuhan perangkat terhadap syarat kepatuhan; hanya ketika kebijakan Conditional Access mensyaratkan perangkat yang patuh perangkat yang patuh diizinkan dan yang tidak patuh diblokir
        policy["Definisikan syarat kepatuhan"] -.-> cond["BitLocker aktif, OS mutakhir, dan sejenisnya"]
        policy --> state["Nilai keadaan kepatuhan perangkat"]
        state --> ca["Conditional Access mensyaratkan kepatuhan"]
        ca -->|Patuh| allow["Akses Microsoft 365 diizinkan"]
        ca -->|Tidak patuh| block["Akses diblokir"]

Gambar 10: Menilai keadaan kepatuhan adalah pekerjaan kebijakan kepatuhan; memblokir adalah pekerjaan Conditional Access. Hanya dalam kombinasi blok itu berlaku.

6. Menginventarisasi GPO saat ini — menata dengan Group Policy Analytics

Pekerjaan nyata pertama rencana migrasi adalah menginventarisasi GPO saat ini. Intune punya fitur khusus, Group Policy analytics, yang dapat mengklasifikasikan, per pengaturan, “dapatkah MDM mengganti ini” tanpa Anda harus membaca GPO secara manual.⁶

Langkahnya sebagai berikut.⁶

1. Buka Group Policy Management Console (GPMC.msc) di domain controller atau sejenisnya, klik kanan GPO sasaran → Save Report dan ekspor sebagai berkas XML (4 MB atau kurang per berkas)
2. Di pusat admin Intune, pergi ke Devices → Group Policy analytics dan impor XML (pilihan ganda diizinkan)
3. Setelah analisis otomatis, setiap GPO menampilkan persentase dukungan MDM (bagian pengaturan yang punya padanan di Intune)
4. Di laporan Group policy migration readiness, konfirmasi klasifikasi per pengaturan: Ready for migration / Not supported / Deprecated
5. Pengaturan Ready for migration dapat dikonversi apa adanya menjadi kebijakan Settings catalog dan disebar

flowchart TB
        accTitle: Alur inventarisasi dengan Group Policy analytics
        accDescr: Ekspor GPO sebagai XML dari GPMC dan impor ke Intune; persentase dukungan MDM dan kesiapan migrasi per pengaturan ditampilkan, dan pengaturan Ready for migration dapat dikonversi menjadi kebijakan Settings catalog
        export["Ekspor GPO sebagai XML dari GPMC"] --> import["Impor ke Intune"]
        import --> rate["Persentase dukungan MDM ditampilkan"]
        rate --> report["Laporan kesiapan migrasi"]
        report --> ready["Ready for migration"]
        report --> notsup["Not supported"]
        report --> dep["Deprecated"]
        ready --> convert["Konversi menjadi kebijakan Settings catalog"]

Gambar 11: Dari ekspor XML lewat impor, klasifikasi per pengaturan, dan konversi ke Settings catalog — itu alur Group Policy analytics.

Ada catatan penting di lingkungan Jepang. Analisis pengaturan non-ADMX di Group Policy analytics hanya berbahasa Inggris; mengimpor GPO yang berisi pengaturan dalam bahasa selain Inggris dapat membuat persentase dukungan MDM tidak akurat.⁶ Perlakukan persentase dukungan sebagai nilai acuan kasar, dan buat penilaian akhir dari daftar per pengaturan.

flowchart TB
        accTitle: Catatan saat menganalisis GPO Jepang
        accDescr: Analisis pengaturan non-ADMX di Group Policy analytics hanya berbahasa Inggris, jadi GPO yang berisi pengaturan Jepang dapat membuat persentase dukungan MDM tidak akurat; perlakukan persentase sebagai acuan kasar dan buat penilaian akhir dari daftar per pengaturan
        jgpo["GPO yang berisi pengaturan Jepang"] --> limit["Analisis non-ADMX hanya berbahasa Inggris"]
        limit --> rate["Persentase dukungan dapat tidak akurat"]
        rate --> use1["Perlakukan persentase sebagai acuan kasar"]
        rate --> use2["Buat penilaian akhir dari daftar per pengaturan"]

Gambar 12: Di GPO Jepang persentase dukungan MDM dapat tidak akurat, jadi buat penilaian akhir dari daftar per pengaturan.

Dalam praktik, pecah hasil klasifikasi menjadi tiga tumpukan.

1. Pengaturan yang dibuang — pengaturan era Internet Explorer, pengaturan untuk sistem yang sudah pensiun, pengaturan yang tidak ada yang dapat menjelaskan alasannya. Hasil terbesar inventarisasi, pada kenyataannya, adalah dapat membuang tumpukan ini. GPO yang dijalankan selama sepuluh tahun punya jumlah warisan yang cukup besar.
2. Pengaturan yang dipindahkan ke Intune — yang di antara Ready for migration yang masih Anda butuhkan. Konversi ke Settings catalog dan validasi dengan grup percontohan.
3. Pengaturan yang Anda rancang penggantinya — yang di antara Not supported yang masih Anda butuhkan. Contoh representatif dan arah substitusi sebagai berikut.

flowchart TB
        accTitle: Tiga tumpukan hasil inventarisasi
        accDescr: Hasil inventarisasi ditangani sebagai tiga tumpukan: pengaturan yang dibuang, pengaturan yang dipindahkan ke Intune dan divalidasi, dan pengaturan yang tidak punya padanan dan yang Anda rancang penggantinya
        result["Hasil klasifikasi"] --> discard["Pengaturan yang dibuang"]
        result --> more{"Pindahkan atau ganti?"}
        more --> move["Pindahkan ke Intune"]
        more --> alt["Rancang pengganti"]
        discard -.-> legacy["Buang warisan"]
        move --> pilot["Settings catalog"]
        pilot -.-> pilotN["lalu validasi"]
        alt --> design["Skrip atau jadikan aplikasi"]

Gambar 13: Pecah hasil inventarisasi menjadi tiga tumpukan “buang”, “pindahkan ke Intune”, dan “rancang pengganti”.

7. Skenario migrasi bertahap — lima tahap dan kriteria keluar

Pecah keseluruhan menjadi lima tahap dan letakkan kriteria keluar pada masing-masing. Memutuskan di muka “kapan kita dapat berkata ini selesai” adalah trik yang mencegah migrasi IT satu orang mandek.

flowchart TB
        accTitle: Skenario migrasi lima tahap
        accDescr: Maju secara bertahap dari percontohan lewat kebijakan dasar, penyebaran aplikasi, mengganti PC yang ada pada siklus penyegaran perangkat keras, dan mengecilkan peran AD, dan akhirnya bawa pengaturan yang disebar lewat GPO ke nol
        s1["（1）Percontohan"] --> s2["（2）Kebijakan dasar"]
        s2 --> s3["（3）Penyebaran aplikasi"]
        s3 --> s4["（4）Penggantian alami PC yang ada"]
        s4 --> s5["（5）Mengecilkan peran AD"]
        s5 -.-> goal["Pengaturan yang disebar lewat GPO adalah nol"]

Gambar 14: Majukan migrasi dalam lima tahap dari percontohan sampai mengecilkan peran AD, dan putuskan kriteria keluar setiap tahap di muka.

Poin kunci setiap tahap.

• (1) Percontohan dimulai dengan PC yang tetap akan Anda beli — PC karyawan baru berikutnya, pengganti rusak/perbaikan, dan sejenisnya. Memulai dari mesin baru punya keuntungan bahwa Anda dapat mulai dengan investasi tambahan nol, dan jika gagal Anda dapat wipe dan mulai lagi. Begitu jumlahnya tumbuh, pertimbangkan memakai Windows Autopilot untuk mengotomatiskan dari OOBE (pengaturan awal) sampai Entra join plus pendaftaran Intune.²
• Di (2) Kebijakan dasar, jangan bertujuan mereproduksi setiap pengaturan GPO. Pertama persempit ke lima: pembaruan, enkripsi, Defender, kunci layar, dan LAPS, dan visualisasikan keadaan kepatuhan dengan kebijakan kepatuhan. Mengaktifkan “hanya perangkat yang patuh” di Conditional Access datang setelah Anda mengonfirmasi tidak ada positif palsu di percontohan.¹⁶
• (3) Penyebaran aplikasi berkelanjutan dengan mengotomatiskan penyediaan. Jika Anda sudah punya prosedur berbasis winget (“Mengotomatiskan penyediaan PC dengan winget + PowerShell”), aset itu dapat dipakai ulang hampir apa adanya sebagai aplikasi Store (baru) atau pembungkus aplikasi Win32.¹¹
• (4) PC yang ada, sebagaimana Bab 3 katakan, tidak punya jalur konversi ke Entra join, jadi prinsipnya adalah penggantian alami. Organisasi yang masih punya rencana penggantian Windows 10 (“Pilihan praktis setelah akhir dukungan Windows 10”) dapat menghindari mengerjakan dua kali dengan memajukan penggantian itu bersamaan dengan (4).
• Di (5) Mengecilkan peran AD, mengosongkan GPO tidak berarti AD segera tidak diperlukan. Jika autentikasi file server, pencarian LDAP dari aplikasi lama, dan sejenisnya tetap ada, AD berlanjut dalam bentuk yang dikecilkan sebagai “server autentikasi”. Menginventarisasi itu dan menetapkan tenggat adalah pekerjaan tahap ini.

flowchart TB
        accTitle: Apa yang dilakukan dengan AD setelah GPO kosong
        accDescr: Bahkan setelah GPO kosong, jika autentikasi file server atau pencarian LDAP dari aplikasi lama tetap ada, AD berlanjut dalam bentuk yang dikecilkan sebagai server autentikasi, dan menginventarisasi peran tersisa serta menetapkan tenggat adalah pekerjaan tahap akhir
        gpoempty["GPO kosong"] --> remain{"Peran tersisa apa yang ada?"}
        remain -->|Autentikasi file server| keep["Lanjutkan dalam bentuk yang dikecilkan sebagai server autentikasi"]
        remain -->|Pencarian LDAP warisan| keep
        remain -->|Tidak ada peran tersisa| retire["Pertimbangkan menonaktifkan AD itu sendiri"]
        keep --> task["Jalankan inventarisasi dan penetapan tenggat"]

Gambar 15: Bahkan setelah GPO kosong, jika peran tersisa ada, AD berlanjut dalam bentuk yang dikecilkan sebagai server autentikasi.

8. Jebakannya

8.1. Penerapan ganda GPO dan MDM — secara default GPO menang

Selama periode migrasi, baik GPO maupun Intune akan menyebarkan pengaturan ke PC yang sama (mesin hybrid-joined). Di sini, ketika pengaturan yang sama bertabrakan, Group Policy menang secara default. Menyetel MDMWinsOverGP Policy CSP ke 1 membuat pengaturan sisi MDM menang dan memblokir pengaturan GPO yang berkorespondensi, tetapi mekanisme itu hanya berlaku untuk pengaturan di bawah Policy CSP dan tidak berlaku untuk pengaturan yang didefinisikan di CSP lain seperti Defender CSP. Microsoft sendiri menyatakan bahwa jika Anda mengonfigurasi pengaturan yang tidak di bawah MDMWinsOverGP dari GPO dan MDM, Anda masuk ke keadaan konflik dan tidak ada jaminan yang mana menang.¹⁴

flowchart TB
        accTitle: Prioritas ketika GPO dan MDM bertabrakan
        accDescr: Jika Anda menyebarkan pengaturan yang sama dari GPO dan MDM, GPO menang secara default; menyetel MDMWinsOverGP ke 1 membuat MDM menang hanya untuk pengaturan di bawah Policy CSP, dan untuk pengaturan di CSP lain tidak ada jaminan yang mana menang
        both["Sebar pengaturan yang sama dari GPO dan MDM"] --> flag{"MDMWinsOverGP=1?"}
        flag -->|Tidak| gpowin["GPO menang（default）"]
        flag -->|Ya| csp{"Pengaturan di bawah Policy CSP?"}
        csp -->|Ya| mdmwin["MDM menang"]
        csp -->|Tidak| unknown["Tidak ada jaminan yang mana menang"]
        both -.-> avoid["Prinsipnya adalah jangan sebar dari keduanya"]

Gambar 16: Secara default GPO menang, dan MDMWinsOverGP hanya berlaku di bawah Policy CSP. Prinsipnya adalah menghindari penyebaran ganda.

Prinsip praktisnya sederhana. Jangan andalkan kontrol prioritas; jangan sebar pengaturan yang sama dari keduanya. Untuk pengaturan yang telah Anda pindahkan ke Intune, kembalikan konfigurasi sisi GPO yang berkorespondensi ke “Not configured”, atau putuskan tautan GPO sama sekali. Daftar yang dimigrasikan di Bab 6 juga adalah buku besar untuk ini.

8.2. Ketergantungan pada aset on-premises — drive jaringan dan printer

Banyak tempat migrasi mandek bukan fitur Intune melainkan konektivitas ke aset on-premises. Akses itu sendiri dari mesin Entra-joined ke file server on-premises dimungkinkan,² tetapi jika pemetaan drive dan penyebaran printer bergantung pada skrip logon GPO, sarana penyebaran itu hilang lebih dulu. Putuskan selama percontohan apakah melipat migrasi share ke OneDrive/SharePoint atau penggantian dengan Universal Print ke tahap (3), atau menjembatani untuk sementara dengan penyebaran skrip.¹²

flowchart TB
        accTitle: Mengganti penyebaran yang bergantung pada aset on-premises
        accDescr: Jika pemetaan drive dan penyebaran printer bergantung pada skrip logon GPO, sarana penyebaran itu hilang lebih dulu dalam migrasi, jadi putuskan selama percontohan apakah merespons dengan migrasi share ke OneDrive atau SharePoint, penggantian dengan Universal Print, atau penyebaran skrip untuk sementara
        dep["Ketergantungan pada skrip logon"] --> lost["Sarana penyebaran hilang dalam migrasi"]
        lost --> share["Migrasi ke OneDrive/SharePoint"]
        lost --> print["Ganti dengan Universal Print atau sejenisnya"]
        lost --> script["Jembatani dengan penyebaran skrip"]
        share --> decide["Putuskan pendekatan selama percontohan"]
        print --> decide
        script --> decide

Gambar 17: Penyebaran yang bergantung pada skrip logon kehilangan sarananya lebih dulu dalam migrasi, jadi putuskan penggantinya selama percontohan.

8.3. Mendesain ulang penyediaan — Autopilot bukan “wajib”

Anda kadang dinasihati untuk memperkenalkan Windows Autopilot sebagai satu paket dengan migrasi Intune, tetapi pada skala pengadaan beberapa hingga belasan mesin per tahun, masuk dengan akun kerja di OOBE dan Entra-join secara manual tidak merugikan secara nyata. Autopilot mulai menguntungkan ketika jumlah pengadaan tumbuh dan pengaturan tanpa pengawasan dari unboxing punya nilai, atau ketika Anda dapat memakai pendaftaran perangkat di sisi reseller. Menambahkannya setelah (2) dan (3) ada di tempat tidak apa-apa; itu bukan prasyarat migrasi.

flowchart TB
        accTitle: Keputusan memperkenalkan Autopilot
        accDescr: Pada skala pengadaan beberapa hingga belasan mesin per tahun, Entra-join secara manual di OOBE tidak merugikan secara nyata; tambahkan Autopilot nanti, ketika jumlah pengadaan telah tumbuh dan pengaturan tanpa pengawasan punya nilai
        scale{"Berapa skala pengadaan tahunan?"} -->|Beberapa hingga belasan| manual["Entra join manual di OOBE"]
        scale -->|Begitu jumlahnya tumbuh| ap["Tanpa pengawasan dengan Autopilot"]
        ap -.-> later["Tambahkan setelah（2）dan（3）ada di tempat"]

Gambar 18: Sementara skala pengadaan kecil, Entra join manual cukup; Autopilot dapat ditambahkan nanti.

8.4. Kesalahpahaman bahwa “tidak baik kecuali semuanya ada di Intune”

Yang terakhir bukan masalah teknis melainkan masalah asumsi. Koeksistensi mesin Entra-joined dan mesin domain-joined adalah konfigurasi yang didukung secara formal,² dan “AD masih ada = migrasi gagal” tidak benar. Perusahaan yang berjalan bertahun-tahun dengan beberapa pengaturan masih tertinggal di GPO tidak jarang, dan bahkan saat itu ada nilai besar pada keadaan “setiap PC baru dikelola cloud, dan kontrol bekerja di luar kantor juga”. Lebih baik kemajuan kecil yang dapat dibalik daripada keindahan migrasi lengkap.

flowchart TB
        accTitle: Nilai berjalan secara paralel tanpa bersikeras pada migrasi lengkap
        accDescr: AD yang tersisa bukan migrasi yang gagal; bahkan jika Anda berjalan secara paralel bertahun-tahun dengan pengaturan masih di GPO, ada nilai besar pada keadaan di mana setiap PC baru dikelola cloud dan kontrol bekerja di luar kantor
        miscon["AD tersisa berarti migrasi gagal?"] -->|Tidak| run["Berjalan secara paralel bertahun-tahun dengan GPO masih ada"]
        run --> value["PC baru terkendali bahkan di luar kantor"]
        value -.-> forward["Lebih baik kemajuan kecil"]

Gambar 19: Bahkan berjalan secara paralel dengan AD masih ada, keadaan di mana setiap PC baru dikelola cloud punya nilai besar.

9. Jawaban realistis untuk IT satu orang

Akhirnya, ringkasan desain operasional di perusahaan di mana orang yang bertanggung jawab adalah satu (atau memegang peran itu sebagai pekerjaan sampingan).

• Persempit item pengelolaan dari awal. Jika Anda mencoba membawa setiap pengaturan era GPO, Anda akan kelelahan pada inventarisasi saja. Mulai dari lima di Bab 7 (2) (pembaruan, enkripsi, Defender, kunci layar, LAPS) dan jadikan “desain pengurangan” yang menambah pengaturan hanya ketika kebutuhan muncul. Settings catalog menawarkan ribuan pengaturan,⁷ tetapi Anda tidak wajib memakainya.
• Putuskan satu citra PC standar. Pertahankan hanya satu standar: “PC di perusahaan ini adalah set kebijakan ini dan set aplikasi ini”. Pengecualian departemen dapat dinyatakan dengan grup dan filter, tetapi semakin pengecualian tumbuh, semakin satu orang tidak dapat mengikutinya.
• Minta mitra eksternal untuk desain dan pembuatan templat; jaga operasi harian di dalam. Outsourcing migrasi Intune yang mudah gagal adalah kasus di mana Anda melempar pembangunan ke seberang dinding dan berakhir pada keadaan “tidak ada yang memahami apa arti layar admin”. Minta pihak luar untuk desain awal, pembuatan templat kebijakan, dan papan suara untuk keputusan migrasi, dan jadikan tujuannya keadaan di mana Anda dapat menambah PC dan menyesuaikan kebijakan sendiri dari hari ke hari. Dinyatakan sebaliknya, Anda harus memilih mitra yang akan menyerahkan sejauh itu.
• Ubah satu hal pada satu waktu. Buat perubahan kebijakan satu per satu, dan lanjutkan hanya setelah Anda mengonfirmasi hasil di laporan Intune (keadaan penerapan kebijakan dan kegagalan penugasan). Sinkron MDM pada siklus sekitar 8 jam,³ dan sebagian besar “belum diterapkan” adalah soal waktu, bukan kesalahan.

flowchart TB
        accTitle: Siklus operasional perubahan kebijakan
        accDescr: Buat perubahan kebijakan satu per satu, dan lanjutkan ke perubahan berikutnya hanya setelah mengonfirmasi keadaan penerapan di laporan Intune. Sebagian besar kasus belum diterapkan diselesaikan dengan menunggu siklus sinkron kira-kira 8 jam
        change["Buat hanya satu perubahan kebijakan"] --> report["Konfirmasi keadaan penerapan di laporan"]
        report --> next["Jika tidak ada masalah, ke perubahan berikutnya"]
        next --> change
        report -.-> wait["Sebagian besar belum diterapkan adalah menunggu sinkron"]

Gambar 20: Buat perubahan kebijakan satu per satu, dan lanjutkan hanya setelah mengonfirmasi hasil di laporan.

10. Ringkasan

• GPO adalah mekanisme yang mengasumsikan jangkauan ke domain controller, dan secara struktural tidak sampai ke PC di luar kantor. Intune (MDM) menyinkronkan lewat internet, jadi ia menyelesaikan masalah ini dari akar.
• Migrasi bukan semua-atau-tidak-sama-sekali. Mesin Entra-joined dan mesin domain-joined dapat hidup berdampingan, dan migrasi bertahap yang mengalihkan PC baru ke Entra join plus Intune adalah jawaban realistis untuk usaha kecil dan menengah. Tidak ada jalur konversi untuk mesin yang ada, jadi penggantian pada siklus penyegaran perangkat keras adalah pola yang mapan.
• Untuk usaha kecil dan menengah, memulai Intune dengan Microsoft 365 Business Premium (Intune Plan 1 plus Entra ID P1) adalah realistis. Komposisi paket terus berubah, walaupun, dan beberapa fitur seperti Remediations mensyaratkan lisensi yang lebih tinggi, jadi jangan anggap artikel Agustus 2026 ini sebagai injil; konfirmasi sumber primer.
• Inventarisasi GPO saat ini dapat diotomatiskan dengan Group Policy analytics. Konversi pengaturan Ready for migration ke Settings catalog, dan ganti skrip logon serta penyebaran printer yang tidak punya padanan dengan penyebaran skrip, mengubah pekerjaan menjadi aplikasi, atau menghentikan praktik. Catat bahwa di GPO Jepang persentase dukungan dapat tidak akurat.
• Majukan migrasi dalam lima tahap “percontohan → kebijakan dasar → penyebaran aplikasi → penggantian alami PC yang ada → mengecilkan peran AD”, dan putuskan kriteria keluar setiap tahap lebih dulu.
• Konflik penerapan ganda dimenangkan oleh GPO secara default. MDMWinsOverGP adalah mekanisme khusus Policy CSP, jadi prinsipnya adalah “jangan sebar pengaturan yang sama dari keduanya”.
• Ketika kutipan penggantian server tiba adalah waktu terbaik untuk mempertimbangkan migrasi ini. Sebelum “satu siklus AD lagi”, pikirkan di mana PC lima tahun ke depan akan dipakai.

Artikel terkait

• Panduan praktis Group Policy (GPO) — cara kerjanya, mengonfirmasi penerapan, dan memilih antara GPO dan Intune
• Manajemen Windows Update setelah penghentian WSUS — cara memilih antara WUfB, Autopatch, dan Intune
• Pilihan praktis setelah akhir dukungan Windows 10 — tabel keputusan untuk ESU, LTSC, dan penggantian
• Mengotomatiskan penyediaan PC dengan winget + PowerShell — membuat runbook dapat dijalankan
• Panduan praktis BitLocker — enkripsi drive dimulai dengan pengelolaan kunci pemulihan
• Panduan praktis Windows LAPS — menonaktifkan kata sandi administrator lokal bersama di semua PC

Area konsultasi terkait

KomuraSoft LLC menangani desain migrasi bertahap dari lingkungan AD+GPO ke Entra ID+Intune (menginventarisasi GPO saat ini, kebijakan mereproduksi pengaturan, rencana percontohan), tinjauan banding penggantian server versus pindah ke cloud, dan konsultasi yang memakai ulang aplikasi bisnis yang ada serta aset penyediaan. Memulai dari mempertimbangkan bersama “haruskah kita membeli server AD lagi” tidak apa-apa.

• Konsultasi teknis dan tinjauan desain
• Migrasi aset warisan
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Jika kita migrasi dari GPO ke Intune, dapatkah kita mereproduksi setiap pengaturan Group Policy yang kita pakai hari ini?

Anda tidak dapat mereproduksi semuanya. Settings catalog Intune punya ribuan pengaturan Windows, termasuk yang berasal dari ADMX, dan sebagian besar pengaturan keamanan serta pembatasan dapat dipindahkan, tetapi beberapa hal — pemetaan drive lewat skrip logon, penyebaran printer massal — tidak punya pengaturan MDM yang berkorespondensi. Jika Anda mengimpor ekspor XML GPO saat ini ke Group Policy analytics Intune, setiap pengaturan diklasifikasikan sebagai Ready for migration, Not supported, atau Deprecated. Untuk pengaturan yang tidak punya padanan, Anda menutupinya dengan menyebarkan skrip PowerShell, mengubah pekerjaan menjadi aplikasi, atau sekadar menghentikan pengaturan itu.

Lisensi mana yang kita butuhkan untuk memakai Intune?

Dasarnya adalah Microsoft Intune Plan 1. Anda dapat berlangganan secara mandiri, tetapi di usaha kecil dan menengah biasanya dipakai sebagai bagian dari Microsoft 365 Business Premium (hingga 300 pengguna). Business Premium juga mencakup Entra ID P1, jadi Anda dapat sampai menggabungkan kebijakan kepatuhan dengan Conditional Access. Beberapa fitur, seperti Remediations, secara terpisah mensyaratkan lisensi kelas Windows Enterprise E3/E5. Komposisi paket sering berubah, jadi konfirmasi detail terbaru di halaman lisensi resmi Microsoft sebelum Anda menandatangani (artikel ini per Agustus 2026).

Apakah kita harus segera menonaktifkan server AD?

Tidak. PC yang dikelola dengan Entra join plus Intune dan PC yang dikelola dengan AD domain join plus GPO dapat hidup berdampingan di jaringan perusahaan yang sama. Migrasi bertahap — membiarkan AD tetap ada untuk autentikasi file server dan sistem bisnis yang ada, dan hanya Entra-join PC baru — adalah realistis. Sebaliknya, tidak ada cara yang didukung untuk "mengonversi" PC domain-joined yang ada menjadi Entra join; wipe (reset) diperlukan, jadi pola yang mapan adalah mengganti mesin yang ada pada siklus penyegaran perangkat keras. Cukup mempertimbangkan menonaktifkan AD setelah GPO kosong dan Anda telah menginventarisasi peran yang tersisa.

Mengapa Group Policy tidak diterapkan pada PC yang dipakai untuk kerja jarak jauh?

Karena GPO diambil dan diterapkan ketika PC dapat menjangkau domain controller. PC di luar kantor hanya dapat menerima kebijakan terbaru ketika ia dapat menjangkau domain controller lewat VPN atau sejenisnya, dan PC rumah yang tidak memakai VPN pada dasarnya tidak pernah mendapatkannya. Intune (MDM) menyinkronkan kebijakan lewat internet, jadi Anda dapat mengelola PC di mana pun ia berada; masalah mengelola PC di luar kantor diselesaikan oleh struktur MDM. Selain sinkron berkala kira-kira setiap 8 jam, sinkron yang dipicu notifikasi juga berjalan ketika kebijakan berubah.

Jika kita menyebarkan pengaturan yang sama dari GPO dan Intune, yang mana yang menang?

Secara default, pengaturan yang bertabrakan dimenangkan oleh Group Policy. Menyetel kebijakan MDMWinsOverGP ke 1 membuat sisi MDM (Intune) menang, tetapi mekanisme itu hanya berlaku untuk pengaturan di bawah Policy CSP; ia tidak berlaku untuk pengaturan yang didefinisikan di CSP lain seperti Defender CSP. Mengandalkan kontrol prioritas membuat perilaku sulit diprediksi, jadi dalam praktik prinsipnya adalah "jangan sebar pengaturan yang sama dari kedua saluran", dan begitu pengaturan telah pindah ke Intune Anda menghapusnya dari GPO asal untuk menghindari pengelolaan ganda.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.