 |
 |
On 26/09/2017 17:43, Chris McEvoy wrote: > Hi, > > We've deployed Windows 10 Education 1703 to our IT labs and teaching > room PCs over the summer and we thought we'd got a solution for > changing the lockscreen background (both temporarily during imaging > or maintenance, and permanently after imaging was complete) having > tested it on previous Windows 10 versions. However, it seems since > 1703 was released the scripted methods for changing it temporarily > and the GPO for changing it permanently have become, shall we say, > unreliable. It seems sometimes it works, sometimes it doesn't change > at all and other times we just get a blank blue screen. > > It was supposedly fixed in a non-security cumulative update back in > May but it still doesn't work reliably for us. > > Has anyone else had similar issues or, even better, got a working > solution to changing the Windows 10 lockscreen image for 1703 via a > script or GPO? Yes, this seems to be a known issue, much disussed on technet, but no proper fix as yet. Specifying a lockscreen results in Windows trying to cache the image you've told it to use (which is fair enough as you can supply a UNC path to the image). This caching mechanism is not reliable, and can fail to cache the image properly. This failure to cache can happen either initially when it picks up the policy for the first time, or any time subsequently if the source image is updated. I think it's also possible for it to fail to notice that the source image has been updated, and continue to display the cached version. Not sure if that's still true as we now work around the problem. There are a number of ways of working around it, but essentially you either need to clear the cache or clear it and populate it correctly. The relevant folder is (for us): C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P I have seen reports of other users seeing LockScreen_Z instead, but it's always LockScreen_P for us. This folder is extremely locked down such that drastic measures are needed to make it writeable even to and administrative account. An alternative method is to have a scheduled task that runs as system - this has the rights to do what's needed without changing the rights assignments on disk. So, we have a scheduled task that runs a script that creates all the path elements as needed down to LockScreen_P, deletes the contents, and populates it with the correct image as lockscreen.jpg. Windows will then generate versions of this at various small thumbnail resolutions, plus one at the current windows resolution. We set this scheduled task to run once at some point in the distant past and not repeat, which means it only runs when manually triggered. We then trigger it whenever the lock screen image needs updating, which is once at the end of post-imaging, and again if the lock screen gets updated. For staff PCs, this is relatively rare, but for bookable student rooms we include the booking info for that day on the lockscreen image, and regenerate the image every morning just after midnight. Stripped down to its basics, our task does this (probably line wrapped): if not exist C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18 md C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18 if not exist C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly md C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly if not exist C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P md C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P if not exist C:\windows\mwsbackdrop\current\mwsbackdrop.jpg exit 1 del /f C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\*.jpg copy /y C:\windows\mwsbackdrop\current\MWSBackdrop.jpg C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\lockscreen.jpg In our case the lock screen image is generated locally at each PC, and is stored in C:\windows\mwsbackdrop\current\mwsbackdrop.jpg This method seems to work reliably, and avoids rights changes or changes to the windows\web folder (both of which may be undone on an update/upgrade). However, all of these fixes depend on how this caching system happens to work, and an update/upgrade might change that at any time. Also, once you have something like this in place, you have to go out of your way to see if the underlying issue has been fixed in the meantime. Mike -- Mike Sandells The University of Liverpool - Computing Services Department Email: [log in to unmask] (*Preferred*) - Phone: 0151 794 4437 http://www.liverpool.ac.uk/csd