Từ Group Policy sang Intune — hướng dẫn di chuyển quản lý thiết bị cho doanh nghiệp vừa và nhỏ

“Cửa sổ hỗ trợ máy chủ hết hạn, nên chúng tôi đang lên kế hoạch thay. Nhưng chúng tôi mất tin rằng nên mua thêm một máy chủ AD và chạy domain cùng Group Policy thêm một chu kỳ nữa (năm năm).” “Group Policy chúng tôi quyết ở văn phòng không bao giờ áp lên laptop dùng cho làm việc từ xa. Nếu nó chỉ áp khi họ kết nối VPN, chúng tôi có thật sự nói là đang quản chúng không?” — Vài năm gần đây, kiểu tư vấn này từ khách doanh nghiệp vừa và nhỏ tăng đều.

Bối cảnh là thay đổi cách người ta làm việc. Active Directory (AD) tại chỗ và Group Policy (GPO) là cơ chế giả định “PC nằm trên LAN công ty và luôn tới được domain controller”. Nay PC mang về nhà và làm việc từ xa là chuẩn, chính giả định đó đã vỡ. Thêm nữa, WSUS — lâu nay là mặc định cho quản lý cập nhật — bị ngừng phát triển vào tháng 9 năm 2024,¹ và trọng tâm quản lý thiết bị của Microsoft đã chuyển sang Entra ID plus Intune (MDM).

flowchart TB
        accTitle: Giả định vỡ và sự dịch chuyển trọng tâm
        accDescr: AD và GPO giả định PC nằm trên LAN công ty và luôn tới được domain controller, nhưng PC mang về nhà và làm việc từ xa thành chuẩn đã làm vỡ giả định đó, và với WSUS bị ngừng phát triển trọng tâm quản lý đã chuyển sang Entra ID và Intune
        adgpo["AD tại chỗ và GPO"] -.-> premise["Giả định: DC luôn tới được"]
        work["PC mang về nhà và làm việc từ xa thành chuẩn"] --> broken["Chính giả định đã vỡ"]
        premise --> broken
        wsus["WSUS bị ngừng phát triển"] --> shift["Trọng tâm chuyển sang Entra ID+Intune"]
        broken --> shift

Hình 1: Giả định AD+GPO rằng “PC nằm trên LAN công ty” vỡ khi cách làm việc đổi, và trọng tâm quản lý chuyển sang Entra ID+Intune.

Dù vậy, di chuyển không phải tất cả hoặc không gì. PC quản bằng Entra join plus Intune và PC AD domain-joined plus GPO có thể cùng tồn tại trong cùng công ty,² và di chuyển theo giai đoạn là khả thi: để AD lại cho máy chủ tệp, và chuyển PC mới sang quản lý Intune. Hướng tới nhân viên IT và chủ doanh nghiệp vừa và nhỏ, bài viết này sắp xếp — dựa trên nguồn gốc như Microsoft Learn tính tới tháng 8 năm 2026 — khác biệt cách GPO và MDM hoạt động, cấu hình tiên quyết, giấy phép, cách kiểm kê GPO hiện tại, kịch bản di chuyển theo giai đoạn, và các cạm bẫy.

1. Kết luận trước

• GPO được áp khi PC kết nối mạng miền; Intune (MDM) đồng bộ qua internet. Bài toán “thiết lập không bao giờ tới PC nhà” về cấu trúc không phát sinh với MDM. Đồng bộ trạng thái ổn định khoảng mỗi 8 giờ, và một đồng bộ do thông báo cũng chạy khi chính sách đổi.³
• Di chuyển không phải tất cả hoặc không gì; di chuyển theo giai đoạn giả định cùng tồn tại là câu trả lời thực tế. Bản thân Microsoft khuyến nghị Entra-join PC mới, và để PC domain-joined sẵn có làm hybrid join rồi thay chúng theo chu kỳ làm mới phần cứng.²
• Bạn có thể đăng ký Intune riêng, nhưng với doanh nghiệp vừa và nhỏ đường thực tế là dùng Intune Plan 1 kèm trong Microsoft 365 Business Premium (tính tới tháng 8 năm 2026). Thành phần gói cứ đổi, nên luôn xác nhận nguồn gốc trước khi ký.⁴⁵
• Để kiểm kê GPO hiện tại, dùng Group Policy analytics có sẵn trong Intune. Nhập bản xuất XML GPO và từng thiết lập được phân loại theo việc có thể di chuyển không; thiết lập có đối ứng có thể chuyển thành chính sách Settings catalog.⁶
• Các việc chính thời GPO gần như đều có đối ứng Intune. Administrative Templates ánh xạ sang Settings catalog,⁷ WSUS sang Windows Update for Business, khóa khôi phục BitLocker sang lưu trong Entra ID,⁸ mật khẩu quản trị viên cục bộ sang Windows LAPS,⁹ và triển khai ứng dụng sang ứng dụng Win32 (.intunewin)¹⁰ và ứng dụng Microsoft Store (dựa trên winget).¹¹
• Những thứ cổ điển không chuyển nguyên vậy là tập lệnh đăng nhập, ánh xạ ổ, và triển khai máy in. Bạn thay chúng bằng triển khai tập lệnh PowerShell,¹² Remediations (trước đây Proactive remediations),¹³ biến việc thành ứng dụng, hoặc “dừng thực hành đó”.
• Đừng triển khai cùng một thiết lập từ cả GPO lẫn MDM. Theo mặc định GPO thắng xung đột. Đặt MDMWinsOverGP thành 1 làm MDM thắng, nhưng nó chỉ áp cho thiết lập Policy CSP.¹⁴
• Máy domain-joined và máy Entra-joined có thể cùng tồn tại, và máy Entra-joined có thể truy cập máy chủ tệp tại chỗ. Ngừng AD ngay không phải điều kiện của di chuyển.²

Trong một câu: câu hỏi “chúng ta có nên thay máy chủ AD thêm một chu kỳ nữa không” nên được đặt lại thành “trong năm năm tới, chúng ta sẽ dùng gì để quản PC ngồi ngoài văn phòng” và quyết trên cơ sở đó.

