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

“Masa dukungan server habis, jadi kami merencanakan penggantian. Namun kami mulai ragu apakah harus membeli lagi server AD dan menjalankan domain serta Group Policy untuk satu siklus lagi (lima tahun).” “Group Policy yang diputuskan di kantor tidak kunjung diterapkan pada laptop kerja dari rumah. Kalau hanya berlaku saat tersambung ke VPN, bisakah itu disebut terkelola?” — Beberapa tahun terakhir, konsultasi semacam ini dari pelanggan usaha kecil dan menengah terus bertambah.

Latar belakangnya adalah perubahan cara kerja. Active Directory (AD) on-premises dan Group Policy (GPO) adalah mekanisme yang mengasumsikan “PC berada di LAN kantor dan selalu dapat menjangkau domain controller”. Kini PC bawa pulang dan kerja dari rumah sudah biasa, asumsi itulah yang runtuh. Di samping itu, WSUS yang lama menjadi andalan manajemen pembaruan menjadi deprecated pada September 2024,¹ dan titik berat manajemen perangkat Microsoft berpindah ke Entra ID+Intune (MDM).

flowchart TB
    accTitle: Asumsi yang runtuh dan pergeseran titik berat pengelolaan
    accDescr: AD dan GPO mengasumsikan PC berada di LAN kantor dan selalu dapat menjangkau domain controller, tetapi PC bawa pulang dan kerja dari rumah yang menjadi biasa meruntuhkan asumsi itu, dan dengan WSUS yang deprecated titik berat pengelolaan berpindah ke Entra ID dan Intune
    adgpo["AD on-premises dan GPO"] -.-> premise["Asumsinya: DC selalu dapat dijangkau"]
    work["PC bawa pulang dan kerja dari rumah yang menjadi biasa"] --> broken["Asumsinya yang runtuh"]
    premise --> broken
    wsus["WSUS menjadi deprecated"] --> shift["Titik berat ke Entra ID+Intune"]
    broken --> shift

Gambar 1: Asumsi AD+GPO bahwa “PC berada di LAN kantor” runtuh seiring perubahan cara kerja, dan titik berat pengelolaan berpindah ke Entra ID+Intune.

Meski begitu, migrasi bukan pilihan semua-atau-tidak-sama-sekali. PC yang dikelola dengan Entra join+Intune dan PC domain join AD+GPO bisa hidup berdampingan di kantor yang sama,² dan migrasi bertahap dimungkinkan: AD tetap ada untuk file server, sementara PC baru dialihkan ke pengelolaan Intune. Ditujukan kepada staf sistem informasi dan pengambil keputusan di usaha kecil dan menengah, artikel ini merangkum—berdasarkan sumber primer seperti Microsoft Learn per Agustus 2026—perbedaan mekanisme GPO dan MDM, konfigurasi prasyarat, lisensi, cara menginventarisasi GPO yang berjalan, skenario migrasi bertahap, dan titik tersandungnya.

1. Kesimpulan lebih dulu

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

Dalam satu kalimat: pertanyaan “apakah server AD diganti untuk satu siklus lagi” harus diganti menjadi “untuk lima tahun ke depan, dengan apa PC di luar kantor dikelola” lalu diputuskan atas dasar itu.

flowchart LR
    accTitle: Merumuskan ulang pertanyaan yang harus diputuskan
    accDescr: Pertanyaan apakah server AD diganti untuk satu siklus lagi diganti menjadi pertanyaan dengan apa PC di luar kantor dikelola selama lima tahun ke depan, lalu diputuskan atas dasar itu
    q1["Server AD diganti satu siklus lagi?"] -->|diganti| q2["5 tahun ke depan: PC di luar kantor dikelola dengan apa?"]

Gambar 2: Pertanyaan penggantian server dirumuskan ulang menjadi “untuk lima tahun ke depan, dengan apa PC di luar kantor dikelola” lalu diputuskan atas dasar itu.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 20, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Apa perbedaan GPO dan MDM — membandingkan mekanisme penerapan

Pertama, keduanya dibandingkan di lapangan yang sama. Mekanisme GPO itu sendiri (urutan penerapan LSDOU, cara memeriksa dengan gpupdate/gpresult) dibahas lebih dalam di “Pengantar praktis Group Policy (GPO)”, jadi di sini hanya perbedaan yang memengaruhi keputusan migrasi.

Yang paling penting untuk keputusan migrasi adalah baris pertama dan ketiga. GPO tidak sampai ke PC rumah bukanlah bug, melainkan asumsi desain “PC berada di tempat yang dapat menjangkau domain controller” yang tidak lagi cocok dengan cara kerja masa kini. Ada juga jalan memperpanjang GPO dengan memaksa VPN selalu terhubung ke seluruh karyawan, tetapi itu juga pilihan untuk memikul pemeliharaan infrastruktur lain: fondasi VPN.

flowchart TB
    accTitle: Memperpanjang GPO atau pindah ke MDM
    accDescr: GPO tidak sampai ke PC rumah karena asumsi desain tidak lagi cocok dengan cara kerja masa kini, dan jalan memperpanjang GPO dengan memaksa VPN selalu terhubung adalah pilihan memikul pemeliharaan infrastruktur lain yaitu fondasi VPN
    gap["Asumsi desain tidak cocok dengan cara kerja"] --> sel{"Bagaimana menanganinya?"}
    sel -->|Perpanjang dengan VPN selalu terhubung| vpn["Lanjutkan GPO"]
    sel -->|Pindah ke MDM| mdm["Kelola lewat internet"]
    vpn --> cost["Memikul pemeliharaan infrastruktur lain"]

