Hướng dẫn thực tế Group Policy (GPO) — cơ chế, xác nhận áp dụng, và cách chọn với Intune

“Thiết lập này được phân phối bằng GPO”, “PC của khách bị Group Policy khóa chặt” — ai làm hệ thống nghiệp vụ trên Windows đều nghe chữ “GPO” bay quanh liên tục. Thế nhưng khi thật sự phải tiếp nhận vận hành AD, hoặc triển khai ứng dụng lên PC domain-joined tại khách, số người giải thích được chính xác Group Policy được áp khi nào, từ đâu, và theo thứ tự ưu tiên nào lại bất ngờ ít.

“Tôi đổi thiết lập rồi mà chưa có hiệu”, “bảo chạy gpupdate nhưng không biết nó đang làm gì”, “ứng dụng chạy trên máy phát triển mà tại khách thì không, lần ra lại là GPO” — bài viết này hướng tới nhà phát triển ứng dụng nghiệp vụ gặp các tình huống đó, và nhân viên IT doanh nghiệp vừa và nhỏ đã tiếp nhận vận hành AD. Nó sắp xếp cơ chế Group Policy (thứ tự áp LSDOU), thời điểm có hiệu, cách phân tách bằng gpresult và nhật ký sự kiện, ADMX cùng central store, và cách chọn giữa GPO và Intune (MDM), dựa trên nguồn gốc tính đến tháng 8 năm 2026.

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

• Group Policy là “cái xử lý sau thắng”. Nó được xử lý theo thứ tự cục bộ → site → miền → OU (LSDOU), và GPO nào xử lý sau thì được ưu tiên khi xung đột. GPO cục bộ (gpedit.msc) là lớp yếu nhất.¹
• Thời điểm áp là “tiền cảnh cộng nền”. Computer Configuration luôn được áp lúc khởi động và User Configuration luôn lúc đăng nhập; thêm vào đó, mặc định có cập nhật nền khoảng mỗi 90 phút cộng offset ngẫu nhiên 0–30 phút (5 phút trên domain controller).²
• gpupdate /force là “áp lại mọi thiết lập” — không phải thuốc chữa bách bệnh. Một số thiết lập, như cài phần mềm và folder redirection, chỉ được xử lý lúc đăng nhập hoặc khởi động lại (đúng vì thế mới có tùy chọn /logoff và /boot).³
• Điểm khởi đầu phân tách là báo cáo RSoP từ gpresult /h. Nó hiện cả GPO đã áp lẫn GPO bị từ chối, kèm lý do. Để đào sâu, dùng nhật ký vận hành GroupPolicy (Microsoft-Windows-GroupPolicy/Operational).⁴⁵
• Theo nguyên tắc, chính sách mẫu quản trị được ghi vào khóa registry dành riêng cho chính sách (Software\Policies và tương tự). Giá trị chính sách được ưu tiên hơn thiết lập riêng của ứng dụng, và “Not Configured” không ghi gì cả. Dù vậy, một số chính sách ghi ra ngoài các khóa dành riêng (Chương 5).⁶
• Central store ADMX là thư mục PolicyDefinitions trong SYSVOL. Một khi tạo, GPMC bắt đầu tham chiếu định nghĩa mẫu chung toàn miền từ đó.⁷
• Chọn GPO hay Intune dựa trên nền tảng danh tính của thiết bị. Cấu hình cùng một thiết lập ở cả hai không bảo đảm kết quả. Group Policy analytics giúp khi bạn cân nhắc di chuyển.⁸⁹
• Với nhà phát triển, GPO là nguyên nhân kinh điển khiến ứng dụng “chỉ hỏng tại khách”. Các thiết lập đổi giả định của ứng dụng — execution policy, tắt gộp quy tắc firewall cục bộ, cấu hình proxy và ổ đĩa, và nữa — được phân phối qua quản lý tập trung.¹⁰¹¹

2. Group Policy là gì — GPO cục bộ và GPO miền

Group Policy là cơ chế để quản trị viên định nghĩa tập trung các thiết lập Windows và bắt buộc chúng trên máy tính và người dùng đích. Một bó thiết lập được gọi là GPO (Group Policy Object). GPO có thể nằm ở một trong hai chỗ.

PC workgroup (không tham gia miền) chỉ xử lý GPO cục bộ.¹ Vì vậy trong thực tế, khi người ta nói máy “được quản bằng GPO”, hầu như luôn nghĩa là GPO miền.

flowchart TB
    accTitle: GPO mà PC workgroup và PC domain-joined xử lý
    accDescr: PC workgroup chỉ xử lý GPO cục bộ, còn PC domain-joined xử lý cả GPO cục bộ lẫn GPO miền được phân phối từ Active Directory
    pc{"Hình thức tham gia của PC?"}
    pc -->|Workgroup| wg["Chỉ xử lý GPO cục bộ"]
    pc -->|Domain-joined| dom["GPO cục bộ + GPO miền"]
    dom -.-> note["GPO thực tế hầu hết là GPO miền"]

Hình 1: PC workgroup chỉ xử lý GPO cục bộ; PC domain-joined còn xử lý cả GPO miền.

Dù GPO nào, nội dung cũng chia rộng thành hai nhánh.

• Computer Configuration: thiết lập có hiệu với bất kỳ ai đăng nhập vào PC đó. Được áp lúc khởi động.
• User Configuration: thiết lập có hiệu với người dùng đó bất kể họ đăng nhập PC nào. Được áp lúc đăng nhập.

Trục “thiết lập gắn với PC hay với người” xuất hiện nhất quán cả ở thứ tự áp lẫn cách xác nhận đã có hiệu, về sau trong bài. Một số mục tồn tại dưới cả hai cấu hình, nên hãy thành thói quen luôn xem cả hai nhánh khi đang tìm một thiết lập.

flowchart TB
    accTitle: Hai nhánh nội dung của GPO
    accDescr: Mọi GPO đều có hai nhánh, cấu hình máy tính và cấu hình người dùng; cấu hình máy tính được áp lúc khởi động và có hiệu với bất kỳ ai đăng nhập vào PC đó, còn cấu hình người dùng được áp lúc đăng nhập và có hiệu với người dùng đó trên bất kỳ PC nào
    gpo["Nội dung GPO"] --> comp["Cấu hình máy tính"]
    gpo --> user["Cấu hình người dùng"]
    comp --> boot["Áp lúc khởi động"]
    user --> logon["Áp lúc đăng nhập"]
    boot -.-> anyone["Có hiệu với bất kỳ ai đăng nhập"]
    logon -.-> anypc["Có hiệu trên mọi PC"]

