Struggling to Apply Desktop Wallpaper GPO: Security Denied Issue

0
2
Asked By TechieWizard42 On

I'm trying to set a desktop wallpaper for certain computers using Group Policy Objects (GPO), and I'm hitting a snag. The wallpaper setting is found under User Configuration (User Config -> Admin Templates -> Desktop -> Desktop -> Desktop Wallpaper). Here's what I've done so far:

- The computers that should get the GPO are in a Universal Security group.
- I created a GPO to set the Desktop wallpaper (complete with the image path) and linked it to a GPO above the applicable computers and the security group.
- I've enabled Loopback processing in Merge mode.
- I added the Universal Security Group to the GPO's Security Filtering and removed Authenticated Users.
- I then added Authenticated Users back to Delegation with just "Read" rights.
- Finally, I made sure the target hosts can access the wallpaper file location.

When I check with GPresult as a standard user, the GPO is listed but it's denied due to security issues:

Apply-Wallpaper
Filtering: Denied (Security)

Running GPresult as an elevated user with computer scope confirms the GPO is listed, but it's not applied. I'm wondering what I might be missing here. I've heard something about needing to apply User configuration based on computer object membership, but I thought Loopback handled that. Plus, I made sure to re-add the Read permission for Authenticated Users. Any ideas?

1 Answer

Answered By AdminGuru88 On

It sounds like you're on the right track! If you're aiming to have those Windows 10 systems show a specific wallpaper, linking the GPO directly to the OUs with those users could solve the problem. Just set the Security Filtering to allow Authenticated Users—this might ensure the GPO is applied without issues. Alternatively, you could incorporate the wallpaper settings into an existing GPO that’s already applying successfully. It's often easier to modify GPOs that are working than to troubleshoot one that's encountering security denials.

PixelPlayer99 -

That's a good point! But the issue is that the affected systems are mixed in with already updated systems across multiple OUs. I can't just throw them all into a single OU because we have other essential GPOs in play.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.