It's still ENTERPRISE buddy, just configure Group policies correctly (additionally set Ethernet to metered). No need for any additional tools with any Enterprise or Education edition . I even needed to disable the metered connection to be able to enable Developer Mode, with metered on it failed the download .
With Group Policies configured this is only additional measure and not really needed, especially on LTSB/C.
Just switch the "Rem" at the start of two lines near the end of the script to switch between WUMT & WuMgr (WuMgr needs to be in same folder as script). See @pf100's post at https://forums.mydigitallife.net/th...ows-update-service.72203/page-41#post-1470993.
I'm very close to the next script update since I devised a way of disabling Windows Update Assistant without having to run the script again after every update and without having to make a dummy folder in the root directory of C:/ (%systemdrive%\Windows10Upgrade\). No version of the script as of 2.5.4 makes dummy folders, but the next one will make two dummy folders, %systemroot%\UpdateAssistant\ and %systemroot%\UpdateAssistantV2\ used by Update Assistant (files in one these last two folders, depending on your version of Windows 10, are what creates the first folder I mentioned), and will lock them so the system can't read from or write files in these folders. That will prevent Update Assistant from being created, installed, or ran through an update. Plus, there are lots of other improvements that won't be visible to the user. There are going to be script users that don't uninstall the old script before installing the new one, and if you go straight to 2.5.4 from 2.5.3 running 1809, users will have a bunch of renamed system files that 2.5.4 won't automatically restore the original file names unless you uninstall 2.5.3 first, so I'm going to rename them back to the original file names in the script 2.5.5 itself so uninstalling first isn't necessary. It looks like I'll have to add some timeouts to the initialization of the script because I'll be, in this order, 1) renaming up to 10 system files back to original file names for those upgrading from 2.5.3 to 2.5.5 (then a 2 second timeout for FOR command to finish, 2) removing permissions from those same system files as TrustedInstaller with Powerrun (then another 2 second timeout for the same FOR issue), 3) renaming any system files that couldn't be locked. This last, number 3, is only a failsafe "just in case." The reason I say "just in case" is because without the fallback system file renaming for ones that couldn't be locked, 2.5.3 wouldn't have worked in 1809. That was an accidental success, and one that could keep the script working even if the ability to remove system file permissions is removed from Windows 10 (not likely, but I like to be on the safe side). That would give me time to investigate and update the script without having to push out an emergency script update. And for any batch script gurus reading this, batch script is supposed to be linear, one line is read and executed, then the next and so on. But I've found in practice this isn't always the end result. I have to give a complex FOR command time to finish and using timeouts work to achieve this. Changing the Windows Update service sometimes requires a timeout to let the command finish. If you want any more information on this I'd be glad to give detailed examples. About open source, I've been waiting on NSudo to hide command prompts but there are still issues with it, so it looks like I might have to use closed source Powerrun again like 2.5.4 does now (In 1809 system file permissions have to be removed as TrustedInstaller). As it is now, NSudo pops-up up to 10 ugly flashing command prompts when it removes permissions to system files, and Powerrun hides those prompts. Windows Update Blocker (WUB) v1.0 may as well be open source because I know exactly what it does in detail. The only thing I don't like about WUB v1.0 is that it manipulates the now useless "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" key's "NoAutoUpdate" dword value, but that doesn't hurt anything either so it doesn't matter. It still locks the Update service reliably, so for reasons I mentioned previously it'll be the last thing in the script that I replace with something open source. I could do the same things WUB does with commands, but WUB v1.0 really makes things convenient for me and I don't see any good reason to stop using it. And about WuMgr, I've been waiting on that until I see no more issues like this. But it looks like the bugs have been worked out enough that I can use it in the next script version. I will still include WUMT in the next version and provide the option to edit the script's cmd file to switch to WUMT just like the option is there to switch to WuMgr now. I was toying with the idea of creating an option to choose between WUMT or WuMgr in the script, but haven't decided if that's needed. A menu with the option "You're about to check for updates, do you want to use 1) WuMgr or 2) WUMT. Maybe it would be a good idea, I don't know, so I'd appreciate any input on that. I do want to give the option to choose, at least through a simple script edit like I'm doing now. I don't like putting a time frame on when the next release will be (v2.5.5), because I keep hoping NSudo (open source) will be updated but I've been waiting on that for a while now and am not going to hold a release any longer since Powerrun (closed source) is working fine. Maybe v2.5.6 will finally use NSudo, or maybe NSudo will be fixed tomorrow and it'll make it into v2.5.5. But 2.5.5 should be out in about a week or so but that's just a guess. 2.5.5 will be a superior script to 2.5.4, but it'll really do the same thing 2.5.4 does now except it'll permanently kill Update Assistant (until you uninstall the script), with some additional checks for renamed system files correction that is accomplished in 2.5.4 by uninstalling 2.5.3 first. So to repeat, 2.5.3 only renames system files in 1809 where 2.5.4 properly locks them. 2.5.5 will intelligently handle any remnants of the effects of 2.5.3 if it's not uninstalled before using a higher version script. It's generally always a good idea to uninstall the script before upgrading to a newer version, but you don't always have to, and I always try to make it clear when you have to uninstall before installing or using a newer version.
pf100, thank you for your in-depth explanation and information, very educational. I think that option is a very good idea, if it is not too much work to accomplish, it seems the wumgr will be a continueing development like the Wrapper Script. I notice that the MajorGeeks website has a note to un-install previous versions, but I did not see that important note at the Softpedia website. Are there other websites to download the Wrapper Script? Again, thank you for your continued development of this fine tool.
First, thanks again for all the work and fine tuning you do in this script. Concerning uninstalling previous scripts: Edit for clarification: It might not be readily evident that an earlier script was run and needs to be uninstalled if it was run manually and if you're dealing with multiple computers. Until you put the option to use either WUMT or WuMgr in the script, I was installing the script into the Windows Start Menu, which was my preference rather than running it manually. But to use WuMgr, I had to edit and run the script manually. Well, when it's in the Start Menu, it's easy to run, to know that you've got it and have been using it, and . . . gosh, there's the uninstall option right there. Why might I not remember that I was already running a previous version? I've got six computers, but I've had to lock down only three from feature updates to keep them working. Only recently did I start using the script manually on computers that haven't had update problems. So did I already have 2.5.3 on this computer before running 2.5.4, or not? To be safe, I ran the uninstall script anyway, but if uninstalling wasn't necessary (or was somehow automatic), that would be cool. I vote for an option to choose between WUMT or WuMgr, and I'd like to see it in installation version. However, that choice could be presented during the setup process, and whichever is picked would be used for the duration of that installation. It would be simple enough to uninstall and reinstall with the other choice. However, the decision to choose each time a check for updates is made would make it easy to compare WUMT and WuMgr for those who are continuing to evaluate and help improve WuMgr and fight the good fight.
this is what i actually try: cd /d "%~dp0" && ( if exist "%temp%\getadmin.vbs" del "%temp%\getadmin.vbs" ) && fsutil dirty query %systemdrive% 1>nul 2>nul || ( cmd /u /c echo Set UAC = CreateObject^("Shell.Application"^) : UAC.ShellExecute "cmd.exe", "/k cd ""%~dp0"" && ""%~dpnx0""", "", "runas", 1 >> "%temp%\getadmin.vbs" && "%temp%\getadmin.vbs" 1>nul 2>nul && exit ) takeown /f "%WINDIR%\System32\UsoClient.exe" /a icacls "%WINDIR%\System32\UsoClient.exe" /inheritance:r /remove "Administratoren" "Authentifizierte Benutzer" "Benutzer" "System" %windir%\system32\shutdown.exe -r -t 0 found the elevation part here @MDL !! greetz! PS: ineffective..... next, i sheduled a daily tortue and dishonoring of micros**t winblows ten in addition to an overkill TI disabling ALL tasks with one klick (execTI + ccleaner, mhh, also zero effect.. but nice to look at removing the same packages again ;-) even staying offline will soon be no longer a "solution", take a look at techno progress
@pf100 hi i have a question... RS5 is giving me some issues and i am running "sfc /scannow " ... do i have to uninstall and reinstall WU wrapper script again after this process completes?
The FAQ says to expect SFC errors if you haven't uninstalled first. But if you're concerned that SFC might "fix" the files that the script is protecting you from, uninstalling and reinstalling takes only about 2 minutes. A3. How can I be sure that installing the Wrapper Script won't mess up my system? I've read comments that it makes changes that cause errors in the System File Checker (SFC) results. SFC errors are caused by locking update hijacker files. The included uninstaller undoes script changes and leaves everything like it was before you ever used the script. (Use the "Uninstaller_undo-all-script-changes.cmd" to undo all script changes whether you run the script in the portable folder or install the script into your Windows start menu (it's the "Uninstaller - undo script changes" shortcut in the start menu.)) The wrapper script causes SFC errors because it makes update hijacker files unreadable. The errors go away after uninstalling the script. So if you want to run SFC, uninstall the script first. Or when you read the logs produced by SFC, recognize that there should be errors for osrss.dll, UsoClient.exe, WaaSMedic.exe, WaasMedicSvc.dll, WaasMedicPS.dll, WaaSAssessment.dll, MusNotificationUx.exe, and SIHClient.exe.
@pf100 hi i dont know wheter you take feature requests incase you dont sorry incase you do could you integrate an option to shut down after updates have been installed because it can take very long sometimes and having to wait by your computer can be very annoying. (would be great if it would run the script automatically again before shutting down to disable windows updates again so i dont have to remember it when i turn the computer back on the next time) also: great program ! without this win 10 home is completely unusable. thanks so much for sharing.
@Lars220 I submit the wrapper script to Major Geeks and Softpedia only. Softpedia does their own review. Major Geeks more or less posts what I tell them to. If it's available for download at any other site, I didn't put it there. @Whistler4 I put the version number in "version.txt" in the script folder, plus the version is at the top of each txt file in the script folder, and when running the script shows the version in the command prompt window title, but I might be able to make the script version more obvious and will look at ways to do that. If you have any ideas on how I could make it more obvious, please let me know. @app_raiser As you found out, what you're doing will not work in 1809. icacls has to be run as TrustedInstaller with NSudo or Powerrun or whatever. Doesn't work: Code: icacls "%WINDIR%\System32\UsoClient.exe" /inheritance:r /remove "Administratoren" "Authentifizierte Benutzer" "Benutzer" "System" The code below is how I do it in script 2.5.4 (I actually use a long list of files in a variable using a FOR command to remove permissions, but this is the command I use to remove the permissions you're trying to remove for usoclient.exe) This works: Code: ::set correct version of powerrun as %prun% for x86 or x64 wmic cpu get AddressWidth /value|find "32">nul&&set prun=PowerRun.exe||set prun=PowerRun_x64.exe ::Remove permissions from usoclient.exe "%prun%" /SW:0 "%systemroot%\System32\icacls.exe" "%WINDIR%\System32\UsoClient.exe" /inheritance:r /remove *S-1-5-32-544 *S-1-5-11 *S-1-5-32-545 *S-1-5-18 @olafbobinski Yes, I take feature requests. Shutting down after update, let me think about that. And to everybody, I see I got more requests to choose between WUMT and WuMgr while running the script, but I'm thinking I'll just switch to WuMgr and leave the option to edit the script to use WUMT. WUMT does what is needed in the script, but I can't disable the options in the lower left like I can in WuMgr. Also, WuMgr registers Microsoft Update and WUMT doesn't. So for those reasons, WuMgr is superior to WUMT. WUMT has more language translations though, but I don't want to wait until WuMgr has as many translations as WUMT simply because that may be a year from now. I think WuMgr is stable enough now for mainstream use. Any more thoughts on the whole WUMT vs WuMgr thing would be appreciated. Also, NSudo just got an update so I'll be testing that and if no problems it will replace Powerrun in the next version.
What you're doing to identify the script version is just fine and needs nothing further. (I also tack the version number on the zip filename when I download it so that it unzips into a folder with version number.) My point was that I don't think I can be positive that I've got the script installed if I haven't used the Windows installation method, so I prefer that over the manual script. The reason is that I uninstall, experiment, maybe forget to reinstall. I could've been more clear, without rambling about version numbers. Sounds like you're going to switch to default WuMgr, which I'm trying to use regularly, and I'll be able to use the Start Menu installation again. I'm okay with not using WUMT as default in the script, and you plan to allow the script to be edited to make the choice: good enough!
Hi pf100, I have 1803 and I am using your old script to block all the updates. Reading the posts I understand that you are still working on a script for 1809. I understand that WUMT has still some problems with 1809. Can you confirm.... the posts are very confusing
The script has worked with 1809 since it's original release. 2.5.4 works with 1809. There's not a problem. The various discussions are mostly about using open source as much as possible.
@pf100, just one interface suggestion: The uninstall window asking whether you want to open network connections forces me to study it each time it opens. What do you think about rearranging it in this fashion? WUMT Wrapper Script Uninstaller If you continue, and have no other method of controlling updates, UPDATES MAY START RIGHT AWAY. DISABLE THE INTERNET FIRST? Press (Y)es or (N)o If you select (Y), "Network Connections" in the Control Panel will open so you can temporarily disable your Internet connection. Whether you select (Y) or (N), the next script window will stay open allowing you to fully uninstall the script and all associated changes that were made when you first ran the script.