Hình 2: GPO có hai nhánh: cấu hình máy tính gắn với PC, và cấu hình người dùng gắn với người.

3. Cơ chế áp dụng — “cái xử lý sau thắng” của LSDOU và kiểm soát kế thừa

3.1. LSDOU: Local → Site → Domain → OU

Trên PC domain-joined, GPO được xử lý theo thứ tự sau.¹

1. GPO cục bộ
2. GPO liên kết tới site
3. GPO liên kết tới miền
4. GPO liên kết tới OU (organizational unit) — xử lý từ OU cấp trên xuống, với GPO trên OU mà máy tính/người dùng đích thuộc trực tiếp được xử lý cuối

Lấy chữ cái đầu cho ra tên thứ tự, LSDOU. Điểm then chốt là đây không phải “ưu tiên cao trước” mà là thứ tự GPO được xử lý. Khi nhiều GPO cấu hình cùng một thiết lập, cái nào xử lý sau thì thắng (thiết lập không xung đột thì được cộng lại).¹ Nói cách khác, GPO trên OU gần đối tượng nhất là mạnh nhất, và GPO cục bộ là yếu nhất. “Tôi sửa trong gpedit.msc rồi nó hoàn nguyên” không phải hỏng — đó đúng là đặc tả đang chạy như thiết kế.

flowchart TB
    accTitle: Thứ tự xử lý LSDOU và cái sau thắng
    accDescr: GPO được xử lý theo thứ tự cục bộ, site, miền, OU, và khi xung đột GPO xử lý sau thắng, nên GPO của OU gần đối tượng nhất là mạnh nhất và GPO cục bộ là yếu nhất
    l["1. GPO cục bộ"] --> s["2. Site"]
    s --> d["3. Miền"]
    d --> ou["4. OU (từ trên xuống)"]
    ou --> win["Xung đột thì cái sau thắng"]
    win -.-> strongest["GPO OU gần đối tượng mạnh nhất"]
    win -.-> weakest["GPO cục bộ yếu nhất"]

Hình 3: LSDOU là thứ tự được xử lý, và khi cùng thiết lập xung đột thì GPO xử lý sau thắng.

Khi nhiều GPO được liên kết tới cùng một site, miền, hoặc OU, ưu tiên giữa chúng do link order trên tab “Linked Group Policy Objects” của GPMC quyết định. GPO có số link order nhỏ nhất được xử lý cuối và được ưu tiên cao nhất.¹

flowchart TB
    accTitle: Thứ tự liên kết khi nhiều GPO cùng một chỗ
    accDescr: Khi nhiều GPO được liên kết tới cùng site, miền hay OU, thứ tự xử lý do link order trên GPMC quyết định, và GPO có số nhỏ nhất được xử lý cuối nên được ưu tiên cao nhất
    multi["Nhiều GPO cùng một chỗ"] --> tab["Quyết bởi link order trên GPMC"]
    tab --> last["GPO số nhỏ nhất xử lý cuối"]
    last --> win["Cái sau thắng, ưu tiên cao nhất"]

Hình 4: Trên cùng một đích liên kết, GPO có số link order nhỏ nhất được xử lý cuối và thắng.

3.2. Block Inheritance và Enforced

Bạn có thể tạo ngoại lệ cho thứ tự mặc định.¹

• Block Inheritance: đặt trên miền hoặc OU, việc này dừng kế thừa GPO từ cấp trên. Đó là công cụ cho “OU này không nên nhận chuẩn toàn công ty.”
• Enforced (trước đây gọi là No Override): đặt trên liên kết của GPO, việc này làm GPO đó luôn được áp, ngay cả khi cấp dưới đã đặt Block Inheritance, và nó không còn bị GPO cấp dưới ghi đè. Khi Block Inheritance và Enforced xung đột, Enforced thắng.¹

flowchart TB
    accTitle: Quan hệ giữa chặn kế thừa và Enforced
    accDescr: Chặn kế thừa dừng kế thừa GPO từ cấp trên, nhưng GPO được Enforced luôn được áp ngay cả khi cấp dưới chặn kế thừa, và không bị GPO cấp dưới ghi đè
    upper["GPO từ cấp trên"] --> blocked{"Cấp dưới chặn kế thừa?"}
    blocked -->|Không| inherit["Kế thừa như cũ"]
    blocked -->|Có| enforced{"GPO có đặt Enforced?"}
    enforced -->|Không| stop["Kế thừa dừng"]
    enforced -->|Có| apply["Luôn được áp"]
    apply -.-> noover["Không bị GPO cấp dưới ghi đè"]

Hình 5: Block Inheritance dừng kế thừa từ cấp trên, nhưng GPO được Enforced vượt qua Block Inheritance và luôn được áp.

Enforced là cơ chế phá nguyên tắc “cái xử lý sau thắng”, nên lạm dụng nghĩa là ngày càng nhiều kết quả trên RSoP đọc lên sẽ phản trực giác. Thực hành chuẩn là dành nó cho các thiết lập bảo mật toàn công ty bắt buộc phải tuân.

3.3. Lọc bảo mật

Ngoài vị trí liên kết, bạn cũng có thể thu hẹp ai được GPO áp, theo từng GPO. Để GPO được áp, người dùng hoặc máy tính đích phải giữ cả hai quyền “Read” và “Apply group policy” trên GPO đó. Mặc định cả hai được cấp cho Authenticated Users (gồm cả người dùng lẫn máy tính), nên GPO áp cho mọi người dưới đích liên kết. Lọc bảo mật là cách thu hẹp điều này vào các nhóm bảo mật cụ thể. Bộ lọc tác động lên GPO như một khối; bạn không thể đổi nó theo từng thiết lập trong GPO.¹³

Có một lưu ý quan trọng. Khi thu hẹp phạm vi, đừng gỡ luôn “Read” khỏi Authenticated Users mặc định. Từ bản cập nhật bảo mật MS16-072 (2016), chính sách người dùng được lấy dưới ngữ cảnh bảo mật của máy tính, nên nếu tài khoản máy tính không đọc được GPO, GPO hướng người dùng sẽ không được áp dù người dùng đích có cả hai quyền.¹⁴ Cách thu hẹp đúng là cấp “Read + Apply group policy” cho nhóm đích, đồng thời để lại chỉ “Read” trên Authenticated Users (hoặc Domain Computers).¹⁴

