Best practice for installing custom registry keys within typical NTLite ISO

S

Sonicmojo

Member
All

Spending a lot of time with NT Lite these days as I begin to move away from a (soon to be) outdated Windows deployment model using MDT.

Would rather focus efforts on a couple of really well-done Win 10 and Win 11 ISOs and use these instead of navigating WDS servers, network booting and all of that.

One area that I see a lot of pros/cons and chatter is the best spot to ensure that custom registry settings are applied (to the correct hives and contexts) within the established "phases" of Windows setup. I see some folks (like me) dropping reg files into the actual "Registry" node area within NT Lite (left panel) and others state without issue that the best spot is actually Post Setup (after Win login happens) and an account is on it's desktop?

What is the best way to handle this and does anyone have any examples on how to do this post-setup (PS commands or cmd.exe etc etc)

I have about 90 reg settings that I consider to be required for my use cases - and would love to see some intel from the field on this.

Cheers

Sonic.
 
There isn't a single rule that covers how and where registry keys need to be applied. It really depends on what Windows process normally creates those keys and what stage of installation, post-setup, or user provisioning you're in.

install.wim has some keys predefined in the different registry hives.
Some keys will be dynamically created when Features are installed, or the first time a process runs.

NTLite will deploy reg changes in the following formats:
  • *.reg files added to Registry
  • *.reg files, reg commands or a script added to Post-Setup (Machine) or (User)
Here's some useful guidelines:

1. Most HKLM keys can be integrated into the image (from the Registry screen). There are notable exceptions, usually covering Defender or kernel security settings -- where Windows gets upset if you define a key before its own process starts the first-run initialization.

Integrated keys are present as soon as Windows boots. This is most useful for preventing actions from never happening in the first reboot stage of Windows install. For example, I disable the paging file so Windows never gets to create one.

2. Prior to later W10 (and all W11) releases, it was useful to add HKCU keys (also from Registry). Lately this step appears to be less useful, as user provisioning is ignoring/overwriting more of these values. When you check the Default user's hive, everything is there. But if you created a new local user, many of those settings don't carry over.

There is no guide on which keys are blocked. You just have to experiment :(

To update HKCU, you can have Post-Setup (User) run a reg command, or add a reg file. This guarantees it will be pushed since (User) runs in the first logon session, after user provisioning has completed.

3. When in doubt, you can add a "reg query > output.txt" command to Post-Setup (Machine), since that runs before user provisioning. This can be useful as a sanity check that your intended change was present at that stage, or was clobbered later on.

Just remember (Machine) runs under the SYSTEM context, and you would have to load Default user's NTUSER.DAT (and later unload) if you wanted to inspect it.

4. Most of your reg problems will be applying a change too early, or too late in the install process to affect an action. Too early, and first-time run will clobber your settings. Too late, and the process has already started and will ignore the setting until it's restarted or the next reboot.

Hope that covers everything.
 
Sonicmojo said:
would love to see some intel from the field on this.
Click to expand...
If you want to see a "final" image that has been built by integrating 500+ keys directly then browse my Optimized Image guide (link). Be sure to organize and document your keys because it not only improves your own efficiency in researching/testing them, but also makes it easier for people to assist you if something goes wrong (edit my files to see how I documented mine as an example).

I have yet to come across a key that requires me to use post-setup because there is usually an alternative registry key that can be manipulated instead, which doesn't get overwritten. An example of this is how I tweak the local_machine "Visual Effects" settings, whereas everyone else uses the current_user method further downstream and it tends to result in people using post-setup.

I highly recommend integrating keys rather than post-setup whenever possible for the most robust image, since some keys will affect others, and some also need to be present very early in the install of Windows for them to take effect. I'm sure there's probably a few keys that must be post-setup, but I personally haven't experienced that yet (or those tweaks aren't as necessary as people think they are).

The downside to registry keys is you will need to manually re-check them at least with every new major version release, to ensure they continue to stick on a clean install, haven't been deprecated, replaced, or had additional companion keys added into the mix. Make sure to grab a registry compare tool as well because it's necessary for this kind of tweaking and to test your images (link). Also, read the Quality Control guide before getting started (link).
 
Hellbovine said:
I have yet to come across a key that requires me to use post-setup because there is usually an alternative registry key that can be manipulated instead, which doesn't get overwritten. An example of this is how I tweak the local_machine "Visual Effects" settings, whereas everyone else uses the current_user method further downstream and it tends to result in people using post-setup.
Click to expand...
I'll disagree here. You're talking about HKLM vs HKCU contexts.

When it's a single user PC, HKLM can replace using HKCU. But there are enough folks here, working in multi-user or shared PC environments where you can't apply a blanket HKLM solution. And you're forced to go the long road to provide the correct solution.
 
I'm not sure what you're disagreeing with, what was quoted is verifiable and I've tested it numerous times--there are multiple threads on it in which I helped people reach a solution on this matter. I guess you can disagree with the idea of using HKLM for IT/Enterprise scenarios, but that's all situational depending on what kind of tweak we're discussing and doesn't change the fact that you *can* find alternatives to keys. I was just giving OP the information, he will need to see what works for him, there's really not anything to argue here.

I give people examples because it helps them to understand. You may not always agree with the examples, but there's a reason I get constant comments and mail about how my guides are easy to follow, the examples help it to "click" for people, even if it isn't a perfect example by your standards. You're being nitpicky here IMO.

I laid out my experience in this field, of which I have a ton of because all my image editing is registry-based and unlike so many other images on this forum, mine works and doesn't result in anything broken. I know a little bit about the registry since I have 1,000+ hours in tweaking it, I'm not just pulling this info from nowhere.
 
Last edited:
No, I'm not being nitpicky. I don't believe your guides explain (or least I've read a part) that gently explain the difference between HKLM and HKCU usage for the same keys. Most users gloss over the rules of precedence. And if they're not aware, it causes confusion on why a set of them don't work as expected.

My background is systems management, where the defining rule is to make the least change possible to get any task done, in order to prevent unintentionally doing something you didn't expect. For an inexperienced user, they will follow your guide literally -- because they don't know any other ways of getting things done. For a more experienced user who has more at play, you need to know the nuances.

Unlike your approach, I don't distill everything to an one size-fits-all guide. Guides only work if they're followed religiously. As soon as you stray off the path, then most creators don't have the patience to debug the problem. They're good as primers, but it's a not a reference text.

I don't have a problem with your approach. But I don't want to see what happens on other Windows sites -- where every nail is pounded by the same YouTube hammer, because the responder has too much invested in a rehearsed answer.

The OP is from a MDT/WDS background, so I recognize who is my target audience and what they ought to be advised.
 
garlin said:
...difference between HKLM and HKCU usage for the same keys...The OP is from a MDT/WDS background, so I recognize who is my target audience...
Click to expand...
What I was relying on is that if OP actually investigates my keys and looks at the visual effects he will see they are completely different than what you are describing. I am not talking about the kind of keys where you can literally just change the path from HKCU to HKLM and vice versa, which seems to be what you are talking about. The visual effects keys I am referencing are not a HKCU to HKLM scenario at all, they are different paths and keys because they both handle something different, but similar.

While I do spoonfeed people, I also try to teach them to fish too when the situation warrants it, and because OP seemed like he may be able to figure things out on his own I directed him to take a look at the keys for himself, rather than me copy/pasting an example here. Below is an example of what I mean, where I'm *not* talking about directly converting HKCU to HKLM, but rather an alternative:

; Start > Settings > System > About > Advanced system settings > Advanced > Performance (Settings) > Visual Effects > Enable Peek > Off
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM]
"EnableAeroPeek"=dword:00000000

Or use a tweak like the one below for the same/similar tweak outcome:

; Start > Settings > System > About > Advanced system settings > Advanced > Performance (Settings) > Visual Effects > Enable Peek > Off
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects\DWMAeroPeekEnabled]
"DefaultValue"=dword:00000000

The reason I like these "DefaultValue" keys instead is because not only did the group of them resolve a display bug, but it integrates cleanly for all users and does not get overwritten. It also happens to be just as safe as the "usual" method, and easier to read and understand in comparison to the mess that is a full set of tweaked visual effects using HKCU.
 
Last edited:
Gents

Much appreciate the info from the field. And while both of you have different views of this - it's all good. Appreciate the MDT/WDS angles AND the gobs of HKCU keys in Hellbovines stash.

I do have a question for HB: You have probably 40+ keys in your files that are specific to IE - which has been dead (and gone) for a long while. Now - I took a quick look in the registry and yes - most of these key locations continue to exist and keys would be placed as part of an ISO build - BUT what is the point of all these tweaks when IE (as an actual usable browser) is non-existent now?

Unless someone is (god forbid) using IE in this day and age OR insists on staying with a (deprecated) prior (21H2 etc) build of Windows that is now out of support? These keys seem to make little sense now with the latest Win 10 version.

All anyone could possibly see within 22H2 (post Feb 2023) is a rare glimpse the ghost of IE past if/when the Trident rendering engine makes a rare appearance in IE Mode (for those that ever need it).

Would be nice to see all these IE keys replaced with modern keys that could tune up Edge nicely within a standard NT Lite layout.

Appreciate your take on this.

Sonic.
 
Last edited:
Sonicmojo said:
when IE (as an actual usable browser) is non-existent now?
Click to expand...
The guide was built for 21H2 and IE didn't officially retire until 7 months later. Many businesses/agencies, including work laptops people bring home, still require IE because the agencies refuse to migrate from outdated software which rely on it. I've worked as an emergency dispatcher, and my wife is a social worker, and both agencies relied on IE, including other obsolete software (Java). As someone else mentioned in my guide thread, it's better to have the tweaks and not need them than the other way around--users can always just view my files as like a farmer's market, but everything's free. Those keys are all still valid and a real part of the operating system though (in 21H2 at least).

Sonicmojo said:
Would be nice to see all these IE keys replaced with modern keys that could tune up Edge nicely
Click to expand...
I agree, I had planned to do both, but Edge now uses Chromium and that software doesn't save registry keys for the user's settings like IE does. There's no simple solution for this at the moment, it's been on my to-do list and I've dabbled a few times, but was hoping Microsoft might make this easier as people complain, then maybe when I update the guide for 23H2 I can find a way.
 
Last edited:
Hellbovine said:
The guide was built for 21H2 and IE didn't officially retire until 7 months later. Many businesses/agencies, including work laptops people bring home, still require IE because the agencies refuse to migrate from outdated software which rely on it. I've worked as an emergency dispatcher, and my wife is a social worker, and both agencies relied on IE, including other obsolete software (Java).
Click to expand...
Well - I have to respectfully disagree with this as I too work in IT a VERY large municipal government here in Canada, we are STILL on 21H2 and yes - there are internal sites that "need" IE compatibility - but on the user desktop - there is no IE. There is no icon, no start menu reference, no file payload, no launch capability - no nothing.

All there is - is IE Mode (as delivered by Edge) where the old Trident render engine becomes visible - but only when a user hits on of these old timey sites on our intranet.

The only way that anyone in the world could possible still be accessing IE (as actual usable browser) is if they are running a machine (in a business environment) that has not been patched since May 2022. That simply does not seem feasible (or normal) for any business environment.

Sonic.
 
If it's not special reggies - just point to the folder with your reggies - if some don't get integrated in the image, then the post-setup method would work.
 

Attachments

  • Skærmbillede 2023-08-03 211852.png
    Skærmbillede 2023-08-03 211852.png
    56 KB
Sonicmojo said:
...I have to respectfully disagree...
Click to expand...
I don't see which part you quoted that can be disagreed with, since every word of it is verifiable. I think the problem is you've made a lot of assumptions in your reply, and I'll try to elaborate on that below. Please know that I mean all of this in a friendly tone, it's just an open discussion, but I feel like I need to defend my credibility since I post guides, so here goes...

Sonicmojo said:
...on the user desktop - there is no IE. There is no icon, no start menu reference, no file payload, no launch capability - no nothing...
Click to expand...
Here you assume that everyone in the world is using your same Windows build and configuration settings. IE is visible in the start menu on at least some 21H2 builds (attached a screenshot as proof), and your reply also isn't considering that not everyone allows communication to Microsoft's servers and/or doesn't use Windows Updates, meaning there's a few factors that affect your concept of Windows:

The build number for the original November 16th, 2021 21H2 ISO is 19044.1288 and anyone with a build higher than that is applying Windows Updates, which changes how stuff functions as Microsoft patches and evolves things. Just because someone hasn't flipped the switch for 22H2 or higher, doesn't mean they haven't received tons of updates over the months/years.

