This is why I don't use the metered method. I really wish it were that simple. Windows still checks for updates with the connection metered and eventually forces updates anyway. I want complete control of updates, not partial control. Plus, checking for updates slows the computer down. I only want update checks like it used to be in windows 7 when you set it to manual. My script is the closest thing I've found to that. It will never check for updates unless I run the script. Besides my own computers, I have one computer 100 miles from me that I administer. In case an update borks it, I want people at the remote site that can do a system restore or whatever is required to get the computer working again. I have to coordinate that at the correct time; therefore, I don't want that computer to ever update until I tell it to update remotely with my script. So, in the future, just realize that I'm working towards the Windows 7 manual update model for any version of Windows 10. The metered connection solution doesn't meet that need, but thanks for posting it. Also, in case anyone is wondering, I'm not trying to stop updates permanently even though that's possible with the script. I always update when updates are available. And I can choose a convenient time to update, all at my complete control, just like I like it. That's what my script is all about.
Yes i agree, your script is closest thing to win 7 manual update method. you said "Metered connection eventually updates anyway" but in my one month using 1709 and one day using 1511 with metered it didnt install any updates, so i'm not sure how it may forced down updates.can you elaborate more on that. but as you pointed out slowing down of computer while update checking, i didnt thought about that and i'm not sure how much it affect the system.but in system there are tons of background and scheduled task, so i dont know how it can burden the system more compared to other task. but anyway my trust grew in metered method bcoz it didnt install any updates in 1511 and 1709 (both rtm release) even though 1709 said it may install some updates, but wu didnt found any updates worth to be installed even after six month of release of iso. I'm not trying to say that your script is bad and needs to be replaced, but i'm just trying to find the possibility of dealing with updates in more simple ways, while still i have full trust in your script.
I just downloaded v2.2.7, as I just heard about it approx. 15 minutes ago. It's found updates under "Installed", such as: Feature update to Windows 10, version 1803; I have 1803 installed, which I just did about an hour ago...so what is it..?! MSXML 6.0 RTM Security Update (925673) Security Update for Microsoft Silverlight (KB4023307) Update for Windows Defender Antivirus antimalware platform - KB4052623 (Version 4.14.17639.18041); This one failed under Windows Update itself, when I was doing a general update after installing Win10.But, it's not actually giving me the ability to install any of these, or am I doing something wrong..?!
Edit: I installed 1803 and everything you mentioned looks fine except for the failed Windows Defender update.
May 5, 2018 Script updated to v2.2.8 Updated for Windows 10 1803 Improvements since v2.2.7 Uninstalls and removes Windows 10 Update Assistant. Disables new WaasMedic components introduced in 1803 Changelogs here.
@pf100 hi , i uninstalled the script as i wanted to run the store , but i am getting this error Code: 0x80240438 and store applications are not downloading.
have you tried this: Command Used In Powershell: Get-AppXPackage | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
this is proper command. Get-AppXPackage | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
@Skunk1966, could you edit your post to show the proper command? It doesn't look harmful but someone might run it anyway. Thanks.