flowchart LR
        accTitle: Đặt lại câu hỏi bạn nên quyết
        accDescr: Câu hỏi có thay máy chủ AD thêm một chu kỳ nữa không nên được đặt lại thành câu hỏi bạn sẽ dùng gì để quản PC ngoài trụ sở trong năm năm tới
        q1["Thay máy chủ AD thêm một chu kỳ nữa?"] -->|Đặt lại| q2["Trong 5 năm tới, cái gì quản PC ngoài trụ sở?"]

Hình 2: Đặt lại câu hỏi thay máy chủ thành “trong năm năm tới, chúng ta sẽ dùng gì để quản PC ngồi ngoài văn phòng” và quyết trên cơ sở đó.

2. GPO và MDM khác nhau thế nào — so cơ chế áp dụng

Trước hết, so hai bên trên cùng một sân. Bản thân cơ chế GPO (thứ tự áp LSDOU, cách xác nhận bằng gpupdate/gpresult) được trình bày sâu trong “Hướng dẫn thực tế Group Policy (GPO)”, nên ở đây chúng ta thu hẹp vào khác biệt quan trọng cho quyết định di chuyển.

Các hàng quan trọng nhất cho quyết định di chuyển là hàng đầu và hàng thứ ba. GPO không tới PC nhà không phải lỗi — đó là vì giả định thiết kế “PC ngồi nơi nó tới được domain controller” không còn khớp cách người ta làm việc hôm nay. Bạn có thể giữ GPO sống bằng cách buộc always-on VPN trên mọi nhân viên, nhưng đó cũng là lựa chọn gánh bảo trì một mảnh hạ tầng riêng: nền tảng VPN.

flowchart TB
        accTitle: Lựa chọn giữa giữ GPO sống và di chuyển sang MDM
        accDescr: GPO không tới PC nhà vì giả định thiết kế không còn khớp cách người ta làm việc hôm nay, và đường buộc always-on VPN để giữ GPO sống là lựa chọn gánh bảo trì một mảnh hạ tầng riêng, nền tảng VPN
        gap["Giả định thiết kế không còn khớp cách người ta làm việc"] --> sel{"Bạn đáp thế nào?"}
        sel -->|Giữ sống bằng always-on VPN| vpn["Tiếp tục GPO"]
        sel -->|Di chuyển sang MDM| mdm["Quản qua internet"]
        vpn --> cost["Bạn gánh bảo trì hạ tầng khác"]

Hình 3: Đường giữ GPO sống bằng always-on VPN cũng là lựa chọn gánh bảo trì một mảnh hạ tầng riêng: nền tảng VPN.

Mặt khác, khoảng đồng bộ MDM (khoảng 8 giờ) thô hơn làm mới định kỳ của GPO (khoảng 90 phút), và cảm giác “triển khai là áp ngay” không theo. Khi bạn gán hoặc đổi một chính sách, thông báo được gửi tới thiết bị và nó đồng bộ tương đối nhanh,³ nhưng các kiểm soát đòi tính tức thời (chặn khẩn cấp, và tương tự) cần được thiết kế quanh khoảng đồng bộ.

flowchart TB
        accTitle: GPO và MDM áp chính sách thế nào
        accDescr: GPO chỉ áp khi PC kết nối được domain controller nội bộ, nên PC nhà phụ thuộc VPN; Intune đồng bộ qua internet khoảng mỗi 8 giờ và cũng đồng bộ theo thông báo khi chính sách đổi, nên nó tới PC ở bất cứ đâu
        officepc["PC nội bộ"] --> dc["Domain controller"]
        officepc -.-> when["Khởi động và đăng nhập"]
        when -.-> when2["cộng làm mới định kỳ"]
        homepc["PC nhà"] --> vpn{"Tới DC qua VPN?"}
        vpn -->|Có| dc
        vpn -->|Không| miss["Chính sách không bao giờ tới"]
        anypc["PC ở bất cứ đâu"] --> intune["Dịch vụ Intune"]
        anypc -.-> every["Đồng bộ khoảng mỗi 8 giờ"]
        intune -.-> notify["Đổi do thông báo"]
        dc ~~~ homepc
        miss ~~~ anypc

Hình 4: GPO chỉ áp khi PC tới được domain controller; Intune đồng bộ qua internet bất kể vị trí.

3. Sắp các tiên quyết — ba dạng: Domain Join, Hybrid Join, và Entra Join

Có ba dạng “một PC Windows gia nhập công ty thế nào”, và cái bạn chọn quyết công cụ quản lý nào bạn dùng được.²

Hybrid join là dạng để “cho PC domain-joined sẵn có một danh tính đám mây”, và cho phép bạn bắt đầu dùng Intune và Conditional Access trong khi giữ tài sản sẵn có. Microsoft, tuy nhiên, khuyến nghị không lấy hybrid join làm đích cuối, và Entra-join PC mới cùng PC thay.²

Có một ràng buộc cần nắm. Không có cách Microsoft hỗ trợ để chuyển một PC domain-joined sẵn có (kể cả hybrid join) thành Entra join; cần đặt lại Windows (wipe). Đó là vì sao Microsoft cũng khuyến nghị chuyển sang Entra join lúc làm mới phần cứng hoặc cài lại OS.²

flowchart TB
        accTitle: Ba dạng join và các đường di chuyển
        accDescr: Một PC chỉ-AD-domain-join có thể được đăng ký trong Entra ID nữa và trở thành hybrid join, nhưng không có cách chuyển trực tiếp sang Entra join và cần wipe, nên Entra-join PC mới và PC thay được khuyến nghị
        adonly["Chỉ AD domain join（GPO）"] -->|Cũng đăng trong Entra ID| hybrid["hybrid join（GPO và Intune）"]
        hybrid -.->|Không có đường chuyển trực tiếp| wipe["Cần wipe（đặt lại）"]
        wipe --> entra["Entra join（Intune）"]
        newpc["PC mới và PC thay"] -->|Được khuyến nghị| entra

Hình 5: Không có cách được hỗ trợ để chuyển máy domain-joined sẵn có thành Entra join; mẫu ổn định là chuyển từ PC mới và PC thay.

Từ trên, một đích thực tế cho doanh nghiệp vừa hoặc nhỏ có thể nói như sau.

1. Quản PC mới và PC thay bằng Entra join plus Intune
2. Để PC domain-joined sẵn có yên và để chúng được thay tự nhiên theo chu kỳ làm mới phần cứng
3. Để AD lại tạm thời cho các vai trò còn lại như xác thực máy chủ tệp, và làm trống nội dung GPO theo giai đoạn

