Hi Mike,



No - It's actively broken in 1803 and only takes effect after a user has logged in.



Post here to drum up some more visibility:



https://social.technet.microsoft.com/Forums/windows/en-US/1664b0ab-f1d8-4e60-8337-13f079a33752/windows-10-1803-custom-loginlock-screen-image-is-not-applied-until-a-user-logs-in?forum=win10itprosetup#5892fb83-116e-48ca-a1d4-d61403a5f3d1



Rich Mawdsley







-----Original Message-----

From: Support issues for windows in UK HE & FE <[log in to unmask]> On Behalf Of Mike Sandells

Sent: 25 May 2018 12:11

To: [log in to unmask]

Subject: Re: Windows 10 (1607/1803) LockScreen and Pre-Login Screen



On 25/05/2018 11:48, Ben Allsup wrote:

> I appreciate that there was a discussion about this last year, but 

> we've had quite a few issues recently that we would appreciate some 

> help/guidance on.

> 

> 1) Our current build is 1607 and we copy down an image and set the 

> wallpaper/lockscreen/pre-login screen via GPO at the end of the 

> imaging task sequence in SCCM. If the task sequence fails, then we 

> send a bright red "ERROR" screen so that the technicians know that it 

> failed and they don't start using a broken image. This worked fine 

> until fairly recently, where we are now getting a blank blue screen 

> until the first logoff or lock event, then it updates to the correct 

> image. We can only assume that a Windows Update in the last couple of 

> months triggered this change but unfortunately we've only just noticed 

> it. If you copy the jpg into the System Lockscreen_P folder, then this 

> fixes it. This is not too much of a problem as we will be moving to 

> 1803 in the summer. Except that...

> 

> 2) on 1803 Task Sequence, the file copy does not appear to fix the 

> problem and after initial imaging we are always presented with a blank 

> blue screen rather than a customised working one or a red ERROR one. 

> This does go away once the first user logs OFF the PC and all is fine.

> 

> Believe me when I say we have spent hours trying to delete and 

> re-apply files/registry keys/GPOs etc in order to get this working.

> We even had an occasion when GPOs were applying during the SCCM task 

> sequence (impossible according to Microsoft).

> 

> My question therefore is has anyone managed to get the Pre-login 

> screen to be correct after imaging (prior to the first logon of the

> PC) and how. We are open to any suggestions and innovative solutions.





This is all very familiar to us....



On 1607 we work around the problem by clearing out the folder where the

images are cached, and populating the lockscreen.jpg there ourselves.

The folder is



C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P



Rights on this are very locked down, but we work around that by having a

script to clear and populate the folder correctly that is run as a

scheduled task (and therefore can run as SYSTEM), and we then trigger

this task using schtasks whenever the image needs updating.



Duct tape and paperclips, but it works.





In 1803 populating the cache in this way doesn't work (for reasons we

are not clear on), and we can confirm the solid colour appears until a

user has logged on. This also now seems to be consistent rather than

intermittent behaviour.



Windows is clearly aware of the policy though, as otherwise you'd get a

normal default MS image rather than the solid colour. My current theory

on this is that the code to display the image from the cache is working,

but the code to populate the cache is only triggering on the logon

event, in the expectation that the lock screen is a per-user setting.

i.e. looks like a bug to us.



For our reimaging environment, this is not an issue as our post-imaging

stage uses auto-logon as a domain user and so we have at least one logon

after the policy applies. (In fact we don't even use GPO for this, and

just populate the registry key directly - that way it's in place and

working before domain join happens.)



Luckily, once it's noticed that it's supposed to be displaying an image,

it does then honour updates to that image reliably, as long as the file

is newer. For us, images are generated as needed, so always have a

current timestamp, but if using a mechanism that involves copying

existing files around it may need to timestamp them as well.



Where we do have this issue is on the staff side - you also get the

solid colour problem on the first boot after an in-place upgrade, and we

don't have an auto-logon there to fix it. So far we've just documented

that as a known issue and lived with it.



There's discussion of this on TechNet, but I've not seen any

acknowledgement from Microsoft that this is a known issue. We haven't

raised it with MS as it's only a problem for in-place upgrades in our

environment, but if it's more serious in your environment I'd suggest

opening a call.



Meanwhile, another thing to try might be to populate the registry key

for this and have a default image to display, and do this as part of

building the image you're deploying. That might allow you to get the

first logon done in the image rather than having the setting apply for

the first time after deployment. This does depend on how you build your

images though.



Also (long shot), maybe running something transient via RunAs.exe would 

count as a logon?





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