[FIXED] GPOs and NTLite

Of course - but at the same time think that nuhi has already made reservations uncklicking Telemetry in NTL.
 
Settings / Privacy / Allow Telemetry -> DataCollection\AllowTelemetry

Using the GPO version allows for auditing, and gpupdate /force to revert changes. Reg keys are (normally) unprotected.
 
If you have natively deleted apps in the native image with NTLITE, I recommend configuring (gpedit.msc) the following settings:

Administrative Model/Windows Components/App Privacy

regarding privacy

PS: to check (and possibly correct) your status, I recommend testing OOSU10

O&O ShutUp10++: Free antispy tool for Windows 10 and 11

With the freeware O&O ShutUp10++, unwanted Windows 10 and 11 features can be disabled and the transfer of sensitive personal data onto Microsoft prevented.
www.oo-software.com www.oo-software.com
 
Concluding / summarizing:

there are 2 possibilities to "add" local policies to a Windows 10 Operating System (ISO) treated with NTLITE:

1) using the LGPO.exe file and related Group Policies backup in post installation of the OS;

2) by modifying (after creating the ISO with NTLITE) the relative install.wim file, extracting it and adding the files referred to in all 'image. After this change install.wim (modified) will be reinserted into the ISO.

Thanks
 

Attachments

  • Snap2.jpg
    Snap2.jpg
    25.1 KB
The key difference is GPO's inserted in the image run on boot, and Post-Setup LGPO runs later in execution. Pay attention if your GPO needs to stop background services from starting up (WU, telemetry).
 
"Group Policies for Dummies"
dont laugh, i (re)built my 1st pc using a "for Dummies" book.

garlin said:
I performed a test by copying my System32\GroupPolicy folder into a new image (which is empty). My GPO policies were recognized as good.
This means you can copy existing or exported Security.pol files to a newly created User or Machine folder.
Click to expand...
any policy created with gpedit.msc goes into both/either of these 2 folders yes?
Code: 
C:\Windows\System32\GroupPolicy\Machine and C:\Windows\System32\GroupPolicy\User
and once there can be copied over to a mounted wim or partition/extracted wim file folder?
and if successful will be recognised and applied during setup.

garlin said:
What are our deployment options?
- copy GroupPolicy folder directly to install.wim ✔
- run Post-Setup LGPO to import our policy files ✔

LGPO is probably the preferred solution. I do that myself.
Click to expand...
both are preferable but depending on if you want to build a default updated "gold" or tweaked image.


garlin said:
The key difference is GPO's inserted in the image run on boot, and Post-Setup LGPO runs later in execution. Pay attention if your GPO needs to stop background services from starting up (WU, telemetry).
Click to expand...
as above depending on the scenario i guess.
 
I would operate like this, given your doubts:
1) Through LGPO I would back up existing policies;
2) I would insert my new configuration in the \GroupPolicies folder and (after restarting the PC) I would check what the new configuration entails. If I am not satisfied with the backup I can always go back to the previous status
 
W7 EOL. while i am doing this im scanning/searching System32\GroupPolicy to see any changes, anything added.
no files are being added but i can see Registry.pol in "GroupPolicy\Machine" changing, gpt.ini seems to being modified too, thats all correct yeah?
 
gpt.ini is a version file intended for your domain controller to compare against. It has no meaning on single PC's.
 
GPO is just a folder copy, that can be easy implied in a SFX to mounted folder of NTL and can be updated over time depending of WIN version used. But MS seems to use the same outdated W7 scheme in W10 and W11 + new ones for EDGE you can pick up here as they enforce the browser. The same thing goes on for OFFICE - the new templates can be picked up here for OFFICE GPO.
 
I see that the topic "Group Policies Object" - GPO - is interesting.

In this regard, I would like to underline some ineluctable foundations for their correct management:
1) There are GPOs aimed at PCs that access the Company Domain (based on Active Directory), whose management is completely different
2) There are GPOs aimed at local PCs (our case)

In the case of local GPOs, we have 2 different situations:
1) GPO referring to the PC (Machines) which, once set, regardless of the access account - existing or new - will always be valid (except for possible variations dependent on updates and / or new software installations) and for everyone
2) GPO referring to the user (Users) which, once set, will be valid only and exclusively for the User only at the time of their creation; If new accounts are created on that PC, the previously created GPOs will not be valid.

This is why it is preferable to set up GPO for Machines...

However, various previously set GPOs may change as a result of software updates, new software installations, etc .: keeping any changes under control requires a fair amount of specific knowledge.

When setting up a PC, perhaps via ISO optimized with NTLITE, the only manageable policies are those of Windows, detectable via gpedit.msc.
In addition to downloading the respective admxs, it is necessary to import the same (preferably only the part in your own language) according to this guide - specifically referring to Microsoft Edge but also valid for Office, etc.)

Here instead you can find the GPOs for various other software even if some info may be "dated".

There is a lot more to say but it would be extremely difficult, as well as dispersive, to deal with the different aspects.

Moreover, I think nuhi is taking an interest in this and if there were specific requests, in my small way, I'm here.
 
GPO Machines is like HKLM while GPO Users is like HKCU, me savvy,
thanks for the clarification ia_100000051.gif
 
Group policy editor is limited to editing only those features/products for which it has local ADMX files. 3rd-parties and users can create their own ADMX files They're just editing templates, and don't restrict the actual GPO contents.

After a GPO file is created, it can be copied to any other PC. It's just another reg file in a different encoding. Like with reg edits, if your Windows doesn't support a directive then it's silently ignored.

When enabled, GPO's push out reg key changes to CurrentVersion\Policies. The same effect can be done without a GPO by editing the same keys, in fact that's what almost all users do. GPO will always push to reg. Registry edits don't push back to GPO, it only works in one direction.

The system or the admin can force a refresh and override the CurrentVersion\Policies keys. You can have other CurrentVersion\Policies keys which your current GPO doesn't cover, and they go untouched.

If that's all true, why bother with a GPO? The reason for using GPO's is to prevent users or apps from making unauthorized changes to their own settings, because the GPO will revert them back to the policy.
 
For those (certainly not for the "experts" who already know them) who would like to delve further into the GPOs, I wanted to summarize the indispensable tools for their management.

LGPO.exe is a command-line utility that is designed to help automate management of Local Group, including backup existing settings at the time or importing GPOs from a previous Setup/Backup.​

  • RSOP.MSC, (Resultant Set of Policy) is a Microsoft tool that is built into Windows 7 and later versions.
It provides administrators a report on what group policy settings are getting applied to users and computers. It can also be used to simulate settings for planning purposes. RSoP integrates and completes the better known but less immediate gpresult. Here is a brief user guide.​
With RSOP.msc, unlike gpedit.msc which will show ALL the possible GPOs available in Windows, you will be able to view only the currently active/modified GPOs on your PC.​
 
garlin said:
If that's all true, why bother with a GPO? The reason for using GPO's is to prevent users or apps from making unauthorized changes to their own settings, because the GPO will revert them back to the policy.
Click to expand...
Exactly, but NTL is becoming more oriented towards professionals than towards private users. That's fine enough, even though we're still a large crowd of private users who just use the tricks of the professionals to configure installations for ourselves, family and friends. So when you know the habits of your installations, the GPOs are of course adapted to this, so us NTL users just have to update their systems when new versions of Windows come out unless they have become too old to keep up with that race and everything works safe and sound.
 
You must log in or register to reply here.
Back
Top