flowchart TB
        accTitle: Cấu hình cùng tồn tại trong di chuyển theo giai đoạn
        accDescr: Máy Entra-joined và máy domain-joined có thể cùng tồn tại trong cùng môi trường công ty; cái trước quản bằng Intune và cái sau bằng GPO, trong khi AD được để lại cho các vai trò còn lại và chỉ nội dung GPO được làm trống theo giai đoạn
        env["Cùng môi trường công ty"] --> ejoin["Máy Entra-joined"]
        env --> djoin["Máy domain-joined"]
        ejoin --> intune["Quản bằng Intune"]
        djoin --> gpo["Quản bằng GPO"]
        gpo -.-> shrink["Làm trống nội dung theo giai đoạn"]
        env -.-> ad["Để AD cho các vai trò còn lại"]

Hình 6: Máy Entra-joined và máy domain-joined có thể cùng tồn tại trong cùng môi trường công ty, và AD được để lại tạm thời cho các vai trò còn lại.

Máy Entra-joined và máy domain-joined có thể cùng tồn tại trong cùng môi trường, và máy Entra-joined có thể truy cập tài sản nội bộ như máy chủ tệp tại chỗ.² Đăng nhập một lần đó, tuy nhiên, có hai tiên quyết. (1) Người dùng là danh tính lai được đồng bộ từ AD tại chỗ bằng Entra Connect (hoặc Cloud Sync) (người dùng chỉ tồn tại trên đám mây không lấy được thông tin xác thực Kerberos/NTLM của AD), và (2) PC có thể tới mạng tới domain controller (từ ngoài trụ sở, cần VPN hoặc tương tự).¹⁵ Trong kế hoạch di chuyển, hãy xác nhận trước rằng không có người dùng hoặc kịch bản dùng nào thất bại hai điểm này.

flowchart TB
        accTitle: Tiên quyết SSO từ máy Entra-joined tới tài sản tại chỗ
        accDescr: Để truy cập máy chủ tệp tại chỗ từ máy Entra-joined, hai tiên quyết phải được thỏa: danh tính lai đồng bộ bằng Entra Connect hoặc tương tự, và khả năng tới domain controller
        pc["Máy Entra-joined"] --> cond1{"Danh tính lai?"}
        cond1 -->|Có| cond2{"Nó tới được DC?"}
        cond1 -->|Không| ng1["Không lấy được thông tin xác thực AD"]
        cond2 -->|Có| ok["SSO tới máy chủ tệp"]
        cond2 -->|Không| ng2["Từ ngoài trụ sở, cần VPN hoặc tương tự"]

Hình 7: SSO từ máy Entra-joined tới tài sản tại chỗ có hai tiên quyết: danh tính lai và khả năng tới domain controller.

4. Giấy phép và chi phí — gói nào gồm Intune (tính tới tháng 8 năm 2026)

Giấy phép Intune nền là Microsoft Intune Plan 1, được chào vừa như thuê bao độc lập vừa gói vào các gói Microsoft 365 khác nhau.⁴

Điều quan trọng với doanh nghiệp vừa và nhỏ là Microsoft 365 Business Premium, cho tới 300 người dùng, gồm Intune Plan 1.⁵ Business Premium cũng gồm Microsoft Entra ID P1 và Microsoft Defender for Business, nên cấu hình chính sách tuân thủ plus Conditional Access mô tả sau có thể hoàn tất trong gói này. Business Standard/Basic, mặt khác, không gồm Intune. Khi bạn bước từ hợp đồng chỉ thư-và-Office sang quản lý thiết bị, chi phí nâng lên Business Premium là chi phí hiệu quả của việc đưa Intune vào.

flowchart TB
        accTitle: Các gói SME liên hệ với Intune thế nào
        accDescr: Business Premium cho tới 300 người dùng gồm Intune Plan 1, Entra ID P1, và Defender for Business và hoàn tất tới Conditional Access, nhưng Business Standard/Basic không gồm Intune
        bp["Business Premium"] -.-> cap["Tới 300 người dùng"]
        bp --> intune["Intune Plan 1"]
        bp --> p1["Entra ID P1"]
        bp --> dfb["Defender for Business"]
        p1 --> ca["Hoàn tất tới Conditional Access"]
        dfb ~~~ std["Business Standard/Basic"]
        std --> noint["Không gồm Intune"]

Hình 8: Business Premium gồm Intune Plan 1 và Entra ID P1; Business Standard/Basic không gồm Intune.

Có hai lưu ý.

• Thành phần gói thay đổi thường xuyên. Ngay vào 2026, các thay đổi phân phối lại tính năng Intune Suite vào các gói Microsoft 365 cao hơn (E3/E5 và tương tự) vẫn đang diễn ra, và rà soát những gì được gói tiếp tục.⁴ Coi mục này tính tới tháng 8 năm 2026, và trước khi ký luôn xác nhận thông tin mới nhất trên các trang giấy phép và giá Microsoft.
• Một số tính năng bạn mở được từ UI Intune đòi giấy phép riêng. Ví dụ điển hình là Remediations, mô tả sau: nó đòi giấy phép hạng Windows Enterprise E3/E5 (gói trong Microsoft 365 E3/E5 và tương tự) và không có trong phạm vi Business Premium.¹³

So chi phí không phải “chi phí thuê bao Intune” versus “không”. Ở phía GPO bạn đã trả thay phần cứng máy chủ AD, giấy phép Windows Server và CAL, chi phí dựng, năm năm bảo trì, sao lưu, và ứng phó sự cố. So đúng là đặt báo giá thay máy chủ cạnh năm năm Business Premium, rồi tính thêm khác biệt năng lực “quản lý có tới PC ngoài trụ sở không”.