flowchart TB
    accTitle: Phán quyết áp của bộ lọc bảo mật
    accDescr: Để GPO được áp, người dùng hoặc máy tính đích phải có cả hai quyền Đọc và Áp Group Policy, và GPO hướng người dùng còn cần tài khoản máy tính đọc được GPO
    target["Đối tượng dưới đích liên kết GPO"] --> perm{"Cả quyền Đọc và Áp?"}
    perm -->|Không| deny["Từ chối bởi bộ lọc"]
    perm -->|Có| usergpo{"GPO hướng người dùng?"}
    usergpo -->|Không| apply["Được áp"]
    usergpo -->|Có| comp{"Máy tính đọc được?"}
    comp -->|Có| apply
    comp -->|Không| deny2["Không áp (MS16-072)"]

Hình 6: Để áp cần cả “Read” lẫn “Apply group policy”, và với GPO hướng người dùng còn cần tài khoản máy tính đọc được GPO.

Trong thực tế, hai vấp kinh điển là “tôi đã thêm vào nhóm mà vẫn chưa được áp (đó là thiết lập hướng máy tính, nhưng tôi chỉ thêm người dùng vào nhóm)” và “tôi đã gỡ khỏi nhóm mà nó vẫn cứ áp”. Cái sau sẽ không hết dù bạn chờ cập nhật nền. Tư cách thành viên nhóm được đánh giá từ security token tạo lúc đăng nhập, nên đổi nhóm của người dùng chỉ tới bộ lọc sau một vòng đăng xuất/đăng nhập, và đổi nhóm của máy tính chỉ sau khởi động lại — một khi token mới đã được cấp.

flowchart TB
    accTitle: Đến khi đổi nhóm phản ánh vào bộ lọc
    accDescr: Tư cách thành viên nhóm được đánh giá bằng security token tạo lúc đăng nhập, nên đổi người dùng chỉ phản ánh sau đăng nhập lại, đổi máy tính sau khởi động lại, khi token mới được tạo
    change["Đổi thành viên nhóm"] --> old["Token cũ thì chưa phản ánh"]
    old --> u["Người dùng đăng nhập lại"]
    old --> c["Máy tính khởi động lại"]
    u --> token["Đánh giá bằng token mới"]
    c --> token
    token --> ok["Phản ánh vào bộ lọc"]
    old -.-> bg["Cập nhật nền không giải được"]

Hình 7: Đổi nhóm chỉ phản ánh vào bộ lọc sau khi đăng xuất hoặc khởi động lại tạo ra token mới.

Ngoài ra còn có chế độ đặc biệt gọi là loopback processing, cho các tình huống như PC dùng chung hoặc máy Remote Desktop, khi bạn muốn ai đăng nhập vào PC đó cũng nhận User Configuration bị thay (cơ chế áp thiết lập người dùng dựa trên vị trí máy tính, với chế độ Replace và Merge).¹⁵ Đó là tính năng nâng cao dùng trên máy kiosk và PC lớp học, nên bài này chỉ ghi nhận là nó tồn tại.

flowchart TB
    accTitle: Cách nghĩ về loopback processing
    accDescr: Loopback processing là chế độ đặc biệt áp cấu hình người dùng dựa trên vị trí máy tính, có hai chế độ Thay thế và Gộp, dùng cho PC dùng chung hay kiosk khi muốn cùng thiết lập người dùng với mọi người đăng nhập
    shared["PC dùng chung, kiosk, v.v."] --> lb["Loopback processing"]
    lb --> base["Quyết theo vị trí máy tính"]
    base --> rep["Chế độ Thay thế"]
    base --> mrg["Chế độ Gộp"]
    lb -.-> aim["Có hiệu với mọi người đăng nhập"]

Hình 8: Loopback processing là chế độ đặc biệt áp cấu hình người dùng dựa trên vị trí máy tính, với hai chế độ Replace và Merge.

4. Khi nào thiết lập có hiệu — xử lý tiền cảnh và cập nhật nền

Một nửa “tôi cấu hình rồi mà chưa có hiệu” đơn giản là thời điểm áp chưa tới. Có hai loại áp.²

Nói cách khác, với thiết bị đang chạy và tới được domain controller, các thiết lập hỗ trợ cập nhật nền sẽ lan trong khoảng hai giờ sau khi bạn đổi GPO, không cần thao tác thêm. Thiết bị offline, hoặc laptop mang ra ngoài không có kết nối VPN, sẽ không nhận cho đến lần tới DC tiếp theo. Thiết lập chỉ được áp qua xử lý tiền cảnh còn phải chờ thêm một lần khởi động hoặc đăng nhập. Nếu đang gấp, chạy gpupdate trên PC đích. Mặc định chỉ các thiết lập đã đổi được áp; thêm /force thì áp lại mọi thiết lập, bất kể đã đổi hay chưa.³

rem Cập nhật chỉ các thiết lập đã đổi (thường là đủ)
gpupdate

rem Áp dụng lại mọi thiết lập (khi nghi trạng thái đã cache)
gpupdate /force

flowchart TB
    accTitle: Khả năng tới DC và cách thiết lập lan tới
    accDescr: Trên thiết bị đang chạy tới được domain controller, thiết lập hỗ trợ cập nhật nền lan trong khoảng 2 giờ, nhưng PC mang đi offline hoặc chưa VPN thì không tới cho đến lần kết nối DC tiếp theo
    pc{"Tới được DC?"}
    pc -->|Có| ok["Lan trong khoảng 2 giờ"]
    pc -->|Không| ng["Không tới đến khi kết nối"]
    ng -.-> ex["PC mang đi offline hoặc chưa VPN"]

Hình 9: Thiết bị đang chạy tới được DC thì lan trong khoảng 2 giờ, còn thiết bị offline thì không tới cho đến lần kết nối DC tiếp theo.

Điều cần để ý là một số thiết lập đơn giản không có hiệu qua gpupdate. Cài phần mềm hướng người dùng và folder redirection chỉ được xử lý lúc đăng nhập, còn cài phần mềm hướng máy tính chỉ lúc khởi động. gpupdate cung cấp các tùy chọn /logoff (đăng xuất sau khi cập nhật) và /boot (khởi động lại sau khi cập nhật) đúng cho việc này.³ Trước khi kêu “tôi chạy gpupdate /force rồi mà vẫn chưa vào”, hãy kiểm xem thiết lập đó có thuộc loại đòi khởi động lại hoặc đăng nhập hay không.

