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