flowchart TB
        accTitle: Cách nghĩ đúng về so chi phí
        accDescr: Phía GPO cũng phát sinh chi phí như thay máy chủ AD, giấy phép, và năm năm bảo trì, nên đặt báo giá thay máy chủ cạnh năm năm Business Premium rồi quyết với khác biệt năng lực quản lý có tới PC ngoài trụ sở không được tính vào
        gpocost["Chi phí tiếp tục GPO"] --> hw["Thay máy chủ, giấy phép, CAL"]
        gpocost --> ops["Dựng, bảo trì, sao lưu"]
        bpcost["Chi phí di chuyển sang Intune"] --> sub["Năm năm Business Premium"]
        hw --> diff["Đặt chênh năm năm cạnh nhau"]
        ops --> diff
        sub --> diff
        diff --> ability["Tính vào việc quản lý có tới PC ngoài trụ sở không"]

Hình 9: Đặt báo giá thay máy chủ cạnh năm năm Business Premium, và quyết với khác biệt năng lực quản PC ngoài trụ sở được tính vào.

5. Cách làm trong Intune những gì trước đây bạn làm bằng GPO

Với từng việc chính của vận hành GPO, đối ứng Intune được hiện trong bảng ánh xạ.

Vài ghi chú.

• Settings catalog là màn hình tương ứng với “bản đám mây của trình soạn GPO”, và bản thân Microsoft định vị nó là “đích di chuyển tự nhiên khi bạn muốn cấu hình chi tiết như GPO tại chỗ”. Nó gồm các chính sách dựa trên ADMX (bản MDM của thiết lập định nghĩa trong ADMX), và cũng có tính năng (xem trước) nhập ADMX bên thứ ba.⁷
• Chính sách tuân thủ plus Conditional Access là ý tưởng GPO không có. Bạn định nghĩa điều kiện tuân thủ như “BitLocker bật, OS cập nhật, Defender chạy” và có thể chặn truy cập Microsoft 365 từ thiết bị không đạt. Conditional Access là tính năng Entra ID P1 và nằm trong Business Premium.¹⁶
• Remediations đã đổi tên từ Proactive remediations. Đó là cơ chế định kỳ chạy cặp detect-script plus remediate-script, và có thể thay loại vận hành GPO “sửa gì đó mỗi lần đăng nhập”, nhưng như đã nói nó đòi giấy phép hạng Windows Enterprise E3/E5.¹³ Trong phạm vi Business Premium, thay thế thực tế là kết hợp platform scripts (chạy khi tập lệnh hoặc gán đổi, và thử lại khi thất bại)¹² với quy tắc phát hiện ứng dụng Win32.
• Các lựa chọn chi tiết cho quản lý cập nhật (quyết giữa WUfB, Autopatch, và tiếp tục WSUS) được trình bày trong “Quản lý Windows Update sau khi WSUS ngừng phát triển”, và thiết kế BitLocker cùng LAPS trong “Hướng dẫn thực tế BitLocker” và “Hướng dẫn thực tế Windows LAPS” lần lượt.

flowchart TB
        accTitle: Luồng chính sách tuân thủ và Conditional Access
        accDescr: Chính sách tuân thủ chỉ đánh giá trạng thái tuân thủ của thiết bị đối với các điều kiện tuân thủ; chỉ khi một chính sách Conditional Access đòi thiết bị tuân thủ thì thiết bị tuân thủ được phép và thiết bị không tuân thủ bị chặn
        policy["Định nghĩa điều kiện tuân thủ"] -.-> cond["BitLocker bật, OS cập nhật, và tương tự"]
        policy --> state["Đánh giá trạng thái tuân thủ của thiết bị"]
        state --> ca["Conditional Access đòi tuân thủ"]
        ca -->|Tuân thủ| allow["Truy cập Microsoft 365 được phép"]
        ca -->|Không tuân thủ| block["Truy cập bị chặn"]

Hình 10: Đánh giá trạng thái tuân thủ là việc của chính sách tuân thủ; chặn là việc của Conditional Access. Chỉ khi kết hợp thì việc chặn có hiệu lực.

6. Kiểm kê GPO hiện tại — sắp bằng Group Policy Analytics

Việc thật sự đầu tiên của kế hoạch di chuyển là kiểm kê GPO hiện tại. Intune có tính năng riêng, Group Policy analytics, có thể phân loại, theo từng thiết lập, “MDM có thay cái này được không” mà bạn không phải đọc GPO bằng tay.⁶

Các bước như sau.⁶

1. Mở Group Policy Management Console (GPMC.msc) trên domain controller hoặc tương tự, chuột phải GPO mục tiêu → Save Report và xuất thành tệp XML (4 MB trở xuống mỗi tệp)
2. Trong trung tâm quản trị Intune, vào Devices → Group Policy analytics và nhập XML (chọn nhiều được phép)
3. Sau phân tích tự động, từng GPO hiện phần trăm hỗ trợ MDM (tỷ lệ thiết lập có tương đương trong Intune)
4. Trong báo cáo Group policy migration readiness, xác nhận phân loại theo từng thiết lập: Ready for migration / Not supported / Deprecated
5. Thiết lập Ready for migration có thể chuyển nguyên thành chính sách Settings catalog và triển khai

flowchart TB
        accTitle: Luồng kiểm kê bằng Group Policy analytics
        accDescr: Xuất GPO dạng XML từ GPMC và nhập vào Intune; phần trăm hỗ trợ MDM và mức sẵn sàng di chuyển theo từng thiết lập được hiện, và thiết lập Ready for migration có thể chuyển thành chính sách Settings catalog
        export["Xuất GPO dạng XML từ GPMC"] --> import["Nhập vào Intune"]
        import --> rate["Phần trăm hỗ trợ MDM được hiện"]
        rate --> report["Báo cáo mức sẵn sàng di chuyển"]
        report --> ready["Ready for migration"]
        report --> notsup["Not supported"]
        report --> dep["Deprecated"]
        ready --> convert["Chuyển thành chính sách Settings catalog"]

Hình 11: Từ xuất XML qua nhập, phân loại theo từng thiết lập, và chuyển sang Settings catalog — đó là luồng Group Policy analytics.

Có một lưu ý quan trọng trong môi trường tiếng Nhật. Phân tích thiết lập không-ADMX trong Group Policy analytics chỉ tiếng Anh; nhập GPO chứa thiết lập bằng ngôn ngữ khác tiếng Anh có thể làm phần trăm hỗ trợ MDM không chính xác.⁶ Coi phần trăm hỗ trợ như giá trị tham chiếu thô, và phán cuối từ danh sách theo từng thiết lập.

