[FIXED] GPOs and NTLite

C

clarensio

Active Member
for nuhi:

I was wondering if there is some way to manage the GPOs when preparing the final ISO image with NTLITE.

Currently in post production it is extremely "simple" - both for the Prof+ version but also for the Home version.

But, I repeat, I was intrigued by his possible native predisposition with NTLITE...

Thanks

ClaMod Note - Administrative Templates (.admx) for Windows 11/10/8.1/7 links.
 
Last edited by a moderator:
Do you mean NTLite should read admx files and present policies directly for change in registry?
 
nuhi said:
Do you mean NTLite should read admx files and present policies directly for change in registry?
Click to expand...
I don't know if reading the adm and admx files directly...
I am mainly referring to the import of Group policies a bit like you can do with lGPO.exe... if I could explain myself...
 
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.
 
Pretty much. I don't think you can merge two policy files, except to load multiple files on an existing system and export the combined results.
 
Ive never dived into gpedit.msc too much, changed a setting here and there, set some policies with reg files, getadmx. I'll have a look at it closer.
 
So the problem I encounter is the following:
- I insert the files with the policies through the installation ISO via $OEM$\System32\GroupPolicy - and the files are regularly inserted;
- however the \GroupPolicy\<folder and related files> are hidden and by executing "gpedit.msc" I get the "Access denied" window
- changing the permissions of the folder / files and after the reboot everything works normally (applying the command "gpupdate /Force" + reboot does not change the answer instead).

My question is therefore essentially the following:
1) by inserting the files in $OEM$\$$ is there a way for the files to be "copied" not read only / hidden???
2) solved - whenever possible - this is definitely necessary "gpupdate /Force" + restart: should you enter this command via NTLITE in post Setup???

Because I definitely have another system working which, of course, needs a .cmd file to copy (xcopy) the files and update the criteria: and this other way works perfectly.

I realize that all these operations seem "useless" but I have found that even by natively removing the apps+Store+Edge+etc ... the Privacy settings in the Group Policy are not changed with consequent "information traffic" from / to MS and its active loopback traffic, I see no other way than updating the Policy Group.

Tnx
 
If any help - i ask the same question if there's a simple way doing this through post setup, but found my own way solving this in a simple and functional way as Garlin stated by simply put the over years tweaked hidden GPO folder into a WinRAR sfx archive and point it to the mounted NTLite image.
Never had any issue with ISO's created or restart before Oobe and all the GPO tweaks works seamlessly after install (using Windows Pro) even betweeen the different Windows versions 8, 10 or 11. Also doing this with MS EDGE and OFFICE ADMX files as they are released regulary with updates for MS EDGE and MS OFFICE.
 

Attachments

  • GPOsfx.png
    GPOsfx.png
    42.5 KB
Trying and trying again, at the moment I can get what I need perfectly; that is to say:

1) in the native installation ISO, I add the $OEM$/System32/GroupPolicy/<files of GPO> folder: these files are copied correctly in C: \ ... but they are copied in hidden mode.
2) I solve this "problem" in post-setup by inserting an attrGP.cmd file that changes the folder attributes.

Filnal result: in phase of 1° startup of the OS (Win10 Enterprise 21H2 1686) the Group Policies are active, functioning and modifiable.

I attach AttrGP.7z (with AttrGP.cmd) if anyone is interested.

PS: I still believe that it would be sooooo nice if NTLITE were manageable (directly and / or indirectly ALSO the policy groups, at least those related to the native elimination of apps + Edge + ...
 

Attachments

  • AttrGP.7z
    185 bytes
Maybe the problem occur coz of copying the hidden GroupPolicy folder instead of what's inside the folder which is not hidden.
Would be nice if NTL somehow could handle import of content in GPO folder before making the final ISO.
 

Attachments

  • gpo nohidden.png
    gpo nohidden.png
    3.7 KB
francis11 said:
Maybe the problem occur coz of copying the hidden GroupPolicy folder instead of what's inside the folder which is not hidden.
Would be nice if NTL somehow could handle import of content in GPO folder before making the final ISO.
Click to expand...
Exactly

Even for what has been said here:

[FIXED] SmartScreen and Edge

For nuhi: After natively deleting - from NTLITE - Microsoft Edge from a clean image of Windows 10 1682 (UUP dump) and disabling SmartScreen Settings à Privacy: - Use SmartScreen Online Services to help you… = Disabled - Use SmartScreen Online Services to check… = Disabled the "SmartScreen...
www.ntlite.com www.ntlite.com
 
Hidden file attribute doesn't prevent file access if you already know the filename. It's security thru obscurity.

Instead of copying GroupPolicy directly to install.wim, what happens if we use $OEM$ folder -- but rename it to GroupPolicy2?
Does OOBE Setup save our original permissions?
Code: 
C:\Windows\system32>icacls GroupPolicy
GroupPolicy NT AUTHORITY\Authenticated Users:(RX)
            NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(GR,GE)
            BUILTIN\Administrators:(F)
            BUILTIN\Administrators:(OI)(CI)(IO)(F)
            NT AUTHORITY\SYSTEM:(F)
            NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)

C:\Windows\system32>icacls GroupPolicy2
GroupPolicy2 NT SERVICE\TrustedInstaller:(I)(F)
             NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
             NT AUTHORITY\SYSTEM:(I)(F)
             NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
             BUILTIN\Administrators:(I)(F)
             BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
             BUILTIN\Users:(I)(RX)
             BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
             CREATOR OWNER:(I)(OI)(CI)(IO)(F)
             APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
             APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)
             APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)
             APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)

What's missing? NT AUTHORITY\Authenticated Users (you).

What are our deployment options?
- copy GroupPolicy folder directly to install.wim ✔
- run Post-Setup takeown/icacls commands to fix permissions ❌
- run Post-Setup command to extract from ZIP/CAB file (restoring permissions) & gpupdate /force ✔
- run Post-Setup LGPO to import our policy files ✔

LGPO is probably the preferred solution. I do that myself.
 
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...
Sorry Garlin,

when you say "copying my System32 \ GroupPolicy folder..." you mean that you have copied your folder Group Policy into the final install.wim of the ISO obtained with NTLITE ... right?
 
All credit to Aaron Margosis - but he seems to figured it out already in 2016.
techcommunity.microsoft.com

LGPO.exe - Local Group Policy Object Utility, v1.0

First published on TechNet on Jan 21, 2016 LGPO.exe is a new command-line utility to automate the management of local group policy. It replaces the no-longer-maintained LocalGPO tool that shipped with the Security Compliance Manager (SCM), and the Apply_LGPO_Delta and ImportRegPol tools...
techcommunity.microsoft.com
 
Not surprising, since Aaron wrote LGPO :p

Copying System32\GroupPolicy into the filesystem of each image inside install.wim is one option. It doesn't require any Post-Setup action, and policies take effect on boot. However it's not as flexible as using LGPO and dropping a new policy file in $OEM$.

Copying is cleaner if you only have one edition, LGPO is better if you like testing different GPO's.

If you want to disable diagnostic data (telemetry) for Windows, use this GPO:
https://docs.microsoft.com/en-us/wi...in-your-organization#diagnostic-data-settings
 
You must log in or register to reply here.
Back
Top