Gambar 3: Jalan memperpanjang GPO dengan VPN selalu terhubung juga merupakan pilihan memikul pemeliharaan infrastruktur lain, yaitu fondasi VPN.

Di sisi lain, interval sinkron MDM (sekitar 8 jam) lebih kasar daripada pembaruan berkala GPO (sekitar 90 menit), sehingga rasa “disebar, langsung berlaku” tidak berlaku. Saat kebijakan ditugaskan atau diubah, notifikasi dikirim ke perangkat dan sinkron relatif cepat,³ tetapi pengendalian yang harus berlaku segera (pemblokiran darurat, misalnya) harus dirancang dengan interval sinkron sebagai prasyarat.

flowchart TB
    accTitle: Jalur penerapan kebijakan GPO dan MDM
    accDescr: GPO hanya diterapkan saat domain controller di kantor terjangkau sehingga PC rumah bergantung VPN, sedangkan Intune menyinkronkan lewat internet kira-kira setiap 8 jam dan juga menyinkronkan lewat notifikasi saat kebijakan berubah sehingga sampai di mana pun
    officepc["PC di kantor"] -->|saat boot dan masuk plus pembaruan berkala| dc["Domain controller"]
    homepc["PC di rumah"] --> vpn{"DC terjangkau lewat VPN?"}
    vpn -->|ya| dc
    vpn -->|tidak| miss["Kebijakan terbaru tidak sampai"]
    anypc["PC di mana pun"] -->|sinkron kira-kira setiap 8 jam| intune["Layanan Intune"]
    intune -.-> notify["Saat kebijakan berubah, sinkron lewat notifikasi"]

Gambar 4: GPO hanya diterapkan saat domain controller terjangkau; Intune menyinkronkan lewat internet tanpa peduli lokasi.

3. Menata prasyarat — tiga bentuk domain join, hybrid join, dan Entra join

Cara Windows PC “bergabung ke perusahaan” ada tiga bentuk, dan sarana pengelolaan yang bisa dipakai ditentukan oleh pilihan itu.²

Hybrid join adalah bentuk untuk “memberi identitas cloud kepada PC domain-joined yang ada”, sehingga Intune dan Conditional Access bisa mulai dipakai sambil memanfaatkan aset yang sudah ada. Namun Microsoft tidak merekomendasikan hybrid join sebagai tujuan akhir, dan merekomendasikan Entra join untuk PC baru dan pengganti.²

Ada satu batasan yang harus dipegang. Tidak ada cara yang didukung Microsoft untuk mengonversi PC domain-joined yang ada (termasuk hybrid join) menjadi Entra join; reset Windows (wipe) diperlukan. Karena itu Microsoft juga menganjurkan pindah ke Entra join bertepatan dengan pembaruan perangkat keras atau penggantian OS.²

flowchart TB
    accTitle: Tiga bentuk join dan jalur migrasi
    accDescr: PC yang hanya domain join AD bisa didaftarkan juga ke Entra ID menjadi hybrid join, tetapi tidak ada cara mengonversi langsung ke Entra join dan wipe diperlukan, sehingga PC baru dan pengganti direkomendasikan Entra join
    adonly["Hanya domain join AD (GPO)"] -->|didaftarkan juga ke Entra ID| hybrid["hybrid join (GPO dan Intune)"]
    hybrid -.->|tidak ada cara konversi langsung| wipe["Wipe (reset) diperlukan"]
    wipe --> entra["Entra join (Intune)"]
    newpc["PC baru dan pengganti"] -->|direkomendasikan| entra

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

Dari situ, tujuan realistis untuk usaha kecil dan menengah bisa diletakkan seperti ini.

1. PC baru dan pengganti dikelola dengan Entra join+Intune
2. PC domain-joined yang ada tidak dipaksa diubah, melainkan diganti secara alami pada siklus penggantian
3. AD untuk sementara tetap ada karena peran yang tersisa seperti autentikasi file server, dan hanya isi GPO yang dikosongkan secara bertahap

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

Gambar 6: Mesin Entra join dan mesin domain-joined bisa hidup berdampingan di lingkungan kantor yang sama; AD untuk sementara tetap ada karena peran yang tersisa.

Mesin Entra join dan mesin domain-joined bisa hidup berdampingan di lingkungan yang sama, dan akses dari mesin Entra join ke aset kantor seperti file server on-premises juga memungkinkan.² Namun single sign-on ini punya dua prasyarat. ① Pengguna adalah identitas hibrid yang disinkronkan dari AD on-premises dengan Entra Connect (atau Cloud Sync) (pengguna yang hanya ada di cloud tidak bisa memperoleh kredensial Kerberos/NTLM AD), ② PC secara jaringan dapat menjangkau domain controller (dari luar kantor diperlukan VPN atau sejenisnya).¹⁵ Dalam rencana migrasi, pastikan lebih dulu tidak ada pengguna atau skenario pemakaian yang tidak memenuhi dua poin ini.