flowchart TB
        accTitle: Lưu ý khi phân tích GPO tiếng Nhật
        accDescr: Phân tích thiết lập không-ADMX trong Group Policy analytics chỉ tiếng Anh, nên GPO chứa thiết lập tiếng Nhật có thể làm phần trăm hỗ trợ MDM không chính xác; coi phần trăm như tham chiếu thô và phán cuối từ danh sách theo từng thiết lập
        jgpo["GPO chứa thiết lập tiếng Nhật"] --> limit["Phân tích không-ADMX chỉ tiếng Anh"]
        limit --> rate["Phần trăm hỗ trợ có thể không chính xác"]
        rate --> use1["Coi phần trăm như tham chiếu thô"]
        rate --> use2["Phán cuối từ danh sách theo từng thiết lập"]

Hình 12: Trong GPO tiếng Nhật phần trăm hỗ trợ MDM có thể không chính xác, nên phán cuối từ danh sách theo từng thiết lập.

Trong thực tế, tách kết quả phân loại thành ba đống.

1. Thiết lập bỏ — thiết lập thời Internet Explorer, thiết lập cho hệ thống đã nghỉ, thiết lập không ai giải thích được lý do. Phần lời lớn nhất của kiểm kê, thực ra, là được phép vứt đống này. Một GPO chạy mười năm có một lượng kế thừa đáng kể chồng lên.
2. Thiết lập chuyển sang Intune — những cái trong Ready for migration mà bạn vẫn cần. Chuyển sang Settings catalog và kiểm với nhóm thí điểm.
3. Thiết lập bạn thiết kế thay — những cái trong Not supported mà bạn vẫn cần. Ví dụ điển hình và hướng thay như sau.

flowchart TB
        accTitle: Ba đống kết quả kiểm kê
        accDescr: Kết quả kiểm kê được xử lý thành ba đống: thiết lập bỏ, thiết lập chuyển sang Intune và kiểm, và thiết lập không có đối ứng mà bạn thiết kế thay
        result["Kết quả phân loại"] --> discard["Thiết lập bỏ"]
        result --> more{"Chuyển hay thay?"}
        more --> move["Chuyển sang Intune"]
        more --> alt["Thiết kế thay"]
        discard -.-> legacy["Thanh lý phần kế thừa"]
        move --> pilot["Settings catalog"]
        pilot -.-> pilotN["rồi kiểm"]
        alt --> design["Tập lệnh hoặc làm ứng dụng"]

Hình 13: Tách kết quả kiểm kê thành ba đống “bỏ”, “chuyển sang Intune”, và “thiết kế thay”.

7. Kịch bản di chuyển theo giai đoạn — năm giai đoạn và tiêu chí thoát

Tách toàn bộ thành năm giai đoạn và đặt tiêu chí thoát lên từng cái. Quyết trước “khi nào ta nói xong” là mẹo giữ một cuộc di chuyển IT một người khỏi khựng.

flowchart TB
        accTitle: Kịch bản di chuyển năm giai đoạn
        accDescr: Tiến theo giai đoạn từ thí điểm qua chính sách nền, triển khai ứng dụng, thay PC sẵn có theo chu kỳ làm mới phần cứng, và thu hẹp vai trò AD, rồi cuối cùng đưa thiết lập triển khai qua GPO về không
        s1["（1）Thí điểm"] --> s2["（2）Chính sách nền"]
        s2 --> s3["（3）Triển khai ứng dụng"]
        s3 --> s4["（4）Thay tự nhiên PC sẵn có"]
        s4 --> s5["（5）Thu hẹp vai trò AD"]
        s5 -.-> goal["Thiết lập triển khai qua GPO là không"]

Hình 14: Đẩy di chuyển theo năm giai đoạn từ thí điểm tới thu hẹp vai trò AD, và quyết tiêu chí thoát từng giai đoạn từ trước.

Các điểm then của từng giai đoạn.

• (1) Thí điểm bắt đầu bằng một PC bạn vẫn sẽ mua — PC nhân sự mới tiếp theo, máy thay hỏng/sửa, và tương tự. Bắt đầu từ máy mới có lợi là bạn bắt đầu với đầu tư thêm bằng không, và nếu thất bại bạn có thể wipe rồi làm lại. Khi số lượng tăng, cân nhắc dùng Windows Autopilot để tự động hóa từ OOBE (thiết lập ban đầu) tới Entra join plus đăng Intune.²
• Trong (2) Chính sách nền, đừng cố tái tạo mọi thiết lập GPO. Trước hết thu hẹp vào năm thứ: cập nhật, mã hóa, Defender, khóa màn hình, và LAPS, và hình dung trạng thái tuân thủ bằng chính sách tuân thủ. Bật “chỉ thiết bị tuân thủ” trong Conditional Access tới sau khi bạn xác nhận không có dương tính giả trong thí điểm.¹⁶
• (3) Triển khai ứng dụng liền mạch với tự động hóa cấp phát. Nếu bạn đã có thủ tục dựa trên winget (“Tự động hóa cấp phát PC bằng winget + PowerShell”), tài sản đó có thể tái sử dụng gần như nguyên vậy như ứng dụng Store (mới) hoặc vỏ ứng dụng Win32.¹¹
• (4) PC sẵn có, như Chương 3 nói, không có đường chuyển sang Entra join, nên nguyên tắc là thay tự nhiên. Tổ chức vẫn còn kế hoạch thay Windows 10 (“Các lựa chọn thực tế sau khi Windows 10 hết hỗ trợ”) có thể tránh làm việc hai lần bằng cách đẩy việc thay đó cùng lúc với (4).
• Trong (5) Thu hẹp vai trò AD, làm trống GPO không nhất thiết nghĩa là AD ngay lập tức thừa. Nếu xác thực máy chủ tệp, tra LDAP từ ứng dụng cũ, và tương tự còn, AD tiếp tục ở dạng thu hẹp như “máy chủ xác thực”. Kiểm kê những thứ đó và đặt hạn là việc của giai đoạn này.

