Sheridan

Hmm if thats the case I might try a complete fresh install of 1703 with the latest CU and then apply the group policies and see if that works. Applying 1703 as an update takes longer then reimaging anyway.

We use a locally copied file as the lock screen - worked OK in 1607. Our registry entries are correctly pointing to the local file which is why I haven't deleted them yet - did yours show the correct path/file before you actually removed them?

I applied KB4022725 as its the latest one after 4020102, maybe that breaks it again!

In the registry delete fix mentioned, the correct path to our custom lock screen is in there (GPImagePath) - is that how you found it? Even thought the path is correct and the file is there it still shows the MS default.

1507 and 1607 were good?!

Looks like its a 'No' then unless you're prepared to hack around with this mess of an OS, time to roll back to 1607 until 1903 or 2207 fixes the bug....

We updated some 1607 to 1703 and applied the latest CU, as soon as 1703 went on the default login screen/lock screen is back to the MS one and not ours. Its a well know bug and still seems to be unresolved. Did you install 1703 from scratch or an update? Sometimes that seems to make a difference.

I noticed that a test upgrade to 1703 and the latest cumulative update KB4022725 still haven't fixed the fact the custom lock screen shows as the default MS one and not your own. I know MS removed this option from Pro (out of pointless spite seemingly!) but we use Edu and its still broken. Every day a new 10 problem pushes my planned deployment further back.

Definitely something wrong with the firewall service - once you started it via the services.msc you can't stop it, short of restarting the PC, you eventually get a message saying it didn't repond in time.

Yup - this 1607 image is fully patched up! It looks like the firewall service isn't starting properly - at least not for around 10-15 minutes. You can see in the services.msc that the IP Sec service is stuck at 'starting' until the cpu usage drops, which implies the firewall services is hanging for some reason. We've tried disabling all other services but the problem appears as soon as the firewall service is re-enabled!

Its actually runs at high cpu even with the NIC disabled, or with the cable out. It must be a bug in W10 somewhere, we have used the same image elsewhere though and not seen this problem

I'd have to install Wireshark or similar on one of them to see whats going on with traffic - just looking at the windows details doesn't show much traffic across the NIC

Full removal of Sophos made no difference, as soon as the firewall was enabled the cpu rose to 40-48% and stays around there. if I wait at least 10 minutes it settles down to more normal levels. Bizarrely, one of the PCs in this group actually has a different NIC to the others, but shows the same problem. Thats thrown me as it doesn't point to it being driver based!

These are odd Marvell Yukon NICs - with the latest driver being 2012 as Windows 8.1. They seem to work fine, just not when the firewall is enabled!

Hmm disabling Sophos seems to have no effect. If you login with the Firewall service disabled, and then enable it the CPU usage shoots up and the firewall service cannot then be stopped, it takes a reboot to get the PC working again. I wonder if its a combination of W10 and the hardware.

We use Sophos, and like you disable its firewall settings to use the Windows firewall with GPO settings. We Sophos on the same hardware with no issues (although W7 admittedly) and various other W10 PCs running Sophos with no issue. Doing SFC probably won't make much difference, these PCs have recently been reimaged to try and resolve the problem, so they are basically a new install of W10. Oddly, on this set of PCs, Windows update doesn't work as it fails to download. If we enabled the firewall the PCs is unusably slow but the updates start to download! I might remove Sophos temporarily and see if it has any effect.

Odd one this - even for 10! On a set of 1607 (latest build) machines we've noticed initial logins taking a long time (>=5 mins) and it seems to be because the firewall service is clocking a steady 45-50% of the cpu. Now these are oldish PCs but worked fine on W7 and work fine when the firewall service is disabled. It seems to settle down after about 10 minutes - until the pc is rebooted and the usage racks up again. I can leave the firewall service disabled but its not ideal. The task manager shows the guilty process as Service Host: Local Service (No Network) which shows the four services, Windows Firewall, Diagnostic Policy Service, Coremessaging and Base Filtering Engine. Out of those you can only really stop the firewall and it doesn drop the cpu right down to 3-6% usage on idle, bring the logins back down to the sub minute level which is acceptable for this age of machine. I've tried several different network card drivers and it seems to be the same result. Odd.

I'd never noticed that policy before! Thanks! Getting them weaned off flash is the better plan longterm but a lot of sites are slow to change.

With Chrome now blocking flash support unless you manually whitelist sites I'm wondering how everyone is going to handle this. Are you simply letting the block affect all sites, or allowing users to unblock sites themselves? We don't allow users to change Chrome settings, so they couldn't unblock a flash site unless we change that policy, or is there a way of maintaining an 'allowed flash sites' for Chrome through group policies perhaps. I know flash is a troublesome nuisance like java, but educational sites still use it a lot.

Another bug for the W10 pile maybe. When we change the driver on our Server 2012 Print Server, the W10 clients (1607 and 1703) don't change to the new driver. No errors seem to be logged they just simply ignore the change. W7 PCs detect the driver change and download the new driver. The printers are deployed using GPO Computer preferences - deleting the printer and rebooting the PC seems to be the only way, not exactly an ideal solution. Another example of something that you can't rely on anymore.

Actually - correction, once you do this WSUS is completely broken, even uninstalling it and reinstalling doesn't work. Only a reinstall of the server! Otherwise you will get stuck on the http error! Time to bin WSUS and just use home updating methods I think

After setting up SUS on a 2016 server (I know, I'm a sucker for punishment!) I realised that it was still dhcp, so I set the lan card to a fixed IP. Oh Oh, bad idea, WSUS is now broken! It can't synchronize any more and after much searching around it seems a full uninstall and reinstall of wsus is required. You can really tell 2016 server is based on W10! So beware changing ip or lan card after wsus install, it breaks it!

Maybe I should just wait for Windows 11!

And my 1703 personal PC just gets the error 0x8024401c every time I try to check for updates - not even using WSUS!

Our base image is 1607 build 1198, or the 1703 more recently. Neither will download updates from WSUS on our Server 2012, the usual 0% downloading at the client and missing/failed updates showing in WSUS. At this point I think reimaging every year is more realistic than fixing the updates, I haven't got the time to waste on fixing the ever growing list of bugs on this crappy OS.