flowchart TB
    accTitle: Prasyarat SSO dari mesin Entra join ke aset on-premises
    accDescr: Agar mesin Entra join dapat mengakses file server on-premises, dua prasyarat harus terpenuhi: identitas hibrid yang disinkronkan lewat Entra Connect atau sejenisnya, dan domain controller yang dapat dijangkau
    pc["Mesin Entra join"] --> cond1{"Identitas hibrid?"}
    cond1 -->|ya| cond2{"DC dapat dijangkau?"}
    cond1 -->|tidak| ng1["Kredensial AD tidak diperoleh"]
    cond2 -->|ya| ok["SSO ke file server"]
    cond2 -->|tidak| ng2["Dari luar kantor diperlukan VPN dll."]

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

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

Lisensi dasar Intune adalah Microsoft Intune Plan 1, dan disediakan baik sebagai langganan mandiri maupun sebagai bundel di berbagai paket Microsoft 365.⁴

Yang penting bagi usaha kecil dan menengah: Microsoft 365 Business Premium hingga 300 pengguna mencakup Intune Plan 1.⁵ Business Premium juga mencakup Microsoft Entra ID P1 dan Microsoft Defender for Business, sehingga konfigurasi kebijakan kepatuhan + Conditional Access yang dibahas kemudian selesai di dalam paket ini. Sebaliknya, Business Standard/Basic tidak mencakup Intune. Jika melangkah ke manajemen perangkat dari kontrak yang hanya email dan Office, biaya peningkatan ke Business Premium secara praktis menjadi biaya pengenalan Intune.

flowchart TB
    accTitle: Hubungan paket untuk usaha kecil dan menengah dengan Intune
    accDescr: Business Premium hingga 300 pengguna mencakup Intune Plan 1, Entra ID P1, dan Defender for Business sehingga Conditional Access pun selesai, 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["Hingga Conditional Access selesai"]
    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 hal yang perlu diperhatikan.

• Komposisi paket sering berubah. Bahkan setelah masuk 2026, perubahan seperti redistribusi fitur Intune Suite ke paket Microsoft 365 tingkat atas (E3/E5 dll.) masih berjalan, dan tinjauan isi bundel berlanjut.⁴ Isi bagian ini diperlakukan sebagai kondisi per Agustus 2026; sebelum berkontrak selalu konfirmasikan informasi terbaru di halaman lisensi dan halaman harga Microsoft.
• Ada fitur yang bisa dibuka dari layar Intune tetapi mensyaratkan lisensi terpisah. Contoh khasnya Remediations yang dibahas kemudian: lisensi kelas Windows Enterprise E3/E5 (terbundel di Microsoft 365 E3/E5 dll.) diperlukan, dan tidak bisa dipakai dalam lingkup Business Premium.¹³

Perbandingan biaya bukan “biaya langganan Intune” versus “nol rupiah”. Di sisi GPO pun ada biaya: penggantian perangkat keras server AD, lisensi Windows Server dan CAL, biaya pembangunan, pemeliharaan lima tahun, cadangan, dan penanganan gangguan. Perbandingan yang benar adalah menyejajarkan selisih antara estimasi penggantian server dan Business Premium selama lima tahun, lalu menimbang perbedaan kemampuan “apakah pengelolaan sampai ke PC di luar kantor”.

flowchart TB
    accTitle: Cara berpikir yang benar untuk perbandingan biaya
    accDescr: Sisi GPO pun menanggung biaya penggantian server AD, lisensi, dan pemeliharaan lima tahun, sehingga estimasi penggantian server dan Business Premium selama lima tahun disejajarkan, lalu perbedaan kemampuan apakah pengelolaan sampai ke PC di luar kantor ditimbang
    gpocost["Biaya melanjutkan GPO"] --> hw["Penggantian server, lisensi, CAL"]
    gpocost --> ops["Pembangunan, pemeliharaan, cadangan"]
    bpcost["Biaya pindah ke Intune"] --> sub["Business Premium selama 5 tahun"]
    hw --> diff["Sejajarkan selisih 5 tahun"]
    ops --> diff
    sub --> diff
    diff --> ability["Timbang apakah pengelolaan sampai ke PC di luar kantor"]

Gambar 9: Sejajarkan estimasi penggantian server dengan Business Premium selama lima tahun, lalu putuskan dengan menimbang perbedaan kemampuan pengelolaan PC di luar kantor.

5. Apa yang dikerjakan dengan GPO, bagaimana dikerjakan dengan Intune

Untuk setiap pekerjaan utama operasional GPO, padanan di Intune ditunjukkan dalam tabel korespondensi.

Beberapa catatan tambahan.

