none
Windows 10 1803 - Custom Login/Lock Screen Image Is Not Applied Until a User Logs In RRS feed

  • Question

  • We are deploying Windows via SCCM CB in our environment, and have noticed that a Windows 10 1803 deployment no longer displays the custom login/lock screen image unless a user logs in to the computer first. Instead, the computer displays the solid blue colour associated with a lack of an available image and no Spotlight.

    Our task sequence removes all of the default images from the default location (C:\Windows\Web\Screen) and replaces them with our own, as well as clearing the contents from %ProgramData%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z

    We are also using the "Force a Default Lock Screen Image" GPO.

    The image is displayed after the task sequence concludes on a 1709 deployment, but not on 1803. Did the location of the default lock screen change? Or is there another reason that it would not apply until a user logs in?

    Curiously, as soon as any user logs in, the behaviour returns to normal.

    Friday, May 11, 2018 7:33 PM

Answers

  • The fix is now available @ https://support.microsoft.com/en-us/help/4458469


    - Jason E

    • Marked as answer by foxtrot_romeo Friday, October 12, 2018 12:56 PM
    Thursday, September 20, 2018 5:53 PM

All replies

  • Hi,

    We have not heard any information about default image location changes, also as the last result after user logon, it seems that there is no changes between Windows 10 1709 and Windows 10 1803 on this point.

    I noticed you deploy a group policy object to force a default lock screen image, however sync group policy in domain needs computers established network connection, according to my know, the network will establish after user logon. So I think that this why we saw the default blue solid color without spotlight on Windows 10 1803.

    Bests,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, May 14, 2018 7:31 AM
    Moderator
  • We've noticed this as well - it looks like the actions to populate the cache do not trigger until a user has logged on (even though the image to display is not dependent on or related in any way to the user).

    Populating the cache manually should work, but I can confirm that it doesn't work for us either.

    For fresh installs, we have an auto-login as part of our post-imaging process so that tends to sort itself out anyway.

    The problem also occurs following an in-place upgrade, and for that we're just living with it not working properly between coming out of the upgrade process and the first user login.

    It's not great, but at least it does fix itself reliably after that first login, which was not the case for 1703 (not sure about 1709).

    Monday, May 14, 2018 9:47 AM
  • Unfortunately, since the image was working as expected before, we know that network connectivity is not the issue. No changes whatsoever were made in the testing environment other than the OS edition. 1709 works as expected, 1803 does not.
    Monday, May 14, 2018 5:07 PM
  • I am seeing that it takes two reboots after the completion before the lock screen is there.  
    Monday, May 14, 2018 7:16 PM
  • We are experiencing exactly the same issue wih 1803. Tried presetting the registry value during task sequence, but that doesn't help, lock screen image is applied only after any user logs in.
    Tuesday, May 15, 2018 7:50 AM
  • Unfortunately, since the image was working as expected before, we know that network connectivity is not the issue. No changes whatsoever were made in the testing environment other than the OS edition. 1709 works as expected, 1803 does not.

    Likewise, for us the registry setting to force the pre-login lock screen is set directly (not delivered by GPO) much earlier, and the file it refers to is local. The network is not involved.

    Tuesday, May 15, 2018 9:18 AM
  • Same thing happening here, doesn't work whether we put the setting in a GPO, set it in the base image, or add a TS step.  Worked fine in 1607, 1703, and 1709.

    It definitely is not network connectivity.  We have carefully run through our build documentation multiple times with 1703, 1709, and 1803 and 1803 is the outlier.  University here as well so we're going to be imaging 1,500 or so lab PCs in about 60 days via SCCM.



    Tuesday, May 15, 2018 5:47 PM
  • I am in the same situation here. We previously used Windows 10 EDU (1703) and GP worked fine. We are now deploying Windows 10 Pro (1803) and we currently having issues getting the Custom Lock Screen image to display. Still wondering why issue is consistent with Windows 10 Pro.

    If anyone finds a fix please post!

    Thursday, May 17, 2018 5:27 PM
  • Hi,

    We have not heard any information about default image location changes, also as the last result after user logon, it seems that there is no changes between Windows 10 1709 and Windows 10 1803 on this point.

    I noticed you deploy a group policy object to force a default lock screen image, however sync group policy in domain needs computers established network connection, according to my know, the network will establish after user logon. So I think that this why we saw the default blue solid color without spotlight on Windows 10 1803.

    Bests,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    We have now had a few days of this issue being confirmed by other users. As we have consistently reported, the only difference here is the OS version - whether the images are populated in the default location, placed directly in the cache, or administered via a GPO, they are all failing to apply in 1803. Do you have any new insight as to where the files need to be populated, or how to direct the new behavior in 1803 to use the existing images? 

    Friday, May 18, 2018 6:02 PM
  • Is there any news on this. We discovered the same issue today while we start to test windows 10 1803 for our university. Our lock screen was working perfectly in Windows 10 1709.

    Cheers

    Wednesday, May 23, 2018 11:35 AM
  • Yep - same boat here, and have also had it confirmed by numerous users on WinAdmins Slack.

    Simply setting the "hklm\Software\Policies\Microsoft\Windows\Personalization - LockScreenImage" key to an image on the local disk, which has worked flawlessly for the past few Windows 10 revisions, does not work on 1803 until after a user has logged in and back out.

    This needs resolving.

    Wednesday, May 23, 2018 11:39 AM
  • No, not yet - I can't find any evidence that MS has even acknowledged this issue other than the reply above from Joy-Qiao.
    Wednesday, May 23, 2018 2:04 PM
  • I can confirm that we are also seeing the same issue. Whilst monitoring the lockscreen_P folder, we can see it being populated with the image files as a user logs off.

    I'm really hoping that Microsoft can get this fixed as like others we will be imaging a large amount of University computers over the summer.

    We also noticed that this also occurs if you use the upgrade path from 1607 to 1803.

    Friday, May 25, 2018 2:52 PM
  • I am currently testing this on Windows 10 EDU x64 (1803) w/latest updates on a VM.

    I have place the custom image on "C:\Windows\Web\Screen\"

    Enabled the Local GPO "Force a specific default lock screen and logon image" and entered path to custom image.

    Went into the Registry and verified that the String Value is pointing the the correct path where the custom image is located.

    Went on to "Settings-Personalization-Lock Screen" and the Settings Window Froze, not allowing me to click on anything. Just wanted to verify that the custom image was being displayed on "Preview" and "browse" was greyed out.

    Restarted the VM and I am now getting a Blue Lock Screen as a bakcground and not the "Custom1" image I set in place. Note: I have checked the dimensions/resolution/size of the .jpg image and it meets the requirements from MS.

    Is anyone else experiencing this on  Windows 10 x64 EDU (1803)? Similar results applied to Windows 10 Pro x 64 (1803) when I tested it earlier. I have no problems with this on Windows 10 x64 EDU (1703)
    Tuesday, May 29, 2018 11:54 PM
  • Same issue here with our 1803 Enterprise image. 1709 enterprise worked as expected...

    Any ideas?

    Monday, June 4, 2018 12:00 PM
  • I am currently testing this on Windows 10 EDU x64 (1803) w/latest updates on a VM.

    I have place the custom image on "C:\Windows\Web\Screen\"

    Enabled the Local GPO "Force a specific default lock screen and logon image" and entered path to custom image.

    Went into the Registry and verified that the String Value is pointing the the correct path where the custom image is located.

    Went on to "Settings-Personalization-Lock Screen" and the Settings Window Froze, not allowing me to click on anything. Just wanted to verify that the custom image was being displayed on "Preview" and "browse" was greyed out.

    Restarted the VM and I am now getting a Blue Lock Screen as a bakcground and not the "Custom1" image I set in place. Note: I have checked the dimensions/resolution/size of the .jpg image and it meets the requirements from MS.

    Is anyone else experiencing this on  Windows 10 x64 EDU (1803)? Similar results applied to Windows 10 Pro x 64 (1803) when I tested it earlier. I have no problems with this on Windows 10 x64 EDU (1703)

    Hi there - you say "Note: I have checked the dimensions/resolution/size of the .jpg image and it meets the requirements from MS". 

    I'd be grateful if you could share the location of these requirements as I haven't been able to find them via searching?


    Jonathan Conway

    • Edited by Jonathan Conway Tuesday, June 5, 2018 10:53 AM corrupt signature
    Tuesday, June 5, 2018 10:52 AM
  • It must be a 1803 problem.
    Wednesday, June 6, 2018 12:21 PM
  • Confirmed that I'm also seeing this issue with my pilot builds. Hopefully this is resolved more quickly than past lock screen issues of which there have been many.

    Cheers Damon Blog: www.damonjohns.com Twitter: https://twitter.com/DamonAJohns

    Sunday, June 17, 2018 9:41 AM
  • We have not started testing 1803 in our environment yet but have had lots of issues with lock screens on previous builds. Generally, it seems that PNG files are more reliable than JPG. Is anyone here using PNG?

    Secondly, has anyone contacted MS support directly?  This forum is mainly user to user support and unless they are aware of it internally, nothing will get fixed. 

    Monday, June 18, 2018 12:25 PM
  • Yep, this is an issue with 1803 but this is worst compared to 1703 update last year where it is really broken. This one is a bit light. In our case we have our wallpaper set by GPO and the files are located on the Windows folder. Log off/on refreshes the lock screen to what it is. This is evident on an in-place upgrade or fresh new builds.

    The work around we had in place back in 1703 was to change the regkey and make it look elsewhere using a different image and then revert it to the original one (your custom made) and resolves the issue too but it is a bit cumbersome process but I didn't bother applying the same on 1803 as you only need to log on/off to refresh it, provided you got everything in place and your GPO is applying.

    There is another bug too where if you set your STart Menu, in our case it is partially locked down, the GPO is failing to copy it down to the machine to use it. It knows there is a GPO for it but just won't do it properly. A work around is added a step in the TS to just copy the xml file and it works. Stinks TBH! But hey with these bugs, we keep to do some work and keep us in our jobs ehehe, otherwise if things are perfect then we won't be needed either :D

    Tuesday, June 19, 2018 4:19 AM
  • Same issue here on 1803 Education.  Please fix this Microsoft.

    Edit to say that we have only ever used .png files and they've worked fine in every version up till 1803.

    Tuesday, June 19, 2018 3:18 PM
  • We have not started testing 1803 in our environment yet but have had lots of issues with lock screens on previous builds. Generally, it seems that PNG files are more reliable than JPG. Is anyone here using PNG?

    Secondly, has anyone contacted MS support directly?  This forum is mainly user to user support and unless they are aware of it internally, nothing will get fixed. 


    Yes, I have reported the issue via the MS official support channels.
    Wednesday, June 20, 2018 6:24 PM
  • Hi all.

    I used Win10 LTSB v1607  in my labs last year and the custom lock screen worked as it should when applied using GPO. This year i'm using the same image but with the latest MS updates and i'm now experiencing the same issues you guys have.  Microsoft must have issued a KB with a bug... not like them at all!

    Thursday, June 21, 2018 2:10 PM
  • I'm seeing this issue too. It just started a few weeks ago, randomly on a handful of systems. When it happened, we just rebuilt it, and it seemed to work again. Now I'm trying to fix one that I don't want to rebuild, and can't get it to work. 

    Also using Win10 LTSB v1607. Custom background is absolutely essential for us. If anyone finds a solution, please let us know.

    Friday, June 22, 2018 4:50 PM
  • Hey guys,

    Just wanted to chime in on what is probably the issue for many of you. About two years ago, a Windows server update was released that changed the way in which GPOs were applied to systems depending on the delegation settings of a GPO object. Said patch is: MS16-072 / KB 3163622.

    In other words, if the above patch was installed on to the domain controller, and you did not add read permissions for the Authenticated Users group under the DELEGATION tab, you could expect to see some strange behavior. See more information on this at the following link: https://blogs.technet.microsoft.com/askpfeplat/2016/07/05/who-broke-my-user-gpos/

    Anyways, in our case, the fresh profile would logon, but the mapped drives linked to the GPO were not appearing. We confirmed that we could manually navigate to the shares, but the GPO was not functioning automatically. Even a gpresult /R command displayed the GPO listed which made things even more confusing.

    As soon as I added the 'authenticated users' group with read permissions to the GPO, the problem was resolved almost instantaneously. Hope this helps you all! Good luck. And yes, in case you are wondering, said system is on Windows10-1803.

    Edit/Update: Just wanted to say that I discovered just now that I have ran into this before, but added 'domain computers' in the delegation tab instead of authenticated users. So please read the above article I linked to and make up your mind. I wish I could give more clearer instructions, but it's a confusing issue even to myself.

    Cheers


    • Proposed as answer by ForrestGrump Monday, June 25, 2018 5:55 PM
    • Edited by ForrestGrump Monday, June 25, 2018 9:20 PM
    • Unproposed as answer by foxtrot_romeo Tuesday, June 26, 2018 12:26 PM
    Monday, June 25, 2018 5:55 PM
  • Hello, ForrestGrump:

    Thank you for your reply, but as many of us in this thread have stated, this was a policy which was functioning as expected prior to moving to 1803. I could see how you might reach this conclusion if this were a server upgrade or other work was being mentioned as performed as the server, but most of us are moving from 1709 to 1803, and only just now noticing the issue. Also, as this change was made by MS a back in 2016, I would venture a guess that almost everyone has a security group on each policy which includes their computer accounts as well as their users authorized for login with Read permissions for this policy.

    For this reason, I am unproposing your response as a solution, but someone may still be helped on this issue whom may not have made accomodations on their GPO delegation prior to this update.

    Tuesday, June 26, 2018 12:26 PM
  • Agreed.  That's not even close to the solution.

    Microsoft Premier support has been completely useless in helping with this as well.

    Jeff

    Tuesday, June 26, 2018 9:27 PM
  • Hi Robert, 

    We have known that this is really hot issue in Windows 10 1803 and involved senior resources on investigating this issue. 

    If there is any update, I will post back here. Thanks for your feedback here. 



    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Wednesday, June 27, 2018 5:12 AM
    Owner
  • Hi Kate,

    please bare in mind this is not only an issue with Win10 1803, as myself and others have started to now see the issue with the Win10 LTSB version. Where last year I used this with no lock screen issues, and this year the same LTSB version but with updates exhibits the same problem.

    KBs installed on my build are:

    KB4033631
    KB4049411
    KB4103729
    KB4132216
    KB4103720

    Wednesday, June 27, 2018 9:23 AM
  • Hi Kate, can we expect any updates, resolutions within this issue in the next hours? We, the IT provider for the Swiss Government, have the same issue on all 1803 installations. Doesn’t matter whether we wipe&load or inplace update from earlier W10 versions to 1803.

    We have a "must go productive" date next week for 1803 (2 month after day zero) for approx. 65'000 clients and this is the only behavior we have to blame on. Should I open a premier support case? If so, let me know a reference to which we can point.


    Thursday, June 28, 2018 4:13 AM
  • Hi All, 

    I have updated my Windows 10 to 17134.112, and in my Environment, I add a shared picture as forced lock screen on my DC. 

    Then, it worked fine after Windows 10 restart. Would you all have such issue please installed all latest updates for Windows 10 and check the results again?


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, June 28, 2018 7:47 AM
    Owner
  • Hello, ForrestGrump:

    Thank you for your reply, but as many of us in this thread have stated, this was a policy which was functioning as expected prior to moving to 1803. I could see how you might reach this conclusion if this were a server upgrade or other work was being mentioned as performed as the server, but most of us are moving from 1709 to 1803, and only just now noticing the issue. Also, as this change was made by MS a back in 2016, I would venture a guess that almost everyone has a security group on each policy which includes their computer accounts as well as their users authorized for login with Read permissions for this policy.

    For this reason, I am unproposing your response as a solution, but someone may still be helped on this issue whom may not have made accomodations on their GPO delegation prior to this update.

    Hi Robert, 

    I have also tested this issue via local GPO or deploying GPO via DC, when I get latest update on my Windows 10, there seems no such issue now. 

    Would you please test?


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, June 28, 2018 7:50 AM
    Owner
  • Hi All, 

    I have updated my Windows 10 to 17134.112, and in my Environment, I add a shared picture as forced lock screen on my DC. 

    Then, it worked fine after Windows 10 restart. Would you all have such issue please installed all latest updates for Windows 10 and check the results again?

    Problem still exists (unchanged) here.

    To test, I upgraded an existing PC (running 15063.1182) with the April 2018 update, using an update image that had had the latest cumulative slipstreamed into it, so was upgrading directly to 17134.137.

    On first boot after upgrading, we get a solid colour as the pre-logon lock screen, instead of the correct image (which was being correctly displayed by 15063). Logging on and back off again corrects this and the image is then displayed, but the whole point of this thread is that it is not correctly displayed until a logon has taken place. i.e. the problem still exists and is unchanged by the latest update.

    Can you clarify that you've been able to make the correct image appear on first boot after installing/upgrading to 17134, without requiring a logon first? If so, I'm unable to reproduce that success here.

    Thursday, June 28, 2018 11:22 AM
  • We are still experiencing the lockscreen issue along with -> Windows 10 Build 1803 unable to request Enterprise CA computer certificates https://social.technet.microsoft.com/Forums/windows/en-US/fc7162ed-c83a-4e41-bf2e-1e52158b99a2/windows-10-build-1803-unable-to-request-enterprise-ca-computer-certificates?forum=win10itprosecurity. These seem to be the top two issues in our deployment phase currently.

    Thursday, June 28, 2018 1:40 PM
  • We are also experiencing this lockscreen issue going from 1703 to 1803 (in-place upgrade)

    I have tried the registry solution it worked fine in 1703

    REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows\Personalization /V LockScreenImage /T REG_SZ /D C:\Users\Public\BG\LockScreen.jpg /F

    I have tried replacing the default lockscreen images in C:\Windows\Web\Screen\*.* and the clean lockscreen cache solution, but if I check smsts.log after upgrade I can see that the folder S-1-5-18 does not exists?

    TAKEOWN /F C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P /R /D Y 

    which update are you talking about? What is the KB number on that? The only new update I could find is KB4338853, and it is included in my upgrade.

    No matter what I try, the lockscreen is dark blue ish after it finnish the in-place upgrade, until a user login and restarts the computer or log off. Then it will show the correct custom lockscreen image.

    Our Windows 10 image is version 10.0.17134.1 (The version where the RecEnv.exe not being executed failure during the upgrade, waiting for Microsoft to release at new version)

    Thursday, June 28, 2018 2:42 PM
  • Thank you for your reply , Kate. Unfortunately, even with the late updates (from 2018-06-26) applied, my VM still does not apply the lock screen until a user logs in. On your test machine, had you previously logged in to that computer? This issue that I have reported here is only present before any user has logged in to the OS instance. Once a user logs in, all is well, but this is not feasible when imaging thousands of computers at once.

    I am currently rebuilding my captured image with the updates from the 26th to fully assess (i.e. without a quiet install on a computer with no previous logons), but this will take some time. Perhaps others whom rebuilt immediately after the late round of updates may have a capture already prepared.


    • Edited by foxtrot_romeo Thursday, June 28, 2018 5:30 PM Clarification.
    Thursday, June 28, 2018 3:41 PM
  • I've been working on this for a day and a half now. I have tried every fix there is on the net and nothing works for me. I work in a school environment and was going to roll out windows 10 for the first time but I can't even set our school "property of" custom wallpaper on our machines. At least with Windows 7 I can have everything working. This has been a nightmare trying to debloat, disable all kinds of telemetry stuff, work around the issues. I think Windows 7 is still working great for us the more I get into windows 10... 
    Thursday, June 28, 2018 7:34 PM
  • So, All your issues happened on the first time the computer startup from Upgrading or clean installation successfully, right?

    Did you configure the GPO before the upgrade or in previous Windows version? 

    Please know that during setup, the GPO will not apply. Except, you get restarting after OOBE or login with a user account. 

    We can try to add Synchronouscommand with "gpupdate /force" command during the Configuration phase. And see if we can bypass this issue. 

    https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-deployment-runsynchronous-runsynchronouscommand


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.



    Friday, June 29, 2018 2:13 AM
    Owner
  • All your issues happened on the first time the computer startup from Upgrading or clean installation successfully, right?

    Yes, but it also persists indefinitely until a user logs on. I.e. Simply rebooting at the login screen does not fix it. It's nothing to do with the first time the computer starts, it's to do with the fact that no user has logged on yet.

    Did you configure the GPO before the upgrade or in previous Windows version?

    Obviously, yes, given that the image was being correctly displayed before the upgrade. Also, the issue is reproducible using the registry keys directly (again, all present and working before the upgrade) with no GPO involved. This means all the issues about when GPO applies, and the use of gpupdate /force are irrelevant.

    The underlying issue is that the actions needed to populate the image and display it correctly are not being triggered until a user has logged on. This is easily reproduced here.

    Friday, June 29, 2018 9:26 AM
  • We have stated multiple times now that this issue persists through restarts, gpupdates, and all other efforts until a user logs in.

    On my test machines, I have verified that the GPO is applied via gpresult and have restarted scores of times. Nothing changes the behaviour until a user logs in, which was never required on previous versions of Windows 10. 

    However, once any user at all logs in, something is created/populated/permissioned correctly, and then the default lock/login screen works thereafter. A restart isn't even required at this point - just locking the device/logging out will immediately display the custom login image. If we could just know what this change is that is made on the first login, we might be able to find a way to address this issue.

    Friday, June 29, 2018 11:38 AM
  • All your issues happened on the first time the computer startup from Upgrading or clean installation successfully, right?

    Yes, but it also persists indefinitely until a user logs on. I.e. Simply rebooting at the login screen does not fix it. It's nothing to do with the first time the computer starts, it's to do with the fact that no user has logged on yet.

    Did you configure the GPO before the upgrade or in previous Windows version?

    Obviously, yes, given that the image was being correctly displayed before the upgrade. Also, the issue is reproducible using the registry keys directly (again, all present and working before the upgrade) with no GPO involved. This means all the issues about when GPO applies, and the use of gpupdate /force are irrelevant.

    The underlying issue is that the actions needed to populate the image and display it correctly are not being triggered until a user has logged on. This is easily reproduced here.

    Correct Mike, I hope that microsoft have solution to this issue very soon.
    Friday, June 29, 2018 12:11 PM
  • Hi Kate, can we expect any updates, resolutions within this issue in the next hours? We, the IT provider for the Swiss Government, have the same issue on all 1803 installations. Doesn’t matter whether we wipe&load or inplace update from earlier W10 versions to 1803.

    We have a "must go productive" date next week for 1803 (2 month after day zero) for approx. 65'000 clients and this is the only behavior we have to blame on. Should I open a premier support case? If so, let me know a reference to which we can point.


    If you do choose to open a Premier case, could you please post the resolution in this thread?
    Friday, June 29, 2018 1:07 PM
  • If you do choose to open a Premier case, could you please post the resolution in this thread?

    I have a case open with Premier Support already. We have been trying to resolve it for a couple of weeks without success. 

    Basically until after the first log OFF (naturally requires login first) the C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen.jpg is not created. It should be created as we know (and as it has been up to 1709) once the build is complete but alas currently it doesn't until after the first log OFF and it also (during testing) has sometimes taken about 5 seconds for it to complete the creation after logoff which then suddenly displays.

    The DllHost.exe and Windows.UI.Immersive.dll are a couple of investigation areas being looked into. I have been supplying various logs and ProcMon results but to date I have no resolution.

    Once a resolution has been found I will post it here (unless someone else works it out first - please)

    Friday, June 29, 2018 1:23 PM
  • Just to add to this, when I was initially looking at the problem I tried various ways of populating the LockScreen.jpg in the LockScreen_P folder, and while there are ways of putting the image into place Windows seems to ignore it unless it put it there itself.

    i.e. I wasn't able to find a way to populate this file by other means (this is another difference from earlier builds).

    As things stand the only workaround I know of is to use auto-logon registry keys to ensure that a logon takes place after installing 1803 or upgrading to it, to get the necessary things to trigger. This is obviously not feasible in many cases.

    Friday, June 29, 2018 1:31 PM
  • Kate,
    As of this morning, I rebuilt my build and capture image and re-ran our task sequence using all of the latest updates available via our SCCM's update synchronization (KB4338853, released 6/26) and this issue persists with identical symptoms.
    Friday, June 29, 2018 1:46 PM
  • For info, I have just supplied Microsoft with Bootlog information (using Procmon.exe /enablebootlogging /accepteula as a RunSynchronousCommand) so hopefully they will see where the problem lies and sort it. 

    Like others, we are holding off on a 1,400 Win 10 (1607, 1703, 1709) upgrade let alone the 22,000 1803 roll-out that is on hold.

    Friday, June 29, 2018 4:21 PM
  • Penfold69, thank you very much for this response! Like the response above from Mike, I have also tried populating the LockScreen_P folder with a LockScreen.jpg during the task sequence with no success. I have even taken the "known good" LockScreen and LockScreen__* files from a computer in a good state and attempted to take ownership of this directory tree and apply them to another computer with the symptoms with no luck.

    The owner of these files appears to be TrustedInstaller, with SYSTEM and TrustedInstaller both having Full Control, but using PSExec to copy the files as NT AUTHORITY\SYSTEM also does not fix the issue.

    Friday, June 29, 2018 4:48 PM
  • Same issue here with our 1803 Enterprise image. 1709 enterprise worked as expected...

    Any ideas?

    Have tested and found the the Enterprise version does work.  The professional version back in Creator Edition broke the login screen default image you can force via AD Group Policy.  I activated a Pro version and made it an Enterprise Win 10, and rebooted, the Default Login screen is not being enforced by Group Policy.

    WTF Microsoft????  Not a huge deal since I have volume licensing and can convert these to Enterprise, but what a hassle that they broke this.

    Friday, June 29, 2018 6:45 PM
  • Hello, we've had this issue since Windows 1803 as well.  The only fix I found was that I converted a few machines to Windows 10 Enterprise since I have volume licensing.  All machines with Windows 10 Pro, won't work.

    As soon as I converted the licensing and activated the Enteprise version, I rebooted, and the Default Login Screen is now being enforced upon login/reboot with the logo we use.  We changed nothing on the GP side in AD.  Only touched the Windows 10 Pros, converted then to an Enterprise license and wallah!  It started working.

    Otherwise, you get that daily picture option for the login screen.  Also, after converting to Enterprise, the option for the Daily Photo in the drop down for your chosen login screen vanishes, it isn't even available anymore as-if the feature isn't installed/used compared to Win 10 Professional.

    So, make of it what you will...but would suggest if you have an Win 10 Enterprise license, activate a current machine with that license, and see what happens.  We have done this on 5 machines that really need this now, conference rooms etc...and some users..and it fixed the issue.

    This really started on 1709 and Creator update.  According to articles, the default Lock screen has also been affected on later releases now.  This apparently applies as well to the Default Login Screen.

    https://social.technet.microsoft.com/Forums/windows/en-US/36ca2d1b-0249-43e1-a088-81824f647f86/windows-10-pro-lock-screen-background-deployment-in-the-company?forum=win10itprosetup

    Also, Educator version works as well for many of these issues/settings for custom lock screen/login logos.

    https://community.spiceworks.com/topic/2120383-windows-10-lockscreen-gpo-not-working-on-windows-10-1709


    • Edited by Foil1 Friday, June 29, 2018 7:03 PM
    Friday, June 29, 2018 6:57 PM
  • Hello, we've had this issue since Windows 1803 as well.  The only fix I found was that I converted a few machines to Windows 10 Enterprise since I have volume licensing.  All machines with Windows 10 Pro, won't work.

    As soon as I converted the licensing and activated the Enteprise version, I rebooted, and the Default Login Screen is now being enforced upon login/reboot with the logo we use.  We changed nothing on the GP side in AD.  Only touched the Windows 10 Pros, converted then to an Enterprise license and wallah!  It started working.

    Otherwise, you get that daily picture option for the login screen.  Also, after converting to Enterprise, the option for the Daily Photo in the drop down for your chosen login screen vanishes, it isn't even available anymore as-if the feature isn't installed/used compared to Win 10 Professional.

    So, make of it what you will...but would suggest if you have an Win 10 Enterprise license, activate a current machine with that license, and see what happens.  We have done this on 5 machines that really need this now, conference rooms etc...and some users..and it fixed the issue.

    This really started on 1709 and Creator update.  According to articles, the default Lock screen has also been affected on later releases now.  This apparently applies as well to the Default Login Screen.

    https://social.technet.microsoft.com/Forums/windows/en-US/36ca2d1b-0249-43e1-a088-81824f647f86/windows-10-pro-lock-screen-background-deployment-in-the-company?forum=win10itprosetup

    Also, Educator version works as well for many of these issues/settings for custom lock screen/login logos.

    https://community.spiceworks.com/topic/2120383-windows-10-lockscreen-gpo-not-working-on-windows-10-1709


    In our lab we are using the Enterprise ISO image downloaded from VLSC, the lockscreen are bark blue after the upgrade finished. but after the first logon the lockscreen is showen correct again weird!

    Mike, in my lab I see a path called "C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-21-3355819419-3267743485-3502526523-2726\ReadOnly\LockScreen_O\" but not "C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-21-3355819419-3267743485-3502526523-2726\ReadOnly\LockScreen_P" or "C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P". The folder S-1-5-18 does not exists until a user log on to the computer, can you confirm that too in your lab?

    I was thinking of trying to copy the lockscreen.jpg in to the LockScreen_O folder.

    I will let you Guys know if I find an solution to this, hope that you will do the same thing.

    Sunday, July 1, 2018 9:29 PM
  • Hello, we've had this issue since Windows 1803 as well.  The only fix I found was that I converted a few machines to Windows 10 Enterprise since I have volume licensing.  All machines with Windows 10 Pro, won't work.

    We are able to reproduce the problem consistently with Enterprise - all our devices run enterprise and we have no workaround (short of automating a logon).
    Monday, July 2, 2018 7:59 AM
  • Mike, in my lab I see a path called "C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-21-3355819419-3267743485-3502526523-2726\ReadOnly\LockScreen_O\" but not "C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-21-3355819419-3267743485-3502526523-2726\ReadOnly\LockScreen_P" or "C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P". The folder S-1-5-18 does not exists until a user log on to the computer, can you confirm that too in your lab?

    No - if you're seeing full SIDs like that under SystemData, that means you still have some aspect of the lock screen being a per-user setting. That's the SID of a particular user (probably the last user to log on) and is essentially their personal lock screen being applied to the device.

    If the "force a specific default lock screen and logon image" policy (or underlying reg key) is in effect, you should only see the S-1-5-18 folder and no others. In our case we're populating the relevant registry keys during the specialise pass, and we end up with just that folder even after logging on as a domain user.

    I think the S-1-5-18 folder existed (but empty) before the first user logged on but this would be tricky to test in our environment given that we use an auto-logon as part of our imaging process. Certainly it's already there and correctly populated with a lockscreen.jpg before upgrading, but the image is still not shown until after a logon/logoff (based on info upthread, it looks like it might be the logoff that actually populates it correctly).

    As for the LockScreen_P vs LockScreen_O distinction - I'm not sure what that means, only that we only ever see LockScreen_P. On other threads I've seen mention of LockScreen_X, Y and Z as well.

    Monday, July 2, 2018 8:14 AM
  • Mike, in my lab I see a path called "C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-21-3355819419-3267743485-3502526523-2726\ReadOnly\LockScreen_O\" but not "C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-21-3355819419-3267743485-3502526523-2726\ReadOnly\LockScreen_P" or "C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P". The folder S-1-5-18 does not exists until a user log on to the computer, can you confirm that too in your lab?

    No - if you're seeing full SIDs like that under SystemData, that means you still have some aspect of the lock screen being a per-user setting. That's the SID of a particular user (probably the last user to log on) and is essentially their personal lock screen being applied to the device.

    If the "force a specific default lock screen and logon image" policy (or underlying reg key) is in effect, you should only see the S-1-5-18 folder and no others. In our case we're populating the relevant registry keys during the specialise pass, and we end up with just that folder even after logging on as a domain user.

    I think the S-1-5-18 folder existed (but empty) before the first user logged on but this would be tricky to test in our environment given that we use an auto-logon as part of our imaging process. Certainly it's already there and correctly populated with a lockscreen.jpg before upgrading, but the image is still not shown until after a logon/logoff (based on info upthread, it looks like it might be the logoff that actually populates it correctly).

    As for the LockScreen_P vs LockScreen_O distinction - I'm not sure what that means, only that we only ever see LockScreen_P. On other threads I've seen mention of LockScreen_X, Y and Z as well.

    Thanks for explaining that, I will look into it :-)
    I hope that Microsoft will get back to us soon...

    Monday, July 2, 2018 1:46 PM
  • Microsoft released a new ISO image yesterday that I will test in my lab today.
    Tuesday, July 3, 2018 9:20 AM
  • Microsoft released a new ISO image yesterday that I will test in my lab today.

    Well still blue screen here...

    Mike these policies are set via group policy before upgrade.

    • Force a specific default lock screen and logon image
    • Prevents users from changing the background image

    We do not allow our users to change the logon image and S-1-5-18 do not exists during upgrade, the only folder in SystemData are S-1-5-21-3355819419-3267743485-3502526523-2726\ReadOnly\LockScreen_O

    Wednesday, July 4, 2018 5:57 AM
  • New ISO still has the same issue. I haven’t had any fix from Microsoft yet. Sent more logs on Tuesday
    Thursday, July 5, 2018 4:39 PM
  • Well, hi from Austria. We have the same Lockscreen Problem with 1803, no issues with 1709 and/or 1703. I also tried the new ISO which is 3 days old from 07/02/2018 from the Volume Licence Portal -No luck at all. Please MS fix this... otherwise we can´t roll out Win10 because this is a mature issue for our 6000+ Users in a Hospital Environment. Every new install have a blue Lockscreen and for most of the users this will look like a broken windows client and they have to call the helpdesk.... Thanks!
    Thursday, July 5, 2018 5:36 PM
  • Bingo, I got our custom lockscreen to show right after in-place upgrade and without user logon!

    After many tests and looking at log files I might have a solution that will work in our environment. I will run some more tests tomorrow and post it here afterwards.

    Thursday, July 5, 2018 7:49 PM
  • Have you tried replacing the default lockscreen images in C:\Windows\Web\Screen with your custom image, as described here?

    https://garytown.com/windows-10-lock-screen

    Thursday, July 5, 2018 8:23 PM
  • No, we just want to use the gpo admx files directly from Microsoft which should work like they told us 20 years and more. We don´t want to manuelly interact, neither with registry or with other things like garytown describes it. Why GPO exist when it doesen´t work, make no sense.

    These kind of bugs are not acceptable, not in a 50 computer environment and really never in a 6000+ computer environment. Please MS - fix this ! Your GPO should work as you describe it! Thanks

    Friday, July 6, 2018 7:54 AM
  • Not sure if this helps, but during our rollout of 1511 we set a registry key to disable the "hero" lockscreen image. We were experiencing a similar issue to above, the lock screen was a standard blue assent colour.

    HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System


    DisableLogonBackgroundImage = DWORD 0


    0 (enable) 
    1 (disable)

    https://chronicbit.blogspot.com/2018/01/blank-lockscreen-image-windows-10-1709.html 

    Monday, July 9, 2018 11:20 AM
  • Bingo, I got our custom lockscreen to show right after in-place upgrade and without user logon!

    After many tests and looking at log files I might have a solution that will work in our environment. I will run some more tests tomorrow and post it here afterwards.

    This is very exciting, Sune! What was your solution?
    Monday, July 9, 2018 6:17 PM
  • Still working on it :-/

    My solution worked perfect on VM (Hyper-V) but not on our laptop...

    They got the same image (1703) from our system center, and being upgraded to 1803. only differens is that our VM are not bitlocked, but I have testet with an laptop that was not bitlocked, no differens! This is really frustrating...

    So status right now is that I can get lockscreen to show efter in-place upgrade on all type of machines (VM, Laptop and Workstations) On VM, I can change the lockscreen path and it still appears after a reboot, but on our laptops it will show the blue screen if I change the lockscreen path, but it will show after a undefined numbers of restart or logof...

    Tuesday, July 10, 2018 5:24 AM
  • Is there anyone with Premier Support who can create an urgent fix request for that problem?
    Tuesday, July 10, 2018 7:14 AM
  • Is there anyone with Premier Support who can create an urgent fix request for that problem?
                    

    Penfold69 has a open premier support case.

    Any news on that ?

    Tuesday, July 10, 2018 7:19 AM
  • Here is my solution that work(ish) in our environment.

    We had a GPO to set the following policies

    • Force a specific default lock screen and logon image
    • Prevent changing lock screen and logon image

    These policies are being set via a Computer Configuration and added before user logon. The issue here is that it overwrites the settings set by the upgrade task sequence.

    Therefore, I have changed our GPO to add the same registry settings via "User Configuration - Preferences - Windows Settings - Registry". That way our custom lockscreen path will be set at first user logon.

    The next step might not be pretty, but I have to overwrite the default Windows lockscreen and finish it off by deleting the old registry key for our current custom lockscreen path if it exists.

    Upgrade task sequence

    1. Take ownership of "c:\windows\web\screen" and overwrite the img103.png with our custom lockscreen image. **

    2. Delete HKLM\SOFTWARE\Policies\Microsoft\Windows\Personalization if exists during TS

    ** In Gary’s blog he is overwriting the img100.jpg and img105.jpg it does not work in our lab, I found out that I had to replace img103.png.

    The correct custom lockscreen now appears after upgrade and before user logon! On a VM (Hyber-V) when a user logs on, the GPO will set our custom lockscreen path and after a reboot, it all work as before.

    BUT! If I tests this on a laptop, the blue screen appears after first user logon and a reboot… If I delete the registry “HKLM\SOFTWARE\Policies\Microsoft\Windows\Personalization” and reboot the img103.png appears again. Now if I log off then the correct custom image appears, but only if I log off? On the VM (Hyber-V) a reboot is enough to trigger the custom lockscreen! Also I found out that Windows 10 are looking at last modified date on the lockscreen image, so I have done some test and if I replace the custom lockscreen with a newer one it won’t change during a reboot it still requires a log off and then it will chance right away, this worked perfect on Windows 10 1703…

    Conclusion: If registry “HKLM\SOFTWARE\Policies\Microsoft\Windows\Personalization\LockScreenImage” exists after the upgrade, you will get the blue lockscreen, when the registry are set during first user logon on laptop and reboot you will get the blue lockscreen unless you log off before the reboot. If you want to change your custom lockscreen with a newer, you have to log off before it will change.

    It’s like a log off trigger the change lockscreen, but not a reboot unless it’s a VM (Hyber-V)?

    Also I tried this.

    •  Delete all *.jpg in C:\ProgramData\Microsoft\Windows\SystemData and subfolders before and during TS
    • Creating the C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P and copy lockscreen.jpg to the folder during TS.
    • Change modified date on the lockscreen.jpg
    • Tried with *.png format instead (lockscreen.png)
    • Setting “HKLM\SOFTWARE\Policies\Microsoft\Windows\Personalization\LockScreenImage” path to c:\windows\web\screen\img103.png, but still blue screen after reboot.

    For now I won´t be setting the custom lockscreen i registry "HKLM\SOFTWARE\Policies\Microsoft\Windows\Personalization\LockScreenImage" I'll just replace the default img103.png and hope that MS will fix it some day in the future!



    Tuesday, July 10, 2018 11:47 AM
  • The lockscreen in Win10 is a pain i.t.a. and it gets worse and worse with every release..

    Here's my successful adaption:

    - Place the known GPOs
    - replace the ../web/screen img100 / img103 images with a script that also takes ownership of that folder
    - at start take ownership of .../systemdata and delete the custom jpgs for every user. Also place the new "lockscreen.jpg"
    - then it get's tricky with 1803: You don't want the bluescreen or the random image?:
    You'll have to change for every User SID
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Creative\<your__ SID> the corresponding paths to your local .JPGs!
    Don't let Windows use the ContentDeliveryAsset JPGs.
    Also: remember to set the RotatingLockScreen to 0.
    That should do the trick for you.

    If you want you can delete the Assets from ContentDeliveryManager, but I guess they will be coming back if you don't remove ContentDeliveryManager completely...


    • Edited by MWCJ Tuesday, July 10, 2018 4:44 PM
    Tuesday, July 10, 2018 4:32 PM
  • The lockscreen in Win10 is a pain i.t.a. and it gets worse and worse with every release..

    Here's my successful adaption:

    - Place the known GPOs
    - replace the ../web/screen img100 / img103 images with a script that also takes ownership of that folder
    - at start take ownership of .../systemdata and delete the custom jpgs for every user. Also place the new "lockscreen.jpg"
    - then it get's tricky with 1803: You don't want the bluescreen or the random image?:
    You'll have to change for every User SID
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Creative\<your__ SID> the corresponding paths to your local .JPGs!
    Don't let Windows use the ContentDeliveryAsset JPGs.
    Also: remember to set the RotatingLockScreen to 0.
    That should do the trick for you.

    If you want you can delete the Assets from ContentDeliveryManager, but I guess they will be coming back if you don't remove ContentDeliveryManager completely...


    I looked at your solution and on my test pc "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Creative\<SID>" only contains RotatingLockScreenEnabled=1 (I tried changeing it to 0, it did nothing...) Do I have to create something?

    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ContentDeliveryManager" does not exists on my test pc.

    BTW. in our lab I only need to replace img103.png no need for replacing other image files in "c:\windows\web\screen"

    Wednesday, July 11, 2018 6:46 AM
  • I looked at your solution and on my test pc "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Creative\<SID>" only contains RotatingLockScreenEnabled=1 (I tried changeing it to 0, it did nothing...) Do I have to create something?

    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ContentDeliveryManager" does not exists on my test pc.

    BTW. in our lab I only need to replace img103.png no need for replacing other image files in "c:\windows\web\screen"

    Yes, since v1703, or was it v1709?, only img103.png had to be replaced.
    Is your lab v1803 system connected to the Internet?

    The ContentDeliveryManager is an AppX Package - can't really be controlled through registry since it's doing it's own thing. I wanted it to stop downloading so I took a risk and eliminated it completely from my systems. I can't tell if it affects other functions as well - remember to try this first on lab systems.

    - remove or rename  %Windir%\systemApps\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy

    - remove or rename (without user being logged in!) for all present users on the system %userprofile%\AppData\Local\Packages\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy

    Wednesday, July 11, 2018 3:18 PM
  • Really Microsoft? Do you really want us administrators to manually adjust or manually fix your broken GPO with strange file changes, file locks, etc.? Does this really work on the principle of "using the new ADMX extensions" but if certain settings of the GPO are no longer effective, then you have had bad luck admins out there? Is this your way of telling us that Windows 10 SaaS will be harder to configure with each feature update and we'll have to get used to Windows Online like Office 365? Are these your omens? For what do we pay 6000 Windows Enterprise licenses (which are damn expensive) if your tools do not work for that? Is anyone here reading from Microsoft? Incredible...
    Wednesday, July 11, 2018 9:35 PM
  • I looked at your solution and on my test pc "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Creative\<SID>" only contains RotatingLockScreenEnabled=1 (I tried changeing it to 0, it did nothing...) Do I have to create something?

    "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ContentDeliveryManager" does not exists on my test pc.

    BTW. in our lab I only need to replace img103.png no need for replacing other image files in "c:\windows\web\screen"

    Yes, since v1703, or was it v1709?, only img103.png had to be replaced.
    Is your lab v1803 system connected to the Internet?

    The ContentDeliveryManager is an AppX Package - can't really be controlled through registry since it's doing it's own thing. I wanted it to stop downloading so I took a risk and eliminated it completely from my systems. I can't tell if it affects other functions as well - remember to try this first on lab systems.

    - remove or rename  %Windir%\systemApps\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy

    - remove or rename (without user being logged in!) for all present users on the system %userprofile%\AppData\Local\Packages\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy

    Yes our lab are connected to the Internet.

    Thanks for explaining the ContentDeliveryManager

    Thursday, July 12, 2018 5:59 AM
  • Is there anyone with Premier Support who can create an urgent fix request for that problem?

                    

    Penfold69 has a open premier support case.

    Any news on that ?

    Unfortunately no update yet. The last email from MS was on Monday stating:

    Currently it looks like a code change in 1803. I do not have access to RS4 code so I will engage Escalation Team.

    Annoyingly, I thought it had already been escalated considering it was logged on 23/05 as a Sev B - Urgent!!

    I will chase them up to see where we are.

    Thursday, July 12, 2018 2:47 PM
  • Hello everybody

    We're really unhappy with all the changes Microsoft is making in each build that changes the setup behavior. Since Windows 10 1803 no Scheduled Task is run until a user logs in. The LockScreenImage is not set after the deployment ends (ConfigMgr OSD Deployed). This is really annoying and time consuming.

    I hope we'll get a community elaborated solution. Because Microsoft is not really fast in delivering solutions for such "little" problems.

    Kind regards,
    Matias

    Friday, July 13, 2018 8:46 AM
  • ACS_DAN,

    Windows 10 Professional will not pickup this policy. Only read by Clients running Enterprise and Education or Server SKUs



    - Jason E


    Monday, July 16, 2018 2:39 PM
  • ACS_DAN,

    Windows 10 Professional will not pickup this policy. Only read by Clients running Enterprise and Education or Server SKUs



    - Jason E


    Jason, I can assure you that the problem also occurs on Windows Enterprise Clients.

    Tuesday, July 17, 2018 9:26 AM
  • I am currently debugging the issue to try isolate the change that lead this change in behavior.

    1. We have been able to reproduce this in a lab environment here.

    2. If anyone has repro steps that do NOT involve SCCM or an alternative deployment solution, I would like know. This would help simplify the scenario.

    3. If you are running "Pro" the policy never works because it is not read by client OS versions that are NOT Enterprise or Education SKU. 


    - Jason E

    Tuesday, July 17, 2018 11:17 AM
  • I am currently debugging the issue to try isolate the change that lead this change in behavior.

    1. We have been able to reproduce this in a lab environment here.

    2. If anyone has repro steps that do NOT involve SCCM or an alternative deployment solution, I would like know. This would help simplify the scenario.

    3. If you are running "Pro" the policy never works because it is not read by client OS versions that are NOT Enterprise or Education SKU. 


    - Jason E

    1) Thanks

    2) We deploy our Win1803 Enterprise Clients with IVANTI DSM and the newest *.iso from MS Volume Licensing Center - lockscreen issue confirmed every time for all of our 30 testclients in our lab.

    3) we know.

    Tuesday, July 17, 2018 8:28 PM
  • I am currently debugging the issue to try isolate the change that lead this change in behavior.

    1. We have been able to reproduce this in a lab environment here.

    2. If anyone has repro steps that do NOT involve SCCM or an alternative deployment solution, I would like know. This would help simplify the scenario.

    3. If you are running "Pro" the policy never works because it is not read by client OS versions that are NOT Enterprise or Education SKU. 


    - Jason E

    1. Thanks

    2. Can´t help you there, we are using SCCM! But read my posts above.

    3. We know and are only using Enterprise edition (English) with languagepacks (Danish/Norwegian)

    Wednesday, July 18, 2018 7:11 AM
  • 2. If anyone has repro steps that do NOT involve SCCM or an alternative deployment solution, I would like know. This would help simplify the scenario.

    Our bare-metal deployment is our own scripting within WinPE, using DISM to apply the wim and then apply the unattend.xml to it.

    However, for us the main issue is that this problem occurs following in-place upgrades from pre-1803 to 1803, and for that we're just launching the windows setup executable with appropriate parameters - no SCCM or other management technologies involved. This gives a solid colour after the upgrade completes until a user has logged on and back off again - rebooting without logging on does not fix it.

    Prior to upgrading, the specified prelogon lock screen was being displayed correctly.

    We're using enterprise 64bit.

    Wednesday, July 18, 2018 8:44 AM
  • As of this month's round of updates (KB4343669, 10.1.17134), this issue still persists unchanged.
    Wednesday, July 18, 2018 1:04 PM
  • 2. If anyone has repro steps that do NOT involve SCCM or an alternative deployment solution, I would like know. This would help simplify the scenario.

    Our bare-metal deployment is our own scripting within WinPE, using DISM to apply the wim and then apply the unattend.xml to it.

    However, for us the main issue is that this problem occurs following in-place upgrades from pre-1803 to 1803, and for that we're just launching the windows setup executable with appropriate parameters - no SCCM or other management technologies involved. This gives a solid colour after the upgrade completes until a user has logged on and back off again - rebooting without logging on does not fix it.

    Prior to upgrading, the specified prelogon lock screen was being displayed correctly.

    We're using enterprise 64bit.

    "rebooting without logging on does not fix it." Ehm... Unless you are testing on a VM (Hypber-V)
    Thursday, July 19, 2018 5:50 AM
  • As of this month's round of updates (KB4343669, 10.1.17134), this issue still persists unchanged.

    No and I can confirm that too :-/
    Thursday, July 19, 2018 5:50 AM
  • "rebooting without logging on does not fix it." Ehm... Unless you are testing on a VM (Hypber-V)
    I'm testing on real hardware, but when looking at similar issues on earlier builds, I did find that a screen resolution change would sometimes fix it. Not tried that with 1803 (as it's academic), but it may be that a VM is seeing a resolution change when you connect to it that is triggering events that result in the lock screen fixing itself.
    Thursday, July 19, 2018 10:07 AM
  • "rebooting without logging on does not fix it." Ehm... Unless you are testing on a VM (Hypber-V)

    I'm testing on real hardware, but when looking at similar issues on earlier builds, I did find that a screen resolution change would sometimes fix it. Not tried that with 1803 (as it's academic), but it may be that a VM is seeing a resolution change when you connect to it that is triggering events that result in the lock screen fixing itself.
    Hmmm... Maybe? But I'm running the in-place upgrade from the same Hyper-V Window so it should not change the screen resulution right? I could try your theory on real hardware, log on and change screen resolution and reboot...
    Thursday, July 19, 2018 11:02 AM
  • Hmmm... Maybe? But I'm running the in-place upgrade from the same Hyper-V Window so it should not change the screen resulution right? I could try your theory on real hardware, log on and change screen resolution and reboot...

    ... but logging on (to change screen res) will definitely fix it anyway.

    Been a while since I've played around with client OSs in a VM, but last I did they booted at a sort of default resolution, and then when you connected to their console they acted as if their resolution had changed - usually to the size of window I was using.

    To test this on real hardware I think you'd need to reboot with the monitor unplugged, so that windows defaults to whatever it defaults to these days (used to be 800x600), hook the monitor up, and then reboot from there without having logged on.

    • Proposed as answer by TheBrain0 Thursday, July 19, 2018 6:52 PM
    • Unproposed as answer by TheBrain0 Thursday, July 19, 2018 6:52 PM
    Thursday, July 19, 2018 11:16 AM
  • We run Windows 10 Pro 1803 and we're deploying the PowerShell script below via a task running under the SYSTEM account via GPO. It applies nightly to grab a new image and I believe it will clean up any new SIDs in the registry that may have 'RotatingLockScreenEnabled' set to 1 instead of 0. I haven't tested to see if new profiles get a 0 or a 1.

    If you're running Windows Enterprise or Education verion you would just need the one-liner below and I think you would just need the usual GPO settings in place for "NoLockScreen" and "NoChangingLockScreen" that are set in the full PS script in the registry. 
    "Get-ChildItem -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Creative\ -Recurse | where { $_.Property -match 'RotatingLockScreenEnabled'} | Set-ItemProperty -Name RotatingLockScreenEnabled -Value 0"

    Sources: 
    https://community.spiceworks.com/topic/1262253-change-windows-10-lock-screen-background-image-gp?page=4
    MWCJ's comment in this thread about RotatingLockScreenEnabled



    ###PowerShell Script###

    #This is what we used since I'm lazy and didn't want to change the drop point File Copy from Win7 to Win10
    $LockImagesFolder = "C:\windows\system32\oobe\info\backgrounds"

    if(test-path $LockImagesFolder)
    {
    #I couldn't get the random to work for me but I just wanted a single image name at a time
    #    $LockRandomImage = get-random (get-childitem $LockImagesFolder).Name
        $LockRandomImage = "backgrounddefault.jpg"
        $LockRandomImage = "$LockImagesFolder\$LockRandomImage"

        takeown /F C:\ProgramData\Microsoft\Windows\SystemData
        icacls C:\ProgramData\Microsoft\Windows\SystemData /grant:r 'Administrators:F'
        icacls C:\ProgramData\Microsoft\Windows\SystemData /grant:r 'SYSTEM:(OI)(CI)F'
        icacls C:\ProgramData\Microsoft\Windows\SystemData /setowner Administrators
        takeown /F C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18 /R /D Y
        icacls C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18 /grant:r 'Administrators:(OI)(CI)F'
        icacls C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18 /grant:r 'SYSTEM:(OI)(CI)F'
        icacls C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\* /inheritance:e /T
        icacls C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18 /setowner Administrators /T

        remove-item C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\* -Recurse -Force

        takeown /F C:\Windows\Web\Screen\img100.jpg
        icacls C:\Windows\Web\Screen\img100.jpg /grant:r 'Administrators:(OI)(CI)F'
        icacls C:\Windows\Web\Screen\img100.jpg /grant:r 'SYSTEM:(OI)(CI)F'
        icacls C:\Windows\Web\Screen\img100.jpg /inheritance:e /T
        icacls C:\Windows\Web\Screen\img100.jpg /setowner Administrators /T



        remove-item C:\Windows\Web\Screen\img100.jpg
        copy-item $LockRandomImage "C:\Windows\Web\Screen\img100.jpg"



    New-Item -Path "HKLM:\Software\Policies\Microsoft\Windows" -Name Personalization –Force
    Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\Personalization" -Name NoLockScreen -Value 0 -Type DWord
    New-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\Personalization" -Name "NoChangingLockScreen" -PropertyType "DWord" -Value '00000001'

    #Added 2018-07-19 to cover 1803 issues with the lock screen. Microsoft may release an update to fix the issue where on reboot it displays Windows Spotlight or the local account default
    Get-ChildItem -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Creative\ -Recurse | where { $_.Property -match 'RotatingLockScreenEnabled'} | Set-ItemProperty -Name RotatingLockScreenEnabled -Value 0


    }
    • Proposed as answer by TheBrain0 Thursday, July 19, 2018 7:01 PM
    • Unproposed as answer by TheBrain0 Thursday, July 19, 2018 7:59 PM
    Thursday, July 19, 2018 7:01 PM
  • We run Windows 10 Pro 1803 and we're deploying the PowerShell script below via a task running under the SYSTEM account via GPO. It applies nightly to grab a new image and I believe it will clean up any new SIDs in the registry that may have 'RotatingLockScreenEnabled' set to 1 instead of 0. I haven't tested to see if new profiles get a 0 or a 1.

    If you're running Windows Enterprise or Education verion you would just need the one-liner below and I think you would just need the usual GPO settings in place for "NoLockScreen" and "NoChangingLockScreen" that are set in the full PS script in the registry. 
    "Get-ChildItem -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Creative\ -Recurse | where { $_.Property -match 'RotatingLockScreenEnabled'} | Set-ItemProperty -Name RotatingLockScreenEnabled -Value 0"

    Sources: 
    https://community.spiceworks.com/topic/1262253-change-windows-10-lock-screen-background-image-gp?page=4
    MWCJ's comment in this thread about RotatingLockScreenEnabled



    ###PowerShell Script###

    #This is what we used since I'm lazy and didn't want to change the drop point File Copy from Win7 to Win10
    $LockImagesFolder = "C:\windows\system32\oobe\info\backgrounds"

    if(test-path $LockImagesFolder)
    {
    #I couldn't get the random to work for me but I just wanted a single image name at a time
    #    $LockRandomImage = get-random (get-childitem $LockImagesFolder).Name
        $LockRandomImage = "backgrounddefault.jpg"
        $LockRandomImage = "$LockImagesFolder\$LockRandomImage"

        takeown /F C:\ProgramData\Microsoft\Windows\SystemData
        icacls C:\ProgramData\Microsoft\Windows\SystemData /grant:r 'Administrators:F'
        icacls C:\ProgramData\Microsoft\Windows\SystemData /grant:r 'SYSTEM:(OI)(CI)F'
        icacls C:\ProgramData\Microsoft\Windows\SystemData /setowner Administrators
        takeown /F C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18 /R /D Y
        icacls C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18 /grant:r 'Administrators:(OI)(CI)F'
        icacls C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18 /grant:r 'SYSTEM:(OI)(CI)F'
        icacls C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\* /inheritance:e /T
        icacls C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18 /setowner Administrators /T

        remove-item C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\* -Recurse -Force

        takeown /F C:\Windows\Web\Screen\img100.jpg
        icacls C:\Windows\Web\Screen\img100.jpg /grant:r 'Administrators:(OI)(CI)F'
        icacls C:\Windows\Web\Screen\img100.jpg /grant:r 'SYSTEM:(OI)(CI)F'
        icacls C:\Windows\Web\Screen\img100.jpg /inheritance:e /T
        icacls C:\Windows\Web\Screen\img100.jpg /setowner Administrators /T



        remove-item C:\Windows\Web\Screen\img100.jpg
        copy-item $LockRandomImage "C:\Windows\Web\Screen\img100.jpg"



    New-Item -Path "HKLM:\Software\Policies\Microsoft\Windows" -Name Personalization –Force
    Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\Personalization" -Name NoLockScreen -Value 0 -Type DWord
    New-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\Personalization" -Name "NoChangingLockScreen" -PropertyType "DWord" -Value '00000001'

    #Added 2018-07-19 to cover 1803 issues with the lock screen. Microsoft may release an update to fix the issue where on reboot it displays Windows Spotlight or the local account default
    Get-ChildItem -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Creative\ -Recurse | where { $_.Property -match 'RotatingLockScreenEnabled'} | Set-ItemProperty -Name RotatingLockScreenEnabled -Value 0


    }

    Sorry but I / we know all the above workarrounds and I can get the custom lockscreen image to appear after upgrade in my lab.

    I want is to use a custom image path "c:\users\puclic\bg" and not overwrite img103.png in "c:\windows\web\screen" so in Windows 10 1703 I had to use this registry “HKLM\SOFTWARE\Policies\Microsoft\Windows\Personalization\LockScreenImage”

    If I use “HKLM\SOFTWARE\Policies\Microsoft\Windows\Personalization\LockScreenImage” with custom path "c:\users\public\bg\lockscreen.jpg" in Windows 10 1803 I get a blue screen after the upgrade, but if I Lock / log off it will change lockscreen image to my custom image located in "c:\users\puclic\bg"

    If I overrite the old lockscreen image with one that have a newer last modified date I want the lockscreen image to change during next reboot. Again that worked perfect in Windows 10 1703, but now I have to lock / log off before lockscreen image will change?

    Friday, July 20, 2018 6:26 AM
  • Hello, TheBrain0 - Thank you for your reply, but this does not address the issue in this thread, as it pertains specifically to the failure of the lock screen to apply (via replacing the files, group policy, local policy, or any other method) before a user logs in.

    Just to be sure, I imaged a VM and ran  your script using a local image which is applied during our task sequence, and the behaviour still persists. 

    Friday, July 20, 2018 11:27 AM
  • Sorry that didn't help the conversation Sune Thomsen and foxtrot_romeo. Definitely a lot to process going through this thread. This thread did help me discover the solution to fix the logon screen appearing as a Windows Spotlight image before anyone logged on. So thank you all! If I get some time I hope to figure out the lock screen issue as well (or maybe Microsoft will release a fix before that).
    Friday, July 20, 2018 6:53 PM
  • In my testing, this issue persists in VMs as well as on physical hardware. I'm not sure how you are opting to change the resolution without logging in, but assuming that you are using the Set-VMVideo PowerShell cmdlet, I was not able to effect any change in the blue login screen symptom when I used that method.
    Monday, July 23, 2018 12:03 PM
  • Sad to say guys/all but this is still an issue that persists. With the build 1803.165, it is still there fresh or in-place upgrade. Had it logged in the hope to speed it up sadly they asked me instead to send the a vhd so they can troubleshoot further in their lab. Sadly not intending of doing it, it is widely known issue. I think that was a bit silly to ask. I also tried the 1703 work around as noted here earlier, it doesn't work but an update on my previous post, the Start Menu is fixed now for partial locked down Start Menu which is good.

    If I get to know more straight from the horses mouth, I'll keep you updated.

    Monday, July 23, 2018 12:28 PM
  • Sad to say guys/all but this is still an issue that persists. With the build 1803.165, it is still there fresh or in-place upgrade. Had it logged in the hope to speed it up sadly they asked me instead to send the a vhd so they can troubleshoot further in their lab. Sadly not intending of doing it, it is widely known issue. I think that was a bit silly to ask. I also tried the 1703 work around as noted here earlier, it doesn't work but an update on my previous post, the Start Menu is fixed now for partial locked down Start Menu which is good.

    If I get to know more straight from the horses mouth, I'll keep you updated.

    Thanks Joe!

    Would be interessting if anyone has the time to test with 1809 redstone 5 Build, I can´t do this in the next days because we are already working 13 hours/day and I have to sleep some times. Maybe I can test this on 1809 BETA Build next week...

    Thanks,

    System32

    Monday, July 23, 2018 5:27 PM
  • I opened a new techcommunity thread about this lockscreen bug, we need to push this more then before...

    https://techcommunity.microsoft.com/t5/Windows-10/Windows-10-1803-Custom-Login-Lock-Screen-Image-Is-Not-Applied/m-p/218144#M1662

    What is premier support status @ Penfold69

    Thanks

    Monday, July 23, 2018 9:28 PM
  • Found this thread, as we are experiencing the issue as well.  Worked with all the 1709 images, but not now with 1803; Education.
    Monday, July 23, 2018 10:40 PM
  • I'm using the same LTSB version I used last year in student labs when the force lockscreen GPO worked fine, however the same .iso this year but with MS updates has now given me the same problem people are seeing on the Win v1803.

    The (rather dirty) 'workaround' i'm putting in place because I can't sit around waiting for Microsoft to get their finger out is to set a reghack to auto login the machine as a local account at the end of the SCCM task sequence, then switch on a GPO to remove the auto login and reboot the PCs once deployment is complete. Not the best but it seems to work ok without too much of an overhead.

    I think it's disgusting that Microsoft continually throw out 'updates' riddled with bugs and constantly expect the end user to find workarounds or fix it for them! They could not care less as they know many have no option but to continue to use/purchase Windows! If Microsoft were a plumber they would have gone out of businessyears ago!!

    Tuesday, July 24, 2018 1:47 PM
  • KB4340917 for 1803 was released and again... no word from this lockscreen bug, come on Microsoft !!!

    https://support.microsoft.com/en-sg/help/4340917/windows-10-update-kb4340917

    Tuesday, July 24, 2018 8:53 PM
  • oh come on... just read it .... for 1709 a new Patch 

    KB4338817

    was also released which addresses an issue in which the correct lock screen image won't show when all of the following are true:

      • GPO policy “Computer Configuration\Administrative Templates\Control Panel\Personalization\Force a specific default lock screen and logon image” is enabled.
      • GPO policy "Computer Configuration\Administrative Templates\Control Panel\Personalization\Prevent changing lock screen and logon image" is enabled
      • Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\DisableLogonBackgroundImage is set to 1.

    https://support.microsoft.com/en-us/help/4338817/july172018kb4338817osbuild16299579

    Tuesday, July 24, 2018 8:57 PM
  • I am working with several customers on this, and I am not sure the issue that was addressed in this update will address the issue reported in this thread. The issue that was addressed impacted every logon, not just first logon. If anyone confirms this that these 3 settings are all set and changing any one of these mitigates the 1803 lock screen issue, please reply.


    - Jason E

    Tuesday, July 24, 2018 9:35 PM
  • More info on the fix from KB4338817:

    Customer wanted custom image on lock screen and NO image (solid color) on logon screen (instead of the dimmed out version of the lock screen image).

    This involved the use of 3 settings:

    • GPO “Force a specific default lock screen and logon image”
    • GPO “Prevent changing lock screen and logon image”
    • Registry entry DisableLogonBackgroundImage to 1

    Before the fix, this set of settings resulted in the custom image being set on both the lock screen and logon screen (dimmed out logon screen image) and NOT the desired behavior of:

    • Custom image on lock
    • No custom image on logon screen
    • User can't change image

    After the fix, this trio of settings should result in the ability to have a solid color on the logon screen with the settings outlined above.

    From what I can tell, this fix should not have any impact on the issue discussed in this thread. 


    - Jason E


    Tuesday, July 24, 2018 9:59 PM
  • Rab68 -

    Exactly how are you doing this?

    

    


    sysbuilder

    Wednesday, July 25, 2018 1:38 AM
  • Rab68 -

    Exactly how are you doing this?

    

    


    sysbuilder

    sysbuilder

    one of the last steps in my SCCM task sequence is to run a reghack to set these 3 keys:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
    "AutoAdminLogon"="1"
    "DefaultUserName"="<a local account>"
    "DefaultPassword"="<pw to local account>"

    Restart the machine and it will autologin to the account set, so this will be your first machine login which will 'activate' the settings to make the lock screen appear.

    I then have a GPO linked to the OU the machine is in which will reverse the autologin. Switch this on, reboot (often twice is required) the machines and they are then sitting waiting for a login with the desired forced lock screen displayed.

    Not the most sexy approach, but it's simple and it works.

    Would have liked to have been able to remove the autologin as part of the TS so it's fully automated, but couldn't get this to work without breaking the TS.

    Wednesday, July 25, 2018 7:05 AM
  • Thank you, Jason - I can confirm that this has no impact on the issue that we have reported in this thread, as our goal was to unify both the lock and login images and we were not able to get even that far in 1803.
    Wednesday, July 25, 2018 1:29 PM
  • Rab68,

    Thank you for your fast reply. What if the reg punch is added as a synchronous pass in an unattend.xml file? When then machine comes up for the first time, local admin would get logged in but the SCCM task sequence would continue running as System. Then at some later point in the task sequence reverse the AutoAdminLogon and do a reboot.

    We are going to try to do this today


    sysbuilder

    Wednesday, July 25, 2018 4:05 PM
  • The patch released is for 1709.  It can't be applied to 1803.
    Wednesday, July 25, 2018 4:11 PM
  • @foxtrot_romeo,
    Can you reach out to me @ jasone_at_microsoft.com


    - Jason E

    Wednesday, July 25, 2018 4:53 PM
  • Nothing to report yet unfortunately just updates stating there is no update and that the escalation team have not provided any news.

    In one of their responses they suggested as a work around to use an auto sign in step during the build to correct the issue. I stipulated that this is not something we, as a company, would even contemplate doing.

    There next update was a link to this thread actually referencing James E's reply - seriously this is just a joke in a bad way, just makes me laugh and cry at the same time. Over 23,000 devices waiting to deploy and they just don't seem to give a crap.


    Thursday, July 26, 2018 9:23 AM
  • Nothing to report yet unfortunately just updates stating there is no update and that the escalation team have not provided any news.

    In one of their responses they suggested as a work around to use an auto sign in step during the build to correct the issue. I stipulated that this is not something we, as a company, would even contemplate doing.

    There next update was a link to this thread actually referencing James E's reply - seriously this is just a joke in a bad way, just makes me laugh and cry at the same time. Over 23,000 devices waiting to deploy and they just don't seem to give a crap.


    I know exactly what you mean Penfold :( We have 6000 devices who are waiting.... I could cry.... Nobody cares.
    Thursday, July 26, 2018 12:28 PM
  • Hi all,

    I have been facing the same issue as everyone else on a customers site and have managed to get it to work on multiple test machines in the last 30 minutes. 

    To do this i applied the following two registry edits and the Force a specific default lock screen and logon image GPO. 

    Windows Registry Editor Version 5.00

    [HKEY_USERS\.DEFAULT\Control Panel\Desktop]
    "TileWallpaper"="0"
    "Wallpaper"="C:\\WINDOWS\\StaffPaper.jpg"
    "WallpaperStyle"="2"

    ------------------------------------------------------------------------------------------------------------

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background]
    "OEMBackground"=dword:00000001

    If someone could try these and confirm if it worked or not that'd be good.

    Hope it works for other people too.

    Thursday, July 26, 2018 9:08 PM
  • Hi all,

    I have been facing the same issue as everyone else on a customers site and have managed to get it to work on multiple test machines in the last 30 minutes. 

    To do this i applied the following two registry edits and the Force a specific default lock screen and logon image GPO. 

    Windows Registry Editor Version 5.00

    [HKEY_USERS\.DEFAULT\Control Panel\Desktop]
    "TileWallpaper"="0"
    "Wallpaper"="C:\\WINDOWS\\StaffPaper.jpg"
    "WallpaperStyle"="2"

    ------------------------------------------------------------------------------------------------------------

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background]
    "OEMBackground"=dword:00000001

    If someone could try these and confirm if it worked or not that'd be good.

    Hope it works for other people too.


    Hi Ryan, nope… sorry. I tested it with a new 1803 Enterprise Installation.
    Friday, July 27, 2018 6:38 AM
  • Hi all,

    I have been facing the same issue as everyone else on a customers site and have managed to get it to work on multiple test machines in the last 30 minutes. 

    To do this i applied the following two registry edits and the Force a specific default lock screen and logon image GPO. 

    Windows Registry Editor Version 5.00

    [HKEY_USERS\.DEFAULT\Control Panel\Desktop]
    "TileWallpaper"="0"
    "Wallpaper"="C:\\WINDOWS\\StaffPaper.jpg"
    "WallpaperStyle"="2"

    ------------------------------------------------------------------------------------------------------------

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background]
    "OEMBackground"=dword:00000001

    If someone could try these and confirm if it worked or not that'd be good.

    Hope it works for other people too.

    It did not Work in our environment...
    Friday, July 27, 2018 1:10 PM
  • This seems to work fine with local group policy - it’s only effecting my PCs before someone logs in for the first time. Once someone has logged in after the Pc has been built and the pc then restarted, the login wallpaper works
    Friday, July 27, 2018 5:50 PM
  • Hi Everyone,
    Jason E. here from the Windows debug team. I have been able to isolate the cause of what is causing this issue. The issue here is actually not with group policy or with the LogonUI (the component that reads these registry values and applies the custom images). It turns out this is an issue that was caused by a change in the Task Scheduler made in 1803 (as odd as that sounds). During the first boot after a deployment, the group policy does in fact make all the required changes for the policy to get applied. LogonUI successfully reads the policy data and starts going through the steps to apply the policy. One of these steps is to check to see if the Task Scheduler is up and running because one of the components it (LogonUI) uses is a task basked COM server. Turns out Task Scheduler is running, but is a state where it is not advertising itself as such (there is a named event LogonUI expects to be created and set, which is how it knows things are not quite ready). This is the point the applying of the logon and lock screen images fails out. 

    So.. why isn't Task Scheduler getting up and running? Prior to 1803, the Task scheduler would execute scheduled tasks that were from the previous install (e.g. upgrade scenario) before the OS upgrade was really done. A change was made in 1803 to try to improve the reliability of the upgrade. The change was to not run these tasks until the first user had completed a logon. This is why this is only impacting the first boot after a deployment. While this should mean more reliable upgrades, it has caused the side effect outlined in this thread.

    What are we doing? I am working on getting the right teams looped into this issue to see what we can to get this addressed as soon as possible.

    How can you help? I am currently working with a small set of Premier customers on this issue and we have pretty good understanding of how this issues is impacting them. It would be great to get some additional insights into how this issues impacts you and your deployments. I want to make sure I have your responses to "If it only impacts the first boot, how does this impact the end user experience?". 

    What I have so far:

    • This was working... just fix it :)
    • This is a VDI environment so ever boot is a first boot.

    Are there others?


    - Jason E

    Monday, July 30, 2018 7:53 PM
  • Hello Jason,

    we're also affected by this issue and I opened a MS case last week (118072618659075). We basically have a fixed lockscreen for the endusers and after update to 1803 we only see the mentioned blue lockscreen (since we have the two GPOs in place - NoChangingLockScreen and LockScreenImage).

    It is a problem for us since the users will think that something is wrong due to the changed lockscreen. Since first rollout of Windows 10 about 2 years ago the users 'live' with this one and only lockscreen and if after the feature update there will be another one it would be a sign that something went wrong and the users will call the helpdesk - and we really want to avoid this !

    We have about 6000 clients in our environment.

    Thanks and Regards
    Clemens

    Tuesday, July 31, 2018 5:06 AM
  • Hi Everyone,
    Jason E. here from the Windows debug team. I have been able to isolate the cause of what is causing this issue. The issue here is actually not with group policy or with the LogonUI (the component that reads these registry values and applies the custom images). It turns out this is an issue that was caused by a change in the Task Scheduler made in 1803 (as odd as that sounds). During the first boot after a deployment, the group policy does in fact make all the required changes for the policy to get applied. LogonUI successfully reads the policy data and starts going through the steps to apply the policy. One of these steps is to check to see if the Task Scheduler is up and running because one of the components it (LogonUI) uses is a task basked COM server. Turns out Task Scheduler is running, but is a state where it is not advertising itself as such (there is a named event LogonUI expects to be created and set, which is how it knows things are not quite ready). This is the point the applying of the logon and lock screen images fails out. 

    So.. why isn't Task Scheduler getting up and running? Prior to 1803, the Task scheduler would execute scheduled tasks that were from the previous install (e.g. upgrade scenario) before the OS upgrade was really done. A change was made in 1803 to try to improve the reliability of the upgrade. The change was to not run these tasks until the first user had completed a logon. This is why this is only impacting the first boot after a deployment. While this should mean more reliable upgrades, it has caused the side effect outlined in this thread.

    What are we doing? I am working on getting the right teams looped into this issue to see what we can to get this addressed as soon as possible.

    How can you help? I am currently working with a small set of Premier customers on this issue and we have pretty good understanding of how this issues is impacting them. It would be great to get some additional insights into how this issues impacts you and your deployments. I want to make sure I have your responses to "If it only impacts the first boot, how does this impact the end user experience?". 

    What I have so far:

    • This was working... just fix it :)
    • This is a VDI environment so ever boot is a first boot.

    Are there others?


    - Jason E

    Hi Jason,

    As I wrote earlier in this thread then in our lab the user have to lock the screen or log off before custom lockscreen appears instead of the blue screen. An reboot is not enough unless it’s a VM (Hyper-V).

    Thank you for looking into this issue.

    - Sune Thomsen

    Tuesday, July 31, 2018 5:33 AM
  • Hi Everyone,
    Jason E. here from the Windows debug team. I have been able to isolate the cause of what is causing this issue. The issue here is actually not with group policy or with the LogonUI (the component that reads these registry values and applies the custom images). It turns out this is an issue that was caused by a change in the Task Scheduler made in 1803 (as odd as that sounds). During the first boot after a deployment, the group policy does in fact make all the required changes for the policy to get applied. LogonUI successfully reads the policy data and starts going through the steps to apply the policy. One of these steps is to check to see if the Task Scheduler is up and running because one of the components it (LogonUI) uses is a task basked COM server. Turns out Task Scheduler is running, but is a state where it is not advertising itself as such (there is a named event LogonUI expects to be created and set, which is how it knows things are not quite ready). This is the point the applying of the logon and lock screen images fails out. 

    So.. why isn't Task Scheduler getting up and running? Prior to 1803, the Task scheduler would execute scheduled tasks that were from the previous install (e.g. upgrade scenario) before the OS upgrade was really done. A change was made in 1803 to try to improve the reliability of the upgrade. The change was to not run these tasks until the first user had completed a logon. This is why this is only impacting the first boot after a deployment. While this should mean more reliable upgrades, it has caused the side effect outlined in this thread.

    What are we doing? I am working on getting the right teams looped into this issue to see what we can to get this addressed as soon as possible.

    How can you help? I am currently working with a small set of Premier customers on this issue and we have pretty good understanding of how this issues is impacting them. It would be great to get some additional insights into how this issues impacts you and your deployments. I want to make sure I have your responses to "If it only impacts the first boot, how does this impact the end user experience?". 

    What I have so far:

    • This was working... just fix it :)
    • This is a VDI environment so ever boot is a first boot.

    Are there others?


    - Jason E

    Hi Jason, for us it is a big problem because we are a 6000 client and 7000 user environment (hospital) and our user thins there is a problem (bug) and call our helpdesk. so he have a user who cant work with the patient for minutes because he thinks his client is broken, we have helpdesk stuff who are getting hundred of calls and have no time for others stuff and yes... this is our problem :)

    Thanks for getting us involved and updated.

    Tuesday, July 31, 2018 6:17 AM
  • How can you help? I am currently working with a small set of Premier customers on this issue and we have pretty good understanding of how this issues is impacting them. It would be great to get some additional insights into how this issues impacts you and your deployments. I want to make sure I have your responses to "If it only impacts the first boot, how does this impact the end user experience?". 

    What I have so far:

    • This was working... just fix it :)
    • This is a VDI environment so ever boot is a first boot.

    Are there others?


    - Jason E

    Hi,

    Thanks for the update on this - great to know it's being looked at, and progress made on the underlying cause.

    For us, there are a couple of issues. We happen (for other reasons) to use an auto-logon as part of our bare-metal deployment, so we don't see a problem there. For in-place upgrades though, it's a consistent issue which so far we have merely listed as a known problem that resolves itself after the first logon post-upgrade.

    However, because we set a custom pre-logon screen, any time a machine boots and doesn't have one of those, it looks like it isn't one of our managed installations, but is instead a standalone PC that has been installed by one of our departments. i.e. it makes a PC that is part of our centrally managed service look like something else. This has a risk of confusing people, and making them wonder whether they can log on there or not with their domain account. Or, they think there's a fault with the PC.

    We also generate the bitmap to use for the pre-logon screen at the device in question (so that the resolution comes out right, amongst other things), which means we can include information on it that is specific to the device and its current state. So, you can read the computername and Windows build number right off the pre-logon screen without logging on.

    The pre-logon screen also includes our instructions on how to register for our services if you're new to the University.

    For our computers in bookable teaching centres, we rebuild the bitmap daily with information about the bookings in that room for that day - so that they are visible to the user before they log on. We happen not to be using 17134 in teaching centres, so this isn't a problem there, yet, but anything that causes the pre-logon bitmap to be missing would be a very serious problem.

    Tuesday, July 31, 2018 8:48 AM
  • Hi everyone. Just wanted to let everyone know that we are still working on this. All the right people are engaged and talking through this. As soon as I have an update I will update this thread.


    - Jason E

    Friday, August 3, 2018 9:05 PM
  • Hi everyone. Just wanted to let everyone know that we are still working on this. All the right people are engaged and talking through this. As soon as I have an update I will update this thread.


    - Jason E

    Thanks Jason!

    Great to hear this, thank you

    Friday, August 3, 2018 9:40 PM
  • Hello,

    How did you push the  Background screen via GPO or with the script on SCCM? And the picture applied to all screen resolutions?

    Thanks 

    Nick

    Monday, August 6, 2018 9:48 PM
  • Hi everyone. Just wanted to let everyone know that we are still working on this. All the right people are engaged and talking through this. As soon as I have an update I will update this thread.


    - Jason E

    I'm not sure I'm having the exact same issue so I wanted to post as well. We haven't looked at in-place upgrades yet, usually don't do that until after the bare-metal image has been vetted by all departments.

    In our SCCM bare metal 1803 OSD, we are using a custom branding script that replaces permissions and pictures of the default wallpapers in the OS AND using the GPO's listed by many other users here to make sure the lockscreen and wallpaper are using our branded wallpaper. This script and policies have worked for all previous versions of Win10.

    The issue is that after OSD the lockscreen is set to the default blue background like everyone else is stating. Logging in as any user (domain or local admin), the lockscreen is replaced by our branded image. If the user signs out or locks their workstation, the lockscreen remains the branded image, but rebooting causes the machine to revert back to the default blue lockscreen.

    Here's the rub, as everyone was stating above, logging in fixes the lockscreen, but in our case, it's only fixed until the next reboot. I thought the issue might have to do with the GPO, boot timing, etc... but then I accidentally found that hitting CTRL-ALT-DEL and getting to the logon dialog, but not signing in and letting the logon screen timeout, the lockscreen comes back with the branded image.

    So this tells me that it has nothing to do with anyone logging in at all, but seems to be more of a boot timing issue. Does this fit in to the scenario that you have identified as the issue with the task scheduler or do I have a different issue?

    Wednesday, August 8, 2018 9:04 PM
  • Hi everyone. Just wanted to let everyone know that we are still working on this. All the right people are engaged and talking through this. As soon as I have an update I will update this thread.


    - Jason E

    Can you give us an update? Any good news?

    This is the only thing that keeps us from upgrading, we do not want our employees to believe something went wrong and then call our support team....

    Friday, August 10, 2018 8:11 AM
  • Hi Jason

    As I wrote on 13 July no scheduled tasks are run after Windows 10 1803 OSD until a user logs in. For this issue I opened a MS case (118052818268644). I now suppose that the lock screen image issue has the same cause. The Microsoft engineer told me that this is a design change in 1803 that will be reverted back with an update on the third week of October (automatic updates on the second tuesday of November). Can you maybe confirm that the lock screen image issue will also be fixed with this update?

    Just for your information:
    This issue is a big impact for us because we run some actions after the ConfigMgr OSD task sequence (launched by SMSTSPostAction variable content). At the moment of these actions the lock screen is displayed and we use a "Installation in progress..." background image to tell the user he shouldn't log in to the system. We also do some quality tests at this moment and if there were errors we display a "Installation failed" lock screen image and the user cannot log in to the system. As you see, the lock screen is very important for us and we currently manage about 100'000 PCs for 30 different enterprise customers.

    Would be great to have an update.

    Thanks in advance for your precious work!

    Kind regards,
    Matias

    Tuesday, August 14, 2018 7:20 AM
  • I suspect meanwhile that Microsoft no longer fixes this issue under 1803 and fixes it at all with 1809 in around 6 to 8 weeks. @Jason: what are you saying ? Thank you

    I hope not  System32_AUT as the issue affects the LTSB build as well! 

    Wednesday, August 15, 2018 9:52 AM
  • Hi Jason E.

    Can you give us an update?

    Kind regards,
    Sune

    Monday, August 20, 2018 10:22 AM
  • Hi Jason,

    Do you have any Update about this issue?

    Thank You

    Tuesday, August 21, 2018 10:31 AM
  • Hi everyone. Sorry for the delayed reply on this. I have just completed lab testing of the private version of the fix for 1803. I have confirmed the fix resolves the issue and we are now waiting on the servicing team's decision on how fast we can get this out the door. As soon as I get a date, I will update this thread.

    Disclaimer: As with all software, there is a chance we find an issue while testing this update that delays or prevents us from shipping it. Right now it does not look like that is going to be an issue, but I am sharing this so everyone is aware that it is a possibility.


    - Jason E

    Tuesday, August 21, 2018 1:01 PM
  • Hi everyone. Sorry for the delayed reply on this. I have just completed lab testing of the private version of the fix for 1803. I have confirmed the fix resolves the issue and we are now waiting on the servicing team's decision on how fast we can get this out the door. As soon as I get a date, I will update this thread.

    Disclaimer: As with all software, there is a chance we find an issue while testing this update that delays or prevents us from shipping it. Right now it does not look like that is going to be an issue, but I am sharing this so everyone is aware that it is a possibility.


    - Jason E

    Hi Jason,

    Awesome work and thanks for the update! Can't wait to test it...

    How long do you think it will take for the servicing team to make that decision? If everything is testet ok are we then talking about 7-14 business days or?

    Wednesday, August 22, 2018 9:11 AM
  • Sune,The fix for this issue currently scheduled to ship in 2018.9C , which should be September 18th (barring any unforeseen circumstances).


    - Jason E


    Friday, August 24, 2018 9:30 PM
  • Sune,The fix for this issue currently scheduled to ship in 2018.9C , which should be September 18th (barring any unforeseen circumstances).


    - Jason E


    Hi Jason,

    Thank you for the update.

    /Sune

    Monday, August 27, 2018 10:21 AM
  • Sune,The fix for this issue currently scheduled to ship in 2018.9C , which should be September 18th (barring any unforeseen circumstances).


    - Jason E



    Thanks Jason for your important work! Could you please talk with Dona or her Team that this fix is working in 1809 to? Would be a mess if this lockscreen "bug" is starting again in the next SAC/LTSC Release. Thanks for that.
    Tuesday, August 28, 2018 4:36 AM
  • Hi all

    I've just tested this today with Windows 10 1809 Insider Build 17746 and everything is working fine like it was before Windows 10 1803.

    Kind regards,
    Matias

    Monday, September 3, 2018 12:36 PM
  • Hi all

    I've just tested this today with Windows 10 1809 Insider Build 17746 and everything is working fine like it was before Windows 10 1803.

    Kind regards,
    Matias

    Good to know :-)

    Does anyone know, if the fix for 1803 is included in the new ISO file ?

    Tuesday, September 4, 2018 8:01 AM
  • Very good news!

    Just so long as they fix it in 1803 too.

    Wednesday, September 5, 2018 8:26 AM
  • Yeah great news!

    Now... how about the Win10 LTSB that worked fine last year and now doesn't? Or are we just ignoring that in the hope it'll go away?

    Too late... i've  had to push my labs out with a 'dirty fix' as I couldn't wait on you repairing this screw up! If Microsoft was a plumber I wouldn't let them unblock my loo!!

    Grrr

    Thursday, September 6, 2018 2:01 PM
  • Just tried a fresh bare metal build and an in place upgrade of 1803 with this months servicing stack (KB4456655) and the 2018-09 Cumulative Update (KB4457128) and the issue is still there ;(

    There was another option patch released that reportedly resolved this issue (can't find the article to get the KB atm) but it doesn't show in SCCM so isn't availalble for offline servicing.

    Anyone actually resolved this yet?

    Thanks

    Wednesday, September 12, 2018 11:56 AM
  • Jason stated previously that the patch for 1803 SHOULD be released for 18th of September...
    We're only on the 12th of September ;-)

    Gérald


    Wednesday, September 12, 2018 12:01 PM
  • Yep sorry just re-read. I assumed '2018.9C' meant' 2018-09 Cumulative" was so overjoyed I stopped reading :)


    • Edited by Smiley1244 Wednesday, September 12, 2018 12:12 PM
    Wednesday, September 12, 2018 12:12 PM
  • 2018.9C means 2018, September, Third Week ;)

    Gérald

    Wednesday, September 12, 2018 12:44 PM
  • Yep sorry just re-read. I assumed '2018.9C' meant' 2018-09 Cumulative" was so overjoyed I stopped reading :)



    I did the same thing. I assumed Jason meant Patch Tuesday. Built a new image in SCCM this morning, patching it up to KB4457128, and was sad to see the issue wasn't fixed. Guess I'll try again next week.
    Wednesday, September 12, 2018 5:52 PM
  • I'm also curious, does the fix come for the LTSB 2016 (= 1607) also?

    Saturday, September 15, 2018 4:40 AM
  • Hi,

    We do these (and many other) adjustments via the image modifications without any problems.

    DISM /mount-wim /wimfile:c:\source\image.wim /index:[x] /mountdir:c:\mount\wim
    Replace the pictures in C:\mount\wim\Windows\Web\Screen with the specifications of the corporate design and get the correct picture even with the first login.

    Best Regards

    Sunday, September 16, 2018 6:36 AM
  • Yep sorry just re-read. I assumed '2018.9C' meant' 2018-09 Cumulative" was so overjoyed I stopped reading :)



    I did the same thing. I assumed Jason meant Patch Tuesday. Built a new image in SCCM this morning, patching it up to KB4457128, and was sad to see the issue wasn't fixed. Guess I'll try again next week.
    Any updates to this patch being released?  Does anyone know the KB#?
    Tuesday, September 18, 2018 10:58 PM
  • Yep sorry just re-read. I assumed '2018.9C' meant' 2018-09 Cumulative" was so overjoyed I stopped reading :)



    I did the same thing. I assumed Jason meant Patch Tuesday. Built a new image in SCCM this morning, patching it up to KB4457128, and was sad to see the issue wasn't fixed. Guess I'll try again next week.

    Any updates to this patch being released?  Does anyone know the KB#?

    It doesn't seem like any new update were released 18th September.

    @Jason any update on this ?

    Wednesday, September 19, 2018 5:12 AM
  • There was an update released on the 17th (KB4464218) but i can confirm that it did not fix this issue.
    Wednesday, September 19, 2018 1:59 PM
  • There was an update released on the 17th (KB4464218) but i can confirm that it did not fix this issue.
    I can confirm that too. *sigh*
    Wednesday, September 19, 2018 8:03 PM
  • Hi everyone,
    The September release that includes the fix for this issue slipped 2 days in order for us to include some additional fixes we thought warranted the delay. Should be available tomorrow (Sept 20th).


    - Jason E


    Wednesday, September 19, 2018 9:14 PM
  • Hi,

    What's KB for this Update?

    Thanks

    DG


    • Edited by Leinad84 Thursday, September 20, 2018 12:56 PM
    Thursday, September 20, 2018 12:56 PM
  • It looks like it is KB4458469 (OS Build 17134.319)

     

    https://support.microsoft.com/en-us/help/4458469/windows-10-update-kb4458469

     

    Near the bottom it says-

    ·         Addresses an issue in which the lock screen shows a solid color instead of an image specified by a policy before a customer signs in for the first time.


    Thursday, September 20, 2018 5:30 PM
  • The fix is now available @ https://support.microsoft.com/en-us/help/4458469


    - Jason E

    • Marked as answer by foxtrot_romeo Friday, October 12, 2018 12:56 PM
    Thursday, September 20, 2018 5:53 PM
  • And now to wait just a little bit more. KB4458469 appears in the Update Catalog (http://www.catalog.update.microsoft.com/Search.aspx?q=KB4458469), but doesn't appear to be available to WSUS (and subsequently, SCCM) yet. Did a synchronization and got nothing.

    • Edited by the_gizmo Thursday, September 20, 2018 7:11 PM
    Thursday, September 20, 2018 7:11 PM
  • Quick first test with KB4458469

    Lockscreen is still not working

    
    Thursday, September 20, 2018 8:39 PM
  • I've applied the 9/20 update to my gold image.  i'm now on .319 when I run winver.

    I've imaged via an SCCM task sequence multiple computers, and all of them are immediately pulling the group policy and applying the lock screen.  I had hoped this would also be the solution for the device based authentication to our wireless (which also quit working with 1803) but it appears it is not so.  

    Thursday, September 20, 2018 10:10 PM
  • I installed the KB4458469 and it still does not show the personalized image when i block screen, i apply the GPRESULT command and it shows that the policy is being applied but the image does not appear when the screen is blocked, the workstation in my domain are Windows 10 Pro.

    Regards!


    • Edited by Danielg02 Friday, September 21, 2018 12:17 AM Typing error
    Friday, September 21, 2018 12:14 AM
  • I updated image in SCCM and all good now. Thank you.
    Friday, September 21, 2018 3:55 AM
  • So there is no fix for 1607 (= LTSB 2016)? At least it isn't mentioned in the 20th September KB release notes..

    Friday, September 21, 2018 3:59 AM
  • And now to wait just a little bit more. KB4458469 appears in the Update Catalog (http://www.catalog.update.microsoft.com/Search.aspx?q=KB4458469), but doesn't appear to be available to WSUS (and subsequently, SCCM) yet. Did a synchronization and got nothing.

    I'm also waiting for it to be available on WSUS.
    Friday, September 21, 2018 5:45 AM
  • Seems like the patch only fixes the issue if you patch your image and deploy it with this patch. All already productive clients still show the solid blue.

    Well done Microsoft :)

    Friday, September 21, 2018 7:20 AM
  • This issue does not occur on 1607. If you are seeing a similar symptoms on 1607 where the custom lock screen policy does not work, but ONLY does not work on the first boot after a deployment, let me know.

    - Jason E


    Friday, September 21, 2018 5:53 PM
  • This policy does not work on Win10 pro, Only Enterprise and Education SKUs. Refer to https://docs.microsoft.com/en-us/windows/client-management/group-policies-for-enterprise-and-education-editions


    - Jason E

    Friday, September 21, 2018 5:55 PM
  • This makes sense for an issue that only occurs on the first boot after a deployment. The patch has to be slipped into the flat you are using for the install.

    - Jason E

    Friday, September 21, 2018 5:57 PM
  • Can you provide details on how you did your testing. I am assuming you updated your install media with the patch and re-deployed a machine into an OU where the policy would be applied, correct?

    - Jason E

    Friday, September 21, 2018 5:59 PM
  • This issue does not occur on 1607. If you are seeing a similar symptoms on 1607 where the custom lock screen policy does not work, but ONLY does not work on the first boot after a deployment, let me know.

    - Jason E



    Well, I'm seeing the exact behavior on 1607 (LTSB 2016)...
    Saturday, September 22, 2018 4:47 AM
  • The fix is now available @ https://support.microsoft.com/en-us/help/4458469


    - Jason E

    Hi Jason,

    Do you know when it will be available to WSUS? Still waiting... *sigh*

    Sunday, September 23, 2018 11:11 AM
  • The fix is now available @ https://support.microsoft.com/en-us/help/4458469


    - Jason E

    Hi Jason,

    Do you know when it will be available to WSUS? Still waiting... *sigh*

    I added it manually to our image and I can confirm that it will fix the lockscreen issue. Thanks!
    Monday, September 24, 2018 9:33 AM
  • Jason,

    I have updated our install WIM and can confirm that 17134.319 is the installed version, however our lockscreen issue has not been fixed.

    For context, here was my original issue:

    I'm not sure I'm having the exact same issue so I wanted to post as well. We haven't looked at in-place upgrades yet, usually don't do that until after the bare-metal image has been vetted by all departments.

    In our SCCM bare metal 1803 OSD, we are using a custom branding script that replaces permissions and pictures of the default wallpapers in the OS AND using the GPO's listed by many other users here to make sure the lockscreen and wallpaper are using our branded wallpaper. This script and policies have worked for all previous versions of Win10.

    The issue is that after OSD the lockscreen is set to the default blue background like everyone else is stating. Logging in as any user (domain or local admin), the lockscreen is replaced by our branded image. If the user signs out or locks their workstation, the lockscreen remains the branded image, but rebooting causes the machine to revert back to the default blue lockscreen.

    Here's the rub, as everyone was stating above, logging in fixes the lockscreen, but in our case, it's only fixed until the next reboot. I thought the issue might have to do with the GPO, boot timing, etc... but then I accidentally found that hitting CTRL-ALT-DEL and getting to the logon dialog, but not signing in and letting the logon screen timeout, the lockscreen comes back with the branded image.

    So this tells me that it has nothing to do with anyone logging in at all, but seems to be more of a boot timing issue. Does this fit in to the scenario that you have identified as the issue with the task scheduler or do I have a different issue?


    Monday, September 24, 2018 2:33 PM
  • Dyltone,
    This sounds like a separate issue not covered in our debug of the originally reported issue. I would recommend removing the part of your deployment that changes the OS's permissions (never a good idea to replace someone else's permissions) and see if the issue still occurs.


    - Jason E

    Monday, September 24, 2018 2:48 PM
  • This issue does not occur on 1607. If you are seeing a similar symptoms on 1607 where the custom lock screen policy does not work, but ONLY does not work on the first boot after a deployment, let me know.


    - Jason E



    Well, I'm seeing the exact behavior on 1607 (LTSB 2016)...

    I can confirm on our 1607 LTSB 2016 (1607 Semi-Annual is fine) builds we do also experience this too BUT it can be resolved by manually creating '%programdata%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen.jpg' then the problem goes away. On 1803 this does not work (nothing works :) )

    If you are interested this is the batch file we use with SCCM to set and fix the custom background (still needs the GPO set)

    echo off
    SETLOCAL EnableDelayedExpansion
    cls

    copy /V /Y /Z "%~dp0custom.jpg" %windir%\Web\Screen\custom.jpg
    if !ErrorLevel! neq 0 exit /b 1

    If "%1"=="/FIX" goto Fix:
    exit /b 0

    :Fix
    Takeown.exe /F "%ProgramData%\Microsoft\Windows\SystemData" /R /D Y
    rd /S /Q "%ProgramData%\Microsoft\Windows\SystemData\S-1-5-18"
    MD "%ProgramData%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P"
    copy /V /Y /Z "%~dp0custom.jpg" "%ProgramData%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen.jpg"
    exit /b !ErrorLevel!

    The batch file must be in the same dir as the custom.jpg and needs to be executed with the switch '/FIX' to apply the extra LTSB fix

    Monday, September 24, 2018 2:59 PM
  • The fix is now available @ https://support.microsoft.com/en-us/help/4458469

    Hi Jason,

    Just done a quick test with it here, using a patched image to do an in-place upgrade from an earlier build (15063).

    Worked fine - and the correct pre-login image was shown after the upgrade. I've only done one test machine, but it was failing consistently before, so this looks good.

    Monday, September 24, 2018 3:52 PM
  • This issue does not occur on 1607. If you are seeing a similar symptoms on 1607 where the custom lock screen policy does not work, but ONLY does not work on the first boot after a deployment, let me know.


    - Jason E



    Well, I'm seeing the exact behavior on 1607 (LTSB 2016)...

    I can confirm on our 1607 LTSB 2016 (1607 Semi-Annual is fine) builds we do also experience this too BUT it can be resolved by manually creating '%programdata%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen.jpg' then the problem goes away. On 1803 this does not work (nothing works :) )

    If you are interested this is the batch file we use with SCCM to set and fix the custom background (still needs the GPO set)

    echo off
    SETLOCAL EnableDelayedExpansion
    cls

    copy /V /Y /Z "%~dp0custom.jpg" %windir%\Web\Screen\custom.jpg
    if !ErrorLevel! neq 0 exit /b 1

    If "%1"=="/FIX" goto Fix:
    exit /b 0

    :Fix
    Takeown.exe /F "%ProgramData%\Microsoft\Windows\SystemData" /R /D Y
    rd /S /Q "%ProgramData%\Microsoft\Windows\SystemData\S-1-5-18"
    MD "%ProgramData%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P"
    copy /V /Y /Z "%~dp0custom.jpg" "%ProgramData%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen.jpg"
    exit /b !ErrorLevel!

    The batch file must be in the same dir as the custom.jpg and needs to be executed with the switch '/FIX' to apply the extra LTSB fix


    If you use robocopy /B you don't need to take the ownership ;)
    Monday, September 24, 2018 4:19 PM
  • Hi Jason,

    So I have been following this thread for a while now. My agency is using the 3 settings you described from KB4338817:

    • GPO “Force a specific default lock screen and logon image”
    • GPO “Prevent changing lock screen and logon image”
    • Registry entry DisableLogonBackgroundImage to 1

    to get a standard blue background on the password screen because the user icon and the lock screen background are so similar they tended to blend together. On 1703, this worked as expected, but with 1803 it caused the custom lockscreen and logon screen to be blue. I thought it was the same issue that everyone else here was seeing, but when I tested I was still not able to get the custom lock screen before or after a logon even with the KB4458469. I have found that if I set DisableLogonBackgroundImage to 0, I get the custom lock screen, but of course not the blue password screen. It looks like KB4338817 applied to 1709. Was there a fix for this for 1803?

    Thanks,

    Clyde

    Monday, September 24, 2018 7:01 PM
  • Thanks for the tip of robocopy /b, I'm taking ownership to remove the whole dir tree. You sometimes get different subfolders that need removing (LockScreen_Z etc)

    I can confirm that KB4458469 installed manually during a 1803 bare metal SCCM TS end the TS with the correct custom background :)

    wusa.exe "windows10.0-kb4458469-x64_22139e5b137440eac5526d4c5c85762fcbe80030.msu" /quiet /norestart

    I know we could import this manually in to WSUS but is it going to be advertised or built in to next months Cumulative?


    • Edited by Smiley1244 Tuesday, September 25, 2018 9:31 AM
    Tuesday, September 25, 2018 9:01 AM
  • Hi Jason,

    I too have been following this posting for a while. We did a build and Capture in MDT making sure Servicing Stack KB4456655 got installed first then CU KB4458469 bringing the OS build up to 17134.319. we use a copy to stage 2 .jpg files one for Dev and one for Production in that B&C sequence in C:\Windows\Web\Screen and set the one for Dev -

    reg add HKLM\Software\Policies\Microsoft\Windows\Personalization / V LockScreenImage /T REG_SZ /D C:\Windows\Web\Screen\LockscreenA.jpg /F - that .WIM gets forked out to one of our small testing environments to use that lock screen. The same captured .WIM is also deployed through SCCM in production and domain GPO should set the lock screen. It doesn't (blue lock screen) and what's worse logging in and out does not change it. The Domain GPO sets C:\Windows\Web\Screen\LockscreenB.jpg which is correct. We cannot change the lockscreen to any other .jpg in C:\Windows\Web\Screen either

    


    sysbuilder


    • Edited by sysbuilder Thursday, September 27, 2018 12:09 AM
    Wednesday, September 26, 2018 10:53 PM
  • to everyone still following this -

    My team and I see the following. My previous post steps directly above this one, worked perfectly in 1703. We believe the lockscreen can be set at Domain GPO level and work but works only once and the lockscreen cannot be changed after that.

    At WINVER 3.19 (fix from 20th) and .320 (fix from 26th) in Build and Capture, the VM displays the correct wallpaper but if you attempt to change it - you cannot and you get the Blue background. In B&C we use the below reg add

    reg add HKLM\Software\Policies\Microsoft\Windows\Personalization / V LockScreenImage /T REG_SZ /D C:\Windows\Web\Screen\LockscreenA.jpg /F

    That captured WIM deployed to production that had the above reg add but then gets the Domain GPO to change it to a different lockscreen is broken with a blue background with WINVER .319 and .320 and cannot be changed.

    It was better when anyone could log in and get the correct lockscreen

    Anyone else confirm this?


    sysbuilder

    Thursday, September 27, 2018 8:55 PM
  • Hi Jason,

    So I have been following this thread for a while now. My agency is using the 3 settings you described from KB4338817:

    • GPO “Force a specific default lock screen and logon image”
    • GPO “Prevent changing lock screen and logon image”
    • Registry entry DisableLogonBackgroundImage to 1

    to get a standard blue background on the password screen because the user icon and the lock screen background are so similar they tended to blend together. On 1703, this worked as expected, but with 1803 it caused the custom lockscreen and logon screen to be blue. I thought it was the same issue that everyone else here was seeing, but when I tested I was still not able to get the custom lock screen before or after a logon even with the KB4458469. I have found that if I set DisableLogonBackgroundImage to 0, I get the custom lock screen, but of course not the blue password screen. It looks like KB4338817 applied to 1709. Was there a fix for this for 1803?

    Thanks,

    Clyde

    Clyde,

    This is the exact issue we are facing as well. I find that removing the registry key for DisableLogonBackgroundImage "fixes" the missing lock screen image but it makes our password entry (logon) screen un-usable because of the background image still being visible.

    Good find on the KB4338817 and I'm hoping that it becomes available for 1803, but there isn't any mention of it in the update from the 26th.

    https://support.microsoft.com/en-us/help/4458469/windows-10-update-kb4458469


    Friday, September 28, 2018 2:21 PM
  • version 1803 now mentioned in the update

    https://support.microsoft.com/en-us/help/4458469/windows-10-update-kb4458469

    anyone can confirm it is working?

    Tuesday, October 2, 2018 7:57 AM
  • Applied all the latest KBs and no luck. Note that so far I am testing an in-place upgrade from 1703 to 1803 have not tested building from scratch. 

    -Sulabh

    Tuesday, October 2, 2018 7:28 PM
  • I have the custom background working with 1803. I downloaded KB4458469 from the update catalog and then used DISM to slipstream it into the install.wim image of our 1803 installer. Deployed Windows 10 using a Configuration Manager Task Sequence which also enabled the registry settings and saw our background when reaching the lock screen for the first time.

    KB4458469 from Update Catalog: http://www.catalog.update.microsoft.com/Search.aspx?q=KB4458469

    How to mount and unmount a WIM file using DISM: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/mount-and-modify-a-windows-image-using-dism

    How to add a package to a WIM file using DISM: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/dism-operating-system-package-servicing-command-line-options

    I've also noticed that KB4458469 is not available in WSUS so anybody trying to rely on that or Configuration Manager to install the update is not going to have any success. You have to install it manually (DISM or WUSA) or rely on installing updates from Microsoft Update.

    • Edited by the_gizmo Wednesday, October 3, 2018 12:30 PM
    Wednesday, October 3, 2018 12:14 PM
  • Can you confirm that you see the Lock Screen at startup, but hitting CTRL-ALT-DEL will cause the background to no display over the Logon Screen (password entry screen) and can you confirm that you have both GPO's and the registry key set?

    For reference, the issue is caused when all 3 of these are true:

    • GPO “Force a specific default lock screen and logon image”
    • GPO “Prevent changing lock screen and logon image”
    • Registry entry DisableLogonBackgroundImage to 1

    Wednesday, October 3, 2018 2:16 PM
  • Can you confirm that you see the Lock Screen at startup, but hitting CTRL-ALT-DEL will cause the background to no display over the Logon Screen (password entry screen) and can you confirm that you have both GPO's and the registry key set?

    For reference, the issue is caused when all 3 of these are true:

    • GPO “Force a specific default lock screen and logon image”
    • GPO “Prevent changing lock screen and logon image”
    • Registry entry DisableLogonBackgroundImage to 1


    By default we only use the "Force a specific default lock screen and logon image" GPO. We're not using "Prevent changing lock screen and logon image" or enabling the registry setting to disable the background on the logon screen. In our environment (Windows 1803 x64 Education & Enterprise with KBKB4458469 slipstreamed into the install.wim using DISM before installation), everything works as expected:

    • Our custom background image appears on the lock screen (the screen with the time and date).
    • Our custom background image appears on the logon screen (where you enter your username and password).

    I went back and tried the settings above ("Force a specific default lock screen and logon image", “Prevent changing lock screen and logon image”, "DisableLogonBackgroundImage" set to 1)  and the results were also successful per the requirements:

    • Our custom background image appears on the lock screen (the screen with the time and date).
    • No background image is shown on the logon screen (where you enter your username and password).
    All of my testing was performed on virtual machines I use for building reference images and before any account (local or domain) logged on.
    Wednesday, October 3, 2018 7:23 PM
  • With all 3 settings applied, we get the follow:

    • Lock screen is blank on boot.
    • If you hit CTRL-ALT-DEL the password entry page has a blank background (this is what we need as our custom lock screen/wallpaper interfere/clash with the password entry fields.
    • If you hit CTRL-ALT-DEL and let the password page timeout back to lock screen, the custom lock screen wallpaper is displayed.
    • If you logon to any account, the custom wallpaper is displayed as expected.
    • If the user locks the computer, the custom lock screen wallpaper is displayed as expected.
    • Rebooting starts the process over with blank lock screen.

    So we have to options to choose from until M$ fixes the issue:

    1. Allow the lock screen wallpaper to be displayed on the logon screen and all other scenarios are working
    2. Disable the wallpaper from displaying on the logon screen and have no custom lock screen until after a user logs on

    Keep in mind that these options work together on all lower versions of Windows 10 (1709 having been patched for this scenario 2 months ago)

    Thursday, October 4, 2018 3:43 PM
  • We are deploying Windows via SCCM CB in our environment, and have noticed that a Windows 10 1803 deployment no longer displays the custom login/lock screen image unless a user logs in to the computer first. Instead, the computer displays the solid blue colour associated with a lack of an available image and no Spotlight.

    Our task sequence removes all of the default images from the default location (C:\Windows\Web\Screen) and replaces them with our own, as well as clearing the contents from %ProgramData%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z

    We are also using the "Force a Default Lock Screen Image" GPO.

    The image is displayed after the task sequence concludes on a 1709 deployment, but not on 1803. Did the location of the default lock screen change? Or is there another reason that it would not apply until a user logs in?

    Curiously, as soon as any user logs in, the behaviour returns to normal.


    After in-place upgrade from Windows 10 Pro 1709 to 1803 "%ProgramData%\Microsoft\Windows\SystemData\S-1-5-18" has gone. Upgraded twice, to be really sure!!! Can anybody report the same behaviour?

    On the other Hand the folder "S-1-5-18" does exist with a clean install (wipe and load) of 1709 and 1803 furthermore.

    Therefore my solution with deleting "%ProgramData%\Microsoft\Windows\SystemData\S-1-5-18" does not work with in-Place upgrade.


    Thursday, October 11, 2018 6:54 AM
  • I have the same issue as everyone else.  Im not even doing it at the domain level.  Trying as a local policy that only affects my workstation.  I'm also using a windows 10 pro OS and I thought I read somewhere that this wont work on pro.  If so thats ridiculous!

    C'mon MSFT fix this!


    • Edited by Scott(WW) Thursday, October 11, 2018 12:14 PM
    • Proposed as answer by ajw-ottawa Saturday, December 22, 2018 4:43 PM
    Thursday, October 11, 2018 12:05 PM
  • I have the same issue as everyone else.  Im not even doing it at the domain level.  Trying as a local policy that only affects my workstation.  I'm also using a windows 10 pro OS and I thought I read somewhere that this wont work on pro.  If so thats ridiculous!

    C'mon MSFT fix this!


    Microsoft removed the ability to customize the lock screen background of Windows 10 Pro using group policies. You have to use Education or Enterprise.

    https://docs.microsoft.com/en-us/windows/client-management/group-policies-for-enterprise-and-education-editions

    Thursday, October 11, 2018 5:14 PM
  • I'm using Enterprise. The bug was identified and fixed with 1709... just not 1803.
    Thursday, October 11, 2018 7:29 PM
  • Thank you so much, Jason! As of this month's build and capture including the October CU, this issue appears to have been resolved.
    Friday, October 12, 2018 12:57 PM
  • I've got clients running 1803 (latest available CU) that aren't getting an updated lock screen. The file copies to a local folder, but the cache (in programdata) sticks with the old image. All clients are running Enterprise.
    Monday, October 15, 2018 6:57 PM
  • Jason,

    Any update on the fix from KB4338817 for 1709 being added to 1803?:

    • GPO “Force a specific default lock screen and logon image”
    • GPO “Prevent changing lock screen and logon image”
    • Registry entry DisableLogonBackgroundImage to 1
    Friday, October 19, 2018 6:55 PM
  • I searched in numerous places for an answer and nothing seemed to help... I then remembered that there is limitation of size for the images displayed on the lockscreen, if these are not setup to be less than 250kb they simply will not display, no matter what you do. I setup my test image to be 1920x1080 and a file size of 210kb, I put it up on a share, pointed it to that location and verified that it works properly. I'm not sure why so many people are having issues with this. We are running Windows 10 1803 Enterprise and this is working properly on all of our systems.
    Wednesday, October 24, 2018 6:03 PM
  • I'm afraid that can't be correct.  Microsofts default lock screens are up to 3.2MB in size.  All of the lock screens I have used for years are between 1mb and 2mb and there was never an issue until Microsoft made these changes in 1803.  The pictures work on our machines too after the first login which is the whole problem.
    Thursday, October 25, 2018 1:40 AM
  • We too are having this issue with only 1803 after the September update.

    For a workaround I am using a GPP to first delete the "%ProgramData%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P" folder then copying the LockScreen.jpg file into the "%ProgramData%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen.jpg" and into C:\Windows\Web\Screen\img100.jpg

    From what I can see on our 1703 and 1709 builds locking the screen rebuilds the LockScreen_P cache, but after the 1803 September update this folder always remains empty.

    Friday, October 26, 2018 5:03 AM
  • Try this solution - https://pastebin.com/c9D4mgJU

    its work fine on non domain pc, i will going to test it on my AD virtual appliance by several next days


    Tuesday, October 30, 2018 8:03 PM
  • Hi System32_AUT,
    do you plan to move from Ivanti DSM to SCCM? Because DSM is only maintained until 2022.

    -Thilo


    Wednesday, October 31, 2018 8:39 AM
  • I have the same issue as everyone else.  Im not even doing it at the domain level.  Trying as a local policy that only affects my workstation.  I'm also using a windows 10 pro OS and I thought I read somewhere that this wont work on pro.  If so thats ridiculous!

    C'mon MSFT fix this!


    Had same problem on one of 4 Win 10 PRO 1803 and 1809 machines. Found a fix to permanently and reliably display a custom picture on both the SIGN-IN and LOGIN screens:

    1) go to Personalization in Settings, choose Lock Screen on left side

    2) set Background to Windows Spotlight, and set Show Lock Screen Background Picture on Sign-in Screen to ON

    3) Ctrl-Alt-Del on keyboard, and choose Sign Out

    4) Log back into Windows

    5) repeat steps 3) and 4) above

    6) go back to Personalization - Lock Screen window

    7) set Background to Picture

    8) browse to and select your custom image file using the Browse button just below on same window - remember its resolution must match your main display's resolution - and leave Show Lock Screen Background Picture on Sign-in Screen ON

    9) repeat steps 3) and 4) above TWICE

    10) final step:  Restart (not Shut down) your PC twice (it may work without this step, but I figured it's worth making sure)

    You now have your custom image on both the initial Sign-in and subsequent Logon screens - but maybe only until the next MS Update...

    Saturday, December 22, 2018 5:02 PM
  • What i have discover:

    Clean install 1703 1709 1803 1809 without any change, No AD GPO just standalone install  - "Lock Screen Slideshow" from "Personalization"  working, no issues. 

     If i mount and Unmount  via Dism or any other tools,  without changes add to WIM file, it ruin the Slideshow. and nothing helps to fix it  .

    Saturday, February 16, 2019 7:07 AM
  • Just to bump an old thread - we're seeing what looks like very similar symptoms with a solid colour being displayed in place of the specified image on 1809 LTSC, but only if the "Press CTRL+ALT+Del to Unlock" prompt is enabled.

    If we turn off the ctrl+alt+del prompt, then it displays normally.

    When the solid colour is displayed, it looks like the cache in programdata is populated correctly; just not being shown.

    Anyone else tried this and found the same symptoms?

    Wednesday, March 6, 2019 4:46 PM
  • Exact same issues here for LTSC 1809.  Also, if you Press CTRL+AL+DEL and then wait for it to timeout it displays our logon wallpaper.

    It did work pre-patching but as soon as I rolled patches into the image I lost the ability.

    No solution yet for us, at this point I just staged it for testing and told people it is a MS issue that may or may not get resolved.

    Wednesday, March 6, 2019 8:21 PM
  • I have the same problem too and finally find a solution, It's a <g class="gr_ gr_15 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" data-gr-id="15" id="15">powerscript</g> that you can deploy by GPO. I did it from my 2008 server. This script <g class="gr_ gr_16 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar multiReplace" data-gr-id="16" id="16">create</g> a <g class="gr_ gr_18 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling" data-gr-id="18" id="18">register</g> key and copy the jpg to windows 10. It works on my site. Location of the <g class="gr_ gr_46 gr-alert gr_gramm gr_inline_cards gr_run_anim Style multiReplace" data-gr-id="46" id="46"><g class="gr_ gr_31 gr-alert gr_spell gr_inline_cards gr_disable_anim_appear ContextualSpelling ins-del multiReplace" data-gr-id="31" id="31">powerscrip</g> :</g> https://gallery.technet.microsoft.com/scriptcenter/Change-Lock-Screen-and-245b63a0

    • Proposed as answer by EddieHMWong Monday, March 18, 2019 5:02 PM
    Monday, March 18, 2019 5:02 PM
  • Question