Guide: Optimized Image

[xShARkx]

Here's my previous discussions (link1, link2) on power overrides, but the gist of what's happening is that Windows automatically adds up to 4 different registry keys in multiple places, depending on the power capabilities of the hardware in use, when the operating system is first installed.

The tweaks will show up as one of the following key names in Regedit:
- OverrideACSettingIndex
- OverrideDCSettingIndex
- ProvACSettingIndex
- ProvDCSettingIndex

When these keys appear in the \Power\ branch of the registry, they act like a group policy and take priority over the user's settings as well as the operating system defaults. To stop that behavior, simply delete any keys with the names shown above and the operating system will go back to using the values from the standard keys that are labeled plainly as "ACSettingIndex" and "DCSettingIndex" without the "Override" or "Prov" prefixes.

Thank you very much!

One last question, is it safe then to add these to prevent the unwanted behavior:

"OverrideACSettingIndex"=-
"OverrideDCSettingIndex"=-
"ProvACSettingIndex"=-
"ProvDCSettingIndex"=-

To any setting that is using "ACSettingIndex" and "DCSettingIndex"?

Like:

; Start > Windows System > Control Panel > Power Options > Change plan settings (High performance) > Change advanced power settings > Hard disk > Turn off hard disk after > Never
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\0012ee47-9041-4b5d-9b77-535fba8b1442\6738e2c4-e8a5-4a42-b16a-e040e769756e\DefaultPowerSchemeValues\8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c]
"ACSettingIndex"=dword:00000000
"DCSettingIndex"=dword:00000000

Or:

; Start > Windows System > Control Panel > Power Options > Change plan settings (High performance) > Change advanced power settings > High performance > Require a password on wakeup > No
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\0E796BDB-100D-47D6-A2D5-F7D2DAA51F51\DefaultPowerSchemeValues\8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c]
"ACSettingIndex"=dword:00000000
"DCSettingIndex"=dword:00000000

Because I saw that in the "Automate.reg" from the links you provided that you added these to the power button and lid settings, but since there are more settings using "ACSettingIndex" and "DCSettingIndex", I wonder if I should add those 4 keys to these as well (to prevent unwanted behavior from windows depending on machine in every power setting I changed and that is using "ACSettingIndex" and "DCSettingIndex").

 

[Hellbovine]

Safe depends on what the tweak is. I've only tested it on a desktop and a laptop I own, but so far it's been safe for me to delete all the "Override" and "Prov" keys that are generated later by Windows. Each registry path contains information about what the keys do if you want to manually read through them before deleting any, and additional information can be gleaned by comparing power branches to the user interface of the control panel too.

A tweak with a value of =- is telling Windows to delete anything that exists for that key. In this power scenario, Windows doesn't start with the "Override" and "Prov" keys inside the default registry, but are dynamically generated during the installation of the operating system. While preinstalled keys can be deleted using =- in an integrated registry file, the problem here is that these overrides are created after that process tries to delete them, so the overrides still get added. In cases with timing issues, NTLite's post-setup (After Logon) feature avoids that by executing things at a later time.

 

[xShARkx]

Safe depends on what the tweak is. I've only tested it on a desktop and a laptop I own, but so far it's been safe for me to delete all the "Override" and "Prov" keys that are generated later by Windows. Each registry path contains information about what the keys do if you want to manually read through them before deleting any, and additional information can be gleaned by comparing power branches to the user interface of the control panel too.

A tweak with a value of =- is telling Windows to delete anything that exists for that key. In this power scenario, Windows doesn't start with the "Override" and "Prov" keys inside the default registry, but are dynamically generated during the installation of the operating system. While preinstalled keys can be deleted using =- in an integrated registry file, the problem here is that these overrides are created after that process tries to delete them, so the overrides still get added. In cases with timing issues, NTLite's post-setup (After Logon) feature avoids that by executing things at a later time.

Yeah, it did not work rip

I've applied the following file to my iso, but the same motherboard which had given me the problem, it happened again... After installing the iso, went to the power button settings, and it was set to sleep, not power off.

Do you see anything wrong with this file?

 

[garlin]

Do you see anything wrong with this file?

; Hidden > Power Plans > Reset all plans to default settings
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power]
"SystemPowerPolicy"=-