• Settings catalog adalah layar setara “versi cloud dari GPO Editor”, dan Microsoft sendiri menempatkannya sebagai “tujuan migrasi yang alami jika ingin mengonfigurasi secara rinci seperti GPO on-premises”. Kebijakan ADMX-backed (versi MDM dari pengaturan yang didefinisikan ADMX) juga termasuk, dan ada fitur impor ADMX pihak ketiga (pratinjau).⁷
• Kebijakan kepatuhan + Conditional Access adalah gagasan yang tidak ada di GPO. Kondisi kepatuhan seperti “BitLocker aktif, OS terbaru, Defender berjalan” didefinisikan, lalu akses ke Microsoft 365 dari perangkat yang tidak memenuhinya bisa diblokir. Conditional Access adalah fitur Entra ID P1 dan termasuk di Business Premium.¹⁶
• Remediations berganti nama dari nama lama Proactive remediations. Mekanismenya menjalankan pasangan skrip deteksi dan skrip perbaikan secara berkala, dan bisa menjadi pengganti operasional GPO jenis “memperbaiki sesuatu setiap logon”, tetapi seperti disebutkan di atas lisensi kelas Windows Enterprise E3/E5 diperlukan.¹³ Dalam lingkup Business Premium, kombinasi platform scripts (dijalankan saat skrip atau penugasan berubah, dan dicoba ulang jika gagal)¹² dengan aturan deteksi aplikasi Win32 adalah pengganti yang realistis.
• Pilihan rinci manajemen pembaruan (keputusan WUfB, Autopatch, atau lanjut WSUS) dibahas di “Manajemen Windows Update setelah WSUS deprecated”, dan desain BitLocker serta LAPS masing-masing di “Panduan praktis BitLocker” dan “Panduan praktis Windows LAPS”.

flowchart TB
    accTitle: Alur kebijakan kepatuhan dan Conditional Access
    accDescr: Kebijakan kepatuhan hanya menilai status kepatuhan perangkat berdasarkan kondisi kepatuhan, dan baru setelah kebijakan Conditional Access mensyaratkan perangkat yang patuh, perangkat patuh diizinkan dan perangkat tidak patuh diblokir
    policy["Mendefinisikan kondisi kepatuhan"] -.-> cond["BitLocker aktif, OS terbaru, dll."]
    policy --> state["Menilai status kepatuhan perangkat"]
    state --> ca["Conditional Access mensyaratkan kepatuhan"]
    ca -->|patuh| allow["Akses ke Microsoft 365 diizinkan"]
    ca -->|tidak patuh| block["Akses diblokir"]

Gambar 10: Penilaian status kepatuhan adalah peran kebijakan kepatuhan; pemutusan adalah peran Conditional Access. Blokir baru berlaku jika keduanya digabung.

6. Inventarisasi GPO yang berjalan — mengelompokkan dengan Group Policy analytics

Pekerjaan nyata pertama dalam rencana migrasi adalah inventarisasi GPO yang berjalan. Intune punya fitur khusus Group Policy analytics, sehingga tanpa harus membaca GPO secara manual, setiap pengaturan bisa dikelompokkan menurut “apakah bisa diganti dengan MDM”.⁶

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 (maksimum 4 MB per berkas)
2. Di pusat admin Intune, “Devices” → “Group Policy analytics”, impor XML (boleh pilih beberapa)
3. Hasil analisis otomatis menampilkan tingkat dukungan MDM per GPO (proporsi yang punya pengaturan setara di Intune)
4. Di laporan “Group Policy migration readiness”, per pengaturan konfirmasikan pengelompokan Ready for migration (bisa dimigrasi) / Not supported (tidak ada pengaturan padanan) / Deprecated (sudah dihentikan)
5. Pengaturan Ready for migration bisa dikonversi langsung menjadi kebijakan Settings catalog lalu didistribusikan

flowchart TB
    accTitle: Alur inventarisasi dengan Group Policy analytics
    accDescr: Mengekspor GPO sebagai XML di GPMC lalu mengimpor ke Intune menampilkan tingkat dukungan MDM dan kesiapan migrasi per pengaturan, dan pengaturan Ready for migration dapat dikonversi menjadi kebijakan Settings catalog
    export["Ekspor GPO sebagai XML di GPMC"] --> import["Impor ke Intune"]
    import --> rate["Tampilan tingkat dukungan MDM"]
    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, impor, pengelompokan per pengaturan, hingga konversi ke Settings catalog adalah alur Group Policy analytics.

Di lingkungan berbahasa Jepang ada catatan penting. Analisis pengaturan non-ADMX di Group Policy analytics hanya mendukung bahasa Inggris; jika GPO yang berisi pengaturan dalam bahasa selain Inggris diimpor, tingkat dukungan MDM bisa menjadi tidak akurat.⁶ Pakai tingkat dukungan sebagai nilai perkiraan referensi, dan putusan akhir dilakukan dari daftar per pengaturan.

flowchart TB
    accTitle: Catatan saat menganalisis GPO berbahasa Jepang
    accDescr: Analisis pengaturan non-ADMX di Group Policy analytics hanya mendukung bahasa Inggris, sehingga pada GPO yang berisi pengaturan Jepang tingkat dukungan MDM bisa tidak akurat; tingkat itu hanya perkiraan referensi dan putusan akhir dari daftar per pengaturan
    jgpo["GPO yang berisi pengaturan Jepang"] --> limit["Analisis non-ADMX hanya bahasa Inggris"]
    limit --> rate["Tingkat dukungan bisa tidak akurat"]
    rate --> use1["Tingkat hanya perkiraan referensi"]
    rate --> use2["Putusan akhir dari daftar per pengaturan"]

Gambar 12: Pada GPO berbahasa Jepang tingkat dukungan MDM bisa tidak akurat, jadi putusan akhir dilakukan dari daftar per pengaturan.

Dalam praktik, hasil pengelompokan dibagi menjadi tiga tumpukan.