flowchart TB
    accTitle: Đường thiết lập được áp
    accDescr: Đổi GPO tới trong khoảng 90 phút cộng offset 0 tới 30 phút nếu hỗ trợ cập nhật nền; thiết lập chỉ áp bằng xử lý tiền cảnh phải chờ khởi động hoặc đăng nhập; gpupdate khi gấp vẫn cần /logoff hoặc /boot cho thiết lập tiền cảnh
    change["Đổi GPO"] --> kind{"Hỗ trợ cập nhật nền?"}
    kind -->|Có| bg["Cập nhật ~90 phút + 0–30 phút"]
    kind -->|Không| fg["Áp lúc khởi động hoặc đăng nhập"]
    bg --> done["Có hiệu"]
    fg --> done
    rush["Khi gấp"] -.-> upd["Chạy gpupdate"]
    upd -.-> force["/force để áp lại tất cả"]
    upd -.-> reboot["Tiền cảnh cần /logoff hoặc /boot"]

Hình 10: Cập nhật nền chỉ đưa các thiết lập hỗ trợ; thiết lập chỉ áp bằng xử lý tiền cảnh vẫn cần đăng xuất hoặc khởi động lại sau gpupdate.

5. Phân tách khi thiết lập không được áp — gpresult, nhật ký sự kiện, và registry

5.1. Kiểm RSoP bằng gpresult /h

gpresult là công cụ chuẩn để kiểm kết quả cuối (RSoP: Resultant Set of Policy) khi nhiều GPO đã chồng lên nhau. Xuất báo cáo HTML từ command prompt nâng quyền là cách dễ đọc nhất.⁴⁵

rem Xuất báo cáo HTML RSoP cả người dùng lẫn máy tính
gpresult /h C:\temp\gp-report.html /f

rem Để xem chỉ tóm tắt trên console
gpresult /r
gpresult /scope computer /r

Ba điều nên xem trước trên báo cáo:

1. Danh sách GPO đã áp — GPO bạn nhắm có mặt không?
2. Danh sách GPO bị từ chối, kèm lý do — lý do không được áp, như lọc bảo mật, bộ lọc WMI, hoặc GPO trống, hiện ở đây⁵
3. “Winning GPO” cho từng thiết lập — giá trị của GPO nào quyết định thiết lập bạn nhắm. Nếu GPO khác đang thắng, hãy quay lại xem xét các quy tắc ưu tiên ở Chương 3

flowchart TB
    accTitle: Ba điểm xem trước trên báo cáo RSoP
    accDescr: Trên báo cáo gpresult, trước hết xem GPO mục tiêu có trong danh sách GPO đã áp, rồi xem danh sách GPO bị từ chối cùng lý do, cuối cùng xác định GPO nào thắng trên từng thiết lập
    rep["Mở báo cáo RSoP"] --> one["1. Danh sách GPO đã áp"]
    one --> two["2. GPO bị từ chối và lý do"]
    two --> three["3. GPO thắng trên từng thiết lập"]
    three -.-> review["Nếu GPO khác thắng thì xem lại"]

Hình 11: Báo cáo RSoP được đọc theo thứ tự GPO đã áp, GPO bị từ chối kèm lý do, rồi Winning GPO trên từng thiết lập.

5.2. Nhật ký vận hành GroupPolicy

Khi gpresult chưa đủ — ví dụ xử lý thất bại hẳn, hoặc mất quá lâu — hãy xem nhật ký vận hành GroupPolicy trong Event Viewer. Nó nằm tại “Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational” (tên nhật ký Microsoft-Windows-GroupPolicy/Operational). Đây ghi toàn bộ khoảng xử lý chính sách, từ đầu đến cuối, cùng danh sách GPO đã áp và danh sách GPO bị từ chối (kèm lý do). Mỗi vòng xử lý chính sách được gán một ActivityID duy nhất, nên quy trình Microsoft khuyến nghị là lấy ActivityID từ sự kiện cảnh báo hoặc lỗi trên System log, rồi dùng custom view để lọc xuống chỉ đúng lần đó.⁵

flowchart TB
    accTitle: Cách lọc nhật ký vận hành GroupPolicy
    accDescr: Nhật ký vận hành GroupPolicy gán một ActivityID duy nhất cho mỗi lần xử lý chính sách, nên lấy ActivityID từ cảnh báo hoặc lỗi trên System log rồi dùng custom view để lọc chỉ các sự kiện của lần đó
    sys["Cảnh báo hoặc lỗi trên System log"] --> aid["Lấy ActivityID"]
    aid --> cv["Lọc bằng custom view"]
    cv --> one["Đọc sự kiện của một lần xử lý"]
    one -.-> rec["Danh sách GPO đã áp và bị từ chối kèm lý do"]

Hình 12: Nhật ký vận hành lấy ActivityID từ System log, rồi dùng custom view để lọc chỉ các sự kiện của một lần xử lý chính sách.

5.3. Quan hệ với khóa Policies trên registry

Chính sách mẫu quản trị (chương tiếp) cuối cùng được ghi thành giá trị registry. Theo nguyên tắc, chúng được ghi vào các khóa chính sách dành riêng sau.⁶

• HKEY_LOCAL_MACHINE\Software\Policies (Computer Configuration; vị trí khuyến nghị)
• HKEY_CURRENT_USER\Software\Policies (User Configuration; vị trí khuyến nghị)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

Ở đây có một tư tưởng thiết kế quan trọng. Ứng dụng nhận biết chính sách hành xử bằng cách đọc khóa Policies trước; nếu có giá trị thì giá trị đó được ưu tiên; nếu không, ứng dụng rơi về thiết lập (preference) hoặc mặc định của mình. Chính sách “Not Configured” không ghi gì vào registry cả.⁶ Nói cách khác, chính sách mẫu quản trị không viết đè thiết lập riêng của ứng dụng rồi để lại “hình xăm (tattooing)” — thay vào đó, một giá trị bắt buộc đặt ở chỗ khác được tham chiếu với ưu tiên. Ngừng cấu hình chính sách, và ứng dụng trở lại tuân theo giá trị thiết lập của mình.

flowchart TB
    accTitle: Ưu tiên giữa giá trị chính sách và thiết lập ứng dụng
    accDescr: Ứng dụng hỗ trợ chính sách đọc khóa Policies trước; nếu có giá trị thì ưu tiên giá trị đó, nếu không thì dùng thiết lập hoặc mặc định của mình; chính sách Chưa cấu hình không ghi gì vào registry
    app["Ứng dụng hỗ trợ chính sách đọc thiết lập"] --> haspol{"Khóa Policies có giá trị?"}
    haspol -->|Có| pol["Ưu tiên giá trị chính sách"]
    haspol -->|Không| pref["Dùng thiết lập hoặc mặc định của mình"]
    notconf["Chính sách chưa cấu hình"] -.-> nowrite["Không ghi gì vào registry"]