flowchart TB
        accTitle: Làm gì với AD sau khi GPO trống
        accDescr: Ngay cả sau khi GPO trống, nếu xác thực máy chủ tệp hoặc tra LDAP từ ứng dụng cũ còn, AD tiếp tục ở dạng thu hẹp như máy chủ xác thực, và kiểm kê vai trò còn lại cùng đặt hạn là việc của giai đoạn cuối
        gpoempty["GPO trống"] --> remain{"Còn vai trò nào?"}
        remain -->|Xác thực máy chủ tệp| keep["Tiếp tục ở dạng thu hẹp như máy chủ xác thực"]
        remain -->|Tra LDAP kế thừa| keep
        remain -->|Không còn vai trò| retire["Cân nhắc ngừng bản thân AD"]
        keep --> task["Làm tới kiểm kê và đặt hạn"]

Hình 15: Ngay cả sau khi GPO trống, nếu còn vai trò, AD tiếp tục ở dạng thu hẹp như máy chủ xác thực.

8. Các cạm bẫy

8.1. Áp kép GPO và MDM — theo mặc định GPO thắng

Trong giai đoạn di chuyển, cả GPO lẫn Intune sẽ triển khai thiết lập lên cùng một PC (máy hybrid-joined). Ở đây, khi cùng một thiết lập xung đột, Group Policy thắng theo mặc định. Đặt MDMWinsOverGP của Policy CSP thành 1 làm thiết lập phía MDM thắng và chặn thiết lập GPO tương ứng, nhưng cơ chế đó chỉ áp cho thiết lập dưới Policy CSP và không áp cho thiết lập định nghĩa trong các CSP khác như Defender CSP. Bản thân Microsoft nêu rằng nếu bạn cấu hình một thiết lập không nằm dưới MDMWinsOverGP từ cả GPO lẫn MDM, bạn vào trạng thái xung đột và không có bảo đảm bên nào thắng.¹⁴

flowchart TB
        accTitle: Thứ tự ưu tiên khi GPO và MDM xung đột
        accDescr: Nếu bạn triển khai cùng một thiết lập từ cả GPO lẫn MDM, GPO thắng theo mặc định; đặt MDMWinsOverGP thành 1 làm MDM thắng chỉ với thiết lập dưới Policy CSP, và với thiết lập trong các CSP khác không có bảo đảm bên nào thắng
        both["Triển khai cùng một thiết lập từ cả GPO lẫn MDM"] --> flag{"MDMWinsOverGP=1?"}
        flag -->|Không| gpowin["GPO thắng（mặc định）"]
        flag -->|Có| csp{"Thiết lập dưới Policy CSP?"}
        csp -->|Có| mdmwin["MDM thắng"]
        csp -->|Không| unknown["Không bảo đảm bên nào thắng"]
        both -.-> avoid["Nguyên tắc là đừng triển khai từ cả hai"]

Hình 16: Theo mặc định GPO thắng, và MDMWinsOverGP chỉ áp dưới Policy CSP. Nguyên tắc là tránh triển khai kép.

Nguyên tắc thực tế đơn giản. Đừng dựa vào kiểm soát thứ tự ưu tiên; đừng triển khai cùng một thiết lập từ cả hai. Với thiết lập bạn đã chuyển sang Intune, đưa cấu hình phía GPO tương ứng về “Not configured”, hoặc hủy liên kết GPO hẳn. Danh sách đã di chuyển ở Chương 6 cũng là sổ cái cho việc này.

8.2. Phụ thuộc tài sản tại chỗ — ổ mạng và máy in

Nhiều chỗ một cuộc di chuyển khựng không phải tính năng Intune mà là kết nối tới tài sản tại chỗ. Bản thân truy cập từ máy Entra-joined tới máy chủ tệp tại chỗ là khả thi,² nhưng nếu ánh xạ ổ và triển khai máy in phụ thuộc tập lệnh đăng nhập GPO, phương tiện triển khai đó mất trước. Quyết trong thí điểm xem gấp việc di chuyển share sang OneDrive/SharePoint hoặc thay bằng Universal Print vào giai đoạn (3), hay bắc cầu tạm bằng triển khai tập lệnh.¹²

flowchart TB
        accTitle: Thay các triển khai phụ thuộc tài sản tại chỗ
        accDescr: Nếu ánh xạ ổ và triển khai máy in phụ thuộc tập lệnh đăng nhập GPO, phương tiện triển khai đó mất trước trong di chuyển, nên quyết trong thí điểm xem đáp bằng di chuyển share sang OneDrive hoặc SharePoint, thay bằng Universal Print, hay triển khai tập lệnh tạm
        dep["Phụ thuộc tập lệnh đăng nhập"] --> lost["Phương tiện triển khai mất trong di chuyển"]
        lost --> share["Di chuyển sang OneDrive/SharePoint"]
        lost --> print["Thay bằng Universal Print hoặc tương tự"]
        lost --> script["Bắc cầu bằng triển khai tập lệnh"]
        share --> decide["Quyết hướng trong thí điểm"]
        print --> decide
        script --> decide

Hình 17: Các triển khai phụ thuộc tập lệnh đăng nhập mất phương tiện trước trong di chuyển, nên quyết cái thay trong thí điểm.

8.3. Thiết kế lại cấp phát — Autopilot không “bắt buộc”

Bạn đôi khi được khuyên đưa Windows Autopilot vào như một bộ với di chuyển Intune, nhưng ở quy mô mua vài tới hơn mười máy một năm, đăng nhập bằng tài khoản cơ quan tại OOBE và Entra-join bằng tay không gây hại thực sự. Autopilot bắt đầu có lời khi số lượng mua tăng và thiết lập không người từ lúc mở hộp có giá trị, hoặc khi bạn dùng được đăng ký thiết bị phía nhà bán lại. Thêm nó sau khi (2) và (3) đã sẵn là được; nó không phải tiên quyết của di chuyển.

flowchart TB
        accTitle: Quyết định đưa Autopilot vào
        accDescr: Ở quy mô mua vài tới hơn mười máy một năm, Entra-join bằng tay tại OOBE không gây hại thực sự; thêm Autopilot sau, khi số lượng mua đã tăng và thiết lập không người có giá trị
        scale{"Quy mô mua hàng năm là gì?"} -->|Vài tới hơn mười| manual["Entra join thủ công tại OOBE"]
        scale -->|Khi số lượng tăng| ap["Không người với Autopilot"]
        ap -.-> later["Thêm sau khi（2）và（3）đã sẵn"]

Hình 18: Khi quy mô mua còn nhỏ, Entra join thủ công đủ; Autopilot có thể thêm sau.