1. Pengaturan yang dibuang — pengaturan era Internet Explorer, pengaturan untuk sistem yang sudah pensiun, pengaturan yang tidak ada yang bisa menjelaskan alasannya. Hasil terbesar inventarisasi justru kemampuan membuang tumpukan ini. GPO yang dioperasikan 10 tahun menumpuk warisan dalam jumlah signifikan.
2. Pengaturan yang dipindah ke Intune — yang Ready for migration dan masih diperlukan ke depan. Dikonversi ke Settings catalog dan diverifikasi pada grup percontohan.
3. Pengaturan yang perlu dirancang penggantinya — yang Not supported dan masih diperlukan ke depan. Contoh khas dan arah pengganti sebagai berikut.

flowchart TB
    accTitle: Tiga pengelompokan hasil inventarisasi
    accDescr: Hasil inventarisasi ditangani sebagai tiga tumpukan: pengaturan yang dibuang, pengaturan yang dipindah ke Intune lalu diverifikasi, dan pengaturan tanpa padanan yang perlu dirancang penggantinya
    result["Hasil pengelompokan"] --> discard["Pengaturan yang dibuang"]
    result --> move["Pengaturan yang dipindah ke Intune"]
    result --> alt["Pengaturan yang perlu dirancang penggantinya"]
    discard -.-> legacy["Membuang warisan yang menumpuk"]
    move --> pilot["Konversi ke Settings catalog dan verifikasi"]
    alt --> design["Distribusi skrip atau dikemas jadi aplikasi"]

Gambar 13: Hasil inventarisasi dikelompokkan menjadi tiga tumpukan: “dibuang”, “dipindah ke Intune”, “dirancang penggantinya”.

7. Skenario migrasi bertahap — lima tahap dan syarat selesai

Keseluruhan dibagi menjadi lima tahap, dan setiap tahap punya syarat selesai. Menentukan lebih dulu “kapan bisa dikatakan selesai” adalah kiat agar migrasi sistem informasi satu orang tidak macet.

flowchart TB
    accTitle: Skenario migrasi lima tahap
    accDescr: Maju secara bertahap dari percontohan ke kebijakan dasar, distribusi aplikasi, penggantian PC yang ada pada siklus penggantian, lalu penyusutan peran AD, dan pada akhirnya pengaturan yang disebar dengan GPO menjadi nol
    s1["① Percontohan"] --> s2["② Kebijakan dasar"]
    s2 --> s3["③ Distribusi aplikasi"]
    s3 --> s4["④ Penggantian alami PC yang ada"]
    s4 --> s5["⑤ Penyusutan peran AD"]
    s5 -.-> goal["Pengaturan yang disebar dengan GPO bernilai nol"]

Gambar 14: Migrasi maju dalam lima tahap dari percontohan hingga penyusutan peran AD, dan syarat selesai setiap tahap ditentukan lebih dulu.

Poin setiap tahap.

• ① Percontohan dimulai dengan PC yang tetap akan dibeli, misalnya PC karyawan baru berikutnya atau unit pengganti kerusakan. Bisa dimulai tanpa investasi tambahan, dan jika gagal bisa di-wipe lalu diulang—itu keuntungan memulai dari mesin baru. Ketika jumlah unit bertambah, pertimbangkan Windows Autopilot yang mengotomatiskan dari OOBE (penyiapan awal) hingga Entra join+pendaftaran Intune.²
• ② Kebijakan dasar: jangan menargetkan reproduksi seluruh pengaturan GPO. Mulai dengan lima poin: pembaruan, enkripsi, Defender, kunci layar, LAPS, lalu visualisasikan status kepatuhan dengan kebijakan kepatuhan. Mengaktifkan “hanya perangkat patuh yang boleh akses” di Conditional Access dilakukan setelah dikonfirmasi tidak ada salah deteksi di percontohan.¹⁶
• ③ Distribusi aplikasi berkesinambungan dengan otomatisasi kitting. Jika prosedur berbasis winget sudah ditata (“Mengotomatiskan kitting PC dengan winget + PowerShell”), aset itu hampir bisa dipakai apa adanya sebagai wrapper aplikasi Store (baru) atau aplikasi Win32.¹¹
• ④ PC yang ada, seperti dibahas di bab 3, tidak punya jalur konversi ke Entra join, jadi prinsipnya penggantian alami. Organisasi yang masih punya rencana penggantian dari Windows 10 (“Jawaban realistis setelah dukungan Windows 10 berakhir”) bisa menjalankan penggantian itu bersamaan dengan ④ untuk menghindari kerja ganda.
• ⑤ Penyusutan peran AD: GPO yang kosong tidak otomatis membuat AD segera tidak diperlukan. Jika autentikasi file server, rujukan LDAP aplikasi warisan, dan sejenisnya masih ada, AD dilanjutkan dalam bentuk menyusut sebagai “server autentikasi”. Inventarisasi itu dan penetapan tenggat termasuk pekerjaan tahap ini.

flowchart TB
    accTitle: Perlakuan AD setelah GPO kosong
    accDescr: Meski GPO kosong, jika autentikasi file server atau rujukan LDAP aplikasi warisan tersisa, AD dilanjutkan menyusut sebagai server autentikasi, dan inventarisasi peran yang tersisa plus penetapan tenggat adalah pekerjaan tahap akhir
    gpoempty["GPO sudah kosong"] --> remain{"Peran yang tersisa?"}
    remain -->|Autentikasi file server| keep["Lanjut menyusut sebagai server autentikasi"]
    remain -->|Rujukan LDAP warisan| keep
    remain -->|Tidak ada peran| retire["Pertimbangkan penonaktifan AD itu sendiri"]
    keep --> task["Lakukan sampai inventarisasi dan penetapan tenggat"]

