on-premises Active Directory

Question

on-premises Active Directory

abdo elbarbary 70

experiencing an issue where Group Policy Objects (GPOs) created in the on-premises Active Directory are not being applied to the targeted workstations. The gpresult /r command output does not show the configured GPOs on the affected devices.

0 comments

2 answers

Your answer

Answer 1

Hello abdo elbarbary,

when Group Policy Objects are not applying and gpresult /r does not list them, the root cause is usually that the workstation cannot contact a domain controller or the GPO scope does not match the computer or user. The first step is to confirm that the machine is joined to the domain and that DNS is resolving the domain controllers correctly; without proper DNS, the workstation will fall back to local policy only. Next, check the GPO scope in the Group Policy Management Console to ensure the object is linked to the correct OU and that security filtering includes the affected computer or user account. If WMI filters are in use, verify that the filter conditions are satisfied on the target machine.

On the client side, run gpupdate /force and then review the System and GroupPolicy logs under Event Viewer → Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational. Errors such as 1058 or 1030 will indicate replication or access issues. If no errors appear but the GPOs still do not apply, it is often a replication latency problem between domain controllers, so confirm SYSVOL consistency with dfsrdiag pollad and check that the policy files exist under \\domain\SYSVOL\domain\Policies. Only once these checks are clean will the GPOs appear in gpresult.

If my answer is useful for you, please hit Accept the answer to support me.

Thank you,

QQ.

Answer 2

Use the built-in Group Policy troubleshooting tools on an affected workstation to determine why the GPOs are not applying and then correct the specific cause.

Collect Resultant Set of Policy (RSoP)
1. Run the following on an affected workstation:
```
      gpresult /h gp.html
```
2. Open gp.html and look for the missing GPOs under both Computer Configuration and User Configuration.
3. Check the “Denied GPOs” or error section at the bottom; it will state why each GPO is not applied (for example, security filtering, WMI filter, permissions, or other denial reasons).
Check Group Policy event logs
1. Open Event Viewer on the affected workstation.
2. Review:
  - Application and System logs for Group Policy–related errors.
  - Applications and Services Logs → Microsoft-Windows-GroupPolicy → Operational.
3. In the Operational log:
  - Event ID 4116 marks Group Policy processing start; 8005 marks completion.
  - Compare the list of applied and denied GPOs.
  - Look for events that show the missing GPOs being denied and note the reason (for example, access denied, WMI filter evaluation, or DC connectivity issues).
Verify GPO permissions and security filtering
1. In Group Policy Management Console (GPMC), open the affected GPO.
2. On the Delegation tab, ensure:
  - The target computers (or a group containing them) have Read permission.
  - The target users/computers also have Apply group policy permission if required.
3. If computer objects do not have Read permission, create a group for those computers, add them, and grant that group Read (and Apply if needed) on the GPO via the Delegation tab.
4. Run gpupdate /force on the client and re-check gpresult.
Compare working vs non-working clients
1. On a working machine where the GPO applies, collect:
```
      gpresult /h gp_working.html
```
2. Compare gp_working.html with gp.html from a failing machine to see:
  - Which GPOs are present on the working machine but missing on the failing one.
  - Any differences in denied GPOs or error messages.
3. If needed, export and compare Group Policy Operational logs from both machines to identify differences in DC selection, GPO counts, or processing paths.
If no obvious error appears
1. Follow the checklist:
  - Confirm the GPO is linked to the correct OU/site/domain where the computer/user resides.
  - Confirm the link is Enabled and the GPO is not set to Disabled.
  - Confirm no higher-level GPO or OU has Block Inheritance or Enforced settings that override the target GPO.
2. If still unresolved, enable GPSvc verbose logging as described in the guidance and review the resulting logs for detailed processing information. Use this only temporarily because of performance and disk-space impact.

These steps will identify whether the issue is due to permissions (no Read/Apply), filtering (WMI or security), DC connectivity, or link configuration, and allow correction so the on-premises GPOs appear in gpresult and apply to the targeted workstations.

References: