none
1703 Creators Update no longer adding custom lock screen picture via GPO for Enterprise?

    Question

  • Hi,

    We have been testing and preparing our windows 10 deployment for some months now and have been reliably re-branding the lock screen background using the computer group policy: Control Panel/Personalization/Force a specific default lock screen and logon image.

    Since updating to the new creators update (1703) the settings are applying but not actually working.  The test machine is licensed with Enterprise edition.

    If I open the personalize settings on our test machine I can see the correct settings and picture and any changes are grayed out.  Despite this the lock screen is still just showing the standard windows 10 slideshow with the cave picture?


    Friday, April 07, 2017 8:51 AM

All replies

  • You don't mention what version you were upgrading from, but we've found this setting to be unreliable in some builds (including 14393 and 15063) and simply ignored in various preview builds.

    We have a workaround that seems to work so far, detailed in this thread:

    https://social.technet.microsoft.com/Forums/en-US/9b01f9ec-85de-413c-bf4c-ac12599d46b4

    Friday, April 07, 2017 9:31 AM
  • Hi Mike,

    We upgraded from 1607 which was working fine for us for many weeks without issue.  Interestingly our symptoms do not match the link you posted.  

    The registry setting is being set.

    We are seeing the default cave picture instead of a solid colour and have not once seen the correct picture.

    The personalise menu in shows all the correct pictures as per the screenshot below.

    I will try and have a look at clearing the contents of that cache folder to see if it has somehow got itself stuck.

    Friday, April 07, 2017 10:55 AM
  • We are finding the same thing when trying to build image masters based off 1703.

    What was working in Windows 10 1507, 1511 and 1607 isn't working in 1703 (Setting HKLM\SOFTWARE\Policies\Microsoft\Windows\Personalization\LockScreenImage and HKLM\SOFTWARE\Policies\Microsoft\Windows\Personalization\NoChangingLockScreen).

    Monday, April 10, 2017 4:36 AM
  • Hi Makes006,

    Did the issue occur with all the machines? Have you restarted the machine to make the gpo take effect?

    I have made a test on my Windows 10.15063.14 Enterprise version. That gpo could work well. Please update to the latest version then check the symptom again.
    In addition, I hope Mike's suggestion will work.

    Best regards

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


    Monday, April 10, 2017 5:53 AM
    Moderator
  • Also having the same issue.  Worked fine on all previous releases of Win10 Enterprise, with 1703 it's no longer applied.
    Monday, April 10, 2017 10:17 AM
  • +1 same issue, but randomly on some machines
    Monday, April 10, 2017 1:07 PM
  • Seeing this in our environment also. New SCCM deployments and upgrades to 1703 enterprise all result in the default lock screen background picture despite gpo setting custom background. The custom background is visible in the lock screen settings preview windows but obviously not at logon screen.

    Monday, April 10, 2017 9:49 PM
  • Yup same problem here. Even tried messing around in the hidden readonly cache folder... no luck.

    1703 enterprise, in place upgrade from anniversary edition.


    restarts, gpupdate /force etc etc ... nothings makes it work.

    Not yet running the latest ADM templates in our gpo stack yet. That's the only thing I can think of outside of an OS bug.

    Tuesday, April 11, 2017 1:57 AM
  • Same here!

    Clean install of 1703 education, no custom lockscreen via GPO (even after 'gpupdate /force').

    GPO still works fine with older version (1511, 1607).

    Newest admx-files in use.

    Tuesday, April 11, 2017 9:37 AM
  • Ok I'm going to stop beating my head against the wall here.. Spent 3 hours last night messing around in logs and folders trying to figure out what mechanism is at play here. Got nowhere.
    Tuesday, April 11, 2017 11:11 AM
  • This may be a red herring, and not documented. But, I'm finding this more reliable if I use a png as the specified image rather than a jpg.

    The help text in gpedit.msc just talks about "images" and doesn't mention a list of supported formats, although it uses jpg in its examples. But using a png seems to work, and when the thumbnails are generated in the lockscreen_p folder, they are also pngs (even though they have .jpg file extensions - open them in notepad and they start %PNG).

    May or may not be useful, but its something worth trying, and preferable in our case as it's non-lossy.

    Tuesday, April 11, 2017 11:26 AM
  • This may be a red herring, and not documented. But, I'm finding this more reliable if I use a png as the specified image rather than a jpg.

    The help text in gpedit.msc just talks about "images" and doesn't mention a list of supported formats, although it uses jpg in its examples. But using a png seems to work, and when the thumbnails are generated in the lockscreen_p folder, they are also pngs (even though they have .jpg file extensions - open them in notepad and they start %PNG).

    May or may not be useful, but its something worth trying, and preferable in our case as it's non-lossy.


    I gave that a try. No go.
    Tuesday, April 11, 2017 5:12 PM
  • Did some more testing with this today, but didn't have time to write up a post.

    But, in short, setting the policy to not display the last signed-in username makes it a lot easier to reproduce the problem. With that set, I had two failures in a row from bare metal installs of 15063, allowing it to update before setting any policies, and using a local account.

    It may also continue to work if you've set the lock screen policy and had it working before setting the last signed-in user policy, although I need to do more experimenting with that.

    Tuesday, April 11, 2017 5:34 PM
  • I admire all the effort that people are going to in order to find a fix for this, I on the other hand have not had any more time to test this due to other priorities.  

    It would be really nice if this kind of stuff would just work.  Rolling out windows 10 in the enterprise compared to 7 is a nightmare.

    I will try the png option tomorrow.  For reference my two test machines were a physical and virtual vm each built with our base win 10 image and then updated to creators update.  

    Tuesday, April 11, 2017 10:33 PM
  • Just adding to the list of people having this issue. Has been working great since 1511 and stops working when upgrading to 1703. Also when deploying to bare-metal. I thought this was a insider bug but i guess not since its also in 1703 stable release.
    Wednesday, April 12, 2017 11:53 AM
  • Add me to the affeted people list

    Whislt I add this to my growing "reasons not to upgrade to 1703 yet" list...

    Regards Craig Wilson

    Wednesday, April 12, 2017 12:07 PM
  • Yup, I'm seeing this too. Rolled a machine back to 1607 and it's working again. Same thing on a VM upgraded with the Upgrade Assistant (running Edu). Very scruffy. The correct image shows in the preview (and the GPO is being applied as it's locked out) but it doesn't actually show. I'm sure you really want us to see this cave MS, but we have other plans.
    Wednesday, April 12, 2017 12:38 PM
  • If it was just this, then it wouldn't be much of a show-stopper, but my rollout was already halted with this issue:

    Windows 10 "Creators Update" - Cannot verify MS account when using Domain Account


    Regards Craig Wilson

    Wednesday, April 12, 2017 1:29 PM
  • I'm seeing this as well with a PC I updated from 1607 Education x64 to 1703 Education x64. Coworker did a fresh install the other day and GPO is correctly showing the lock screen so it must be tied to the upgrade process. I've yet to update the admx templates from https://www.microsoft.com/en-us/download/details.aspx?id=55080 but am going to give that a try.
    Wednesday, April 12, 2017 3:23 PM
  • +1

    We are facing the same issue with our tests on 1703, a colleague of mine has created a script that he might want to share, I'll ask him tomorrow.

    Wednesday, April 12, 2017 3:46 PM
  • +1 Here as well.

    This is going to hold us up until it gets fixed.

    Wednesday, April 12, 2017 8:07 PM
  • I also updated the templates yesterday to the newest ones (for 1703). Did a clean install right now (like always), still no GPO-Lockscreen.
    Thursday, April 13, 2017 4:53 AM
  • +1 - I just deployed brand new 1703 image (from ISO, not upgraded) to a lab of PCs and none of them are getting custom lock/login screen.

    I even tried setting it to one of the other Microsoft default pictures, no luck. Tried png, jpg and bmp as others suggested, still no luck. Tried setting the policy locally on the computer and disabling other GPOs applying to it, and it still displays the default lock screen.

    Seems like this entire GPO option is broken on 1703 - I'm interested to know how it works for some people though.

    Interestingly though, if you login to the machines and open up Settings > Personalization > Lock Screen it displays the correct lock screen that is applied by GPO. It's just not showing on the Lock Screen itself.

    • Edited by Chaori_ Thursday, April 13, 2017 7:22 AM
    Thursday, April 13, 2017 7:01 AM
  • Thought I'd add myself to the ever growing list! Exact same problem here.

    GPO Lock Screen shows correctly in  Settings > Personalization > Lock Screen after upgrading from 1607 to 1703. (x64 Education)

    However the default lock screen is displaying on boot up....

    Suffice to say I'm currently rolling out to 500 clients despite this as I don't see it as a major problem that is hindering deployment or operational functionality. Purely cosmetic...

    No doubt a fix will be issued soon.

    Only other anomalies I have encountered with the upgrade is the DVD and Radeon Drivers on some clients get knocked out but a Windows Update resolves these issues...






    • Edited by rebell_dtu Thursday, April 13, 2017 8:31 AM
    Thursday, April 13, 2017 8:03 AM
  • I'm that colleague ;-)

    We've used this script as an startup script in a computer GPO :

    TAKEOWN /F %windir%\Web\Screen /R
    ICACLS %windir%\Web\Screen /grant:r Administrators:F /T
    ICACLS %windir%\Web\Screen /setowner Administrators /T
    DEL /F /Q %windir%\Web\Screen\*.*
    
    TAKEOWN /F %ProgramData%\Microsoft\Windows\SystemData /R
    ICACLS %ProgramData%\Microsoft\Windows\SystemData /grant:r Administrators:F /T
    ICACLS %ProgramData%\Microsoft\Windows\SystemData /setowner Administrators /T
    
    TAKEOWN /F %ProgramData%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_? /R
    ICACLS %ProgramData%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_? /grant:r Administrators:F /T
    ICACLS %ProgramData%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_? /setowner Administrators /T
    DEL /F /Q %ProgramData%\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_*

    And in the same gpo used the file copy option to copy the background image to : C:\Windows\Web\Screen\img100.jpg

    and set that one as an static background image..

    Thursday, April 13, 2017 8:36 AM
  • For anyone from MS having trouble reproducing this issue, here are our steps to reproduce it:

    1. Bare metal install of 15063 Enterprise (from latest ISO), to clean hard disk.
    2. Take defaults during oobe (region, keyboard, both United Kingdom in our case)
    3. Domain join rather than microsoft account. Create a local user.
    4. Once at the desktop, run settings and tell it to check for updates.
    5. The cumulative update will need a restart. Do so and log back in. (Currently this takes me to 15063.138)
    6. Take a screenshot and save it somewhere as a jpg e.g. c:\temp\test.jpg. Or, copy one in from elsewhere.
    7. Run gpedit.msc
    8. Under Computer Configuration, Administrative Templates, Control Panel, Personalization, Enable "Force a specific default lock screen and logon image" and set it to c:\temp\test.jpg or whatever path/filename you used (but it should be local).
    9. Under Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options, set "Interactive logon: Don't display last signed-in" to enabled.
    10. Restart.

    Expected result:

    • test.jpg should be shown as the logon image. (This is the only bit we happen to care about.)
    • test.jpg should be shown when the user locks the device.

    Actual result:

    • Microsoft default (the cave image) is shown instead (on both the logon and user's lock screens)

    However, the panel in settings does show test.jpg as if the user had chosen it. The "Some settings are hidden or managed by your organisation" text is also visible. We haven't set the policy to prevent the user from changing their lock screen from the default, so nothing is actually greyed out.

    (Setting that policy as well has no effect on getting the image to show, although it does grey things out in Settings.)

    The above sequence reproduces the problem consistently here, and did so on earlier updates (15063.13)

    Things are clearly complicated though. The "don't display last signed-in" policy is relevant, in that if I don't enable that as well, I get much more variable results - it sometimes works, sometimes not. But, having followed the above sequence, setting that policy back to disabled doesn't help, even if you clear out the cache in the lockscreen_p folders under programdata. So it matters how you get to a particular configuration as well as what that configuration actually is.

    Thursday, April 13, 2017 10:05 AM
  • +1 Here as well.

    I'll continue testing but can't roll this out until this is fixed.

    Thursday, April 13, 2017 5:08 PM
  • +1 here too.

    I've upgraded a couple of machines and had to roll back.  Win 10 Education 1703.

    James Cracknell IT Dept Archbishop Sancroft High School, Norfolk

    Thursday, April 13, 2017 7:52 PM
  • Same issue here, upgraded from 1607 enterprise to 1703. Lock screen picture reverted back to the cave.

    Has anyone tried updating ADMX files?

    https://www.microsoft.com/en-us/download/details.aspx?id=55080




    • Edited by net_tech Tuesday, April 18, 2017 3:20 PM
    Monday, April 17, 2017 12:15 AM
  • Updated the ADMX files before installing the update, and have the same issue.
    Monday, April 17, 2017 12:46 PM
  • It's now controlled with a LockScreenImageUrl  in Personalization CSP

    https://www.petervanderwoude.nl/post/easily-configure-desktop-and-lock-screen-image-via-windows-10-mdm/

    https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/personalization-csp?f=255&MSPPError=-2147217396

    https://technet.microsoft.com/en-us/itpro/windows/configure/windows-spotlight



    • Edited by net_tech Monday, April 17, 2017 4:32 PM
    Monday, April 17, 2017 4:21 PM
  • It's now controlled with a LockScreenImageUrl  in Personalization CSP

    https://www.petervanderwoude.nl/post/easily-configure-desktop-and-lock-screen-image-via-windows-10-mdm/

    https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/personalization-csp?f=255&MSPPError=-2147217396

    https://technet.microsoft.com/en-us/itpro/windows/configure/windows-spotlight



    Not really sure about what i need to accomplish this. We use a sccm-server w/o intune and my clients dont get the setting when configuring the LockScreenImageUrl, either through sccm or registry key. Is intune really necessary? 
    Tuesday, April 18, 2017 6:50 AM
  • WTF Microsoft?

    https://technet.microsoft.com/en-us/itpro/windows/configure/windows-spotlight

    Warning

    In Windows 10, version 1607, the Force a specific default lock screen image policy setting will prevent users from changing the lock screen image. This behavior will be corrected in a future release.

    Force = Prevent (where is the problem?)

    Tuesday, April 18, 2017 8:10 AM
  • It's now controlled with a LockScreenImageUrl  in Personalization CSP

    Have you tried this and found that it works? Or been advised by Microsoft to use this instead of the other mechanisms?

    The GPO still exists in the latest ADMX files, and the corresponding setting exists in local policy. The Personalization CSP has been added, but there's no indication that it supersedes the other mechanisms.

    Also, the Personalization CSP documentation doesn't mention whether you can use that to change the logon lock screen, as opposed to the lock screen used after a user has logged on. The logon lock screen is the bit we're interested in, and changing the default for all users is a side effect we'd avoid if we could.

    Tuesday, April 18, 2017 8:31 AM
  • Force = Prevent (where is the problem?)

    "Force a specific default lock screen and logon image"

    Force implies prevent, yes. But setting a default implies the user then has the option of changing it.

    At some point they introduced the "Prevent changing lock screen and logon image" setting alongside the above, meaning that you can now set a default and separately decide whether the user is allowed to deviate from it.

    Or you could if the settings worked properly.

    Tuesday, April 18, 2017 8:34 AM
  • In my opinion, with 1703 You can also use an MDM. It does not mean, I hope, from today it is possible to use only one MDM.

    We hope this problem is solved quickly because it has a big impact for all companies that have a corporate identity.

    N.

    Tuesday, April 18, 2017 8:57 AM
  • Hi

    Has anyone actually got a fix for this for machines that are already deployed.


    James Cracknell IT Dept Archbishop Sancroft High School, Norfolk

    Tuesday, April 18, 2017 9:42 AM
  • "Personalization CSP is supported in Windows 10 Enterprise and Education SKUs."

    Here we go again. Pro users getting screwed over.

    Tuesday, April 18, 2017 12:21 PM
  • "Personalization CSP is supported in Windows 10 Enterprise and Education SKUs."

    Here we go again. Pro users getting screwed over.

    Pro SKU is not designed for companies, its designed for "Professional" home users.
    • Edited by ulflundh Tuesday, April 18, 2017 12:27 PM
    Tuesday, April 18, 2017 12:26 PM
  • The ability has been there since Windows 7. Ever since 10 1607, MS has been stripping features. Designed for companies or not, it's lame.
    Tuesday, April 18, 2017 12:49 PM
  • Pro SKU is not designed for companies, its designed for "Professional" home users.

    Not exactly. It's designed for small businesses:

    https://blogs.windows.com/windowsexperience/2015/05/13/introducing-windows-10-editions/

    "Windows 10 Pro ... has many extra features to meet the diverse needs of small businesses."

    Although, I agree, MS do seem to be increasingly treating it as a more expensive version of Home.

    Tuesday, April 18, 2017 12:55 PM
  • We used Windows Configuration Designer from 1703 ADK to build a Win 10 package that was changing the lock screen via LockScreenImageUrl.

    After the package was ran, we confirmed the registry changes, however the lock screen remained unchanged.

    Another dead end.


    https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit

    Tuesday, April 18, 2017 3:16 PM
  • This would be funny if not so completely frustrating.. has anyone heard from microsoft on this issue?

    Tuesday, April 18, 2017 10:45 PM
  • We have found the same issue as well when upgrading from 1607 to 1703 the GPO is set but the lockscreen will not set.

    We are about to start a rollout of 1607 but as mentioned in this thread Windows 10 is such a headache compared to Windows 7.

    I Will open a premier case for this one.


    • Edited by PeterAUS Wednesday, April 19, 2017 8:52 AM
    Wednesday, April 19, 2017 8:51 AM
  • Encountered this today, definitely appears to be a bug.  Bare metal OSD TS via SCCM with 1703 and lock screen (via GPO) is broken. Same TS used with 1607 everything works as expected.  ADMXs are updated etc.

    Looks like that "display last logged on setting" or maybe another of the logon GPO settings could be a factor, as when setting the lock screen reg key directly & blocking GPO inheritance it appears to work.


    Wednesday, April 19, 2017 9:44 AM
  • It's now controlled with a LockScreenImageUrl  in Personalization CSP

    https://www.petervanderwoude.nl/post/easily-configure-desktop-and-lock-screen-image-via-windows-10-mdm/

    https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/personalization-csp?f=255&MSPPError=-2147217396

    https://technet.microsoft.com/en-us/itpro/windows/configure/windows-spotlight



    I am having the same issue with this policy not working.  I made my own Windows 10 Enterprise 1703 ISO from the ESD file that my SCCM downloaded that I am using for testing.  I will wait for the official ISO to be published to my volume license portal before I make my new base image but for testing I will use this.  I also updated the ADMX policies on my domain controller obviously.

    Long story short I do not know what this Windows 10 MDM thing is and do not know if I even have it anywhere to use.  I also rather not use this since we are a large domain network and Group Policy is still needed and used. 

    Wednesday, April 19, 2017 1:30 PM
  • Turn off Prevent Changing lock screen and logon image in the gpo and it works
    Thursday, April 20, 2017 12:27 PM
  • Turn off Prevent Changing lock screen and logon image in the gpo and it works

    Not here it doesn't. We've never turned that on other than to see if it fixes it.

    Further up in this thread I posted detailed steps to reproduce the problem from a bare metal vanilla install, and the problem is reproducible without configuring that GPO.

    No response from MS on this thread in quite a while - anyone had any success with raising a call directly?

    Thursday, April 20, 2017 12:37 PM
  • i forgot to mention i cleared out the c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\ folder and created a jpg lockscreen.jpg with our background in the GPO.

    Thursday, April 20, 2017 1:32 PM
  • i forgot to mention i cleared out the c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\ folder and created a jpg lockscreen.jpg with our background in the GPO.

    Sooo you are overwriting the cached lockscreen with an image of your own. Which means the GPO is still doing nothing. This doesn't help any of us in any way, you won't be able to change it in future with the GPO even doing that.
    Friday, April 21, 2017 12:28 AM
  • Tried this https://abcdeployment.wordpress.com/2017/04/20/how-to-set-custom-backgrounds-for-desktop-and-lockscreen-in-windows-10-creators-update-v1703-with-powershell/

    but all that does is set the registry key which, for me, still does nothing.

    Friday, April 21, 2017 5:02 AM
  • Seems like someone else mentioned waiting on the VL ISO to be released. I am doing the same but have no confidence it will be any different. We have a premier case open with MS. If anything comes out of it, I will post the results here for others.

    I find it baffling how this stuff makes it through QA. Seems like every release of Windows and Deployment tools in the last two years has changed or broken proven methods of simple administrative tasks. It's enough administrative effort to deal with new features, but having to go back an re-work things that have worked for years is extremely frustrating.

    Friday, April 21, 2017 11:02 AM
  • We tried using Windows insider preview and theres no change in build 16176. Same issue. 
    Friday, April 21, 2017 11:13 AM
  • Seems like someone else mentioned waiting on the VL ISO to be released.

    I was planning on raising a call about this then, as I wasn't sure of the status of doing so based on what is technically an insider preview ISO. I certainly don't expect it to be fixed in the VL ISO.

    Meanwhile, a post from Rick Li in this thread:

    https://social.technet.microsoft.com/Forums/en-US/ebe54cb8-c404-4bd3-a787-b3b0452959cf/some-initial-1703-update-issuesobservations?forum=win10itprosetup

    describes this problem as a 'known issue'.

    Friday, April 21, 2017 11:36 AM
  • I've come across 2 issues here. One is if you have Prevent enabled when you try to make changes to Force. You will see the desired lock screen image appear in Settings but it will not work. You have to set Prevent to Disabled/Not enabled, setup Force the way you want it, push that out and then turn Prevent back on. This is the workaround, the GP is being fixed so you will not have to do this in the future.  We're checking on another issue with "Show lock screen background pictures.." being enabled that causes similar behavior.

    ~Kim

    Friday, April 21, 2017 12:19 PM
  • It's is good to know it's being looked at, but I think it's a bit more complicated than that.

    Further up in this thread I posted steps to reproduce the problem from a bare metal install that did not involve the "Prevent" policy at all, but did involve the setting to not display the last signed-in username. That also seems involved in the problem, and your workaround does not address that (although the equivalent of not setting that policy until the lock screen is working might apply).

    (Also, something of an aside as it isn't my thread, but in our environment we not only display a custom logon screen, we also update it regularly. Our student machines include today's room booking information on the pre-login screen, so the image is updated daily. Picking up changes to the image is as important to us as picking up the image in the first place.)

    Friday, April 21, 2017 1:24 PM
  • It's is good to know it's being looked at, but I think it's a bit more complicated than that.

    Further up in this thread I posted steps to reproduce the problem from a bare metal install that did not involve the "Prevent" policy at all, but did involve the setting to not display the last signed-in username. That also seems involved in the problem, and your workaround does not address that (although the equivalent of not setting that policy until the lock screen is working might apply).

    (Also, something of an aside as it isn't my thread, but in our environment we not only display a custom logon screen, we also update it regularly. Our student machines include today's room booking information on the pre-login screen, so the image is updated daily. Picking up changes to the image is as important to us as picking up the image in the first place.)

    Same here, we need to update the lockscreen at least once a month. More regular on our pilote-group. This needs to be fixed. 
    Friday, April 21, 2017 1:43 PM
  • I would suggest looking at the new feature added in the Enterprise and Education SKU's of Windows 10 version 1703 called Personalization CSP:
    https://msdn.microsoft.com/en-us/windows/hardware/commercialize/customize/mdm/personalization-csp

    A nice explanation and script to configure this via PowerShell is available at:
    https://abcdeployment.wordpress.com/2017/04/20/how-to-set-custom-backgrounds-for-desktop-and-lockscreen-in-windows-10-creators-update-v1703-with-powershell/

    Saturday, April 22, 2017 12:20 PM
  • I would suggest looking at the new feature added in the Enterprise and Education SKU's of Windows 10 version 1703 called Personalization CSP:
    https://msdn.microsoft.com/en-us/windows/hardware/commercialize/customize/mdm/personalization-csp

    A nice explanation and script to configure this via PowerShell is available at:
    https://abcdeployment.wordpress.com/2017/04/20/how-to-set-custom-backgrounds-for-desktop-and-lockscreen-in-windows-10-creators-update-v1703-with-powershell/

    1. This does not work, as already stated above.

    2. The main issue has already been confirmed as a known issue thats beeing worked on. 

    Saturday, April 22, 2017 8:24 PM
  • I've come across 2 issues here. One is if you have Prevent enabled when you try to make changes to Force. You will see the desired lock screen image appear in Settings but it will not work. You have to set Prevent to Disabled/Not enabled, setup Force the way you want it, push that out and then turn Prevent back on. This is the workaround, the GP is being fixed so you will not have to do this in the future.  We're checking on another issue with "Show lock screen background pictures.." being enabled that causes similar behavior.

    ~Kim

    I just tried setting "Prevent changing lock screen and logon image" GPO to disabled, but my freshly built 1703 computers still just get the default cave image. Doesn't appear like this workaround does anything. 

    Sunday, April 23, 2017 3:46 AM
  • WTF Microsoft?

    https://technet.microsoft.com/en-us/itpro/windows/configure/windows-spotlight

    Warning

    In Windows 10, version 1607, the Force a specific default lock screen image policy setting will prevent users from changing the lock screen image. This behavior will be corrected in a future release.

    Force = Prevent (where is the problem?)

    What do you not understand?

    In Windows 8.1, Windows 10 1507, and Windows 10 1511, the Force a specific default lock screen image Group Policy correctly set the default -- just like its name implies -- lock screen image for users.  It did not prevent users from choosing their own lock screen.

    If you want to prevent users from changing their lock screen from the default, there is a separate Group Policy to fulfill that need.  Use it if you want it.

    In 1607, there was a bug introduced wherein the Force a specific default lock screen image Group Policy incorrectly prevented users from choosing their own lock screen.  This was incorrect behavior.

    So, I have no idea where your "WTF Microsoft" comment came from.

    Sunday, April 23, 2017 6:59 PM
  • UNC paths work it seems. HTTP/HTTPS paths do not.
    Monday, April 24, 2017 2:54 PM
  • Microsoft today launched a cumulative update which brings us up to build 15063.250 from 15063.138.

    Among the changes i read 

    • Addressed issue that prevents the lock screen from being disabled using Group Policy on Professional SKUs.

    Anyone tried this CU yet?

    kb4016240;

    https://support.microsoft.com/en-us/help/4016240/windows-10-update-kb4016240

    update: did nothing for me (Windows 10 Enterprise x64 en-us )

    • Edited by ulflundh Wednesday, April 26, 2017 11:47 AM
    Tuesday, April 25, 2017 6:23 PM
  • I tested this on Windows 10 Enterprise 1703 Build 15063.250 and this update has NOT solved this issue.
    Tuesday, April 25, 2017 8:47 PM
  • I tested this on Windows 10 Enterprise 1703 Build 15063.250 and this update has NOT solved this issue.
    GRRR...  Is there no such thing as quality control anymore? 
    Wednesday, April 26, 2017 12:43 AM
  • I tested this on Windows 10 x64 Education v1703 and still the issue persists.
    Wednesday, April 26, 2017 1:40 PM
  • Hi All

    Discovered that if you turn the below option off and press the windows key + L the correct image displays as specified in the GPO but reverts to a solid colour when pressing CTRL+ALT+DEL to Sign back in.... turn it back on and the cave image appears.... on both Lock and Sign in Screen Build 15063.250

    So it would seem the issue actually lies with the sign in screen but I cannot see anywhere in the GPO to separate out these two images as the GPO refers to both Lock and Sign In Screens together.



    • Edited by rebell_dtu Wednesday, April 26, 2017 1:59 PM
    Wednesday, April 26, 2017 1:47 PM
  • Hi All,

    we have had the same issues with the lock screen for some time, 1511 didn't work, 1607 did then didn't and then 1703 clean install/upgrade and didn't - all settings provided by group policy and it seems there are still issues. (latest CU, admx, etc)

    However after looking as this thread it seems there is a work around and so far seems to be working fine for us, so I thought i'd share the info.

    Check this folder "C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\" (it might end with P as some mention) and have a look at what's inside. This is owned by system, but using psexec and running a command prompt as system account enabled me to test this locally.

    I found 2 files "LockScreen___[dimension]_notdimmed.jpg", so I replaced these with my custom background - success - we have our custom lock screen.

    So then I updated our GPO object under Computer, Preferences, Windows Settings, Files. I created two entries to replace the files found with our custom background image. gpupdate and lock screen is as required, rebooted, powered off, tested - success.

    This seems to be working for us, and when/if they fix it we can just disable/remove the entries

    Hope this help you all


    Brayshaw Systems Engineer

    • Proposed as answer by iriecolorado Wednesday, April 26, 2017 9:06 PM
    • Unproposed as answer by iriecolorado Wednesday, April 26, 2017 9:06 PM
    Wednesday, April 26, 2017 3:05 PM
  • Something I noticed about this issue, it seems to entirely depend on the screen resolution.

    Out of every 1920x1080 desktop I have imaged with 1703, none have had our organization's lock screen.

    Same goes for 800x600 and 1024x768. None have worked.

    However, every 1366x768 and 1650x1050 device - both laptops and desktops - have worked perfectly. I have imaged the same device several times and it gets the lock screen via GPO instantly without fault.

    Anyone else able to reproduce with different resolutions?


    • Edited by Chaori_ Thursday, April 27, 2017 8:07 AM
    Thursday, April 27, 2017 7:35 AM
  • I was able to reproduce the problem with 1920x1080 and 1280x1024 - different res, different aspect ratio. I've not tried on other resolutions, but depending on what other policies are set it can be intermittent.
    Thursday, April 27, 2017 8:30 AM
  • It does not work with any resolution (i'm on hyper-v virtual machine)
    Thursday, April 27, 2017 8:33 AM
  • It does not work with any resolution (i'm on hyper-v virtual machine)

    I haven't been able to get any resolution working on a VM, but am able to get it working on actual machines.

    Beats me then.

    Thursday, April 27, 2017 8:48 AM
  • Something I noticed about this issue, it seems to entirely depend on the screen resolution.

    Out of every 1920x1080 desktop I have imaged with 1703, none have had our organization's lock screen.

    Same goes for 800x600 and 1024x768. None have worked.

    However, every 1366x768 and 1650x1050 device - both laptops and desktops - have worked perfectly. I have imaged the same device several times and it gets the lock screen via GPO instantly without fault.

    Anyone else able to reproduce with different resolutions?


    We are using 1920x1080 on all our lockscreens. Resizing them to 1366x768 or 1650x1050 did not work for us unfortunately. Build 15063.250 on a Surface Pro 3
    • Edited by ulflundh Thursday, April 27, 2017 8:59 AM
    Thursday, April 27, 2017 8:58 AM
  • Changing resolutions didn't have any effect on machines that were already not working.

    Imaging a device that was already using 1366x768 or 1650x1050 seems to work every time (for me).

    Thursday, April 27, 2017 9:19 AM
  • I can confirm that switching this setting of works. But turning it back on the default lock screen image appears again.
    Thursday, April 27, 2017 9:44 AM
  • rem ------ loosen permissions on a single folder in the path where the cached images are kept takeown /F C:\ProgramData\Microsoft\Windows\SystemData icacls C:\ProgramData\Microsoft\Windows\SystemData /grant:r %UserName%:F icacls C:\ProgramData\Microsoft\Windows\SystemData /grant:r Administrators:F icacls C:\ProgramData\Microsoft\Windows\SystemData /setowner Administrators rem ------ loosen permissions on the sub-folders where the cached images are kept 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 %UserName%:(OI)(CI)F 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

    del /Q C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen*

    Deployed this at 1703 systems via SCCM.  After reboot this resolved the issue for me.  How this bug made it past testing is mind-boggling and frankly, very sad.  MS, get off your butts and address this problem.
    • Edited by iriecolorado Thursday, April 27, 2017 3:04 PM error
    • Proposed as answer by Brent_AS Thursday, April 27, 2017 6:13 PM
    Thursday, April 27, 2017 3:01 PM
  • Thanks, will test this with SCCM myself later...

    If it works then I'm thinking it may be worth re-applying on each reboot in case any future patches reset the permissions.


    Regards Craig Wilson

    Thursday, April 27, 2017 5:16 PM
  • I attempted to use your script and was able to delete the cached images. However, upon reboot the recreated cached images in the LockScreen_P folder were still the cave image.

    Thanks for the suggestion though.

    Thursday, April 27, 2017 8:42 PM
  • I attempted to use your script and was able to delete the cached images. However, upon reboot the recreated cached images in the LockScreen_P folder were still the cave image.

    Thanks for the suggestion though.

    Our workaround is not only clear out the Lockscreen_P folder, but also copy our desired image into it as Lockscreen.jpg. We do this with a scheduled task running as system as that way the rights don't need to be reset. Anything that updates the lockscreen image can then trigger this task to ensure the lockscreen cache gets updated.

    This is obviously not a great workaround, as there is no understanding why this is needed, or why it's LockScreen_P (which it always is for us) rather than LockScreen_Z (as others have reported) or any other folder. Any update might change the undocumented behaviour that we're relying on - it needs a proper fix.

    Friday, April 28, 2017 9:01 AM
  • here is a question for everyone. how are you getting your Enterprise systems to 1703 if the official release of 1703 for Volume License customers is May 1st?

    https://blogs.technet.microsoft.com/windowsitpro/2017/04/05/whats-new-for-it-pros-in-the-windows-10-creators-update/

    are you changing the key to pro,  applying the update and then switching back to ent?


    • Edited by net_tech Friday, April 28, 2017 8:10 PM
    Friday, April 28, 2017 8:09 PM
  • here is a question for everyone. how are you getting your Enterprise systems to 1703 if the official release of 1703 for Volume License customers is May 1st?

    1703 Enterprise ISO has been up on MSDN for like 3 weeks.


    • Edited by Chaori_ Saturday, April 29, 2017 12:57 AM
    Saturday, April 29, 2017 12:57 AM
  • What we had managed to do to work around this issue was apply the GPO to prevent our users from changing their Lock screens and prevent the slideshow feature to keep it from cycling then we scripting on login to take owner ship of C:\Windows\Web\Screen\img100.jpg (The Default Cave image) and then replace it with our Brand image this works across Enterprise and Professional from our testing and it works very well. If we every need to change the image we change the image in the sysvol folder of our domain and it will update when the PC Restarts
    Saturday, April 29, 2017 11:32 PM
  • Glad to see this is still an issue for everyone else!

    Thanks for the clever work around Zachery, I will test this asap as this seems like minimal effort to get our branding working again whilst MS figure out a fix.

    Monday, May 01, 2017 8:24 AM
  • Still nothing huh?  I like Zachery's work around and may try that route if I get desperate.  I would like to have a working and patched image by late June at the latest so I can image all my computer labs and student issued windows devices with version 1703 before school starts in August so I have some time.   I just can't get over how Microsoft doesn't seem to acknowledge this at all or care
    Tuesday, May 02, 2017 12:23 AM
  • It is available as a deployable upgrade in SCCM.
    Tuesday, May 02, 2017 2:37 PM
  • 1703 upgrade is available in SCCM / WSUS as long as you have upgrades enabled. Build a Win10 servicing plan and it will upgrade. Unfortunately upgrade still brings back all of the un-provisioned apps and breaks the lock screen wallpaper.

    Fresh build and capture using 1703 ISO from VLSC has brocken lock screen wallpaper and necessitated changes to answer file to prevent update dialog - I think.

    Tuesday, May 02, 2017 3:34 PM
  • +1

    I am experiencing the same issue and sincerely hope that Microsoft solves this as soon as possible.

    Wednesday, May 03, 2017 12:42 PM
  • Happening here and we're using the VL ISO.
    Thursday, May 04, 2017 7:04 AM
  • Same Problem on all our Testmachines. Currently about 10.
    Thursday, May 04, 2017 8:08 AM
  • Windows 1703 (Build 15063.0) Update from 1603 - Same problem here.
    Thursday, May 04, 2017 12:26 PM
  • Based on Zachery's idea of replacing img100.jpg, here's my workaround.

    I have an AutoIt compiled exe "DeleteCachedWallpaper.exe" to delete cached lock screen images, code:

    #NoTrayIcon
    #RequireAdmin
    #include <File.au3>
    
    ; Removed cached lockscreen images from ProgramData\Microsoft\Windows\SystemData\*\ReadOnly\LockScreen_*
    
    $sRootDir = EnvGet("systemdrive") & "\ProgramData\Microsoft\Windows\SystemData\"
    ;MsgBox (0,"",$sRootDir)
    
    $_dir1 = _FileListToArray($sRootDir, "*", 2)
    If IsArray($_dir1) Then
      For $n = 1 To $_dir1[0]
       $sSubDir = $sRootDir & $_dir1[$n] & "\ReadOnly\"
       ;MsgBox (0,"","Found " & $sSubDir)
       If FileExists($sSubDir) Then
    	   ;MsgBox (0,"","Searching " & $sSubDir)
    	   ; Loop through each SID folder and get sub folders
    		$_dir2 = _FileListToArray($sSubDir, "LockScreen_*", 2)
    		If IsArray($_dir2) Then
    		  For $i = 1 To $_dir2[0]
    		   ;$sPath = @TempDir & "" & $_dir2[$i]
    		   $sPath = $sSubDir & $_dir2[$i]
    		   ;MsgBox (0,"","Found " & $sPath)
    		   If FileExists($sPath) Then
    				;MsgBox (0,"","Removing " & $sPath)
    				DirRemove($sPath, 1)
    		   EndIf
    		  Next
    	   EndIf
       EndIf
      Next
    EndIf

    so using this I can run the following:

    psexec /s /i /d cmd.exe
    
    takeown /F C:\Windows\Web\Screen\img100.jpg
    icacls C:\Windows\Web\Screen\img100.jpg /grant:r %UserName%:F
    icacls C:\Windows\Web\Screen\img100.jpg /grant:r Administrators:F
    icacls C:\Windows\Web\Screen\img100.jpg /setowner Administrators
    
    copy CustomLockScreen.jpg C:\Windows\Web\Screen\img100.jpg /y
    
    DeleteCachedWallpaper.exe

    Or if you're not worried about deleting ALL cached lockscreens, you can just delete the jpgs from: C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\

    So when it re-caches, it caches the copy of CustomLockScreen.jpg

    That said, we'll probably not going to be rolling out 1703 for a while as we've been testing with 1607 and happy with our build for that.



    • Edited by Alex Beech Thursday, May 04, 2017 8:31 PM
    Thursday, May 04, 2017 2:47 PM
  • Going off of what Alex Beech mentioned above, i decided to follow a similar procedure just without any third-party tools (AutoIt).


    I utilized the File System Security Options (Computer Configuration>Policies>Windows Settings>Security Settings>File System) to grant the permissions to the C:\Windows\Web\Screen\img100.jpg file as well as the C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P folder. Permissions are as follows...

    • Administrators- Full
    • System- Full
    • Users- Read

    These are the default permissions that get assigned via the File system Policy and they are exactly what is needed.

    Then i used GP Prefs to copy our custom lockscreen to replace the C:\Windows\Web\Screen\img100.jpg file.


    The last step was to use GP Prefs to delete the C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P folder.

    The main issue with this workaround is, that you are constantly deleting and re-caching the lock-screen after each GP update and subsequent lock of the device, but hopefully Microsoft has a real fix soon.

    Also keep in mind that the lock-screen may not apply after the first GP update (if you have all these steps in 1 GPO like i do), but it will for each consecutive update. This is due to the fact that the file permissions get applied After the policy tries to copy the file, and therefore the file copy fails that time. Each time thereafter, the permissions will be correct and the lock-screen updates successfully.

    If this is an issue for your needs you can always correct this by creating 2 GPOs and setting the 'Permission GPO' to have a higher Precedence than the 'File Copy GPO'.

    I have successfully tested this on 4000 plus machines including VMs with 100% success.


    • Edited by Cmarko-89 Thursday, May 04, 2017 10:11 PM
    Thursday, May 04, 2017 10:10 PM
  • Also keep in mind that the lock-screen may not apply after the first GP update (if you have all these steps in 1 GPO like i do), but it will for each consecutive update. This is due to the fact that the file permissions get applied After the policy tries to copy the file, and therefore the file copy fails that time. Each time thereafter, the permissions will be correct and the lock-screen updates successfully.

    If this is an issue for your needs you can always correct this by creating 2 GPOs and setting the 'Permission GPO' to have a higher Precedence than the 'File Copy GPO'.


    Precedence aka Link Order, doesn't control the order in which CSE's are processed, so, I doubt your latter suggestion would really work.
    Have you actually tested that approach?

    You could always hack the registry to change the order which the CSE's process (but that's not a fantastic idea either...)


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thursday, May 04, 2017 11:10 PM
  • Going off of what Alex Beech mentioned above, i decided to follow a similar procedure just without any third-party tools (AutoIt).


    I utilized the File System Security Options (Computer Configuration>Policies>Windows Settings>Security Settings>File System) to grant the permissions to the C:\Windows\Web\Screen\img100.jpg file as well as the C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P folder. Permissions are as follows...

    • Administrators- Full
    • System- Full
    • Users- Read

    These are the default permissions that get assigned via the File system Policy and they are exactly what is needed.

    Then i used GP Prefs to copy our custom lockscreen to replace the C:\Windows\Web\Screen\img100.jpg file.


    The last step was to use GP Prefs to delete the C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P folder.

    The main issue with this workaround is, that you are constantly deleting and re-caching the lock-screen after each GP update and subsequent lock of the device, but hopefully Microsoft has a real fix soon.

    Also keep in mind that the lock-screen may not apply after the first GP update (if you have all these steps in 1 GPO like i do), but it will for each consecutive update. This is due to the fact that the file permissions get applied After the policy tries to copy the file, and therefore the file copy fails that time. Each time thereafter, the permissions will be correct and the lock-screen updates successfully.

    If this is an issue for your needs you can always correct this by creating 2 GPOs and setting the 'Permission GPO' to have a higher Precedence than the 'File Copy GPO'.

    I have successfully tested this on 4000 plus machines including VMs with 100% success.


    I can confirm this as the first workaround that works for us. Its still a workaround and as such will not be used in production here. Thanks for sharing and lets hope Microsoft gets a fix out soon.
    Friday, May 05, 2017 5:38 AM
  • Tested this workaround on Win 10 1703 EDU and it worked without any issue.  Thanks Cmarko-89!!!!

    • Edited by ITShawn Friday, May 05, 2017 11:59 PM added name
    Friday, May 05, 2017 11:59 PM
  • This is still broken.

    What's the progress on this being fixed?

    Monday, May 08, 2017 2:48 AM
  • From the TechNet article I'm not sure that Microsoft see this as something that is broken and needs fixing.

    Has anyone raised a support call with Microsoft and got confirmation that this is a bug or a "feature"?


    James Saunders

    Monday, May 08, 2017 9:12 AM
  • Personally I wrote in feedback hubs as insiders.

    N.

    Monday, May 08, 2017 12:00 PM
  • Also keep in mind that the lock-screen may not apply after the first GP update (if you have all these steps in 1 GPO like i do), but it will for each consecutive update. This is due to the fact that the file permissions get applied After the policy tries to copy the file, and therefore the file copy fails that time. Each time thereafter, the permissions will be correct and the lock-screen updates successfully.

    If this is an issue for your needs you can always correct this by creating 2 GPOs and setting the 'Permission GPO' to have a higher Precedence than the 'File Copy GPO'.


    Precedence aka Link Order, doesn't control the order in which CSE's are processed, so, I doubt your latter suggestion would really work.
    Have you actually tested that approach?

    You could always hack the registry to change the order which the CSE's process (but that's not a fantastic idea either...)


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    While you are correct about CSE processing, that will only prove to be an issue if all the settings are applied via one single GPO (like the one in my example). If the are split into multiple GPOs and linked in the correct order, Group policy will follow that order during processing.

    See the section directly below 'Figure 2' in the technet article below for a clearer picture.



    https://technet.microsoft.com/en-us/library/hh147307%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396



    While i have not tested it with this Group policy specifically, i do use the precedence method with several other policies within my organization.
    Monday, May 08, 2017 1:49 PM
  • Have the same problem.

    Sad that these things doesn't work just out of the box.

    Tuesday, May 09, 2017 5:15 AM
  • Received a reply from Premier Support today that acknowledged the problem and MS is working on a fix in an upcoming update. It's pretty vague and not useful but at least it's an acknowledgement. Quoting the response:

    I am sorry for the delay.

    I was collaborating with my Sr Engineer to get back to you with a more definitive answer to your support ticket.

    I understand that, there has been some issues with windows 10 setting custom lock screen image background. MS is working on this issue to get it fix in future updates of windows 10.

     

    I do know there is a workaround to this issue via a third-party tool or by tweaking the registry settings but unfortunately Microsoft do not in any way recommend this process to its customers.

     

    There is an internal thread currently going on with finding means of fixing this issue.

    Tuesday, May 09, 2017 5:37 PM
  • I'm having this problem as well.  We would like to prepare an SCCM task sequence to offer updates to users who want to pilot 1703, but I would like to see these types of obvious problems resolved before offering it.  I don't know that I would implement workarounds that change folder permissions to the SystemData folder as that seems to have the potential to cause problems down the road.  Hopefully we'll have a fix from MS soon. 
    Tuesday, May 09, 2017 5:38 PM
  • Todays Cumulative update , which brings us to 15063.296 doesnt seem to adress this issue :/ ;

    This security update includes quality improvements. No new operating system features are being introduced in this update. Key changes include:

    • Addressed issue with Surface Hub devices waking from sleep approximately every four minutes after the first two hours. 
    • Addressed issue where autochk.exe can randomly skip drive checks and not fix corruptions, which may lead to data loss. 
    • Addressed an issue where Microsoft Edge users in networking environments that do not fully support the TCP Fast Open standard may have problems connecting to some websites. Users can re-enable TCP Fast Open in about:flags.  
    • Addressed issues with Arc Touch mouse Bluetooth connectivity.
    • Security updates to Microsoft Edge, Internet Explorer, Microsoft Graphics Component, Windows SMB Server, Windows COM, Microsoft Scripting Engine, Windows kernel, Windows Server, and the .NET Framework.

    https://support.microsoft.com/en-us/help/4016871/windows-10-update-kb4016871


    • Edited by ulflundh Tuesday, May 09, 2017 6:59 PM
    Tuesday, May 09, 2017 6:59 PM
  • https://blogs.technet.microsoft.com/kimberj/2017/05/05/known-lock-screen-issues-with-creators-update-1703/

    Seems to be fixed in the Beta Builds so that we can expect a solution in the next cumulative update


    Thursday, May 11, 2017 7:18 AM
  • https://blogs.technet.microsoft.com/kimberj/2017/05/05/known-lock-screen-issues-with-creators-update-1703/

    Seems to be fixed in the Beta Builds so that we can expect a solution in the next cumulative update



    This blogpost isn't right either. It's not working even if forced or the only GPO. Nor does not setting or disabling the force lock screen. Build 1703 is simply broken. I've not yet seen a patch.

    Nick "The Naked MVP" Whittome

    Thursday, May 11, 2017 9:04 AM
  • I like that Cmarko-89. Clever use of GPOs.

    Alex

    Thursday, May 11, 2017 7:37 PM
  • Chalk me up as another one who's having this issue. 1607 machines picked up our Windows 8 GPO with its lockscreen and accent colour settings. 1703 ignores all GPO settings completely.

    I really don't want to mess around with the default wallpapers as that disturbs Windows' file system integrity checks. I'm also not a fan of copying files from a network share into the C:\Windows\Web folder as that could potentially be used to undermine App Whitelisting.

    I guess I'll just have to wait for a fix.



    Friday, May 12, 2017 12:26 AM
  • Same here, in the personalise screen we can see the actual lockscreen image that's being set but the lockscreen its self doesn't change. I would rather than tweak permissions in our estate and would rather than be copying files, thsi was always something we embedded in our builds using local policy, very disappointed this will stop us moving towards 1703 CB and we will have to wait until it is CBB/
    Monday, May 15, 2017 1:57 PM
  • Hmmm, something strange has happened.

    I left a virtual PC imaging last night before I went home and came in this morning to find it sitting at the logon screen with our corporate logon wallpaper which is set via the GPO...

    So I wondered if perhaps I'd selected the wrong task sequence and put 1607 on by mistake, but no, it turns out I was paying attention...

    So, what has changed?

    Well, not much. I updated our W10 ADMX templates last week and also removed the GPO setting to prevent users from changing the logon wallpaper (after reading advice from a previous message in this thread). Looks like SCCM also installed the 1705 update rollup during the build.

    FYI The JPG is copied to a local folder during OSD by an SCCM package and the GPO references the local path to the JPG.

    This is the only PC this has worked on, all of our other 1703 builds are showing the caveman pic, even the ones which have received the 1705 update rollup.

    Should I build another? I'm almost too scared to see what might happen next time.


    Tuesday, May 16, 2017 8:09 AM
  • Just built a laptop and guess what.

    It worked too.

    What is going on?

    Tuesday, May 16, 2017 9:49 AM
  • I am seeing the same also no changes our end so maybe a windows update?!

    The only thing currently outstanding as an issue is the user account picture is not accepting the company one as before the update.

    GPOs all updated and applied to use the default one but it ignores it.

    Tuesday, May 16, 2017 3:15 PM
  • I've not made any changes and am still seeing the issue

    - Win10 Enterprise 1703
    - WIM file injected with latest updates
    - Deploying via SCCM


    Wednesday, May 17, 2017 1:06 AM
  • This is going to be fixed in a few weeks:

    http://www.urtech.ca/2017/05/solved-windows-10-lock-screen-graphic-gpo-not-working-on-1703/

    I hope this helps.


    Ian Matthews www.urtech.ca www.commodore.ca

    Wednesday, May 17, 2017 4:42 PM
  • This is going to be fixed in a few weeks:

    http://www.urtech.ca/2017/05/solved-windows-10-lock-screen-graphic-gpo-not-working-on-1703/

    I hope this helps.


    Ian Matthews www.urtech.ca www.commodore.ca

    This is great news! Thanks for sharing.
    Wednesday, May 17, 2017 6:35 PM
  • This is going to be fixed in a few weeks:

    http://www.urtech.ca/2017/05/solved-windows-10-lock-screen-graphic-gpo-not-working-on-1703/

    I hope this helps.


    Ian Matthews www.urtech.ca www.commodore.ca


    Well if the patch to fix this comes out on May 23rd I can wait until then.   As long as the fix is released before mid-june I should be in good shape.  I need to prepare a base image so I can re-image my labs and we have 1600 surface devices going out to students that I want to image with version 1703 so they are ready to go.   This should limit the machines that I need update using a servicing plan to mostly office area computers used by secretaries and individuals as the classroom, labs and other general use computers are easily reimaged.
    Wednesday, May 17, 2017 7:12 PM
  • Something I noticed about this issue, it seems to entirely depend on the screen resolution.

    Out of every 1920x1080 desktop I have imaged with 1703, none have had our organization's lock screen.

    Same goes for 800x600 and 1024x768. None have worked.

    However, every 1366x768 and 1650x1050 device - both laptops and desktops - have worked perfectly. I have imaged the same device several times and it gets the lock screen via GPO instantly without fault.

    Anyone else able to reproduce with different resolutions?



    we got the same issue. 1024 x 768 not working all other resolutions works in 1703.
    Friday, May 19, 2017 7:40 AM
  • Yes, we updated ADMX to most current version for 1703 and still no luck.  I can tell MS one thing, our organization won't allow us to use this release globally until this problem is fixed.  They won't allow unbranded systems to be globally deployed.  Simple as that.

    So, while this might seem like a small issue to some - it's a big issue for us.  It's simply unfathomable to me that Microsoft would allow a build to be released with such a fundamental feature broken.

    Unbelievable!

    Saturday, May 20, 2017 2:42 AM
  • Premier support advises that there is an update coming out on 5/23 that should resolved the issue. Take it for what it's worth. I take the wait and see approach but.......
    Saturday, May 20, 2017 2:53 PM
  • Do we have  KB number to look out for?
    Monday, May 22, 2017 2:46 PM
  • Same here!

    Clean install of 1703 education, no custom lockscreen via GPO (even after 'gpupdate /force').

    GPO still works fine with older version (1511, 1607).

    Newest admx-files in use.

    Exact same issue here.  1703 EDU X64.
    Monday, May 22, 2017 7:48 PM
  • Using "Force a specific default lock screen and logon image" group policy in Win10 1703

    If you set this policy in 1703, it will show your forced lock screen wallpaper under settings->lockscreen but then just shows the stock lock screen picture on the actual lock screen.  To make it show your forced lock screen image, you have to disable the "Show lock screen background picture on the sign-in screen".  I'm going to guess that you have the second policy for "prevent lock screen background changes" also set via GP so you won't even see this option if you go into lock screen options.  

    Here's the registry key to change it for all users so that your forced lock screen background will again work right.  I add it using computer-> preferences-> Windows Settings->Registry

    SOFTWARE\Policies\Microsoft\Windows\System 

    DisableLogonBackgroundImage 

    REG_DWORD 

    1


    • Proposed as answer by Mike Plichta Monday, May 22, 2017 11:08 PM
    • Unproposed as answer by Daniel Kingdon Tuesday, May 23, 2017 9:26 PM
    Monday, May 22, 2017 11:08 PM
  • We've tried it with and without that set, and it makes no difference. Way up in the thread I posted steps to reproduce the problem on a vanilla system, and that key wasn't involved there either.

    There's definitely a bug here and the options are to workaround it by updating the cache folder yourself by some mechanism, or wait for the patch and see if that fixes it.

    Tuesday, May 23, 2017 8:34 AM
  • Haven't seen an update in Configuration Manager yesterday (5/23) or today. Any update from your premiere support contact?
    Wednesday, May 24, 2017 4:10 PM
  • I guess there was no update released.   There are two updates in the Update Catalog but I do not think those are what we are looking for.

    the updates are referenced under
    KB4021573
    KB4021572

    They are CAB files and I could not get them to install on a test machine .

    Thursday, May 25, 2017 12:26 AM
  • I guess there was no update released.   There are two updates in the Update Catalog but I do not think those are what we are looking for.

    the updates are referenced under
    KB4021573
    KB4021572

    They are CAB files and I could not get them to install on a test machine .

    I got this one "KB4021572" to install, made no difference...
    Thursday, May 25, 2017 9:02 AM
  • KB4020102 (May 25th CU) is now out for 1703 but the lock screen issue isn't mentioned unless I glazed over it....

    EDIT: Appears to have not made a difference

    • Edited by nbb359 Thursday, May 25, 2017 7:16 PM
    Thursday, May 25, 2017 5:20 PM
  • KB4020102 (May 25th CU) is now out for 1703 but the lock screen issue isn't mentioned unless I glazed over it....

    EDIT: Appears to have not made a difference

    Shame, thanks for reporting. I cannot believe whats keeping them from fixing this ...
    Thursday, May 25, 2017 7:51 PM
  • May 25, 2017—KB4020102 does not mention the issue with lockscreen, but for me it works now after applying the update

    Friday, May 26, 2017 8:22 AM
  • Using MDT, I deployed an image of Windows 1703 15063.332 to a new machine, and the lock screen via GPO is working again.

    Friday, May 26, 2017 11:32 AM
  • The KB4020102 works if run as part of an upgrade from previous version to build 1703 or as a fresh install with an updated image. PCs that have 1703 installer previously will NOT receive the correct lockscreen after KB4020102 is installed.



    • Edited by sewellia Friday, May 26, 2017 12:10 PM
    • Proposed as answer by jnfarmer1990 Friday, May 26, 2017 3:24 PM
    Friday, May 26, 2017 12:01 PM
  • I applied the KB4020102 update by hand on 3 separate computers and the sign on screen background is still the default cave. Ran GPUPDATE /force and checked my policy settings. The image I use is saved locally on each computer in the c:\windows\backgrounds folder.

    Any suggestions?
    Friday, May 26, 2017 1:00 PM
  • We have group of pilot users that use 1703. None of these gets the new lockscreen applied even after applying KB4020102 . Redeploying the machines is obviously not a solution. 
    Friday, May 26, 2017 1:47 PM
  • The KB4020102 works if run as part of an upgrade from previous version to build 1703 or as a fresh install with an updated image. PCs that have 1703 installer previously will NOT receive the correct lockscreen after KB4020102 is installed.




    I can confirm this.  I tried moving a workstation to a test OU with no policies and the running GPUPDATE and then moving back and it had no effect.

    I also unjoined a machine from the domain and rejoined it had no effect.

    However a fresh install with the KB4020102 update applied before joining to the domain and the correct background is applied.

    Now hopefully someone will find a script or method of fixing those machines that cannot be reimaged.
    Friday, May 26, 2017 2:52 PM
  • The KB4020102 works if run as part of an upgrade from previous version to build 1703 or as a fresh install with an updated image. PCs that have 1703 installer previously will NOT receive the correct lockscreen after KB4020102 is installed.



    Yep, created the image with this update, redeployed it and we're in business! Thankfully held back on this deployment until this was sorted.
    Friday, May 26, 2017 3:25 PM
  • However a fresh install with the KB4020102 update applied before joining to the domain and the correct background is applied.

    If you change the image, does it pick up the new one, or does it stick with the first one that worked?

    Friday, May 26, 2017 5:22 PM
  • However a fresh install with the KB4020102 update applied before joining to the domain and the correct background is applied.

    If you change the image, does it pick up the new one, or does it stick with the first one that worked?


    I was going to try that by putting a machine in an OU that does not get that policy, manually changing the image and then moving the machine back to the original OU.  In theory that should work.

    My problem is I messed up and had my group policy set to current branch and not current branch for business so some machines autoupgraded to version 1703.   Most I can reimage because they are in labs and classrooms but the machines used by my secretaries an school administration staff I cannot really image unless I have to since they often have specialized software installed and save their documents all over the local hard drive.
    Friday, May 26, 2017 6:31 PM
  • However a fresh install with the KB4020102 update applied before joining to the domain and the correct background is applied.

    I'm not seeing this - how did you incorporate the update into your install image? I used dism to manually put in the x64 KB4020102 update.

    Cheers

    Wednesday, May 31, 2017 7:24 AM
  • Hi,

    It seems we have different kind of situation with different results, at least in my case:

    1) New deployments of Windows 10, version 1703 with KB4020102 included

    2) Existing Windows 10, version 1703 workstations that we update to KB4020102

    Regarding the first scenario, it seems working time to time but not on all machines. Some machines gets the good lock screen background corporate image and some not. Instead, a blue background image.

    The second scenario doesn't work at all. All my test machines were updated to the new KB and now I have a blue background image.

    Wednesday, May 31, 2017 7:59 AM
  • Hi, 

    KB4020102 did not complete fix this issue for us. The problem was the machine cache under "c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\" 

    After installation of KB4020102 we delete all .jpg in the LockScreen_Z Folder with

    psexec -accepteula -s c:\Windows\system32\cmd.exe /c del /q "c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\*.jpg"

    Now lock screen background works for us.

    Wednesday, May 31, 2017 10:14 AM
  • Hi,

    I tried to run the command

    psexec -accepteula -s c:\Windows\system32\cmd.exe /c del /q "c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\*.jpg"

    That doesn't work for us, I still have a blue bg image.

    Strange thing > once connected, when I look into the lock screen image in the Windows Setting, I can see my custom bg image selected.... thanks Microsoft....



    • Edited by AcetiK Friday, June 02, 2017 6:36 AM
    Wednesday, May 31, 2017 11:47 AM
  • We don't use GPO but we do set a default lock screen by editing the registry. 

    new-item -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\Personalization -Value LockScreenImage -Force
    Set-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\Personalization -Name LockScreenImage -Type String -Value "C:\Path-To\LOCK1703.jpg" -Force

    Before applying KB4020102 to our 1703 reference image, the lock screen would only work about half the time.  Sometimes we'd get the default 'cave' picture and other times the lock screen would be a solid blue background.  Now we get a much more consistent success rate of our custom lock screen being applied, although one time it was solid blue until after the first time we logged in and back out.  Needless to say, in our previous 1511 builds this was never a problem. 

    Wednesday, May 31, 2017 12:34 PM
  • Hi, 

    KB4020102 did not complete fix this issue for us. The problem was the machine cache under "c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\" 

    After installation of KB4020102 we delete all .jpg in the LockScreen_Z Folder with

    psexec -accepteula -s c:\Windows\system32\cmd.exe /c del /q "c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\*.jpg"

    Now lock screen background works for us.


    Just wanted to say this worked for us.  Thank god I only have a few machines to deal with this on.
    Thursday, June 01, 2017 2:38 PM
  • Hi

    Just discovered this, I had a custom lock screen set in GPO control panel/personalization - force a specific default lock screen and logon image and prevent changing lock screen and logon image enabled. It does show up (greyed out) in the display settings dialog box, but I only had the default cave picture showing.

    Out of interest, I have set a GPP to copy the file to a user's local machine, changed the specific lock screen setting from a UNC path to this now local path, and the custom lock screen is now working.

    Hope this helps out.

    Friday, June 02, 2017 1:09 PM
  • Just rebuilt my laptop with 1703 again to have a play with getting this working and noticed that despite getting the cave after the initial deployment (via SCCM), after a few more updates were installed, I can now set a custom lock screen

    I'll need to have a look at what was installed post OSD  (some patches were slipstreamed into the ISO via SCCM) that has fixed the issue


    Regards Craig Wilson

    Saturday, June 03, 2017 11:06 AM
  • Hi, 

    KB4020102 did not complete fix this issue for us. The problem was the machine cache under "c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\" 

    After installation of KB4020102 we delete all .jpg in the LockScreen_Z Folder with

    psexec -accepteula -s c:\Windows\system32\cmd.exe /c del /q "c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\*.jpg"

    Now lock screen background works for us.

    Could you describe in more detail how you pushed this command out? Did you use SCCM or some other way.  I have about 20 machines I need to this too and if Microsoft does not fix this before 1703 goes Current Branch For Business I may need it then too as I have about 80 - 100 machines I need to avoid re-imaging if I can help it and will just auto update according to the service plan.
    Tuesday, June 06, 2017 2:21 AM
  • Hi, 

    KB4020102 did not complete fix this issue for us. The problem was the machine cache under "c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\" 

    After installation of KB4020102 we delete all .jpg in the LockScreen_Z Folder with

    psexec -accepteula -s c:\Windows\system32\cmd.exe /c del /q "c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\*.jpg"

    Now lock screen background works for us.

    Could you describe in more detail how you pushed this command out? Did you use SCCM or some other way.  I have about 20 machines I need to this too and if Microsoft does not fix this before 1703 goes Current Branch For Business I may need it then too as I have about 80 - 100 machines I need to avoid re-imaging if I can help it and will just auto update according to the service plan.
    When I got to work this morning I tried running this manually on my workstation using PSEXEC and got an error that stated "The System cannot find the file specified."

    When I opened CMD as SYSTEM using PSEXEC -i -s -d CMD and then browsed to through the directories manually I found that the folder where the JPGs were was LockScreen_P. 

    Now I wonder if that folder could vary from machine to machine.

    • Edited by bwilkerson217 Tuesday, June 06, 2017 11:10 AM More Details
    Tuesday, June 06, 2017 11:03 AM
  • It's always been LockScreen_P for us, but clearly it can be LockScreen_Z in some circumstances - not sure what.

    I've not properly had chance to look at this, and would have to unpick our workaround in order to test it, but for those who are saying that this update has fixed it - can you confirm that machines reliably pick up changes to the specified lock screen image, as well as picking it up in the first place?

    Tuesday, June 06, 2017 11:44 AM
  • Hi, 

    KB4020102 did not complete fix this issue for us. The problem was the machine cache under "c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\" 

    After installation of KB4020102 we delete all .jpg in the LockScreen_Z Folder with

    psexec -accepteula -s c:\Windows\system32\cmd.exe /c del /q "c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_Z\*.jpg"

    Now lock screen background works for us.

    Deploying this with sccm got us the correct lockscreen. We just hade to change it to c:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\*.jpg
    • Edited by ulflundh Wednesday, June 07, 2017 8:25 AM typo
    Wednesday, June 07, 2017 8:25 AM
  • Hi again,

    deleted the cached files and the corporate lockscreen worked again.

    Now I tried to change it to another image, but the old one is still showing (did several restarts, logons and gpupdates). Deleting the cached files one more time solves this mystery again.

    Thanks MS, now we have to delete the cached files every time????? Even a gpupdate /force didn't help!

    Just wow...



    • Edited by TAFrank Thursday, June 08, 2017 1:20 PM
    Thursday, June 08, 2017 6:34 AM
  • Hi again,

    deleted the cached files and the corporate lockscreen worked again.

    Now I tried to change it to another image and the old one is still active. Thanks MS, now we have to delete the cached files every time????? Even a gpupdate /force didn't help!

    Just wow...

    That was what i was afraid of. Keeps us from deploying 1703 after all. Thanks for reporting. 
    • Edited by ulflundh Thursday, June 08, 2017 6:58 AM typo
    Thursday, June 08, 2017 6:58 AM
  • Sorry for the double post, I had logged on using my Hotmail account without realising. Hopefully the duplicate post should have disappeared now.

    I have encountered this for the first time today. Since Windows 7 our corporate desktop background (wallpaper) and login/lock screen have been set at logon using a VBscript which detects the screen resolution then assigns the appropriately sized image.

    We deploy a customised image via WDS, which encapsulates all recent updates, hardware specific drivers, and custom user environment settings. I have been working on 1703 since the enterprise ISO release with huge frustration. I am aware that MS want to force everyone down the MDT route and want to force use of Settings app over Control Panel etc. but 2 staff supporting almost 5000 users does not allow a lot of time for fundamentally changing how systems have been built for years. 

    As things stand I have had to completely re-write the WDS answer file, re-write customisation scripts, and change the mechanism for setting a custom start panel. 1703 seems to have chosen to ignore the LayoutModification.xml file which has worked all through previous incarnations of Windows 10.

    Current WDS wim is 15063.296 and this has been fine in terms of login/lock screen until yesterday.

    I kicked off 2 systems yesterday, both of which have developed this most recent issue. The only thing I changed was adding a GPO to force our corporate start panel. Surely this should have nothing at all to do with the login/lock screen?

    Edit: Removed the GPO for the start panel and this is still happening. Using the script posted above I removed the offending files and my custom screen worked. Restarted, and the permissions had reverted to original settings.


    Things would be great if they worked properly.


    • Edited by Tom-at-Stirling Thursday, June 08, 2017 12:24 PM formatting was awful
    Thursday, June 08, 2017 12:22 PM
  • Been trying to get this to work on 1703 for ages and finally it happened.......

    (As with everyone else it worked fine on 1511 and 1607 but not 1703)

    Solution:

    Updated policy definition files to creators update 1703.

    https://www.microsoft.com/en-us/download/details.aspx?id=55080

    Set background to \\servername\netlogon\backgrounds\background.jpg

    Worked instantly!

    What i have noticed though... if you edit the image but keep the name the same it isn't updated on the client login screen but if you edit it, rename it and change the group policy to suit it updates the changes.

    Its as if Windows checks to see if it already exists with that name and if so doesn't change it. 

    • Proposed as answer by Geek786 Tuesday, June 13, 2017 8:51 AM
    Monday, June 12, 2017 2:54 PM
  • Been trying to get this to work on 1703 for ages and finally it happened.......

    (As with everyone else it worked fine on 1511 and 1607 but not 1703)

    Solution:

    Updated policy definition files to creators update 1703.

    https://www.microsoft.com/en-us/download/details.aspx?id=55080

    Set background to \\servername\netlogon\backgrounds\background.jpg

    Worked instantly!

    What i have noticed though... if you edit the image but keep the name the same it isn't updated on the client login screen but if you edit it, rename it and change the group policy to suit it updates the changes.

    Its as if Windows checks to see if it already exists with that name and if so doesn't change it. 

    I tried this on a test machine and can confirm that it is working fine after downloading the latest policy definitions for Creators Update and changing the background name to reflect it in the gpupdate.
    Tuesday, June 13, 2017 8:51 AM
  • What i have noticed though... if you edit the image but keep the name the same it isn't updated on the client login screen but if you edit it, rename it and change the group policy to suit it updates the changes.

    Its as if Windows checks to see if it already exists with that name and if so doesn't change it.

    That still sounds like the caching isn't working properly.

    If windows is going to cache the image you've provided (and fair enough I can see the need to do that as it might not be accessible), then it has to pay proper attention as to whether that image has changed since it cached it. Otherwise we're into hacky workarounds to populate or reset the cache via some mechanism that depends on the undocumented internals of how the cache works.

    I wouldn't consider this solved until you can update the image the setting refers to and have the cached version update promptly (i.e. the next time the lock screen is displayed for any reason), and reliably.

    Tuesday, June 13, 2017 9:30 AM
  • Dunno if it is just me, but i noticed with 1703, i can no longer get GPO to apply the computer configuration, which also broke this, among other things on my Windows 10 Systems.. I luckily only have 3 of them i updated, the rest are older builds and i am not going to update them.. (Probably roll the other 6 back to Windows 7) the rest of my network is 7.. which it will remain until i dump microsoft, unless they get their act together.. 


    Rob

    Tuesday, June 13, 2017 1:56 PM
  • This going to sound stupid.. but i assure you there is a reason to the crazy question.. 

    Do you run a 2012R2 Domain controller? 

    Are you using OU's with Ou's under them for policying? 

    I located a bug that was causing a lot of issues in my network today.. 

    The issue seems to be a bug in AD/GP/and windows 10 1703.. 

    The "blocking" of inheritance does not work in 2012R2 with windows 10..

    So i wonder if you have your win 10 machines in an OU that has some blocked inheritance settings..

    If it does.. don't change any of your settings, just move them to another OU.. reboot the Win10 machine and see if your background get's fixed.. it resolved all my issues..

    Just my 2 cents.. understandably everyone's setup is different.. but figured maybe it would help you..  


    Rob

    Tuesday, June 13, 2017 4:57 PM
  • This process was pretty close to right for me, I had to change the name of the image file and then in the GPO. After a gpupdate and restart it came good.

    I did the following in my testing:
    1. Installed all relevant 1703 admx's straight up before I even started.
    2. Built a custom image based on a win 10 1703
    3. Used this image in my production build
    4. Manually installed KB4020102
    5. Changed the lockscreen picture filename & updated its GPO to reflect the new path.
    6. Gpupdate and restart, and it worked ok.

    I will now attempt to inject the update during the vanilla build and see if the filename requires changing yet again or it accepts it.

    Wednesday, June 14, 2017 12:33 AM
  • Been trying to get this to work on 1703 for ages and finally it happened.......

    (As with everyone else it worked fine on 1511 and 1607 but not 1703)

    Solution:

    Updated policy definition files to creators update 1703.

    https://www.microsoft.com/en-us/download/details.aspx?id=55080

    Set background to \\servername\netlogon\backgrounds\background.jpg

    Worked instantly!

    What i have noticed though... if you edit the image but keep the name the same it isn't updated on the client login screen but if you edit it, rename it and change the group policy to suit it updates the changes.

    Its as if Windows checks to see if it already exists with that name and if so doesn't change it. 

    I tried this on a test machine and can confirm that it is working fine after downloading the latest policy definitions for Creators Update and changing the background name to reflect it in the gpupdate.

    This also worked for me. Previously, I had the path set to a local path. The lock screen would only show when a user was logged on. If the user was logged out completely, then the lock screen was the cave. 

    Once I set the lockscreen path as a UNC, it worked instantly whether a user was logged in or not!

    Microsoft still needs to fix the bug though.. It seems that the May 25, 2017 KB4020102 update didn't fix it like we all initially thought.


    Jordan Bardwell YRC Freight Systems Engineer

    Wednesday, June 14, 2017 3:25 PM
  • Hi, thanks for this, I have the policy in place but it isn't working yet, is there any chance you could provide some screen shots of the group policy settings to make sure I have everything set correctly? thanks in advance
    Thursday, June 15, 2017 1:26 PM
  • Been trying to get this to work on 1703 for ages and finally it happened.......

    (As with everyone else it worked fine on 1511 and 1607 but not 1703)

    Solution:

    Updated policy definition files to creators update 1703.

    https://www.microsoft.com/en-us/download/details.aspx?id=55080

    Set background to \\servername\netlogon\backgrounds\background.jpg

    Worked instantly!

    What i have noticed though... if you edit the image but keep the name the same it isn't updated on the client login screen but if you edit it, rename it and change the group policy to suit it updates the changes.

    Its as if Windows checks to see if it already exists with that name and if so doesn't change it. 

    I tried this on a test machine and can confirm that it is working fine after downloading the latest policy definitions for Creators Update and changing the background name to reflect it in the gpupdate.

    This also worked for me. Previously, I had the path set to a local path. The lock screen would only show when a user was logged on. If the user was logged out completely, then the lock screen was the cave. 

    Once I set the lockscreen path as a UNC, it worked instantly whether a user was logged in or not!

    Microsoft still needs to fix the bug though.. It seems that the May 25, 2017 KB4020102 update didn't fix it like we all initially thought.


    Jordan Bardwell YRC Freight Systems Engineer

    Just kidding...

    It worked for a day.. Now its broke again... C'mon Microsoft... This is very buggy!


    Jordan Bardwell YRC Freight Systems Engineer

    Thursday, June 15, 2017 6:07 PM
  • Same problem here +1

    Prior to 1703, it worked OK.  Now, it doesn't.  Haven't found a fix yet that work successfully on VL Enterprise

    Thursday, June 22, 2017 12:29 PM
  • I think it's working for me.  I kept getting the .jpg and .png files mixed up in the c:\windows\web\screen directory. 

    According to the machine registry.pol, the lockscreenoverlaydisabled setting has to be deleted for this setting to work:

    PS C:\> Get-PolicyFileEntry C:\Windows\system32\GroupPolicy\Machine\registry.pol -All
    
    ValueName                        Key                                                 Data                               Type
    ---------                        ---                                                 ----                               ----
    **del.LockScreenOverlaysDisabled Software\Policies\Microsoft\Windows\Personalization                                  String
    LockScreenImage                  Software\Policies\Microsoft\Windows\Personalization c:\windows\web\screen\img101.png String

    Here's the file activity according to process monitor:

    1:19:45.9631609 PM	DllHost.exe	2152	IRP_MJ_CREATE	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen.jpg	SUCCESS	Desired Access: Generic Write, Read Attributes, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Created
    1:19:45.9682988 PM	DllHost.exe	2152	IRP_MJ_CREATE	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen.jpg~RF85afa.TMP	SUCCESS	Desired Access: Generic Write, Read Attributes, Delete, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: HT, ShareMode: None, AllocationSize: 0, OpenResult: Created
    1:19:45.9690113 PM	DllHost.exe	2152	IRP_MJ_SET_INFORMATION	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen.jpg	SUCCESS	Type: SetRenameInformationFile, ReplaceIfExists: True, FileName: C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen.jpg~RF85afa.TMP
    1:19:45.9755284 PM	DllHost.exe	2152	IRP_MJ_SET_INFORMATION	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen.jpg~RF85afa.TMP	SUCCESS	Type: SetDispositionInformationFile, Delete: True
    1:19:46.0531121 PM	DllHost.exe	2152	IRP_MJ_CREATE	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0194_0194.jpg	SUCCESS	Desired Access: Generic Write, Read Attributes, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Created
    1:19:46.0563654 PM	DllHost.exe	2152	IRP_MJ_CREATE	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0194_0194.jpg~RF85b57.TMP	SUCCESS	Desired Access: Generic Write, Read Attributes, Delete, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: HT, ShareMode: None, AllocationSize: 0, OpenResult: Created
    1:19:46.0568366 PM	DllHost.exe	2152	IRP_MJ_SET_INFORMATION	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0194_0194.jpg	SUCCESS	Type: SetRenameInformationFile, ReplaceIfExists: True, FileName: C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0194_0194.jpg~RF85b57.TMP
    1:19:46.0597479 PM	DllHost.exe	2152	IRP_MJ_SET_INFORMATION	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0194_0194.jpg~RF85b57.TMP	SUCCESS	Type: SetDispositionInformationFile, Delete: True
    1:19:46.1394203 PM	DllHost.exe	2152	IRP_MJ_CREATE	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0151_0151.jpg	SUCCESS	Desired Access: Generic Write, Read Attributes, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Created
    1:19:46.1416409 PM	DllHost.exe	2152	IRP_MJ_CREATE	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0151_0151.jpg~RF85bb5.TMP	SUCCESS	Desired Access: Generic Write, Read Attributes, Delete, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: HT, ShareMode: None, AllocationSize: 0, OpenResult: Created
    1:19:46.1441117 PM	DllHost.exe	2152	IRP_MJ_SET_INFORMATION	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0151_0151.jpg	SUCCESS	Type: SetRenameInformationFile, ReplaceIfExists: True, FileName: C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0151_0151.jpg~RF85bb5.TMP
    1:19:46.1457039 PM	DllHost.exe	2152	IRP_MJ_SET_INFORMATION	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0151_0151.jpg~RF85bb5.TMP	SUCCESS	Type: SetDispositionInformationFile, Delete: True
    1:19:46.2299679 PM	DllHost.exe	2152	IRP_MJ_CREATE	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0108_0108.jpg	SUCCESS	Desired Access: Generic Write, Read Attributes, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Created
    1:19:46.2323184 PM	DllHost.exe	2152	IRP_MJ_CREATE	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0108_0108.jpg~RF85c13.TMP	SUCCESS	Desired Access: Generic Write, Read Attributes, Delete, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: HT, ShareMode: None, AllocationSize: 0, OpenResult: Created
    1:19:46.2327592 PM	DllHost.exe	2152	IRP_MJ_SET_INFORMATION	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0108_0108.jpg	SUCCESS	Type: SetRenameInformationFile, ReplaceIfExists: True, FileName: C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0108_0108.jpg~RF85c13.TMP
    1:19:46.2341220 PM	DllHost.exe	2152	IRP_MJ_SET_INFORMATION	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___0108_0108.jpg~RF85c13.TMP	SUCCESS	Type: SetDispositionInformationFile, Delete: True
    1:19:46.4403802 PM	LogonUI.exe	5508	IRP_MJ_CREATE	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___1920_1080_notdimmed.jpg	SUCCESS	Desired Access: Generic Write, Read Attributes, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Created
    1:19:46.4431898 PM	LogonUI.exe	5508	IRP_MJ_CREATE	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___1920_1080_notdimmed.jpg~RF85cde.TMP	SUCCESS	Desired Access: Generic Write, Read Attributes, Delete, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: HT, ShareMode: None, AllocationSize: 0, OpenResult: Created
    1:19:46.4436633 PM	LogonUI.exe	5508	IRP_MJ_SET_INFORMATION	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___1920_1080_notdimmed.jpg	SUCCESS	Type: SetRenameInformationFile, ReplaceIfExists: True, FileName: C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___1920_1080_notdimmed.jpg~RF85cde.TMP
    1:19:46.4499209 PM	LogonUI.exe	5508	IRP_MJ_SET_INFORMATION	C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18\ReadOnly\LockScreen_P\LockScreen___1920_1080_notdimmed.jpg~RF85cde.TMP	SUCCESS	Type: SetDispositionInformationFile, Delete: True
    



    • Edited by JS2010 Thursday, June 22, 2017 9:26 PM
    Thursday, June 22, 2017 9:23 PM
  • iriecolorado's script assisted in getting mine to work.

    I manually took ownership of SystemData and then deleted everything underneath it. Then I ran a gpupdate /forced. After that I ran this script (not sure why the take ownership on the script didn't work for me). Then I locked the computer and restarted.

    • Edited by lejohnston Wednesday, June 28, 2017 7:25 PM added reference
    Wednesday, June 28, 2017 7:24 PM
  • I opened a ticket with Microsoft and they suggested changing the filename extension from .jpg to .png. It started working correctly after that for me.
    Wednesday, July 05, 2017 7:40 PM
  • Exactly!!! I have several Technet posts about how much this has pissed me off.

    I did my due diligence to make sure Pro fit all our Corporate needs.

    Then they decided to strip it away since Windows 10 1607, thanks for ruining my due diligence MS!

    "Pro SKU is not designed for companies, its designed for "Professional" home users." 

    is BS when Pro is allowed to join a domain, means it it designed for corporate use.

    Wednesday, July 05, 2017 9:53 PM
  • Seems like someone else mentioned waiting on the VL ISO to be released. I am doing the same but have no confidence it will be any different. We have a premier case open with MS. If anything comes out of it, I will post the results here for others.

    I find it baffling how this stuff makes it through QA. Seems like every release of Windows and Deployment tools in the last two years has changed or broken proven methods of simple administrative tasks. It's enough administrative effort to deal with new features, but having to go back an re-work things that have worked for years is extremely frustrating.

    This.... this right here times 9000!!
    Wednesday, July 05, 2017 9:56 PM
  • I would like  to thank several posters here for pointing me in the right direction and helping me solve this problem. 

    My issue was that the logon and lock picture would not show up and of course I got the cave. I am working with thinkpad 10 tablets and noticed that if I rotate the tablet, my default image shows, but when i rotate it back it shows the cave again. 

    After reading the posts i tried a different resolution and it worked (changed from 1900x 1200 to something lower). 

    I checked the image that was being used as the background and it was 1900 by 1200. So even though the resolution matched, windows 10 1703 did not like it. 

    I decided to increase the resolution in the picture and then deploy it again. Boom! Issue solved. One of dumbest issues I have had to work with in regards to GPO. 


    So FYI i am using Windows 10 1703 Edu and the may version of Windows 10 1703. I am using file explorer GPO to add the picture to c:\windows\web\background (?). And then just applying it. And I am working with a JPG as opposed to a PNG. 

    Friday, July 07, 2017 1:16 PM
  • I can't figure it out...

    On my test system, I attempted unappling prevent changing the lockscreen, while still having the force a specific lockscreen set.

    Didn't work, but I could now change the lock screen in the windows settings (so the GPOs are being applied)

    I then attempted the listed KB people mentioned which listed it fixing this issue, update stated was not applicable to the computer, I can only assume cause I ran all updates that there was one already installed that superseded it.

    So no luck there. Then I attempted the provided scripts to take over the S-1-5-18 sub folders and clear all the temp cache files, reboot, still no dice.

    Then after reading the latest persons response I copied the UNC path .jpg file and renamed it to .png, then updated my GPO to point to the new .png file. Rebooted and this actually worked!

    Then I went ahead and deployed it to another users computer... did all the same stuff as before and it's not working!!! this is driving me nuts... as other mentioned its not consistent across machines!

    Friday, July 07, 2017 5:01 PM
  • Since the new 1703 Update (KB4025342) it works for me on my PC. I will do some more testing with different machines and look, if this issue is completely fixed.
    Wednesday, July 12, 2017 7:01 AM
  • Nope, fresh deployment of 1703 plus all updates - still the cave.

    gpupdate /force useless

    Update: Now it works magically - stranger things
    • Edited by TAFrank Thursday, July 13, 2017 11:59 AM
    Wednesday, July 12, 2017 9:07 AM
  • I'm starting to think there a ratio issue happening here. I noticed this problem when I first started to try and deploy the custom logon background on Windows 10.

    Here's the thing I noticed. All our laptops main screens use 16:9 with a res of 1920x1080.

    However when most of our monitors were purchased they happen to come in 16:10 using a res of (1920 x 1200).

    The background I noticed applied on teh loaner laptop which was just using it's standard screen. I also noticed on the only client who happened to have 16:9 monitors with the 1920 x 1080 res, the background indeed did apply.

    I had this problem before since the exact specs of what the logon background actually does when it's attempting to be displayed on a screen thats on a different ratio then the image, does it stretch? Does it shrink? 

    I'll play around with different ratio images to see if they apply properly.

    Wednesday, July 12, 2017 4:23 PM
  • I'm starting to think there a ratio issue happening here. I noticed this problem when I first started to try and deploy the custom logon background on Windows 10.

    Here's the thing I noticed. All our laptops main screens use 16:9 with a res of 1920x1080.

    However when most of our monitors were purchased they happen to come in 16:10 using a res of (1920 x 1200).

    The background I noticed applied on teh loaner laptop which was just using it's standard screen. I also noticed on the only client who happened to have 16:9 monitors with the 1920 x 1080 res, the background indeed did apply.

    I had this problem before since the exact specs of what the logon background actually does when it's attempting to be displayed on a screen thats on a different ratio then the image, does it stretch? Does it shrink? 

    I'll play around with different ratio images to see if they apply properly.

    Did anyone find a fix for this? I am still having the issue with all the latest updates, fixes, and patches applied. My domain controllers are running Windows Server 2016 with the latest ADMX templates installed. My Workstations that are domain joined running Windows 10 Enterprise 1703 build 15063.540. I went through every single post on this forum and tried all the fixes suggested and it still doesn't work. 

    Some other fixes I tried

    Tried to use a custom lock-screen image with 1920X1080 resolution and JPG/PNG Format

    Tried to use a custom lock-screen image with 1920X1200 resolution and JPG/PNG Format

    Recreated the the GPO

    Turning off "Show lock screen background picture on the sign-in screen" will make the custom lock-screen appear but only on certain computers. Also when the password screen shows up, it is a solid color as opposed to the custom lock screen image. Thanks in advance for any replies. 


    M

    Tuesday, August 22, 2017 3:29 PM
  • Hi,

    it's still a bug :-(

    see here: https://blogs.technet.microsoft.com/askcore/2017/05/05/known-lock-screen-issues-with-creators-update-1703/

    J


    Thursday, August 24, 2017 11:12 AM
  • Here is the working solution for our company (builds 1511, 1607 and 1703):

    Computer Configuration/Policies/Administrative Templates

    Control Panel/Personalization

    - Force a specific default lock screen and logon image Enabled  
    - Path to lock screen image: \\xxxxxxxxx\xxxxx\BackgroundDefault.jpg 

    - Turn off fun facts, tips, tricks, and more on lock screen Enabled 

    - Prevent changing lock screen and logon image Enabled 

    **********

    User Configuration/Policies/Administrative Templates

    Windows Components/Cloud Content

    - Configure Windows spotlight on lock screen Disabled
    - Do not suggest third-party content in Windows spotlight Enabled
    - Turn off all Windows spotlight features Enabled
    - Turn off the Windows Spotlight on Action Center Enabled
    - Turn off the Windows Welcome Experience Enabled






    • Edited by Vinx Itak Monday, September 04, 2017 4:16 PM
    Tuesday, August 29, 2017 8:31 AM
  • Here is the working solution for our company :

    Computer Configuration/Policies/Administrative Templates

    Control Panel/Personalization

    - Force a specific default lock screen and logon image Enabled  
    - Path to lock screen image: \\xxxxxxxxx\xxxxx\BackgroundDefault.jpg 

    - Turn off fun facts, tips, tricks, and more on lock screen Enabled 

    - Prevent changing lock screen and logon image Enabled 

    **********

    User Configuration/Policies/Administrative Templates

    Windows Components/Cloud Content

    - Configure Windows spotlight on lock screen Disabled
    - Do not suggest third-party content in Windows spotlight Enabled
    - Turn off all Windows spotlight features Enabled
    - Turn off the Windows Spotlight on Action Center Enabled
    - Turn off the Windows Welcome Experience Enabled


    I will post a screenshot when i will be autorize 



    Hi, 

    Thank you so much for your response. I tried it and it didn't work for me :(


    M

    Tuesday, August 29, 2017 3:19 PM
  • Matt I was able to get my background to apply on one of my users system that would never seem to get the logon background applied, even though the Lock Screen section showed the preview for it just fine.

    I manually ran the following:

    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

        rmdir /Q /S C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18

    The last one might be wrong as I'm going off memory and haven't had time yet to actually make a startup script to do this on an admins behalf.

    Can you try the above on the system you are not getting the background to work on? I'd suggest to try it manually first and do a reboot, this was the only thing that worked for me after trying everything else like you said you have.

    Tuesday, August 29, 2017 9:27 PM
  • Matt I was able to get my background to apply on one of my users system that would never seem to get the logon background applied, even though the Lock Screen section showed the preview for it just fine.

    I manually ran the following:

    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

        rmdir /Q /S C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-18

    The last one might be wrong as I'm going off memory and haven't had time yet to actually make a startup script to do this on an admins behalf.

    Can you try the above on the system you are not getting the background to work on? I'd suggest to try it manually first and do a reboot, this was the only thing that worked for me after trying everything else like you said you have.

    JESUS CHRIST Zewwy you are a Genius!!!! It actually worked. I am going to run this script on every machine that is not showing the correct lockscreen. You are a lifesaver. 

    God bless! 


    M

    Thursday, August 31, 2017 7:17 PM
  • If you have sysinternals psexec. you can run "psexec -sid cmd" and get a cmd prompt as the System user.  Then do what you want with the SystemData\S-1-5-18\ folder.  I was just copying the right file, but then over remote desktop with a different resolution it wasn't working, but that's minor.


    • Edited by JS2010 Thursday, August 31, 2017 7:32 PM
    Thursday, August 31, 2017 7:31 PM
  • Hi, I've tried your method but it doesn't work. Can you elaborate which windows version and which methods for custom lockscreen? I've tried everything mentioned here in audit mode but none works.

    tested with 1703 and 1607..

    either Lockscreen doesn't change or the lockscreen settings page froze

    Sunday, September 03, 2017 6:17 AM
  • I'm having this issue as well. For now, I seem to have good results by simply switching the image to another one (or the same one with a different name).

    After a gpupdate (or reboot etc), the image does get applied correctly.

    It seems almost like the image gets stuck during deployment and needs a "refreshment" to work.

    as a messy workaround, you could simply flip the gpo setting every day so every new deployed pc will get its lock screen right after a day...

    Friday, September 22, 2017 1:59 PM
  • setting the DisableLogonBackgroundImage dword to 0 solved the issue for me on a bare metal install of 1709.  i had the issue in 1703 as well, but now that 1709 is out, i've stopped working on 1703 and am getting ready to roll out 1709 instead so we'll have a little longer support window.
    Friday, October 20, 2017 10:09 PM
  • I know this has been running a while and there was a fix issued in May (KB4020102) that resolves this specific issue but have you tried using OOBE to control your lockscreen - this is the way we do it - slightly older way of doing it (OEM method) but works much better in my opinion as you are able to specify a number of different resolutions for the picture you wan to use so if in your estate if anything like ours we have everything from 17" 4:3 ratio monitors all the way upto 64" 4K displays and obviously supplying one picture and expecting it to fit all of these is wishful thinking.

    (group policy prefs is perfect for this or create a package to push out or even incorportate in to your build)

    Basically the OOBE method is really simple - set a reg key to "turn it on", create 2 folders in a specific place on the local machine (to hold pictures), create your backgrounds in your required resolutions - there are about 10 you can use - only caveat is picture needs to be under 256KB in size, copy them down to local machine in the folder above and hey presto - windows 10 has 2 lock screens as well depending on how your have your builds setup - lock and logon (logon is on the ctrl +alt +del screen  -if you are interested I can send you some links to how its setup or a simple google of OOBE lockscreen will find you plenty of resources

    hope this helps

    Thursday, November 09, 2017 3:52 PM
  • Thanks for that.  I didn't know the fix was documented in the .332 monthly update:

    https://support.microsoft.com/en-us/help/4020102/windows-10-update-kb4020102

    "Addressed issue when trying to set a default lockscreen using the following Group Policy, you do not see the defined image on the lockscreen but you do see the defined image in Settings under lockscreen settings.

    Computer Configuration\Administrative Templates\Control Panel\Personalization\"Force a specific default lock screen image"

    Thursday, November 09, 2017 5:29 PM
  • I'm having this issue as well. For now, I seem to have good results by simply switching the image to another one (or the same one with a different name).

    After a gpupdate (or reboot etc), the image does get applied correctly.

    It seems almost like the image gets stuck during deployment and needs a "refreshment" to work.

    as a messy workaround, you could simply flip the gpo setting every day so every new deployed pc will get its lock screen right after a day...

    I think it's fixed in our environment by adding recent patches to our base image. This causes the GPO to apply correctly immediately.
    Thursday, November 16, 2017 1:31 PM
  • Windows Update 1709 corrected the problem with a lock screen.
    • Edited by net_tech Sunday, December 03, 2017 8:32 PM
    Sunday, December 03, 2017 8:32 PM
  • Not working on my 1709
    Thursday, February 01, 2018 3:42 PM
  • It is really weird, we still have this issue and only with last updates in 1703 build.

    For example, machines upgraded to Windows 10 before January have our lockscreen. But machines upgraded to Windows 10 after January still have the same default lockscreen and it cannot be changed with this registry : HKLM\SOFTWARE\Policies\Microsoft\Windows\Personalization\LockScreenImage

    Someone meet something like us ?

    Thanks.


    • Proposed as answer by Reclad Tuesday, March 06, 2018 10:40 AM
    • Unproposed as answer by Reclad Tuesday, March 06, 2018 10:40 AM
    Tuesday, March 06, 2018 10:35 AM
  • I have found if you change the resolution, apply it, then lock the device, it works.  If you change the resolution back to what it was originally, apply it and lock the device again, it works!
    Thursday, March 08, 2018 12:20 PM
  • issue appears to be present again with the latest iteration of 1709. Pathetic!!!!
    Wednesday, May 02, 2018 1:21 PM