3) The Power\User tree is where all of the user modifications live. So for example, if we open that advanced power control panel and then change disk timeout to 5 from the default 20 it will save our change inside this tree. Now, if we go click the "restore defaults" button it relies on the keys from Power\PowerSettings to overwrite our changes. There is also a "SystemPowerPolicy" key which is essentially a config file that stores our current modifications as a value, and if we delete this key's value it also resets our plans to defaults.

 

[Hellbovine]

After installing the iso, went to the power button settings, and it was set to sleep, not power off.

Using NTLite's "Registry" menu to specifically integrate deletions for "Override" and "Prov" keys won't work due to a timing issue. I mentioned that in the last reply, where I was saying the deletions have to be moved to post-setup, because these override keys are dynamically generated during the installation of the operating system, so NTLite fails when it tries to delete them from the installation media, since the keys do not exist yet. There's many ways to solve this, but my suggestions are below, until I find a method that prevents overrides from generating at all.

Option 1: Use NTLite's post-setup to run a .reg file which deletes the various overriding keys. I attached an example file. This same file can also be used on a live desktop to fix the registry without a reinstall of Windows. No post-setup parameters are needed if using the "After logon" option.

Option 2: Use NTLite's post-setup to run a powershell command that loops through and deletes the overriding keys. The command can also be ran on a live desktop to fix the registry without a reinstall of Windows. Garlin provided the powershell script (link) that does this.

 

[xShARkx]

Using NTLite's "Registry" menu to specifically integrate deletions for "Override" and "Prov" keys won't work due to a timing issue. I mentioned that in the last reply, where I was saying the deletions have to be moved to post-setup, because these override keys are dynamically generated during the installation of the operating system, so NTLite fails when it tries to delete them from the installation media, since the keys do not exist yet. There's many ways to solve this, but my suggestions are below, until I find a method that prevents overrides from generating at all.

Option 1: Use NTLite's post-setup to run a .reg file which deletes the various overriding keys. I attached an example file. This same file can also be used on a live desktop to fix the registry without a reinstall of Windows.

Option 2: Use NTLite's post-setup to run a powershell command that loops through and deletes keys of, OverrideACSettingIndex, OverrideDCSettingIndex, ProvACSettingIndex, and ProvDCSettingIndex. The command can also be ran on a live desktop to fix the registry without a reinstall of Windows. I don't have a command to post right now, so if anyone else wants to take a crack at it I believe the only path that needs to be searched is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\

Yeah, sorry, I completely missed that on your last reply and also that key that reset's the power plan to default which was still on my file.

Do I need to add any parameters to the post setup reg file?

 

[Hellbovine]

When no post-setup parameters are specified, NTLite will just run the file, the same as if a user double-clicked on it from a live desktop. Parameters are typically needed more in the "Before logon" section of post-setup, since without silent parameters there it can prevent Windows from installing (reports of spinning circles and hangs, etcetera). Use the "After logon" section of post-setup and it should work without any extra steps.

The tweak you mentioned which resets power plans to defaults won't directly harm or help what we're trying to solve here, so it's a non-issue, because that reset has no bearing on the creation of the "Override" and "Prov" power plan keys, regardless if they existed before or after the reset. However, it's always the best approach to only use tweaks that are necessary, so I recommend deleting any tweaks you don't need and it will make working on computers much easier overall, since the number of variables are reduced, which means the number of potential issues decreases too.

 

[garlin]

Option 2: Use NTLite's post-setup to run a powershell command that loops through and deletes keys of, OverrideACSettingIndex, OverrideDCSettingIndex, ProvACSettingIndex, and ProvDCSettingIndex. The command can also be ran on a live desktop to fix the registry without a reinstall of Windows. I don't have a command to post right now, so if anyone else wants to take a crack at it I believe the only path that needs to be searched is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\

PS script for removing those keys:

$list = @('OverrideACSettingIndex', 'OverrideDCSettingIndex', 'ProvACSettingIndex', 'ProvDCSettingIndex')

Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\Power\PowerSettings' -Recurse |? { $_.PSParentPath -match 'DefaultPowerSchemeValues' } |% {
    foreach ($Property in $_.Property) {
        if ($Property -in $list) {
            Remove-ItemProperty -Path $_.PSPath -Name $Property -Force
        }
    }
}

 