Also, when IE was retired on June 15th, 2022 it presumably (I haven't installed it yet) buried IE from the surface so that it was harder to see, as you point out. However, IE very much works in all builds before a certain point in time. Lastly, Edge itself is designed to update separately from Windows Update which means you can't assume people on a specific OS build are also using a specific Edge build.

Factors like these cause people's understanding of things to differ because not everyone is on the same builds of OS or browser. This new Edge browser has also changed quite a bit over time too, and the functionality of the IE to Edge transition evolved as well. It's like Cortana on this forum, people argue about what it does or doesn't break when it's uninstalled, and the reality is they are all partially correct because it evolved so much with time, that uninstalling it on different builds leads to different results in terms of what breaks.

Sonicmojo said:
The only way that anyone in the world could possible still be accessing IE (as actual usable browser) is if they are running a machine (in a business environment) that has not been patched since May 2022. That simply does not seem feasible (or normal) for any business environment.
Click to expand...
I hate to burst your bubble, but this is a reality. I already explained that both my wife and I worked at government jobs that did this, so you are essentially saying I'm lying...If people knew how many times my work software or computer crashed in the middle of life or death situations, it would shock the hell out of them, and would really help citizens understand how bad our infrastructure is (USA)--My wife's job was using clunky software that had roots to pre-XP operating systems, up until this year when they finally transitioned. These are facts, I was literally there.

I'm not sure if you're aware, but parts of our military still use XP, so do other devices, such as ATM machines. These are all just more examples to consider, they don't need to be picked apart in further replies because they exist whether people like it or not. Here's some links to get you started on this research (link1, link2, link3) so you can see more examples, rather than us arguing over the ones I wrote about.

Keep in mind the bigger picture too, there isn't a one-size-fits-all on computers because everyone uses their systems in different ways. I provided valid tweaks, and I never made any egregious claims that needed to be refuted. I'm open to feedback, but it needs to be supported with actual data to prove me wrong, otherwise it's exhausting to spend hours rebutting this kind of stuff since I put in a ton of effort/research/testing in everything I do, and this takes away time I could spend on upgrading my guides for people. Also, I update the guides annually when Microsoft releases new ISO builds, so when these keys become irrelevant I'll remove them.
 

Attachments

  • Start.png
    Start.png
    83 KB
Last edited:
Hellbovine said:
I don't see which part you quoted that can be disagreed with, since every word of it is verifiable. I think the problem is you've made a lot of assumptions in your reply, and I'll try to elaborate on that below. Please know that I mean all of this in a friendly tone, it's just an open discussion, but I feel like I need to defend my credibility since I post guides, so here goes...


Here you assume that everyone in the world is using your same Windows build and configuration settings. IE is visible in the start menu on at least some 21H2 builds (attached a screenshot as proof), and your reply also isn't considering that not everyone allows communication to Microsoft's servers and/or doesn't use Windows Updates, meaning there's a few factors that affect your concept of Windows:

The build number for the original November 16th, 2021 21H2 ISO is 19044.1288 and anyone with a build higher than that is applying Windows Updates, which changes how stuff functions as Microsoft patches and evolves things. Just because someone hasn't flipped the switch for 22H2 or higher, doesn't mean they haven't received tons of updates over the months/years.

Also, when IE was retired on June 15th, 2022 it presumably (I haven't installed it yet) buried IE from the surface so that it was harder to see, as you point out. However, IE very much works in all builds before a certain point in time. Lastly, Edge itself is designed to update separately from Windows Update which means you can't assume people on a specific OS build are also using a specific Edge build.

Factors like these cause people's understanding of things to differ because not everyone is on the same builds of OS or browser. This new Edge browser has also changed quite a bit over time too, and the functionality of the IE to Edge transition evolved as well. It's like Cortana on this forum, people argue about what it does or doesn't break when it's uninstalled, and the reality is they are all partially correct because it evolved so much with time, that uninstalling it on different builds leads to different results in terms of what breaks.


I hate to burst your bubble, but this is a reality. I already explained that both my wife and I worked at government jobs that did this, so you are essentially saying I'm lying...If people knew how many times my work software or computer crashed in the middle of life or death situations, it would shock the hell out of them, and would really help citizens understand how bad our infrastructure is (USA)--My wife's job was using clunky software that had roots to pre-XP operating systems, up until this year when they finally transitioned. These are facts, I was literally there.

I'm not sure if you're aware, but parts of our military still use XP, so do other devices, such as ATM machines. These are all just more examples to consider, they don't need to be picked apart in further replies because they exist whether people like it or not. Here's some links to get you started on this research (link1, link2, link3) so you can see more examples, rather than us arguing over the ones I wrote about.

Keep in mind the bigger picture too, there isn't a one-size-fits-all on computers because everyone uses their systems in different ways. I provided valid tweaks, and I never made any egregious claims that needed to be refuted. I'm open to feedback, but it needs to be supported with actual data to prove me wrong, otherwise it's exhausting to spend hours rebutting this kind of stuff since I put in a ton of effort/research/testing in everything I do, and this takes away time I could spend on upgrading my guides for people. Also, I update the guides annually when Microsoft releases new ISO builds, so when these keys become irrelevant I'll remove them.
Click to expand...

HB

Do not need a pissing match. I am not running 21H2 and never will be.

My NT Lite work and custom Windows ISOs seek to be 100% current and the instant Microsoft officially closes support on a build - I am off to the next - nuff said.

That said - I really like your work and the effort you put into it - I was simply pointing out these IE keys are of little to no value now that IE is long gone (for let's say 99.94% of users :) in the real world.

I will take what I need from your listings and ignore the rest.

SOnic.
 
I can only post here what I have done, but my ISO is far from a 100% polished solution.

I am importing various HKLM keys using the registry section in ntlite, also some HKCU default user keys, however I found these very hit and miss with many not applying to any created accounts which suggests those values get overwritten post account creation, so those same keys are also applied during my post install script alongside some other keys I never added to ntlite. There is likely a more streamlined approach including adding them during post-setup part of ntlite, but I didnt want to get too distracted by registry stuff and since my post install script is needed anyway for some stuff I run from it, its not a big deal for me. Also some keys are optional in my script depending on options picked, so will always be in my script as interactive.

Hope my 5 pence helps, probably doesnt, but I posted anyway. :)
 
Does that happen when you point to the folder with your regs in NTL or when you try to implement via subcomponents in NTL registry section? Asking as it make a big difference if NTL integrates them or not.
Some HKLM can't be integrated - but maybe be altred through GPO.
 
Sorry, I meant to write hibernation file instead of paging file. Paging files are critical, before someone else derails this topic with a "my Windows runs fine without a paging file" anecdote. Yes, you can run without one. But it can break Windows functions because some virtual memory allocations are based on the page file's size.
 
garlin said:
Sorry, I meant to write hibernation file instead of paging file.
Click to expand...
If the machine is only either on or off then hibernation can be disabled.

garlin said:
Paging files are critical, before someone else derails this topic with a "my Windows runs fine without a paging file" anecdote. Yes, you can run without one. But it can break Windows functions because some virtual memory allocations are based on the page file's size.
Click to expand...
Yes mine does run fine.
Disabling pagefile is very much a case by case basis, some people will have it permanently disabled, some may prefer to set it to a specific size and a different location post install once all their programs and drivers are installed.
 
Sonicmojo said:
I have about 90 reg settings that I consider to be required for my use cases - and would love to see some intel from the field on this.
Click to expand...

Sorry for replying this late but I would like to share experience on this.

I also used MDT and now migrated to NTLite with some custom scripts (also Chocolatey for app installs).

Registry edits are, in my experience, usually properly documented and no trial and error needed. Some registry keys are supported in both HKLM and HKCU registry keys, while some are HKLM or HKCU-only.

I usually implement the custom keys as part of the Inno Setup scripts that encapsulates the original installer with other custom actions and generates silent-mode installers that would be used with "/VerySilent /NoRestart" parameters.

For HKCU keys, the situation gets slightly complicated because the keys do not exist before the user logs in. The user profiles are created from the "Default" user profile ("C:\Users\Default"). Therefore I would use the "reg.exe" tool to load the Default "ntuser.dat" registry hive, perform the registry modifications, and unload the registry hive. When new users log in, the new keys are automatically copied from the "Default" user registry hive and becomes the new HKCU registry.

For Windows policies, I usually use LocalGPO (lgpo.exe) to directly apply the policies instead of edit registry keys.
 
You must log in or register to reply here.
Back
Top