8.4. Ngộ nhận rằng “không ổn trừ khi mọi thứ nằm trong Intune”

Cái cuối không phải vấn đề kỹ thuật mà là vấn đề giả định. Cùng tồn tại máy Entra-joined và máy domain-joined là cấu hình được hỗ trợ chính thức,² và “AD vẫn còn = di chuyển thất bại” không đúng. Các công ty chạy hàng năm với vài thiết lập vẫn còn trong GPO không hiếm, và ngay cả khi đó vẫn có giá trị lớn ở trạng thái “mọi PC mới được quản trên đám mây, và kiểm soát cũng chạy ngoài trụ sở”. Ưu tiên bước nhỏ, đảo được hơn vẻ đẹp của một cuộc di chuyển hoàn chỉnh.

flowchart TB
        accTitle: Giá trị chạy song song mà không khăng khăng di chuyển hoàn chỉnh
        accDescr: AD còn lại không phải di chuyển thất bại; dù bạn chạy song song hàng năm với thiết lập vẫn trong GPO, vẫn có giá trị lớn ở trạng thái mọi PC mới được quản trên đám mây và kiểm soát chạy ngoài trụ sở
        miscon["AD còn lại nghĩa là di chuyển thất bại?"] -->|Không| run["Chạy song song hàng năm với GPO vẫn còn"]
        run --> value["PC mới nằm trong tầm kiểm soát ngay cả ngoài trụ sở"]
        value -.-> forward["Ưu tiên bước nhỏ"]

Hình 19: Dù chạy song song với AD vẫn còn, trạng thái mọi PC mới được quản trên đám mây có giá trị lớn.

9. Câu trả lời thực tế cho IT một người

Cuối cùng, tóm tắt thiết kế vận hành trong công ty mà người phụ trách là một (hoặc giữ vai trò đó như việc phụ).

• Thu hẹp mục quản từ đầu. Nếu cố mang mọi thiết lập thời GPO, bạn sẽ kiệt trên riêng kiểm kê. Bắt đầu từ năm thứ ở Chương 7 (2) (cập nhật, mã hóa, Defender, khóa màn hình, LAPS) và làm “thiết kế trừ” chỉ thêm thiết lập khi nhu cầu phát sinh. Settings catalog chào hàng nghìn thiết lập,⁷ nhưng bạn không bắt buộc dùng chúng.
• Quyết một ảnh PC chuẩn. Chỉ giữ một chuẩn: “PC trong công ty này là bộ chính sách này và bộ ứng dụng này”. Ngoại lệ phòng ban có thể diễn bằng nhóm và bộ lọc, nhưng ngoại lệ càng tăng, một người càng không theo kịp.
• Nhờ đối tác bên ngoài cho thiết kế và làm mẫu; giữ vận hành ngày thường trong nhà. Outsourcing di chuyển Intune dễ thất bại là trường hợp bạn ném phần dựng qua tường rồi rơi vào trạng thái “không ai hiểu các màn hình quản trị nghĩa gì”. Nhờ bên ngoài thiết kế ban đầu, làm mẫu chính sách, và bàn phản biện cho quyết định di chuyển, và lấy đích là trạng thái bạn tự thêm PC và chỉnh chính sách ngày thường. Nói ngược lại, bạn nên chọn đối tác sẽ bàn giao tới đó.
• Đổi một thứ một lúc. Đổi chính sách từng cái một, và chỉ đi tiếp sau khi xác nhận kết quả trong báo cáo Intune (trạng thái áp chính sách và thất bại gán). Đồng bộ MDM theo chu kỳ khoảng 8 giờ,³ và hầu hết “nó chưa áp” là chuyện thời gian, không phải lỗi.

flowchart TB
        accTitle: Chu kỳ vận hành của một lần đổi chính sách
        accDescr: Đổi chính sách từng cái một, và chỉ chuyển sang lần đổi tiếp theo sau khi xác nhận trạng thái áp trong báo cáo Intune. Hầu hết trường hợp chưa áp được giải bằng chờ chu kỳ đồng bộ khoảng 8 giờ
        change["Chỉ đổi một chính sách"] --> report["Xác nhận trạng thái áp trong báo cáo"]
        report --> next["Nếu không vấn đề, sang lần đổi tiếp"]
        next --> change
        report -.-> wait["Hầu hết chưa áp là chờ đồng bộ"]

Hình 20: Đổi chính sách từng cái một, và chỉ đi tiếp sau khi xác nhận kết quả trong báo cáo.

10. Tóm tắt

• GPO là cơ chế giả định khả năng tới domain controller, và về cấu trúc không tới PC ngoài trụ sở. Intune (MDM) đồng bộ qua internet, nên nó giải bài toán này từ gốc.
• Di chuyển không phải tất cả hoặc không gì. Máy Entra-joined và máy domain-joined có thể cùng tồn tại, và di chuyển theo giai đoạn chuyển PC mới sang Entra join plus Intune là câu trả lời thực tế cho doanh nghiệp vừa và nhỏ. Không có đường chuyển cho máy sẵn có, nên thay theo chu kỳ làm mới phần cứng là mẫu ổn định.
• Với doanh nghiệp vừa và nhỏ, bắt đầu Intune bằng Microsoft 365 Business Premium (Intune Plan 1 plus Entra ID P1) là thực tế. Thành phần gói cứ đổi, tuy nhiên, và một số tính năng như Remediations đòi giấy phép cao hơn, nên đừng lấy bài tháng 8 năm 2026 này làm phúc âm; hãy xác nhận nguồn gốc.
• Kiểm kê GPO hiện tại có thể tự động hóa bằng Group Policy analytics. Chuyển thiết lập Ready for migration sang Settings catalog, và thay tập lệnh đăng nhập cùng triển khai máy in không có đối ứng bằng triển khai tập lệnh, biến việc thành ứng dụng, hoặc dừng thực hành. Lưu ý rằng trong GPO tiếng Nhật phần trăm hỗ trợ có thể không chính xác.
• Đẩy di chuyển theo năm giai đoạn “thí điểm → chính sách nền → triển khai ứng dụng → thay tự nhiên PC sẵn có → thu hẹp vai trò AD”, và quyết tiêu chí thoát từng giai đoạn trước.
• Xung đột áp kép do GPO thắng theo mặc định. MDMWinsOverGP là cơ chế chỉ Policy CSP, nên nguyên tắc là “đừng triển khai cùng một thiết lập từ cả hai”.
• Khi báo giá thay máy chủ tới là lúc tốt nhất để cân nhắc cuộc di chuyển này. Trước “thêm một chu kỳ AD”, hãy nghĩ PC năm năm tới sẽ được dùng ở đâu.

