I just opened the hive of user-default in ntlite. Then I find the item to modify and add the permission to everyone in the advanced option of permission. But when I found this registry key after oobe ended, I found that the permission change I added before did not appear. Does anyone know what I should do?
How to make HKCU's permission modification effective?
This is a known problem with later W10 and all W11 releases. OOBE and new user provisioning won't inherit all of Default User's profile settings. If you load the offline image's NTUSER.DAT, it's easy to confirm NTLite has saved your changes. But after installation, Windows is overriding some settings as part of user provisioning.
The only workaround is to apply the same changes as Post-Setup (After logon) commands.
The only workaround is to apply the same changes as Post-Setup (After logon) commands.
Hellbovine
Well-Known Member
- Messages
- 1,209
- Reaction score
- 761
There's a lot of confusion I'm seeing in these permissions and registry posts lately:
PERMISSION ISSUES
REGISTRY ISSUES
WORDING DEFINITIONS
PERMISSION ISSUES
Permissions aren't a problem in NTLite if people are approaching it correctly. I build all my images with over 500 registry tweaks, and I simply do not have any of these permission issues that members on this forum do. What's really happening is that many people with issues are using bad UAC tweaks, which disable it in a way that actually breaks parts of Windows. Some people don't even know they are doing this either, because they randomly use a bunch of registry files, scripts, and tools from the internet alongside NTLite, without understanding what they do. In addition, there's rarely a need to manually modify any permissions, because NTLite automatically handles that during integration.
REGISTRY ISSUES
Windows does not ignore or forget to inherit the .DEFAULT or Current_User registry tree, so that's misleading wording. I've written multiple posts on this and have proven it with all my guides, since my tweaks don't get overwritten by Windows. What's actually going on here, is some things like themes for example, don't get installed until right before or as the user sees the desktop for the first time, and that overwrites some tweaks.
By learning what is interfering, these overwrites can be avoided with some ingenuity, such as preventing the install of the Aero theme with another registry tweak. I do not use post-setup for anything at all, which proves there are ways to integrate almost every tweak that's worth discussing, so saying post-setup is the only workaround is misinformation. Sure, it's easy to tell people to do post-setup to quickly solve a thread, but it's not as robust as integration, and there are even keys that must be integrated in the image or they won't work, meaning post-setup makes them useless.
The biggest things I've seen responsible for overwriting settings are as follows:
1) The Aero theme overwrites some cosmetic settings.
2) The Power plans get both overwritten and overridden, based on hardware capabilities.
3) Windows Update, because updates can reset settings back to defaults.
4) Microsoft Store, because updates can reset settings back to defaults.
5) Unneccessary scripts and tools that aren't a part of NTLite, because these introduce both bugs and conflicting tweaks.
6) Windows 11 may have additional issues, because it isn't a mature operating system and still has bugs.
All of the above can be worked around, and my various guides contain those solutions. For the issue of Windows bugs, those just need to be fixed by Microsoft, but the reality is that Windows 10 is more mature at the moment and also has better performance. There's objectively no good reason for the masses to use Windows 11, especially since it's intentionally more difficult to tweak, because Microsoft wants everyone on default settings.
By learning what is interfering, these overwrites can be avoided with some ingenuity, such as preventing the install of the Aero theme with another registry tweak. I do not use post-setup for anything at all, which proves there are ways to integrate almost every tweak that's worth discussing, so saying post-setup is the only workaround is misinformation. Sure, it's easy to tell people to do post-setup to quickly solve a thread, but it's not as robust as integration, and there are even keys that must be integrated in the image or they won't work, meaning post-setup makes them useless.
The biggest things I've seen responsible for overwriting settings are as follows:
1) The Aero theme overwrites some cosmetic settings.
2) The Power plans get both overwritten and overridden, based on hardware capabilities.
3) Windows Update, because updates can reset settings back to defaults.
4) Microsoft Store, because updates can reset settings back to defaults.
5) Unneccessary scripts and tools that aren't a part of NTLite, because these introduce both bugs and conflicting tweaks.
6) Windows 11 may have additional issues, because it isn't a mature operating system and still has bugs.
All of the above can be worked around, and my various guides contain those solutions. For the issue of Windows bugs, those just need to be fixed by Microsoft, but the reality is that Windows 10 is more mature at the moment and also has better performance. There's objectively no good reason for the masses to use Windows 11, especially since it's intentionally more difficult to tweak, because Microsoft wants everyone on default settings.
WORDING DEFINITIONS
Permissions: What people are referring to here is that some registry keys are protected by Windows, and require Trusted Installer (TI) permissions to change those keys, as a security measure to help prevent malicious stuff from tweaking parts of the operating system. NTLite automatically handles this for people and there's no reason to use other tools or commands to modify permissions if a user integrated the tweaks using NTLite.
User Account Control (UAC): This is the setting in Windows that causes all those message prompts that appear asking a user if they are sure they want to run a program or do some action. This is another security measure, and the proper way to tweak it isn't through hidden registry keys that many people use, but instead to just move the slider down to "Never notify" which can be done with an integratable registry tweak.
Local_Machine (HKLM): This branch of the registry affects all users on a computer. Not every tweak will work here, as some tweaks only function if placed in the Current_User tree of the registry, and that is by Microsoft's design.
Current_User (HKCU): This branch of the registry only affects the currently logged in user. Not every tweak will work here, as some tweaks only function if placed in the Local_Machine tree of the registry, and that is by Microsoft's design. It should be noted that some tweaks work in both Local_Machine and Current_User, and in those cases the Current_User takes precedence if conflicting values exist.
Group Policy Object (GPO): These tweaks are overrides that do not directly alter Local_Machine or Current_User tweaks, instead if a group policy key is enabled it tells the operating system to ignore the relevant key in those two branches and instead does what the group policy wants. The main point behind group policies is for sysadmin to prevent users from changing settings, which is why the red text appears in places saying, "Some settings are managed by..." The other reason people use these, is because they also prevent Windows from changing settings, so it helps to stop some of the overwrites and overrides previously discussed, which is the lazy way to solve a problem.
Integrated: NTLite can integrate settings directly into an image, meaning they are in effect before, during, and after the installation of Windows.
Post-Setup (Before logon): This has been reworded in NTLite, and it used to say "Machine" in parenthesis. By inserting commands or registry tweaks here, it waits to apply them until Windows is installed and preparing things before the first user logs in.
Post-Setup (After logon): This has been reworded in NTLite, and it used to say "User" in parenthesis. By inserting commands or registry tweaks here, it waits to apply them until Windows is installed, and after Post-Setup (Before logon) is applied, then after the first user logs on it applies these.
User Account Control (UAC): This is the setting in Windows that causes all those message prompts that appear asking a user if they are sure they want to run a program or do some action. This is another security measure, and the proper way to tweak it isn't through hidden registry keys that many people use, but instead to just move the slider down to "Never notify" which can be done with an integratable registry tweak.
Local_Machine (HKLM): This branch of the registry affects all users on a computer. Not every tweak will work here, as some tweaks only function if placed in the Current_User tree of the registry, and that is by Microsoft's design.
Current_User (HKCU): This branch of the registry only affects the currently logged in user. Not every tweak will work here, as some tweaks only function if placed in the Local_Machine tree of the registry, and that is by Microsoft's design. It should be noted that some tweaks work in both Local_Machine and Current_User, and in those cases the Current_User takes precedence if conflicting values exist.
Group Policy Object (GPO): These tweaks are overrides that do not directly alter Local_Machine or Current_User tweaks, instead if a group policy key is enabled it tells the operating system to ignore the relevant key in those two branches and instead does what the group policy wants. The main point behind group policies is for sysadmin to prevent users from changing settings, which is why the red text appears in places saying, "Some settings are managed by..." The other reason people use these, is because they also prevent Windows from changing settings, so it helps to stop some of the overwrites and overrides previously discussed, which is the lazy way to solve a problem.
Integrated: NTLite can integrate settings directly into an image, meaning they are in effect before, during, and after the installation of Windows.
Post-Setup (Before logon): This has been reworded in NTLite, and it used to say "Machine" in parenthesis. By inserting commands or registry tweaks here, it waits to apply them until Windows is installed and preparing things before the first user logs in.
Post-Setup (After logon): This has been reworded in NTLite, and it used to say "User" in parenthesis. By inserting commands or registry tweaks here, it waits to apply them until Windows is installed, and after Post-Setup (Before logon) is applied, then after the first user logs on it applies these.
Last edited:
That's not what I wrote, and I've provided the same guidance for the past two years.
.DEFAULT is the profile for SYSTEM, and not the Default User's hive.
It's been demonstrated that even "mundane" user customizations like locale settings are all not passed over to new accounts, and have to be enforced after OOBE. This is a change from how it was allowed back in the W7/8.1 days where your settings were obeyed.
[W10 21H2] Change Date Format, Decimal Separator, Remove Default Tiles, Remove Taskbar Pinned Apps
My point is you can try and see if your integrated hive changes persist after an install, or simply move the change to a different location so you stop worrying about what does or doesn't get clobbered.
Hellbovine
Well-Known Member
- Messages
- 1,209
- Reaction score
- 761
Then we have different interpretations of what the following quotes mean.
Saying it won't inherit all of the settings, and only one workaround exists is incorrect. It does inherit them, they just get overwritten and overridden later, which is why I'm clarifying things, because that type of wording is adding confusion. I understand why you keep promoting post-setup, and I'm not arguing with that, since it does help unskilled users solve problems quickly, but we needed a more thorough post people can study, because this is an obvious point of confusion for members as these threads are numerous and people don't really seem to be getting it.
I already addressed all the other stuff you mentioned, so there's no reason for me to reply to those, because if people approach some things differently it solves the problems. I'm not trying to convince you, because I recognize that you know what you're doing, so this isn't about us, rather it's clear the masses are lost when it comes to permissions and registry, which is part of why this forum rehashes the same questions weekly.
A lot of these users are doing stuff like trying to take ownership of registry keys and branches, and that's simply the wrong approach. It's also muddying the waters when they ask for help, because it leads to XY situations where they don't ask the right question.
Last edited:
Combining your two replies, I think your point is that all registry changes have methods to inherit? And there may be methods that are not overwritten, right? I agree that ntlite will keep all changes to the registry, which is the same as dism. However, I think there is a definition problem for the idea of overwriting. According to my observation, HKCU's registry keys are not simply copied from the default user's ntuser.dat file. They are just created one by one according to the default registry keys. Therefore, the modification of registry permissions will not be applied to HKCU. I think this is unsolvable. The viewpoint you quoted before about correctly modifying the registry and preventing it from being overwritten should not be applicable to this problem. It should only be aimed at the modification of registry keys and values without permission.
Last edited:
I just want to add read-only permission to everyone to a registry key. So I can disable a feature that has no official disabling method.
Hellbovine
Well-Known Member
- Messages
- 1,209
- Reaction score
- 761
Rather than continue conceptual discussion, please post the tweak in question and a detailed explanation of what the specific goal is, so we can address that directly to find a solution, otherwise we're likely to go in circles without an example to troubleshoot.
Last edited:
You don't need a reg file to perform that. Use SetACL instead.
Managing Registry Permissions with SetACL.exe
Managing Registry Permissions with SetACL.exe
I set the permissions through the right-click menu.
Code:
SetACL.exe -on "HKLM\Software\Microsoft\Windows\CurrentVersion\GARLIN" -ot reg -actn ace -ace "n:Everyone;p:read"View attachment 12627
Hellbovine
Well-Known Member
- Messages
- 1,209
- Reaction score
- 761
It sounds like the OP is trying to disable a feature by changing permissions so that Windows cannot utilize a registry key. That should be posted, so we can confirm if there isn't a better method to solve it. Adding the tweak to the thread also makes it searchable, to help others with the same issue.
Last edited:
I added a permission of refusing to set value to the following registry key and its subkeys for everyone.
Code:
HKEY_CURRENT_USER\Software\Microsoft\input\tsf\tsf3overrideIt is a compatibility setting, which is no longer useful at present, but some software will change it by itself and destroy the experience. I didn't post the key at first just because it was too common to be worth exploring further. And I don't think anyone wants to view this registry. The problem is permissions, not keys or values.
Finally, I am sorry for my lateness. I was very busy recently, so I replied a little late.
Last edited:
Hellbovine
Well-Known Member
- Messages
- 1,209
- Reaction score
- 761
Have you tried using the group policy (link) for this instead?
I'm not understanding yet why you feel it's not about keys or values. If you just want to use the old IME, then setting the values is what's needed. If something is deleting or overwriting it later, that's a separate issue that can be investigated too.
I'm not understanding yet why you feel it's not about keys or values. If you just want to use the old IME, then setting the values is what's needed. If something is deleting or overwriting it later, that's a separate issue that can be investigated too.
Well, this is indeed a solution. My understanding of group policy has always stayed on using gpedit. I never thought about modifying the registry corresponding to group policy. This method is great, thank you.
Hellbovine
Well-Known Member
- Messages
- 1,209
- Reaction score
- 761
For anyone else landing on this thread, you can choose other options for keys of this nature too. Just copy and paste the key, which in this case is, ConfigureImeVersion into the search box of admx.help on the top right and it will show results for other languages, operating systems, etcetera.