Hình 13: Chính sách không viết đè thiết lập của ứng dụng; giá trị bắt buộc đặt ở chỗ khác được tham chiếu với ưu tiên.

Dù vậy, không phải mọi chính sách đều ghi vào khóa dành riêng. Một số thiết lập hệ điều hành sẵn có (ví dụ, “Enable Win32 long paths” ghi vào LongPathsEnabled dưới HKLM\SYSTEM\CurrentControlSet\Control\FileSystem), cùng các mẫu thế hệ cũ hoặc bên thứ ba, ghi tới đường tùy ý ngoài các khóa dành riêng. Với các thiết lập kiểu này, giá trị vẫn nằm đó ngay cả sau khi bạn ngừng cấu hình chính sách. Hãy kiểm định nghĩa ADMX, đoạn mô tả của thiết lập, hoặc báo cáo gpresult để biết thiết lập cho trước thật sự ghi vào khóa nào.

Nói ngược lại, thiết kế cư xử đúng mô tả ở trên chỉ đứng trong ranh giới mẫu quản trị (các khóa chính sách dành riêng). Giá trị mà tập lệnh hoặc Group Policy Preferences ghi ra ngoài khóa Policies hành xử như giá trị registry thường, và khung này không có cơ chế hoàn nguyên chúng tự động một khi bạn ngừng phân phối. Trong thực tế, khi phân tách sự cố, cách nhanh và chắc nhất là nhìn trực tiếp xem thiết lập bạn nhắm có được ghi dưới khóa Policies hay không.

# Ví dụ kiểm tra trực tiếp giá trị do chính sách phân phối (hầu hết chính sách được ghi dưới Policies)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

flowchart TB
    accTitle: Quy trình phân tách khi chưa có hiệu
    accDescr: Trước hết xác nhận GPO đã áp và GPO bị từ chối trên báo cáo RSoP của gpresult; nếu chưa đủ thì lọc nhật ký vận hành GroupPolicy theo ActivityID; giá trị thực đã phân phối thì kiểm trực tiếp trên khóa Policies của registry
    start["Thiết lập chưa có hiệu"] --> rsop["Xác nhận RSoP bằng gpresult /h"]
    rsop --> found{"Biết lý do áp và từ chối?"}
    found -->|Có| fix["Xem lại thứ tự ưu tiên hoặc bộ lọc"]
    found -->|Không| oplog["Xem nhật ký vận hành GroupPolicy"]
    oplog -.-> aid["Lọc một lần theo ActivityID"]
    rsop -.-> reg["Kiểm trực tiếp giá trị khóa Policies"]

Hình 14: Phân tách bắt đầu từ gpresult /h; nếu chưa đủ thì nhật ký vận hành GroupPolicy, còn giá trị thực thì kiểm trực tiếp khóa Policies.

6. Mẫu quản trị (ADMX) và central store

Các định nghĩa đứng sau các thiết lập liệt kê dưới “Administrative Templates” của GPMC được viết thành tệp ADMX (thân định nghĩa) cộng tệp ADML (chuỗi hiển thị cho từng ngôn ngữ). Mỗi PC có định nghĩa do hệ điều hành cung cấp dưới C:\Windows\PolicyDefinitions, và các công cụ quản trị nạp chúng để dựng màn hình thiết lập.⁷

Nếu bạn vận hành trong miền, bước cơ bản là tạo central store. Tạo thư mục PolicyDefinitions dưới SYSVOL của một domain controller (ví dụ, \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions), và nội dung được sao chép tới mọi domain controller trong miền; công cụ Group Policy khi đó tham chiếu central store theo mặc định.⁷ Việc này loại bài toán “phiên bản mẫu khác nhau từ máy quản trị này sang máy kia, và các thiết lập nhìn thấy không khớp”. Tệp ADML vào thư mục con theo ngôn ngữ (ja-JP cho tiếng Nhật).⁷

flowchart TB
    accTitle: Cơ chế central store
    accDescr: Tạo thư mục PolicyDefinitions dưới SYSVOL của domain controller thì nội dung được sao chép tới mọi domain controller, và công cụ Group Policy tham chiếu central store theo mặc định nên hết lệch định nghĩa giữa các máy quản trị
    create["Tạo dưới SYSVOL"] --> cs["PolicyDefinitions"]
    cs --> repl["Sao chép tới mọi DC"]
    cs --> ref["Công cụ GP tham chiếu mặc định"]
    ref -.-> benefit["Hết lệch định nghĩa giữa máy"]
    cs -.-> adml["ADML vào thư mục theo ngôn ngữ"]

Hình 15: PolicyDefinitions trên SYSVOL được sao chép tới mọi domain controller, và công cụ Group Policy tham chiếu nó theo mặc định.

Có hai lưu ý vận hành. Thứ nhất, Microsoft phát hành tệp ADMX mới cho mỗi phiên bản Windows mới, và khi cập nhật, bạn thay phía central store. Thay C:\Windows\PolicyDefinitions trên từng PC bằng bản tải về không được hỗ trợ.⁷ Thứ hai, khi cập nhật central store hiện có, hướng dẫn là đừng ghi đè PolicyDefinitions sản xuất trực tiếp. Thay vào đó, gom bộ ADMX đầy đủ — cả cho hệ điều hành lẫn cho ứng dụng như Office và Edge — vào một thư mục làm việc đặt tên phiên bản như PolicyDefinitions-24H2, đổi tên thư mục hiện hành sang chỗ khác kiểu PolicyDefinitions-23H2, rồi đổi tên thư mục làm việc thành PolicyDefinitions để đưa vào sản xuất.⁷ Công cụ Group Policy chỉ tham chiếu thư mục đúng tên PolicyDefinitions, nên chỉ đặt tệp vào thư mục tên phiên bản thì không có hiệu. Ưu điểm của cách này là nếu có vấn đề, bạn có thể hoàn về thư mục đã cất sang.⁷