[xShARkx]

PS script for removing those keys:

$list = @('OverrideACSettingIndex', 'OverrideDCSettingIndex', 'ProvACSettingIndex', 'ProvDCSettingIndex')

Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\Power\PowerSettings' -Recurse |? { $_.PSParentPath -match 'DefaultPowerSchemeValues' } |% {
    foreach ($Property in $_.Property) {
        if ($Property -in $list) {
            Remove-ItemProperty -Path $_.PSPath -Name $Property -Force
        }
    }
}

Would there be a "Best Practice" between this and the reg file in post setup?

 

[Hellbovine]

The registry is easier to learn and troubleshoot, but can also be a lot of work sometimes. For example, if you've got several dozen power overrides, it would take an equal amount of tweaks inside a .reg file to address that. In this case, I've already done all the legwork in my guides, otherwise someone would need to manually track and collect all the registry paths where overrides can be generated. This varies greatly by computer hardware, and my desktop only has a few overrides on a clean install, so it's overkill for me to use other means when a simple .reg file works perfectly.

Powershell is more advanced, but harder to learn and troubleshoot. The reason I wanted it as an option, is because it allows us to search through the entire registry and find all overriding keys, even if we don't know what their registry paths are, and it can handle an infinite number of items. It makes for a very good troubleshooting tool, because it helps remove operator error, like if someone is struggling to eliminate their overrides, a script like this can wipe it all away with faster speed and more accuracy than a human, assuming the script was properly crafted. The obvious downside to powershell, is if a script like this is configured incorrectly, it can be volatile and delete more than intended.

While there can be dozens of methods to achieve a goal, the reality is that most of them are performing identical functions behind the scenes in the operating system, we just don't see that because it's hidden by user interfaces. For example, the "Powercfg" command can manipulate power plans too, but all it's actually doing is the same stuff we can do by loading regedit and manually editing things there, same as if we used a .reg file to upload changes, same as if we use the "Reg delete" command inside NTLite's post-setup, same as if we used a batch file.

That's 5 different approaches we could use here, but in the registry they are all doing identical work. Mostly, it's about picking tools that meet the needs of a project, and selecting approaches that you are most familiar and confident with, so you know how to troubleshoot it.

 

[xShARkx]

I just want to report back that the reg file removing the OverrideACSettingIndex, OverrideDCSettingIndex, ProvACSettingIndex and ProvDCSettingIndex keys in post setup, worked.

 

[tired-it]

Interesting. When I noticed that Windows was overriding my power settings, I simply appended "Override" to every setting I had. Windows didn't alter anything after that. What is "Prov" for? Haven't seen that one before.

 

[Hellbovine]

...I simply appended "Override" to every setting I had...

Spoiler: click here to reveal text

Using overrides is a valid approach. The downside though, is that wherever an override is present it will ignore the related user-defined value. In other words, if you have overrides active and then go to the control panel power options, you can still modify settings there and that will take effect in the registry. However, those new changes will be ignored too, due to the override that isn't reflected in the control panel.

What is "Prov" for? Haven't seen that one before.

Spoiler: click here to reveal text

I don't know all the specifics yet, but it's a type of override too. I believe the difference for the "Prov" keys, is they are active and taking precedence, but only when their specific conditions are met, while the "Override" keys are active all the time. I revised this guide's "Known Issues" section on the overrides topic to better help people, until I become more familiar and can post a preventative solution.

 

[Kerosene Cowboy]

Hello, does anyone know where i can find old versions of win10 specifically win10 21H2. I want to follow the guide for GamerOS and optimized guide together but it says you need win10 21H2. The only ISO i can find on Microsoft website says its for 22H2 and i was reading in the guide that 22H2 breaks somethings? or do i just follow the guide with a version of win10 22H2?

Go to UUP Dump they will have a copy there. LINK HERE

category:server-21h2 - Browse known builds

category:server-21h2 - Browse known builds on UUP dump. UUP dump lets you download Unified Update Platform files, like Windows Insider updates, directly from Windows Update.

uupdump.net

 

[garlin]

Go to UUP Dump they will have a copy there. LINK HERE

category:server-21h2 - Browse known builds

category:server-21h2 - Browse known builds on UUP dump. UUP dump lets you download Unified Update Platform files, like Windows Insider updates, directly from Windows Update.

