Very relevant discussion for me, I cringe at the future of Windows. At this point I ~can~ do what I want through various means, foremost using an enterprise version. I'm sure there will come a time when even that does not provide the means to take Windows where I want. Right now with LTSC 1809 I'm running into problems getting access to some things. At this point I only see a wall at the end of the tunnel and no way forward with Windows.
If you look at what you've quoted from my post you know I explicitly referred to kernel modifications and attacks on ring-0 processes. The topic is bypassing protected processes, the suggestions at first post are about boot chain modifications (bootloader) or even kernel modifications. It's not just about to switch off some services....M$ has no other choice than to consider such approaches as applying 'malware'...even KMS solutions are indicated as malware by any AV.... At the time where some others tried to come up with an alternative method to activate windows vista (that time we've focused on BIOS mods, Daz loader and KMS solutions did not exist yet) people crippled the OS (remove WAT or chew WGA) in a way that the issues prevailed over the 'success'. What I do not want are approaches which come with deep impacts on the system (kernel / bootloader or whatever)....also a 'solution' which can be reversed after each OS upgrade is not the right way... To control WUs in a reasonable way comes with huge efforts. Saying that I mean the decision which WUs to install and which not. You need security fixes, but they might come with additional stuff you do not want. When I've switched off WU on w7 I firstly checked which WUs did come through WSUS at the company where I work. The admin who administrates WSUS has a reasonable concept so I thought I could take benefit from his work just installing the same WUs at home only... Later then I did not install any WUs anymore and I have left windows as my major OS... With LTSB there are only a few security related WUs....IMHO no need to control them, but only here. This does not apply to the home and pro versions....
I understood your thought well, and my answer would be for all OS changes, not just the protected services. Health check, once a week I find it excellent, it is necessary to sanitize the corrupt OS without worrying from which side and with the intent of corruption. It will always improve more and more. There are ways to register Windows which do not bother security. From your writing I understood that you do not use Home and Pro from which it comes that you are not for all informed. As you do with Win7 (control WU) you can do it with all the following Windows, even Home and Pro, it can be applied very easily without patching OS. I'm tired of repeating, it resembles a teaching of the deaf.
I actually have agreed with that. Furthermore I said THEY (WUs) need to be controlled on w10 home and pro. It's a misunderstanding. "This does not apply to the home and pro versions" Means: Whereas WUs for LTSB are mostly security related (I wrote: but only here) the need to control WUs is not that important; THIS (less importance to control them) does not apply to the w10 home and pro versions, though. P.S.: I am underlining the important part of my previous post.
I am underlining the important part too. If you do that as described here Control Windows Update you can control WUs how you want on the windows you want.
I'm only replying to this since I got an alert a comment of mine was tagged, and not because I use ToolKit: The method I personally use that has not resulted in this flag being tripped is by using the default Win32 APIs (DISM, specifically) for full core component package removal because the procedure the API takes - it allocates the entire file structure of the component, which includes any side-programs that utilize the component, into a "component heap." It then maps the entire file structure of the image, minus the "component heap" to a temporary location. Following this, the DismOpenSession command is issued which prepares for the removal of the component by allocating registry keys associated with the component targeted for removal. Finally the DismDelete command is issued which removes the component and any of its associated executables. It does this all while the integrity of the file structure is monitored. Once the removal is complete, the command DismCloseSession is issued and (is no integrity violations occurred) applies the changes to the file structure mapped that was saved to a temporary location. I use this in conjunction with Wimgapi to ensure no integrity violations occur. The DISM command-line cannot do this, though if you look in your DISM.log after running a handful of command-line DISM commands, you will see it has some of these API features included; however, Microsoft does not intend the end-user to remove core components that have a permanency value set as "Permanent" (which is where these problems arise from). **EDIT** Another method is to change the permanency value in the component packages' associated XML file from "Permanent" to "Removable." I cannot guarantee this method as working across all component packages, though, but the packages I have done this to, and then removing the package using command-line, has not tripped the "STATUS_SXS_COMPONENT_STORE_CORRUPT" flag. I must state, though, I have NOT used this process with major core component packages because this is still a workaround and not a solution to the problem. Here is a significantly more detailed description of how I check for these errors, etc.: [DISCUSSION] Windows 10 Enterprise (N) LTSC 2019
Yes, I realize in Windows 98 I could do everything as Admin. Staring with XP, and especially in Vista, "admin" wasn't really "admin" anymore and I had to do extra steps to jump through more hoops in order to get back to the real "admin" mode that I had in prior versions of Microsoft OS. Then with Windows 7, it was locked down even more, and some services could not be disabled etc and some files couldn't be deleted. It got way worse in Windows 10 when a LOT of the exact same named services that could be easily disabled in Windows 7, would REFUSE to be disabled or even stopped in Windows 10, regardless of whether or not one was running as "full admin" etc etc... I also noticed some alarming and disturbing changes from Windows 10 LTSB 2016 to now the new Windows 10 LTSC 2019, including more things that are locked down, more things that cannot be disabled or removed, and even virtualization (VMware workstation for example etc) usage is defacto disabled unless one makes changes in gpedit and disabled Device Guard and uninstalls the HyperV that ships with 1809 (2019)... etc It is for these and other reasons that I've decided that enough is enough and stayhing on the Windows 10 LTSC 2019 (17763.195) basically "forever" and never using another newer version of Windows or Microsoft OS ever again.... [it won't let me post a link as a newcomer] I will quote my own text posting in relevant part: " The reasons LTSC 2019 is preferrable to LTSB 2016 are many fold, but not least of which, the latest Nvidia real-time ray-tracing demands the October Windows 10 update (included in the LSTC 2019) with addition to the Direct X 12 that includes the DXR for ray-tracing that will never be back ported to earlier versions of Windows 10 (LTSB etc) and also other things like Deep Learning and Windows 10 Machine Learning (ML) that again are only available on LTSC 2019, and will never be available on LTSB 2016. Other reasons that make LTSC 2019 more ideal are the fact that Microsoft is not supporting latest gen CPU Processors on the LTSB 2016 version, as it purposefully decided not to backport cpu microcode updates to the 2016 version, instead opting to put them in current/next versions of LTSC. Meaning to run newer processors like the 9900k, one has to be on the 2019 platform as opposed to the 2016 platform... It is now basically 2019, and there is only 19 years from today to 2038 (when LTSC 2019 stops working and hits a hard crash) and while 19 years seem like a long time, my originally intent was to use LTSC 2019 for longer than that. Some companies in some industries are still running Windows XP and if you think about it, that is the same span of time we went from debut of XP to today, vs today to 2038 when LTSC 2019 gets killed off.... Many things in desktop PC computing have lead me to believe that technology has matured at least on the end-user client desktop pc computing front, the XP -> Windows 10 is we went from 32 bit to 64 bit, we never need more than 64bit in terms of addressable memory, this isn't like the good old days of going from 4 bit to 8 bit to 16 bit every few years... math of exponential growth dictates that 64bit will be the last. Same for the going from ipv4 in XP to ipv6 in Win10, there will never need to be a larger address space than ipv6, ever.... And same for DirectX12, most games are still running best and optimized for DirectX11 (XP only supported up to DirectX9c etc) and in truth, I forsee DirectX12 in its latest form/variant (with the October DXR updates) to lasting forever, certainly for PC gaming and 3d applications on the Windows platform goes, I can't imagine anything mainstream ever mandating anything more than DirectX12 (w DXR) in the long term future, esp even today there are virtually zero applications or games that FORCE you to use DX12, as most/all fully support DX11 etc. So is there really no way to keep using LTSC 2019 after 2038? If so I might have to learn linux and come up with a plan to migrate my main computing to Linux by then, leaving only an offline airgapped Windows 10 LTSC 2019 for offline gaming only (with a fake date) after 2038... As a side note, today Steam has finally stopped supporting Windows XP, so everyone playing Steam from tomorrow onwards will need to be on Windows Vista or newer OS. For various reasons Windows 10 1809 is a good-enough "stopping point" for me. I grew up with Windows 95 era and I remember when XP first came out I told myself that 98 was going to be my last version of Windows, and then said the same thing for XP when Windows Vista/Windows 7 came out, and then said the same thing for Windows 7 when Windows 8/8.x/ and later Windows 10 came out... But this time is different, Microsoft said Windows 10 was going to be the last/final version of Windows, so its just matter of choosing which LTSB (now LTSC) platform for rest on and lock in to. DirectX12 is still a mess (not even talking about the gimmick that is DXR right now in its current form) and who knows maybe nvidia's pitch of real-time ray tracing will go the way of its PhysX or who here still remembers the much pitched but spectacularly failed VXGI initivative (a low-res real-time ray tracing that debuted with GTX 980 and precusor to Nvidia's current pitch for ray tracing) so if in the future five years down the road I can't use newer versions of DXR because I choose to still stick with LTSC 2019, then I'm fine with that decision... by then I will be in my 40's and too old for gaming anyway. I understand it is only "supported" until 2029, but there is a difference of when something is "supported" and when it still can be used. For example XP lost any official Microsoft "support" long ago, and yet its been working on Steam gaming and only just tomorrow it will not be supported by Steam but many industries still use XP systems in their silo'd or airgapped systems and will continue to do so in the forseeable future. Imagine taking the same analogy of XP situation and apply it to Windows 10 LSTC 2019 situation; in 2050 when it is no longer "supported" at least without this activation issue it could in theory still be used (not recommended of course, but the option is there if the hardware exists that still runs it, or say in a VM which doesn't even run into hardware issues etc) but with the cutoff of 2038 even in a VM I won't be able to launch or effectively use Windows 10 1809 past 2038; but even in 2050 I can still spin up a Windows XP iso and run XP in virtual environment. That is the difference I'm talking about here, not the fact that it probably would be better to upgrade to a newer version of Windows 10 post 2038 (which is matter of opinion)"
You can still use Windows with default Admin account (with SYSTEM rights I guess), though I wonder, what consequences would be, since I have not tried it in a long time.
I just activated the hidden superuser account and use that. American companies don't believe in personal responsibility. They are used to dealing with people who don't blame themselves when they do something stupid. Its always Microsofts fault if you accidentally delete system32 System gets locked down to protect users from themselves.
I agree that the vast majority should not muck around with the Windows 10 subsystem. However; you just described the IOS model of system integrity which is basically the whole point of this thread. I have 3 jailbroken iphones and I play around in the IOS file system and haven't broken anything I couldn't fix so far. I can make IOS 8 think it's IOS 12 (not a good idea by the way, and don't try this. Ever.) Try to delete or alter any system or plist file on an un-jailbroken iPhone. It's literally impossible unless you're an exceptional genius that finds an exploit which is (sort of) the way Windows 10 seems to be heading. The iPhone has a secure bootrom which prevents tampering. Your computer however does not, so coming up with a "jailbreak" for Windows 10 would be about a thousand times easier than finding a bootrom exploit for an iPhone. But I should have the choice to "jailbreak" Windows 10 so that I can delete any thing I want to. It's my computer and no one else's, and no matter what Microsoft says, it's my operating system that I paid for (cough). If I want to delete or alter a system file to make the system work better for me, or make a permanent change to a registry setting, or make a permanent change with GPO that actually works and stays the way I set it, I should be able to do that. Go ahead, try to stop driver downloads with the GPO setting that stops driver downloads. I can do that with my script now, and I'd like to continue to be able to selectively and carefully modify Windows 10 in the future. The whole point of my rant, and this thread, is that I want to do whatever needs to be done to tame this unweildy beast of an operating system called Windows 10. It's not to discuss why we shouldn't do it. The general public shouldn't be able to do it "for their protection", but I should be able to. See what I mean?
Speak of the devil, the protected process carnage has begn with my script. Warning: if you're using my script, do not install KB4471324 (17134.471) or you'll trash your system. Either that, or uninstall the script for now. More info here.
What about a program that blocks it from a ip address level. That way no data from microsoft can come in. Since its a non-microsoft program, it is not subject to modifications or tampering from windows like host files (host files can be bypassed because its part of windows ) No registry hacks No processes touched
Thinking "Out of the Box"... PS @pf100 - your tool looks great, I will try it today on fresh 19H1 install... This probably was suggested already but I didn't read the whole thread. I think this needs to be done externally via specific rules in the router, use of DD-WRT, Open-WRT flashing of the router and custom ruleset. For Ethernet connection perhaps we can kickstart / build a tiny little "Windows Update Disabler" device, basically run your traffic through the device and it will "Null Route" any requests to Windows Update Servers. More advanced version can perhaps be a stateful device that sniffs/decodes the HTTPS stream and "rewrites" any requests for specific windows updates to say "No Update Needed" (This is in case Defender Updates comes through the same channel and it needs to differentiate). Just my EUR/GBP/USD 0.02
This can be major pain in the ass because MS could add dozen more redundant IPs/routes in each CU and you'll have to endlessly identify + update the ruleset, if one of the IP is routed to major CDN that host millions IPs you'll be screwed. And you can't do this once you are in a shared networks such as airports, cafe or Uni. The ideal now is prevent WU processes from running on devices so it is safe for any network access at any time until the user allows WU to run, i personally can't see a better option than that. But one thing i know there will always be a way to counter future WU reinforcements.
Have you been on the moon for the last few years? People have been playing whack a mole with ms telemetry for the past few years anyway, its nothing new.