flowchart TB
    accTitle: Quy trình cập nhật central store
    accDescr: Cập nhật bằng cách gom bộ ADMX hệ điều hành và ứng dụng vào thư mục làm việc đặt tên phiên bản, đổi tên thư mục hiện hành để cất, rồi đổi tên thư mục làm việc thành PolicyDefinitions sản xuất; nếu có vấn đề thì đổi về thư mục cũ đã cất
    work["Thư mục làm việc tên phiên bản"] --> gather["Gom bộ OS và ứng dụng"]
    gather --> evac["Đổi tên thư mục hiện hành để cất"]
    evac --> rename["Đổi tên thư mục làm việc thành tên sản xuất"]
    rename --> live["Được tham chiếu như sản xuất"]
    live -.-> back["Có vấn đề thì đổi về thư mục cũ"]

Hình 16: Cập nhật bằng cách gom bộ đủ trong thư mục làm việc, cất bản hiện hành, rồi đổi tên để đưa vào sản xuất.

7. GPO so với Intune (MDM/CSP) so với phân phối thủ công/tập lệnh — bảng quyết định

GPO không còn là lựa chọn duy nhất để quản cấu hình thiết bị Windows. MDM, điển hình là Intune, cấu hình thiết lập hệ điều hành qua cơ chế gọi là CSP (Configuration Service Provider). Đây là bảng quyết định nên xây cách tiếp cận quanh cái nào.

Trục quyết định thì đơn giản: nền tảng danh tính của thiết bị (AD, hay Microsoft Entra) và thiết bị đang ở đâu. GPO chắc chắn nhất với đội PC để bàn trong văn phòng tham gia đầy đủ AD tại chỗ; GPO đơn giản không tới được PC di động Entra-joined.

Trong thực tế, hầu hết doanh nghiệp vừa và nhỏ nằm ở giữa, ở cấu hình hybrid (domain-joined cộng đăng ký Intune), và điều tệ nhất bạn có thể làm ở đây là “cấu hình cùng một thiết lập qua cả GPO lẫn MDM”. Policy CSP có chính sách gọi là MDMWinsOverGP cho MDM thắng khi GPO và MDM xung đột, nhưng phạm vi của nó giới hạn ở các chính sách tương ứng trong Policy CSP. Bản thân Microsoft nói rõ rằng cấu hình một thiết lập ngoài tầm kiểm soát đó qua cả GPO lẫn MDM tạo điều kiện đua không bảo đảm bên nào thắng, và nên tránh cấu hình kép.⁸ Nguyên tắc đầu của vận hành hybrid là quyết, theo từng vùng thiết lập, “cái này của GPO, cái này của Intune”, rồi gom về một chủ thể quản.

flowchart TB
    accTitle: Cách chọn giữa GPO và Intune
    accDescr: Nếu nền tảng danh tính thiết bị là AD tại chỗ và máy nằm trong công ty thì GPO phù hợp; nếu Entra-joined hoặc máy ngoài trụ sở thì Intune phù hợp; hybrid thì tránh cấu hình kép cùng một thiết lập và gom chủ thể quản theo từng vùng về một bên
    q{"Nền tảng và vị trí thiết bị?"}
    q -->|Domain-joined, trong công ty| gpo["GPO chắc chắn và chi tiết hơn"]
    q -->|Entra-joined hoặc ngoài trụ sở| intune["Intune tới được cả ngoài công ty"]
    q -->|Hybrid| split["Gom về một bên theo từng vùng"]
    split -.-> warn["Cấu hình kép không bảo đảm kết quả"]
    split -.-> ana["Phân loại bằng Group Policy analytics"]

Hình 17: Cách chọn dựa trên nền tảng danh tính và vị trí thiết bị; trong hybrid đừng cấu hình cùng một thiết lập ở cả GPO lẫn MDM.

Khi bạn tới giai đoạn cân nhắc di chuyển từ GPO sang Intune, Group Policy analytics của Intune là cửa vào. Nhập GPO xuất từ GPMC (XML), và nó sẽ phân tích từng thiết lập được MDM hỗ trợ hay không hỗ trợ/deprecated; các thiết lập đã hỗ trợ có thể được chuyển vào chính sách settings catalog của Intune.⁹ Nên nghĩ đây là công cụ để “phân loại cái gì chuyển được, cái gì không, và cái gì nên bỏ” hơn là để “chuyển hết”. Chủ thể quản Windows Update cũng đang được sắp lại cùng mạch — xem thêm “Quản lý Windows Update sau khi WSUS ngừng phát triển”.

flowchart TB
    accTitle: Phân loại bằng Group Policy analytics
    accDescr: Nhập GPO xuất XML từ GPMC vào Group Policy analytics thì từng thiết lập được phân loại đã hỗ trợ MDM hay deprecated hoặc không hỗ trợ, và thiết lập đã hỗ trợ có thể chuyển sang chính sách settings catalog
    exp["Xuất XML từ GPMC"] --> imp["Nhập vào analytics"]
    imp --> ana["Phân tích tình trạng hỗ trợ từng thiết lập"]
    ana --> ok["Đã hỗ trợ MDM"]
    ana --> dep["Deprecated hoặc không hỗ trợ"]
    ok --> mig["Chuyển sang chính sách settings catalog"]

Hình 18: Group Policy analytics nhập GPO đã xuất và phân loại thiết lập chuyển được sang MDM với thiết lập không chuyển được.

8. Điểm mù của nhà phát triển — GPO của khách đổi hành vi ứng dụng

Cuối cùng, điều đáng biết nếu bạn làm phát triển theo hợp đồng. GPO của khách âm thầm viết lại giả định của ứng dụng bạn. Cùng với firewall và phần mềm diệt virus, GPO là thủ phạm quen trong “chạy trên máy phát triển mà tại khách thì không”. Đây là vài ví dụ cụ thể.