uupdump.net

Not sure why you'd want the Server build, when the normal W10 21H2 version is available on UUP dump.

19044 - Browse known builds

19044 - Browse known builds on UUP dump. UUP dump lets you download Unified Update Platform files, like Windows Insider updates, directly from Windows Update.

uupdump.net

 

[audiobabble]

urrgh... pesky windows update has reared its ugly head again!

no idea why, but update and associated processes are hogging a large percentage of my CPU as soon as I go online. As far as I can tell, it's not actually downloading anything. This goes on for about 20 minutes or so, then stops. Same happens again after a restart. No updates 'waiting to install' or anything like that. Wish I knew what was going on.

Updates are still paused for 4 years as per the 'tweaks'... so it must be some other function of windows update, almost definitely triggered by task scheduler. I have two tasks under Microsoft > Windows > Windows Update in task scheduler: 'Refresh group policy Cache' and 'Scheduled start'. I'm unsure whether it's 'safe' to disable them?

I'm wondering if it's a 'scan' that's taking place, as per the description under scheduled start: 'This task is used to start the Windows Update service when needed to perform scheduled operations such as scans.'

The only thing that's changed recently is that my laptop battery is completely kaput, so much so that the computer is apt to forget the time and date and sometimes the bios settings go back to default -- if mains power is interrupted, even when off. No idea if it could have anything to do with that.

Waiting for a new battery.

 

[garlin]

If your laptop's (or desktop's CMOS) battery dies, then it always resets to a date in the distant past.

Whenever this happens, Windows will be confused until you manually update the date. Avoid shutting down the PC, or remember to fix the date as soon as you're logged on. Yes, it's a hassle.

 

[audiobabble]

If your laptop's (or desktop's CMOS) battery dies, then it always resets to a date in the distant past.

Whenever this happens, Windows will be confused until you manually update the date. Avoid shutting down the PC, or remember to fix the date as soon as you're logged on. Yes, it's a hassle.

Cheers.. actually it's not so much a date in the distant past -- it actually looks suspiciously close to the 'pause updates from' date in the registry tweak. So that probably has a bearing... I think windows update is deciding it's 'time for a scan' for whatever reason -- hard to say because the task scheduler entry has a 'custom trigger' that can't be edited AFAIK.

Hopefully a new battery will solve the issue.

 

[kevau]

Hello, first time NTLite user here. Thanks for the guide!
I tried doing this on W10 22H2 - but somehow Windows update seems to still force itself way in (after connecting to the internet), and eventually got me that WdFilter.sys (kernel "protection"), which reenables (and locks) Tample protection and windows defender.

Might have been because I tried running debloater(s) again after installation (and turned some "optional" features back on), but is that normal?
(Used 2 debloaters)
I used Windows10Debloater & Win-Debloat-Tools from github.

I've tried looking around on ways to disable the wdfilter but havent been able to.
I even tried deleting said file (I have dualboot Windows 10 in my laptop - the new one is for testing NTLite and eventual replacement by cloning) but even that still forces the tamper protection on for some reason

Edit: The windows 10 I made with NTLite does have defender (i think?) on fresh install, as I was able to open security center.
I do still want to be able to access "core isolation" which is in part of the Windows Defender/Security center (my android emulator needs it off, but it won't detect its off when I can't even open the menu or don't have windows defender).
I am unsure if adding the registry tweaks didn't help (as it was for W10 21H2), or because it instantly downloaded updates (for some unknown reasons)

I used W10 Pro from the official iso

 

[garlin]

The rules for disabling Defender services are clear:

1. For a live system, Tamper Protection prevents any Defender service from being disabled. Tamper Protection doesn't allow itself to be disabled by running a reg update. This is a layered defense strategy, forcing you to use the Security Center to turn off Tamper Protection.

2. By changing the Tamper Protection reg value in an offline image, Windows will allow you to disable any Defender service from running. For a live system, some users will boot into WinRE or WinPE and mount the live system's reg hive to force the change.

3. Even better is disabling both Tamper Protection and Defender services in the offline image, using a reg file. This avoids the problem entirely. Most debloating tools or scripts are written to run on a live system, and cannot do offline images.

For the reg file, read this thread:
Disable Windows Defender in Windows 11