So, the first location is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree where the main list of tasks is stored. The SD key is the security descriptor for that task in binary format. Each task has an Id key that references the same key inside HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks and there you can see the security descriptor in SDDL format. If I were to modify both those locations, could I get management permission to disable tasks like Microsoft\Windows\UpdateOrchestrator\Schedule Retry Scan or Microsoft\Windows\DeviceDirectoryClient\IntegrityCheck? Or are there more places to check? Should I worry too about the content inside the files on c:\Windows\System32\Tasks\? Thanks in advance. BTW: I don't want to brute-force through this with RunAsTI, Nsudo or similar tools. Just an administrator account or common user with elevated permission.
Actual permission are applied to %windir%\System32\Tasks files those you need to modify to gain access NSudo bypass that and make it easier
In addition to what @abbodi1406 said, and from my mucking around with this, I suspect the hashes for the UpdateOrchestrator tasks are stored in those registry keys starting in 1809. In addition to Administrator not having permissions to the tasks requiring NSudo to manipulate, I suspect that's how the tasks are protected. So be careful and make backups before you change anything or you could get locked out of Task Scheduler. I stopped investigating any further because I remove permissions from the files the tasks try to run instead of manipulating the tasks themselves. I'll be very interested in anything more anyone finds out about this.
Thanks to both of you. I'll let you know what I end up doing but I don't want to delete/block files. I'd use that as a last measure (like in Cortana) because the eventviewer spam.
@cromulant please do report back on this. I never delete system files other than Windows Update Assistant files, but those are not system files, they're part of a contained mechanism separate from the Windows 10 subsystem. I enjoy the event viewer spam myself because it shows that Windows 10 is having a fit trying to force updates but it's 100% denied, and it's not trying and showing errors that often. But I would love to hear about success in disabling these tasks without causing event viewer errors. I think in your case that along with disabling these tasks, you'd also need to prevent the addition of any new UpdateOrchestrator tasks added by an update and that sounds tricky. I really wish that all of us working to defeat this kind of thing would work together and compare notes and make "the one method to rule them all." I understand the importance of different methods, but it seems as if everyone wants to work alone, and I respect that, but I can only imagine what we could all do working together. If I were rich I would hire all developers here at MDL to work on nothing but controlling updates with a slick interface that works on any version of Windows without fail. I already have a list of who I would attempt to hire. And i would not be in charge except for being in charge of finances, and I would pay well. And for any philanthropist(s) reading this, by funding this we could change the world for the better. Okay, I'll stop my grandiose delusions now. Carry on...
@Thomas Dubreuil if I want it to work on any install, and I do, I wouldn't know how to handle every third party firewall someone might use. The thing is, everybody is taking a different approach to this. The information is scattered all over MDL, including the firewall situation. I've attempted to put it all in one thread before, but it would be a full time job to keep it updated so I quit trying. The simplest method I've seen that would work on any version is symlinking "\Windows\SoftwareDistribution\Download" to a non-existant folder or drive, but then you'd open the floodgates by removing the symlink so you could update. And I'm not sure that would work if an update installed Windows Update Assistant (or something else bypassed it). I don't know. I can't keep up with it all. So any solution is going to be overcomplicated unless you tailor a solution to your specific situation, which is what everybody is doing. So I guess I'll just stick with my method, and everybody can stick with their method, and we'll leave it at that. I don't see any other way unless I win the lottery and can pay people to work together on this. And someone will respond to this and say "what about method x?" And it'll be something that's been discussed to death already (no disrespect intended to you). Every developer would have to read every post at MDL once a week to keep up with it all. Okay, maybe I'm exaggerating, but not by much. So yeah, it's overcomplicated to start with. The most recent thread I know of that discusses almost everything is here.
I understand, just trying to help here, but I'm just a beginner...And my reply wasn't very detailed. You don't need any 3rd party firewall (no one should ever need in fact), unless Microsoft compromises its own firewall... You just need to set your rule(s) and "lock" authorizations on HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy key (as WFC secure profile does)... Here's an example of how I use Windows Update (only when I want), using NSudo and SetACL, who knows maybe that would help? https://forums.mydigitallife.net/th...y-block-everything.64640/page-14#post-1492446 In short I use Code: SetACL -on "HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile" -ot reg -actn setprot -op "dacl:p_nc" -actn clear -clr "dacl" -actn ace -ace "n:SYSTEM;p:full" -ace "n:NT SERVICE\mpssvc;p:read" to lock and Code: SetACL -on "HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile" -ot reg -actn setprot -op "dacl:np" -actn clear -clr "dacl" -actn rstchldrn -rst "dacl" to unlock * with NSudo obviously. ** I'm on private profile but it's same command with \PublicProfile and \DomainProfile
You and I don't need a third party firewall, but that won't work for people using an internet security suite including a firewall or most third party firewalls, because they disable the windows firewall. So we're back to square one of solutions that only work for particular situations. The OP, @cromulant's idea of disabling UpdateOrchestrator tasks could be a part of a solution that works for everybody which is what I'm going on about. So far he hasn't done it, and I'm hoping he succeeds. Then he has to figure out a way to keep updates from installing new UpdateOrchestrator tasks. That'll be the hard part. I gave up on that since my method doesn't require it anyway, but I'm trying to help him out here. If I was only thinking of myself I wouldn't be wasting everybody's time by posting in this thread.