• Execution policy của PowerShell: execution policy có thể được cấu hình tập trung qua GPO, và các phạm vi MachinePolicy/UserPolicy đến từ GPO luôn được ưu tiên hơn giá trị đặt cục bộ hoặc trên tiến trình.¹⁰ Nếu trình cài đặt hoặc tập lệnh vận hành được xây trên giả định “thêm -ExecutionPolicy Bypass là chạy được”, nó thậm chí không khởi động dưới quản lý GPO. Xem “Execution policy PowerShell và ký tập lệnh — hướng dẫn thực tế thoát khỏi “che bằng Bypass”” để biết chi tiết.
• Tắt gộp quy tắc cục bộ trên firewall: trong môi trường firewall được quản tập trung qua GPO/Intune, “local rule merging” (AllowLocalPolicyMerge) có thể bị tắt theo từng hồ sơ. Nơi bị tắt, quy tắc vào mà trình cài đặt đăng ký cục bộ tồn tại nhưng không được áp.¹¹ Đây là điểm bạn phải xác nhận trước khi triển khai ứng dụng kiểu máy chủ; nó được trình bày chi tiết trong “Windows Firewall và ứng dụng nghiệp vụ”.
• Cấu hình môi trường như ánh xạ ổ và proxy: ánh xạ ổ mạng, máy in, và tương tự thường được phân phối qua Group Policy Preferences.¹⁶ Các giả định về môi trường — “ổ Z phải tồn tại”, “proxy phải là kết nối trực tiếp” — có thể sụp tùy người dùng đăng nhập hoặc tư cách OU của PC. Với ứng dụng thường trú cũng dễ bỏ qua rằng thiết lập phân phối qua User Configuration dĩ nhiên không áp cho tài khoản mà dịch vụ hoặc scheduled task chạy dưới.
• Thiết lập đơn giản “không đổi lại được”: thiết lập đến từ mẫu quản trị thường không đổi được bởi người dùng trên giao diện (mục bị làm xám). Việc “cứ nhờ khách đổi thiết lập” không chạy được có hệ quả thật với cách bạn thiết kế hướng hỗ trợ.

flowchart TB
    accTitle: Giả định ứng dụng mà GPO khách đổi
    accDescr: GPO của khách hàng đổi giả định của ứng dụng bằng cách bắt buộc execution policy, tắt gộp quy tắc firewall cục bộ, phân phối ổ đĩa và proxy, và khóa người dùng không đổi lại được thiết lập, thành một nguyên nhân chỉ hỏng tại khách
    gpo["GPO của khách"] --> ep["Bắt buộc execution policy"]
    gpo --> fw["Tắt gộp quy tắc cục bộ"]
    gpo --> env["Phân phối ổ đĩa và proxy"]
    gpo --> lock["Không đổi lại được thiết lập"]
    ep --> sym["Một nguyên nhân chỉ hỏng tại khách"]
    fw --> sym
    env --> sym
    lock --> sym

Hình 19: GPO của khách âm thầm viết lại giả định của ứng dụng — execution policy, firewall, cấu hình môi trường, và nữa.

Có ba sự chuẩn bị thực tế phía phát triển. Thứ nhất, ghi thành yêu cầu triển khai các giả định môi trường ứng dụng phụ thuộc — execution policy, cổng lắng nghe, nơi ghi, đường proxy, và tương tự — rồi nhờ IT khách xác nhận chúng trước khi triển khai. Thứ hai, khi sự cố xảy ra, kiểm báo cáo gpresult /h thật và giá trị thực dưới HKLM\Software\Policies, chứ đừng đoán (Chương 5). Thứ ba, tách từ giai đoạn thiết kế xử lý nào cần đặc quyền quản trị viên và xử lý nào không (ranh giới này được vẽ trong “Khi nào thật sự cần đặc quyền quản trị viên trên Windows — UAC, vùng được bảo vệ, và cách phân biệt từ thiết kế”). GPO không phải kẻ thù — đó là đặc tả của môi trường. Coi nó là đặc tả, và phân tách trở thành máy móc.

flowchart TB
    accTitle: Ba sự chuẩn bị phía phát triển
    accDescr: Sự chuẩn bị phía phát triển gồm ba việc: ghi giả định môi trường ứng dụng phụ thuộc thành yêu cầu triển khai và nhờ IT khách xác nhận trước khi triển khai; khi sự cố thì xác nhận báo cáo gpresult và giá trị thực khóa Policies; tách từ giai đoạn thiết kế các xử lý cần đặc quyền quản trị viên
    dev["Sự chuẩn bị phía phát triển"] --> doc["1. Ghi giả định môi trường"]
    dev --> chk["2. Xác nhận bằng gpresult và giá trị thực"]
    dev --> priv["3. Tách nhu cầu đặc quyền lúc thiết kế"]
    doc -.-> ask["Nhờ IT khách xác nhận trước khi triển khai"]

Hình 20: Ba sự chuẩn bị phía phát triển: ghi giả định môi trường, xác nhận bằng gpresult và giá trị thực, và tách nhu cầu đặc quyền quản trị viên lúc thiết kế.

9. Tóm tắt

• Group Policy là cơ chế xử lý thiết lập cấp GPO theo thứ tự cục bộ → site → miền → OU (LSDOU), và xung đột được giải theo kiểu cái xử lý sau thắng. GPO trên OU gần đối tượng nhất là lớp mạnh nhất, và GPO cục bộ là yếu nhất.
• Block Inheritance, Enforced, và lọc bảo mật cho phép bạn kiểm soát luồng mặc định. Enforced còn thắng cả Block Inheritance, nên không nên lạm dụng.
• Việc áp diễn ra qua hai kênh: xử lý tiền cảnh lúc khởi động/đăng nhập, và cập nhật nền mặc định khoảng mỗi 90 phút cộng offset ngẫu nhiên. gpupdate /force áp lại mọi thiết lập, nhưng không có hiệu với thiết lập chỉ được xử lý lúc đăng nhập hoặc khởi động lại.
• Khi thiết lập không được áp, hãy phân tách máy móc theo thứ tự gpresult /h → nhật ký vận hành GroupPolicy → khóa Policies trên registry. GPO bị từ chối được hiện kèm lý do.
• Định nghĩa mẫu quản trị là ADMX/ADML, và vận hành miền nên gom chúng trong central store trên SYSVOL. Khi cập nhật, thay phía central store chứ đừng thay thư mục PolicyDefinitions cục bộ.
• Dùng GPO hay Intune được quyết bởi nền tảng danh tính và vị trí thiết bị; trong hybrid, tránh cấu hình kép cùng một thiết lập và giữ chủ thể quản ở một bên. Group Policy analytics giúp phân loại khi di chuyển.
• Với nhà phát triển, GPO của khách là một phần đặc tả môi trường. Ghi giả định quanh execution policy, firewall, ánh xạ ổ, và cấu hình proxy, rồi thành thói quen xác nhận chúng bằng gpresult — và hầu hết các vụ “chỉ hỏng tại khách” thôi đáng sợ.

Bài viết liên quan

