Inheritance Blocking Linked GPOs Above an OU

[jmehrmann]

Hi everyone,

This is my first post on this account and first post in many years (another account).

I’ve hit a snag trying to apply a GPO with a Scheduled Task to automate rebooting computers on a regular basis. I created the Scheduled Task under Computer Configuration/Preferences/Control Panel Settings/Scheduled Tasks so it would apply to the system and not the user account. The Action is set to Create as this task does not exist on the computers now.

In Security Filtering, the GPO is set to apply to the default Authenticated Users group and a group I created, WindowsPCs, containing test computers (spare inventory). It is linked at the top/domain level now.

The policy is being blocked, but I can’t figure out where it’s being blocked from. When I run “gpupdate /force” on the 2 workstations, the User Policy updates successfully, but the Computer Policy hangs and returns, “Computer Policy has not completed in the expected timing. Exiting…”

When I run “gpresult,” it shows: “Inheritance is blocking all non-enforced GPOs linked above domain.com/CUSTOM-COMPUTER-OU/GPO-Testing”

“GPO-Testing” is an OU I created for testing purposes, but have since removed from AD. The policy was originally linked here for testing, but I exported and recreated it at the top-level when I started having problems. I thought the issue might then be that the exported GPO still has references to the deleted OU, but after recreating the policy from scratch, the issue persists.

The GPO is also “Enforced” to try to get around the Inheritance, but it didn’t work. Event Viewer isn’t showing any other issues with it. Events are showing the policies process successfully.

I suspect the OU was not truly deleted, or there is some other AD problem where it’s holding onto this reference.

A little background info: I inherited this Active Directory domain recently, where 2-3 different sets of vendors were responsible for managing servers over the years, as well as an admin whose skillset I’m not familiar with. As you can imagine, I’ve been doing a lot of cleanup, but I suspect there are some hidden issues.

Any help or advice would be greatly appreciated. I’ve checked a few other threads, but they didn’t seem to fit my scenario. I’ll keep researching in the meantime. Thank you!

[spiceuser-noob39]

Hello,

I have few questions and idea. I didn’t see anywhere in the post mentioning any replication between another DC, so I am guessing it’s a stand alone controller. The OU could have been back up or exported, which might be hard to identify since you didn’t stand it up. Also, you mentioned you don’t know his background or the process for creating it it could be possible a third-party app could have created an OU. Some of these options wouldn’t explain the bypassing it being enforced.

Do any of the GPOs have block inheritance enabled? Are there any other GPOs that have enforced enabled? Can you create a fresh environment virtual would be easiest, and trying the GPO in the same manner and seeing if it applies correctly?

Another idea, instead of create have you tried using update, since the old gpo was the one creating the task and is already applied, maybe updating could work, but that wouldn’t explain the results error.

Are the workstations still in the OU that the original GPO was attached to? Maybe take them out of the OU.

Just some ideas.

[jmehrmann]

Hello SpiceHead-Noob39,

Thanks for the reply and ideas. There are two DC’s in the domain and replication appears to be working between them. Repadmin /replsummary looks like this:

Source DSA largest delta fails/total %% error
****DC1 09m:10s 0 / 5 0
****DC2 09m:51s 0 / 5 0

Destination DSA largest delta fails/total %% error
****DC1 09m:51s 0 / 5 0
****DC2 09m:10s 0 / 5 0

0 Items remaining in the queue for /Queue, and last attempts at replication were successful:

.Last attempt @ 2023-04-21 12:05:19 was successful - for all categories.

I’m not sure what you mean by “since you didn’t stand it up.” Could you elaborate?

It’s certainly possible previous work was done via a 3rd-party app, but I don’t know the answer. Unfortunately, there’s not a lot of documentation on what was done, when, or by whom. I’ll check it out and see if I find any references to something.

None of the OUs have Block Inheritance enabled-that’s what’s driving me crazy as that would explain it.

I didn’t try “Update” since the task does not exist on the workstation. From what I understand, this would only work if it already exists, but I will try it. I’ve seen weirder things. I’ll update once I give that a shot.

No, the original OU was deleted and the workstations moved out of it. One is in different OU than the other, but both are a member of the WindowsPCs group to which the GPO applies. Per your suggestion, I’ve moved the oddball workstation into the same OU as the other. We’ll see what happens.

Much appreciated!

[jmehrmann]

Update: I tried the Update Action and the task still does not get created and is still referencing the deleted OU in the report. I moved the workstation and turned off Enforcement to see if that had any effect. Enforcement put the policy first in line above the Default Domain Policy in Group Policy Inheritance. Turning off Enforcement puts it at the bottom of the list, as it should, below two other policies I created prior that work.

I also enabled the Recycle Bin in AD Admin Center as well, but I’m not seeing any Deleted Objects in there. I reached out to one of the vendors who did migrations before my time to see if they can offer any insight, but I’m not sure I’ll get a response.

[jmehrmann]

Happy Monday,

A few updates here: I didn’t get an answer from the original vendor, but a current vendor who migrated servers from the former believes that Scheduled Tasks are no longer allowed to be applied via GPO due to malware. That didn’t seem likely, being such a useful feature, but it reminded me there are settings that block new task creation:
“Prohibit New Task Creation” (one each in Computer Configuration and User Configuration)
It states: This setting does not prevent administrators of a computer from using At.exe to create new tasks for prevent administrators from submitting tasks from remote computers.
Both are “Not Configured” so that doesn’t seem to be the issue either (verified on local machine). I’m considering setting them both to Disabled.
I also checked the registry on the test machines, and don’t see a Task Scheduler entry preventing Task Creation under \HKLM\Software\Policies\Microsoft\Windows. I saw this in a thread while doing research.

I also tested creating the task on the local machine, and the task rebooted the computer at the specified time (shutdown.exe /r /c “System Maintenance Restart”)
A few changes I’ve tried (ensuring changes are replicated between DCs):

• changing the Action to “Update” from “Create” (as suggested above), and back to “Create” again on subsequent tries
• removing “Authenticated Users” and adding “Domain Computers” to Scope
• removing Domain Computers and keeping only the two test computer accounts
• removing the original policy and creating a new one fresh, linking it to the top-level (different names as well)

At this point, I’m going to create the same task in the Default Domain Policy as a test and set the first trigger for a future date, just to see if the same task will be applied that way.

Hoping someone can think of something else to try. Thanks all.

[jmehrmann]

I’ve solved this problem, and I’m a little embarrassed that I missed this. The issue was caused by the choice I made when creating the task. I chose the first option in the menu and didn’t pay attention to the 3rd option:

After removing the original task, I created a new task using the 3rd option and got the expanded GUI, and the new task was applied the first time I ran gpupdate /force. The computer then rebooted on schedule.

It’s been some time since I created a Scheduled Task via GPO, and didn’t even think to look at the first step. I must’ve glossed over the menu and clicked too fast. Still, the message in the results file is quite misleading as Inheritance was not blocking he . I’ve been looking in the wrong place the whole time.

Thanks SpiceHead-Noob39 for replying and to anyone else who spent the time to read this and consider offering some advice. Onto the next project!