Gambar 15: Meski GPO kosong, jika ada peran yang tersisa AD dilanjutkan menyusut sebagai server autentikasi.

8. Titik tersandung

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

Selama masa migrasi, GPO dan Intune sama-sama menyebar pengaturan ke PC yang sama (mesin hybrid join). Di sini, jika pengaturan yang sama bentrok, secara default sisi GPO yang diutamakan. Jika MDMWinsOverGP di Policy CSP disetel ke 1, pengaturan sisi MDM yang diutamakan dan pengaturan GPO yang berkorespondensi diblokir, 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 pengaturan yang tidak berada di bawah pengelolaan MDMWinsOverGP dikonfigurasi dari GPO dan MDM, terjadi keadaan bentrok dan tidak dijamin siapa yang menang.¹⁴

flowchart TB
    accTitle: Prioritas saat GPO dan MDM bentrok
    accDescr: Jika pengaturan yang sama disebar dari GPO dan MDM, secara default GPO yang diutamakan; jika MDMWinsOverGP=1 maka hanya pengaturan di bawah Policy CSP yang diutamakan MDM, dan untuk pengaturan CSP lain pemenangnya tidak dijamin
    both["Pengaturan yang sama disebar dari GPO dan MDM"] --> flag{"MDMWinsOverGP=1?"}
    flag -->|tidak| gpowin["GPO diutamakan (default)"]
    flag -->|ya| csp{"Pengaturan di bawah Policy CSP?"}
    csp -->|ya| mdmwin["MDM diutamakan"]
    csp -->|tidak| unknown["Tidak dijamin siapa yang menang"]
    both -.-> avoid["Prinsipnya: jangan sebar dari keduanya"]

Gambar 16: Secara default GPO yang menang; MDMWinsOverGP hanya berlaku di bawah Policy CSP. Prinsipnya hindari distribusi ganda.

Prinsip praktisnya sederhana. Jangan andalkan kontrol prioritas; jangan sebar pengaturan yang sama dari keduanya. Pengaturan yang sudah pindah ke Intune dikembalikan ke “Not Configured” di sisi GPO yang berkorespondensi, atau tautan GPO dilepas seluruhnya. Daftar yang sudah dimigrasi di bab 6 juga merupakan buku besar untuk ini.

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

Banyak titik macet migrasi bukan pada fitur Intune, melainkan koneksi ke aset on-premises. Akses itu sendiri dari mesin Entra join ke file server on-premises memungkinkan,² tetapi jika pemetaan drive atau distribusi printer bergantung pada skrip logon GPO, sarana distribusi itu hilang lebih dulu. Putuskan selama percontohan apakah migrasi berbagi ke OneDrive/SharePoint atau penggantian ke Universal Print dijalin ke tahap ③, atau untuk sementara disambung dengan distribusi skrip.¹²

flowchart TB
    accTitle: Mengganti distribusi yang bergantung pada aset on-premises
    accDescr: Jika pemetaan drive atau distribusi printer bergantung pada skrip logon GPO, sarana distribusi itu hilang lebih dulu saat migrasi, sehingga selama percontohan diputuskan apakah migrasi berbagi ke OneDrive/SharePoint, penggantian ke Universal Print, atau untuk sementara distribusi skrip
    dep["Bergantung pada skrip logon"] --> lost["Sarana distribusi hilang saat migrasi"]
    lost --> share["Migrasi OneDrive/SharePoint"]
    lost --> print["Diganti ke Universal Print dll."]
    lost --> script["Disambung dengan distribusi skrip"]
    share --> decide["Tentukan arah selama percontohan"]
    print --> decide
    script --> decide

Gambar 17: Distribusi yang bergantung pada skrip logon kehilangan sarananya lebih dulu saat migrasi, jadi tujuan pengganti ditentukan selama percontohan.

8.3. Mendesain ulang kitting — Autopilot bukan “wajib”

Bersamaan dengan migrasi Intune, pengenalan Windows Autopilot kadang disarankan, tetapi pada skala pengadaan beberapa hingga belasan unit per tahun, operasional masuk dengan akun kerja di OOBE lalu Entra join secara manual tidak menimbulkan kerugian nyata. Autopilot mulai berarti ketika jumlah pengadaan bertambah dan penyiapan otomatis tanpa operator dari unboxing bernilai, atau ketika pendaftaran perangkat di sisi toko bisa dipakai. Cukup ditambahkan setelah ②③ rapi; bukan prasyarat migrasi.

flowchart TB
    accTitle: Keputusan pengenalan Autopilot
    accDescr: Pada skala pengadaan beberapa hingga belasan unit per tahun, operasional Entra join manual di OOBE tidak menimbulkan kerugian nyata, dan Autopilot cukup ditambahkan belakangan ketika jumlah pengadaan bertambah dan penyiapan otomatis tanpa operator bernilai
    scale{"Skala pengadaan tahunan?"} -->|beberapa hingga belasan| manual["Entra join manual di OOBE"]
    scale -->|jika jumlah bertambah| ap["Otomatis tanpa operator dengan Autopilot"]
    ap -.-> later["Ditambahkan setelah ②③ rapi"]