• Windows Firewall và ứng dụng nghiệp vụ — đăng ký quy tắc vào từ trình cài đặt
• Quản lý Windows Update sau khi WSUS ngừng phát triển — cách chọn giữa WUfB, Autopatch, và Intune
• Execution policy PowerShell và ký tập lệnh — hướng dẫn thực tế thoát khỏi “che bằng Bypass”
• Tự động hóa cấp phát PC bằng winget + PowerShell — làm runbook chạy được
• Hướng dẫn thoát phụ thuộc IE Mode
• Khi nào thật sự cần đặc quyền quản trị viên trên Windows — UAC, vùng được bảo vệ, và cách phân biệt từ thiết kế

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

KomuraSoft LLC đảm nhận điều tra vì sao ứng dụng nghiệp vụ không chạy trong môi trường khách dưới quản lý GPO, sắp xếp yêu cầu triển khai (execution policy, firewall, giả định mạng), và tư vấn kỹ thuật về kiểm kê chính sách cùng phương án dùng chung Intune cho nhân viên IT đã tiếp nhận môi trường AD. Bắt đầu từ giai đoạn “hãy cùng đọc báo cáo gpresult” cũng được.

• Tư vấn kỹ thuật và đánh giá thiết kế
• Điều tra lỗi và nguyên nhân
• Phát triển ứng dụng Windows
• 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.

Tôi đã chạy gpupdate /force nhưng thiết lập vẫn chưa được áp. Vì sao?

Trước hết hãy kiểm xem thiết lập đó có thuộc loại "cập nhật nền không bao giờ áp" hay không. Cài phần mềm hướng người dùng và folder redirection chỉ được xử lý lúc đăng nhập, còn cài phần mềm hướng máy tính chỉ lúc khởi động, nên sau khi gpupdate xong bạn cần đăng xuất (/logoff) hoặc khởi động lại (/boot). Tiếp theo, chạy gpresult /h để xuất báo cáo RSoP và kiểm GPO đó có trong "Applied GPOs" hay nằm trong "Denied GPOs" kèm lý do. Nếu đã được áp mà hành vi không đổi, hãy nghi GPO khác có ưu tiên cao hơn đang ghi đè cùng thiết lập (cái xử lý sau thắng). Báo cáo hiện "Winning GPO" cho từng thiết lập, nên bạn xác định được chính xác GPO nào đang thắng.

gpresult hiện "Denied - Filtering" nghĩa là gì?

Nghĩa là GPO đó nằm trong phạm vi theo vị trí liên kết, nhưng bộ lọc đã loại nó khỏi việc thật sự được áp. Nguyên nhân phổ biến nhất là lọc bảo mật: để GPO được áp, người dùng hoặc máy tính phải giữ cả hai quyền "Read" và "Apply group policy" trên GPO đó. Mặc định cả hai được cấp cho Authenticated Users, nhưng nếu bạn thu hẹp vào nhóm cụ thể, quên thêm nhóm hoặc quên thêm tài khoản máy tính sẽ gây từ chối. Với GPO hướng người dùng, cấp cả hai quyền chỉ cho người dùng đích vẫn chưa đủ. Từ MS16-072, chính sách người dùng được lấy dưới ngữ cảnh bảo mật của máy tính, nên phải để lại "Read" (không cần "Apply") cho Authenticated Users hoặc Domain Computers. Nguyên nhân khác gồm bộ lọc WMI không khớp, hoặc chính GPO đã tắt cấu hình người dùng/máy tính. Lý do từ chối được ghi cả trên báo cáo gpresult lẫn nhật ký vận hành GroupPolicy.

Nên quản thiết bị bằng GPO hay Intune?

Quy tắc cơ bản là khớp nền tảng danh tính của thiết bị. Nếu máy chủ yếu domain-joined vào AD tại chỗ và luôn nối mạng nội bộ, GPO là lựa chọn chắc chắn và chi tiết nhất. Nếu tăng máy Microsoft Entra-joined, hoặc máy làm việc từ nhà không bao giờ chạm domain controller, Intune (MDM/CSP) — vốn phân phối cấu hình cả ngoài văn phòng — phù hợp hơn. Trong môi trường hybrid nơi cả hai cùng tồn tại, cấu hình cùng một thiết lập qua cả GPO lẫn MDM gây xung đột không bảo đảm bên nào thắng, nên nguyên tắc là quyết theo từng vùng thiết lập bên nào quản, rồi gom về một bên. Khi bắt đầu cân nhắc di chuyển, nhập GPO hiện tại vào Group Policy analytics của Intune giúp phân loại thiết lập đã được MDM hỗ trợ và thiết lập không hỗ trợ hoặc deprecated.

Nội dung tôi cấu hình bằng trình soạn thảo Group Policy cục bộ (gpedit.msc) bị thiết lập miền ghi đè. Đó có phải đặc tả không?

Đúng, đó là hành vi theo thiết kế. Group Policy được xử lý theo thứ tự cục bộ → site → miền → OU (LSDOU), và GPO nào xử lý sau thì thắng khi xung đột, nên GPO cục bộ là lớp yếu nhất. Nếu GPO miền cấu hình cùng thiết lập, thay đổi cục bộ luôn bị ghi đè. Ngược lại, nếu phía miền để thiết lập đó là "Not Configured", giá trị GPO cục bộ vẫn đứng. Dù bạn muốn ưu tiên thiết lập cục bộ để kiểm thử, không có cách đảo thứ tự ưu tiên này trên PC domain-joined, nên cách thực tế là tạo OU kiểm thử rồi chỉnh GPO phía miền, hoặc dùng máy kiểm thử không tham gia miền.

Ứng dụng nghiệp vụ chúng tôi phát triển chỉ không chạy trong môi trường khách. Có cách nào kiểm xem nguyên nhân có phải GPO không?

Bước đầu là nhờ quản trị viên phía khách chạy gpresult /h report.html từ command prompt nâng quyền trên PC gặp sự cố và đọc báo cáo RSoP. Tìm các thiết lập sẽ đổi hành vi ứng dụng: tập lệnh bị chặn bởi execution policy, gộp quy tắc firewall cục bộ bị tắt, hoặc proxy và ánh xạ ổ đã cấu hình. Cũng nên kiểm xem giá trị chính sách của sản phẩm liên quan đã được ghi dưới HKLM\Software\Policies và HKCU\Software\Policies trên registry chưa — cách đó giúp đánh dấu máy móc các thiết lập bắt buộc đến từ mẫu quản trị. Phía phát triển, sự chuẩn bị thực tế là ghi các giả định ứng dụng phụ thuộc — execution policy, cổng lắng nghe, thư mục ghi, v.v. — thành yêu cầu triển khai, và nhờ IT khách xác nhận trước khi triển khai.

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.