Sheridan Posted June 21, 2017 Author Posted June 21, 2017 We tested a fresh 1702 update and then added the latest CU and after several reboots it has worked! So upgrading from 1607 to 1703 is a waste of time. Reimaging seems to be the default option now.
arron Posted June 27, 2017 Posted June 27, 2017 We've got the latest CU merged into the wim that we use to do an upgrade and the one for fresh installs, the Lockscreen applies without issue.
3s-gtech Posted June 27, 2017 Posted June 27, 2017 What's wrong with windows 7? :D:D It's not 2010 any more? Just working on a batch of laptops, using the registry hacks I've set up is working well. Getting the occasional one that is still reverting to the cave scene - deleting the entries in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SystemProtectedUserData\S-1-5-18\AnyoneRead\LockScreen a second time seem to be fixing it fine.
Fazza Posted June 29, 2017 Posted June 29, 2017 I've just installed an SCCM image built from a Windows 10 1703 golden image I created (with no Windows Updates installed) and at the logon/lock screen our background image (pushed out via GPO) works fine and displays OK so we dont seem to have the same issue as some of you guys.
Arthur Posted July 5, 2017 Posted July 5, 2017 Its a well know bug and still seems to be unresolved. Known Lock Screen issues with Creator’s Update (1703) My lock screen is also working fine with the latest June CU.
DavR Posted July 6, 2017 Posted July 6, 2017 Seems to really vary by establishment on this one... I'm doing a brand new deployment of Windows 10 Ent 1703 with all the latest updates and updated admx files, and I can't get it to budge.
Fazza Posted July 10, 2017 Posted July 10, 2017 Seems to really vary by establishment on this one... I'm doing a brand new deployment of Windows 10 Ent 1703 with all the latest updates and updated admx files, and I can't get it to budge. I assume you've tried bunging your test PC in a test OU and blocked inheritance of Group Policies and then just applied a single GPO with just the lock screen configured?
Sheridan Posted July 10, 2017 Author Posted July 10, 2017 Stopped working again here, but 1703 seems to be one of the worst updates (and thats saying something!) for breaking things. I'm not deploying any 1703's anymore - updates are broken on many of ours as well so we reimaged them back to 1607. FFS what rubbish are MS doling out these days.
alfatec Posted July 10, 2017 Posted July 10, 2017 I was going to go up to 1703 from 1511 during the Summer but not now. Everything seems to be going worse. 1511 is so stable for me on everything but 1703 can't get the local profile to work, login background now works but only on a fresh build not on an upgrade, and the start menu now doesn't work. Anybody got a good definitive guide to creating a default profile for local use on Windows 10, seem to have lost mine.
mdrabble Posted July 10, 2017 Posted July 10, 2017 I found 1703 unbelievably bad - lock screen didnt work regardless of work arounds and updates. Logon times are almost double compared to 1607 and the profile in use was created on 1703.
DavR Posted July 10, 2017 Posted July 10, 2017 I haven't found 1703 that bad, but I haven't done enough with previous versions to judge it by. Apart from the lock screen thing (which is very annoying, but I'll cope), all the things that are broken for me are also known to be broken in 1607 as well.... I'm just alarmed at how many things are broken out of the box. It's like Microsoft are not only not testing properly, but then they're also not responding when bugs are reported.
Fazza Posted July 11, 2017 Posted July 11, 2017 Just exported my first Student W10 Start Layout and created a new group policy and it worked first time so it sounds weird it's working in some places but not others as we all download the same ISO file and admx files. All I need to do now is see if there is a way of making the layout just 3 tiles wide rather than 2 lots of 3 as that looks messy...
DavR Posted July 11, 2017 Posted July 11, 2017 Just exported my first Student W10 Start Layout and created a new group policy and it worked first time so it sounds weird it's working in some places but not others as we all download the same ISO file and admx files. All I need to do now is see if there is a way of making the layout just 3 tiles wide rather than 2 lots of 3 as that looks messy... I've had that Start Menu layout work and not work for the same test user, never did pin it down. Mine is Programs list on the left plus 3 tiles wide on the right, and for a while there the 3 tiles wouldn't show! I've left it alone though, and am just not relying on the tiles section to work (I didn't really want any tiles, but you have to have them for the XML to work).
Fazza Posted July 11, 2017 Posted July 11, 2017 Mine is Programs list on the left plus 3 tiles wide on the right What did you do to try and make it just 3 tiles wide?
DavR Posted July 11, 2017 Posted July 11, 2017 What did you do to try and make it just 3 tiles wide? When preparing my custom Start Menu, I removed ALL pinned tiles, so I got to a Start Menu that was just the Program list. Then I pinned a few tiles to get Programs + 3 tiles wide.
Sheridan Posted July 12, 2017 Author Posted July 12, 2017 Fresh install of 1703 with latest CU - doesn't show custom lock screen until someone logs in and then back out, then it shows. But reboot it and its back to that stupid cave again. Just as well windows 10 isn't being used in anything mission critical eh!
3s-gtech Posted July 12, 2017 Posted July 12, 2017 Delete the registry entries: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SystemProtectedUserData\S-1-5-18\AnyoneRead\LockScreen\CacheFormat_P HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SystemProtectedUserData\S-1-5-18\AnyoneRead\LockScreen\GPImagePath_P HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SystemProtectedUserData\S-1-5-18\AnyoneRead\LockScreen\SizeX_P HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SystemProtectedUserData\S-1-5-18\AnyoneRead\LockScreen\SizeY_P Once that is done it should work consistently. If the cave ever reappears, delete these again. You can automate this if you need to.
Sheridan Posted July 12, 2017 Author Posted July 12, 2017 Permission block those registry entries - but even so, they GPImagePath_P is pointing to the correct local image filename!
3s-gtech Posted July 12, 2017 Posted July 12, 2017 It'll be correct, yes. Delete it anyway. It's the caching that causes the problem, though the path is correct. Deleting the entries fixes it - I do so using the local administrator account which doesn't have permissions issues so you may need to elevate to do it.
Sheridan Posted July 12, 2017 Author Posted July 12, 2017 (edited) Those entries seem blocked for anything I try, can't change permissions,edit entries, take ownership or anything. I think microsoft have forgotten what an 'administrator' is supposed to be. Edit: Should have read that more thoroughly! I could deleted those as the local admin account. I'll reboot it a few times now and see what happens. Edited July 12, 2017 by Sheridan
3s-gtech Posted August 2, 2017 Posted August 2, 2017 (edited) I have had a SUPER FUN morning with this rearing its head again. None of my previous fixes would get anything to budge - the cave was there to stay. Thankfully, after about two hours of trying different things, I've done three things: 1. Switched back to a UNC image path for the lock screen. 2. Applied this: CD \Windows\Web\Screen ren img100.jpg img99.jpg ren img101.jpg img100.jpg ren img102.jpg img101.jpg ren img103.jpg img102.jpg ren img104.jpg img103.jpg ren img99.jpg img104.jpg cd \ProgramData\Microsoft\Windows takeown /F SystemData /R /A /D Y Rem The /R makes it recursive, and the /A assigns Admin group, /D is default answer for “are you sure” prompts. del SystemData\S-1-5-18\ReadOnly\LockScreen_Z\*.jpg This purges YET ANOTHER cache resource (after taking ownership of it to do so). This was the catalyst to get it working. For something so simple this is ridiculous, but haven't the last two years been like that? EDIT: nope. On a reboot, the cave has come back. It is the unflushable effluent. Edited August 2, 2017 by 3s-gtech
mrbios Posted August 2, 2017 Posted August 2, 2017 I have had a SUPER FUN morning with this rearing its head again. None of my previous fixes would get anything to budge - the cave was there to stay. Thankfully, after about two hours of trying different things, I've done three things: 1. Switched back to a UNC image path for the lock screen. 2. Applied this: CD \Windows\Web\Screen ren img100.jpg img99.jpg ren img101.jpg img100.jpg ren img102.jpg img101.jpg ren img103.jpg img102.jpg ren img104.jpg img103.jpg ren img99.jpg img104.jpg cd \ProgramData\Microsoft\Windows takeown /F SystemData /R /A /D Y Rem The /R makes it recursive, and the /A assigns Admin group, /D is default answer for “are you sure” prompts. del SystemData\S-1-5-18\ReadOnly\LockScreen_Z\*.jpg This purges YET ANOTHER cache resource (after taking ownership of it to do so). This was the catalyst to get it working. For something so simple this is ridiculous, but haven't the last two years been like that? EDIT: nope. On a reboot, the cave has come back. It is the unflushable effluent. I do something similar, and I've had no problems at all since i set this up, I have two scripts running one after the other in my SCCM task sequence. First does this: TAKEOWN /F C:\Windows\Web\Screen /R ICACLS C:\Windows\Web\Screen /grant:r Administrators:F /T ICACLS C:\Windows\Web\Screen /setowner Administrators /T DEL /F /Q C:\Windows\Web\Screen\*.* COPY /Y "\\servername\share\Applications\Windows 10 1703 Lock screen settings\Lockscreen1.jpg" "C:\Windows\Web\Screen\img100.jpg" The second does this: 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* Not had any issues with that at all since i started imaging with 1703.
3s-gtech Posted August 2, 2017 Posted August 2, 2017 (edited) I did try your scripts - problem is they don't seem to be getting applied. I suspect it's a permissions problem - perhaps the script is failing to take ownership. Other parts of the policy are getting set - just not the bits to do with these flipping lock screens. It's actually fighting me at present - putting things back that I've manually deleted. I will beat it, even if it means flying to wherever that poxy cave is, sticking my logo on a piece of fabric there, taking another photo, and somehow putting that into our WIM. /maybe not ANOTHER EDIT: it's working again! Not entirely sure what's different - I essentially have two logon scripts that delete the content of C:\Windows\Web\Screen (because one just isn't enough it seems), one being your script and another being one that also clears the caches from ProgramData. When combined with GPP also trying to delete them, they go away and my custom background appears. I suspect it adds about 30 seconds to logon and it's a massive bodge, but whatever! Edited August 2, 2017 by 3s-gtech
DavR Posted August 17, 2017 Posted August 17, 2017 Hmmm, not sure if Microsoft have finally fixed this in August CU, or whether I've just hit on a lucky combination, but this is now working for me! I'm just getting ready to do a whole school rollout, and have thus updated my Windows 10 build with latest updates. Now, when I build from scratch with my up to date build, this setting works (although sometimes needs a reboot before it kicks in) and my chosen background shows. I can also use policy to flick between different backgrounds. Interestingly, existing workstations that I install August CU on to do not get fixed, they remain with the cave image. I can only imagine that the bug is caused by a corrupt cache, and the fix stops the cache corrupting (ie on new builds), but doesn't fix ones that are already corrupt (ie existing workstations). Like I say I may just have been lucky but thought I'd share my experience
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now