Gambar 18: Selama skala pengadaan kecil, Entra join manual cukup; Autopilot bisa ditambahkan belakangan.

8.4. Kesalahpahaman “semua harus ke Intune”

Terakhir bukan soal teknis, melainkan anggapan. Koeksistensi mesin Entra join dan mesin domain-joined adalah konfigurasi yang didukung secara resmi,² dan “AD masih ada = migrasi gagal” tidak berlaku. Perusahaan yang beriringan beberapa tahun dengan beberapa pengaturan tersisa di GPO tidak jarang, dan meski begitu kondisi “semua PC baru dikelola cloud, dan pengendalian berlaku juga di luar kantor” punya nilai besar. Utamakan langkah maju kecil yang bisa ditarik mundur, bukan keindahan migrasi total.

flowchart TB
    accTitle: Nilai beriringan tanpa memaksa migrasi total
    accDescr: AD yang tersisa bukan berarti migrasi gagal; meski beriringan beberapa tahun dengan pengaturan tersisa di GPO, kondisi semua PC baru dikelola cloud dan pengendalian berlaku juga di luar kantor punya nilai besar
    miscon["AD tersisa berarti migrasi gagal?"] -->|bukan begitu| run["Beriringan beberapa tahun dengan GPO tersisa"]
    run --> value["PC baru terkendali juga di luar kantor"]
    value -.-> forward["Utamakan langkah maju kecil"]

Gambar 19: Meski beriringan dengan AD yang tersisa, kondisi semua PC baru dikelola cloud punya nilai besar.

9. Jawaban realistis untuk sistem informasi satu orang

Terakhir, desain operasional untuk perusahaan yang petugasnya satu orang (atau merangkap) dirangkum.

• Persempit item pengelolaan dari awal. Jika semua pengaturan era GPO dibawa masuk, inventarisasi saja sudah melelahkan. Mulai dari lima poin di bab 7② (pembaruan, enkripsi, Defender, kunci layar, LAPS), dan jadikan “desain pengurangan”: hanya menambah pengaturan ketika kebutuhan muncul. Settings catalog menyediakan ribuan pengaturan,⁷ tetapi tidak ada kewajiban memakainya.
• Tentukan satu standar PC. Pertahankan hanya satu set standar: “PC perusahaan ini memakai kumpulan kebijakan ini dan kumpulan aplikasi ini”. Pengecualian per departemen bisa dinyatakan dengan grup dan filter, tetapi semakin banyak pengecualian semakin tidak tertangani oleh satu orang.
• Minta mitra eksternal merancang dan membuat templat; operasional harian dibuat internal. Kegagalan yang mudah terjadi pada outsourcing migrasi Intune adalah menyerahkan pembangunan sepenuhnya hingga “tidak ada yang paham arti layar pengelolaan”. Minta desain awal, pembuatan templat kebijakan, dan diskusi keputusan migrasi ke pihak eksternal, dan jadikan tujuan keadaan di mana penambahan PC harian dan penyesuaian kecil kebijakan bisa dikerjakan sendiri. Dengan kata lain, pilih mitra yang mau menyerahkan sampai ke situ.
• Satu perubahan dalam satu waktu. Perubahan kebijakan dilakukan satu per satu, lalu hasilnya dikonfirmasi di laporan Intune (status penerapan kebijakan dan kegagalan penugasan) sebelum maju ke berikutnya. Sinkron MDM berperiode sekitar 8 jam,³ dan sebagian besar “belum berlaku” bukan kerusakan melainkan soal waktu.

flowchart TB
    accTitle: Siklus operasional perubahan kebijakan
    accDescr: Perubahan kebijakan dilakukan satu per satu, status penerapan dikonfirmasi di laporan Intune, lalu maju ke perubahan berikutnya. Sebagian besar yang belum berlaku terselesaikan dengan menunggu sinkron berperiode sekitar 8 jam
    change["Lakukan hanya satu perubahan kebijakan"] --> report["Konfirmasi status penerapan di laporan"]
    report --> next["Jika tidak ada masalah, ke perubahan berikutnya"]
    next --> change
    report -.-> wait["Sebagian besar belum berlaku adalah menunggu sinkron"]

Gambar 20: Perubahan kebijakan dilakukan satu per satu, hasil dikonfirmasi di laporan, lalu maju ke berikutnya.

10. Ringkasan

