"Cached" GPO settings
I set a desktop wallpaper GPO and it appeared to be working correctly. I then overwrote the JPG that's stored on the server with another JPG with the same name but it wouldn't change on the client. I ran a gpupdate /force and still to no avail. It wasn't until I add the new JPG under a different name that it updated, but only after a restart of the client.
Is there a way to have the clients update even if the file names were the same? Why didn't it change the JPG when overwriting the file?
Is there a way to have the clients update even if the file names were the same? Why didn't it change the JPG when overwriting the file?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Cliff Galiher
There is no good way o do what you want. It isn't that the GPO is cached, but how windows converts jpeg files to bitmap files when first applied. The behavior in this instance is expected md can't easily be changed due to underlying architecture decisions made almost two decades ago.
Its depends on how you set GPO..
1st of all old and new wallpaper size should not have much difference, or it may get difficulties to render / fix wallpaper on desktops post replacement
If you set clients to directly look on server share path for wallpaper, it may get issues over WAN because in that case some times client won't be able to pickup / render wallpaper on desktop
However within same network this should not be a problem and changed wallpaper should apply
If you are copying wallpaper 1st on workstations and use local path in GPO for applying wallpaper, then you must replace destination file
In that case you should use GP preferences to copy file on workstations with replace mode so that file will get overwritten for sure
If you are using script, some times script fails to copy and overwrite file
I always use GP preference to copy file with same name on clients in replace mode and it works well
Mahesh.
1st of all old and new wallpaper size should not have much difference, or it may get difficulties to render / fix wallpaper on desktops post replacement
If you set clients to directly look on server share path for wallpaper, it may get issues over WAN because in that case some times client won't be able to pickup / render wallpaper on desktop
However within same network this should not be a problem and changed wallpaper should apply
If you are copying wallpaper 1st on workstations and use local path in GPO for applying wallpaper, then you must replace destination file
In that case you should use GP preferences to copy file on workstations with replace mode so that file will get overwritten for sure
If you are using script, some times script fails to copy and overwrite file
I always use GP preference to copy file with same name on clients in replace mode and it works well
Mahesh.
As per above deploy files via GPP. See my article
https://www.experts-exchange.com/articles/29069/How-to-apply-a-dynamic-background-via-Active-Directory-GPP.html
https://www.experts-exchange.com/articles/29069/How-to-apply-a-dynamic-background-via-Active-Directory-GPP.html
Yes, like "Fonts".
Push the the JPG should be in the image or pushed down to the client.
The GPO? Set to Linked and Enforced.
Just like Fonts.
Best to have the JPG local to each workstation. Doesn't work any other way with Fonts.
There are 5 tags listed. Windows 2016, Windows 2010, Azure, Windows Server OS, Windows 10.
Here is the thing about GPO's, regardless of what version of AD. "Central Store".
You must create the GPO, with RSAT tools, from the OS that applies. If Windows 7, different base GPO's, different Central Repository.
Windows 8.1?
Windows 10?
Windows 2012?
Completely different GPO Central Repository.
Unfortunately, you cannot logon to Windows 2012/2016 and just create a GPO from scratch and expect it to apply to all operating systems.
Doesn't work that way without some Pixie dust.
If you truly want Windows 10 GPO policies to work right, GPP or not. Run the Group Policy Admin Tool from Windows 10, while on the domain, and as a Domain Admin, and create a Windows 10 Central Repository. Then, link enable, then enforce.
Every JPG, every Font, local to every WIN 10 workstation. If you want 100% success.
Windows 10 in their own OU
Windows 8.1 in their own OU
Windows 7 in their own OU.
Server 2012R2, own OU.
Server 2016, own OU
2008R2, own OU (No, not Windows 7).
And each one, having their own GPO. Configured from that OS.
Works everytime.
Push the the JPG should be in the image or pushed down to the client.
The GPO? Set to Linked and Enforced.
Just like Fonts.
Best to have the JPG local to each workstation. Doesn't work any other way with Fonts.
There are 5 tags listed. Windows 2016, Windows 2010, Azure, Windows Server OS, Windows 10.
Here is the thing about GPO's, regardless of what version of AD. "Central Store".
You must create the GPO, with RSAT tools, from the OS that applies. If Windows 7, different base GPO's, different Central Repository.
Windows 8.1?
Windows 10?
Windows 2012?
Completely different GPO Central Repository.
Unfortunately, you cannot logon to Windows 2012/2016 and just create a GPO from scratch and expect it to apply to all operating systems.
Doesn't work that way without some Pixie dust.
If you truly want Windows 10 GPO policies to work right, GPP or not. Run the Group Policy Admin Tool from Windows 10, while on the domain, and as a Domain Admin, and create a Windows 10 Central Repository. Then, link enable, then enforce.
Every JPG, every Font, local to every WIN 10 workstation. If you want 100% success.
Windows 10 in their own OU
Windows 8.1 in their own OU
Windows 7 in their own OU.
Server 2012R2, own OU.
Server 2016, own OU
2008R2, own OU (No, not Windows 7).
And each one, having their own GPO. Configured from that OS.
Works everytime.
These links, will provide, evidence, if needed. Everything you need.
Reference 1
and
https://www.microsoft.com/en-us/download/details.aspx?id=25250
Reference
Reference 1
and
https://www.microsoft.com/en-us/download/details.aspx?id=25250
Reference