Bài viết liên quan

• Hướng dẫn thực tế Group Policy (GPO) — cách nó hoạt động, xác nhận áp dụng, và chọn giữa GPO và Intune
• Quản lý Windows Update sau khi WSUS ngừng phát triển — cách chọn giữa WUfB, Autopatch, và Intune
• Các lựa chọn thực tế sau khi Windows 10 hết hỗ trợ — bảng quyết định cho ESU, LTSC, và thay
• Tự động hóa cấp phát PC bằng winget + PowerShell — làm runbook chạy được
• Hướng dẫn thực tế BitLocker — mã hóa ổ bắt đầu từ quản lý khóa khôi phục
• Hướng dẫn thực tế Windows LAPS — nghỉ mật khẩu quản trị viên cục bộ dùng chung trên mọi PC

Lĩnh vực tư vấn liên quan

KomuraSoft LLC đảm nhận thiết kế di chuyển theo giai đoạn từ môi trường AD+GPO sang Entra ID+Intune (kiểm kê GPO hiện tại, chính sách tái tạo thiết lập, kế hoạch thí điểm), rà soát so sánh thay máy chủ versus chuyển lên đám mây, và tư vấn tái sử dụng ứng dụng nghiệp vụ sẵn có cùng tài sản cấp phát. Bắt đầu từ cùng cân nhắc “chúng ta có nên mua thêm một máy chủ AD không” cũng được.

• Tư vấn kỹ thuật và rà soát thiết kế
• Di chuyển tài sản kế thừa
• Liên hệ với chúng tôi

Liên kết tham khảo

Bài viết liên quan

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Chủ đề liên quan

Các trang này đặt chủ đề trong bối cảnh rộng hơn của dịch vụ và quyết định.

Dịch vụ liên quan đến chủ đề này

Bài viết liên quan trực tiếp đến các dịch vụ sau.

Câu hỏi thường gặp

Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.

Nếu di chuyển từ GPO sang Intune, chúng ta có tái tạo được mọi thiết lập Group Policy đang dùng hôm nay không?

Bạn không thể tái tạo hết. Settings catalog của Intune có hàng nghìn thiết lập Windows, gồm cả những cái đến từ ADMX, và hầu hết thiết lập bảo mật cùng hạn chế có thể chuyển, nhưng một số việc — ánh xạ ổ qua tập lệnh đăng nhập, triển khai máy in hàng loạt — không có thiết lập MDM tương ứng. Nếu bạn nhập bản xuất XML các GPO hiện tại vào Group Policy analytics của Intune, từng thiết lập được phân loại Ready for migration, Not supported, hoặc Deprecated. Với thiết lập không có đối ứng, bạn bù bằng triển khai tập lệnh PowerShell, biến việc thành ứng dụng, hoặc đơn giản dừng thiết lập đó.

Chúng ta cần giấy phép nào để dùng Intune?

Nền tảng là Microsoft Intune Plan 1. Bạn có thể đăng ký riêng, nhưng ở doanh nghiệp vừa và nhỏ thường dùng nó như một phần của Microsoft 365 Business Premium (tới 300 người dùng). Business Premium cũng gồm Entra ID P1, nên bạn có thể đi tới kết hợp chính sách tuân thủ với Conditional Access. Một số tính năng, như Remediations, riêng đòi giấy phép hạng Windows Enterprise E3/E5. Thành phần gói thay đổi thường xuyên, nên xác nhận chi tiết mới nhất trên các trang giấy phép chính thức của Microsoft trước khi ký (bài này tính tới tháng 8 năm 2026).

Chúng ta có phải ngừng máy chủ AD ngay không?

Không. PC quản bằng Entra join plus Intune và PC quản bằng AD domain join plus GPO có thể cùng tồn tại trên cùng mạng công ty. Di chuyển theo giai đoạn — để AD lại cho xác thực máy chủ tệp và các hệ thống nghiệp vụ sẵn có, và chỉ Entra-join PC mới — là thực tế. Ngược lại, không có cách được hỗ trợ để "chuyển" một PC domain-joined sẵn có thành Entra join; cần wipe (đặt lại), nên mẫu ổn định là thay máy sẵn có theo chu kỳ làm mới phần cứng. Đủ để cân nhắc ngừng AD sau khi GPO trống và bạn đã kiểm kê các vai trò còn lại.

Vì sao Group Policy không áp lên PC dùng cho làm việc từ xa?

Vì GPO được lấy và áp khi PC tới được một domain controller. PC ngoài văn phòng chỉ nhận chính sách mới nhất khi nó tới được domain controller qua VPN hoặc tương tự, và PC nhà không dùng VPN về cơ bản không bao giờ nhận. Intune (MDM) đồng bộ chính sách qua internet, nên bạn quản được PC ở bất cứ đâu; bài toán quản PC ngoài trụ sở được giải bằng cấu trúc MDM. Ngoài đồng bộ định kỳ khoảng mỗi 8 giờ, một đồng bộ do thông báo cũng chạy khi chính sách đổi.

Nếu triển khai cùng một thiết lập từ cả GPO lẫn Intune, bên nào thắng?

Theo mặc định, thiết lập xung đột do Group Policy thắng. Đặt chính sách MDMWinsOverGP thành 1 làm phía MDM (Intune) thắng, nhưng cơ chế đó chỉ áp cho thiết lập dưới Policy CSP; nó không áp cho thiết lập định nghĩa trong các CSP khác như Defender CSP. Dựa vào kiểm soát thứ tự ưu tiên làm hành vi khó đoán, nên trong thực tế nguyên tắc là "đừng triển khai cùng một thiết lập từ cả hai kênh", và khi một thiết lập đã chuyển sang Intune bạn xóa nó khỏi GPO gốc để tránh quản kép.

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, đặc biệt trong các dự án có hệ thống hiện hữu và lỗi khó tái hiện.