• GPO adalah mekanisme yang mengasumsikan domain controller terjangkau, dan secara struktural tidak sampai ke PC di luar kantor. Intune (MDM) menyinkronkan lewat internet, sehingga menyelesaikan isu ini dari akarnya.
• Migrasi bukan semua-atau-tidak-sama-sekali. Mesin Entra join dan mesin domain-joined bisa hidup berdampingan, dan migrasi bertahap yang beralih ke Entra join+Intune mulai dari PC baru adalah jawaban realistis untuk usaha kecil dan menengah. Karena tidak ada jalur konversi mesin yang ada, penggantian pada siklus penggantian adalah pola yang mapan.
• Intune realistis dimulai dengan Microsoft 365 Business Premium (Intune Plan 1+Entra ID P1) di usaha kecil dan menengah. Namun komposisi paket terus berubah, dan ada fitur seperti Remediations yang mensyaratkan lisensi tingkat atas, jadi jangan menelan artikel ini per Agustus 2026 begitu saja; konfirmasikan sumber primer.
• Inventarisasi GPO yang berjalan bisa diotomatiskan dengan Group Policy analytics. Pengaturan yang bisa dimigrasi dikonversi ke Settings catalog, dan skrip logon atau distribusi printer tanpa padanan diganti dengan distribusi skrip, dikemas jadi aplikasi, atau dihentikan operasionalnya. Perhatikan bahwa pada GPO berbahasa Jepang tingkat dukungan bisa tidak akurat.
• Migrasi maju dalam lima tahap “percontohan → kebijakan dasar → distribusi aplikasi → penggantian alami PC yang ada → penyusutan peran AD”, dan syarat selesai setiap tahap ditentukan lebih dulu.
• Bentrok penerapan ganda secara default dimenangkan GPO. MDMWinsOverGP adalah mekanisme terbatas Policy CSP, jadi prinsipnya “jangan sebar pengaturan yang sama dari keduanya”.
• Saat estimasi penggantian server muncul adalah waktu terbaik menimbang migrasi ini. Sebelum “AD satu siklus lagi”, pertimbangkan di mana PC lima tahun ke depan akan dipakai.

Artikel terkait

• Pengantar praktis Group Policy (GPO) — mekanisme, konfirmasi penerapan, dan pembagian peran dengan Intune
• Manajemen Windows Update setelah WSUS deprecated — cara memilih WUfB, Autopatch, dan Intune
• Jawaban realistis setelah dukungan Windows 10 berakhir — tabel keputusan ESU, LTSC, dan penggantian
• Mengotomatiskan kitting PC dengan winget + PowerShell — membuat prosedur bisa dijalankan
• Panduan praktis BitLocker — enkripsi drive dimulai dari pengelolaan kunci pemulihan
• Panduan praktis Windows LAPS — menghentikan kata sandi administrator lokal yang sama di semua PC

Area konsultasi terkait

Di Komura Soft, kami menangani rancangan migrasi bertahap dari lingkungan AD+GPO ke Entra ID+Intune (inventarisasi GPO yang berjalan, arah reproduksi kebijakan, rencana percontohan), perbandingan penggantian server versus migrasi cloud, dan konsultasi migrasi yang memanfaatkan aplikasi bisnis serta aset kitting yang ada. Boleh dimulai dari menimbang bersama “apakah server AD perlu dibeli sekali lagi”.

• Konsultasi teknis dan tinjauan rancangan
• Pemanfaatan aset yang ada dan dukungan migrasi
• 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 pindah dari GPO ke Intune, apakah semua pengaturan Group Policy yang dipakai sekarang bisa direproduksi?

Tidak semuanya. Settings catalog Intune memuat ribuan pengaturan Windows, termasuk yang berasal dari ADMX. Sebagian besar pengaturan keamanan dan pembatasan bisa dipindahkan, tetapi ada yang tidak punya padanan MDM—misalnya pemetaan drive lewat skrip logon atau distribusi printer secara massal. Jika ekspor XML GPO yang berjalan diimpor ke Group Policy analytics di Intune, setiap pengaturan dikelompokkan menurut kesiapan migrasi (Ready for migration / Not supported / Deprecated). Pengaturan tanpa padanan ditangani dengan distribusi skrip PowerShell, dikemas menjadi aplikasi, atau dengan menghentikan pengaturan itu.

Lisensi mana yang diperlukan untuk memakai Intune?

Dasarnya adalah Microsoft Intune Plan 1. Bisa dilanggan 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, sehingga kombinasi kebijakan kepatuhan dan Conditional Access pun bisa dipakai. Beberapa fitur, seperti Remediations, secara terpisah mensyaratkan lisensi kelas Windows Enterprise E3/E5. Komposisi paket sering berubah, jadi konfirmasikan isi terbaru di halaman lisensi resmi Microsoft sebelum berkontrak (artikel ini per Agustus 2026).

Apakah server AD harus segera dinonaktifkan?

Tidak. PC yang dikelola dengan Entra join+Intune dan PC yang dikelola dengan domain join AD+GPO bisa hidup berdampingan di jaringan kantor yang sama. Migrasi bertahap—menyisakan AD untuk autentikasi file server dan sistem bisnis yang ada, lalu hanya Entra-join PC baru—lebih realistis. Sebaliknya, tidak ada cara resmi untuk "mengonversi" PC domain-joined yang ada menjadi Entra join; wipe (inisialisasi) diperlukan, jadi pola yang mapan adalah mengganti mesin lama pada siklus penggantian perangkat. Cukup pertimbangkan penonaktifan AD setelah GPO kosong dan peran yang tersisa sudah diinventarisasi.

Mengapa Group Policy tidak diterapkan pada PC kerja dari rumah?

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

Jika pengaturan yang sama disebar dari GPO dan Intune, mana yang diutamakan?

Secara default, pengaturan yang bentrok dimenangkan oleh sisi Group Policy. Menyetel kebijakan MDMWinsOverGP ke 1 membuat sisi MDM (Intune) yang menang, tetapi mekanisme itu hanya berlaku untuk pengaturan di bawah Policy CSP; 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 setelah pengaturan pindah ke Intune hapus dari GPO asal agar tidak dikelola 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.