[Post-Setup] GPO folder being cleaned during setup?

TT9tWhD$q

Member
  • host W10 Pro x_64 1909 b18363.657
  • target same as host
  • NTL 1.9.0.7330 x_64 portable mode
______

Having deployed in Post-Setup

Code:
move /Y "%SystemDrive%\gpo\pol\m\*.csv" "%WINDIR%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit"
move /Y "%SystemDrive%\\gpo\pol\u_registry.pol" "%WINDIR%\System32\GroupPolicy\User\registry.pol"
move /Y "%SystemDrive%\gpo\pol\m_registry.pol" "%WINDIR%\System32\GroupPolicy\Machine\registry.pol"
move /Y %SystemDrive%\gpo\*.admx %WINDIR%\PolicyDefinitions
move /Y %SystemDrive%\gpo\*.adml %WINDIR%\PolicyDefinitions\en-US

works as far as the files being moved initially. Checking the registry after install the respective entries are present, meaning being deployed during setup, and also GPEDIT displaying all relevant templates.

That said the issue appears to be that at some later stage during the setup process the directory %WINDIR%\System32\GroupPolicy appears to get wiped and since GPEDIT is not reading the present registry entries all settings showing as not configured

Is the wiping of directory %WINDIR%\System32\GroupPolicy expected by the WIN installer routine or a NTL routine? Since either would defeat the purpose of Post-Setup is there a recommended strategy to deploy GPOs unattended?
 
To apply GPOs directly you can use a domain and set it up on the user itself.
If using local users only, it is possible to apply the GPOs with the Local Policy Editor and sysprep/capture the image, replacing the .\Sources\install.wim with that image - bit tedious.

For NTLite, I recommend taking the actual policy registry change from each GPO and making the .REG file, integrating that instead (Integrate - Registry), the effect is the same.
Some settings are already available on the Settings page, let me know which ones are you missing, or one for example on what registry entries I meant.

Thanks.
 
For NTLite, I recommend taking the actual policy registry change from each GPO and making the .REG file, integrating that instead (Integrate - Registry), the effect is the same.

There is a slight difference due to the design of GPEDIT.mmc since it does not actually queries/reads the registry keys/values but only sets/writes to it when changing a value and stores its settings in:
  • %systemroot%\System32\GroupPolicy\User\registry.pol
  • %systemroot%\System32\GroupPolicy\Machine\registry.pol
Thus even with all the registry keys/values imported (and thus present/applied) the GPEDIT management console will show any/all values as Not Configured unless those *.pol files are present, which being the purpose of the Post-Setup mentioned in in the initial post. But if %systemroot%\System32\GroupPolicy gets wiped after those files been moved during Post-Setup then it would seem pointless.

There is also the LGPO tool but that is rather tedious, compared to just moving the *.pol files, and likely to meet the same outcome in the course of the installation sequence (%systemroot%\System32\GroupPolicy being wiped afterwards).

Searching the public domain I could not trace a reference to %systemroot%\System32\GroupPolicy for in the OS's setup/installation routine and why it would wipe that directory - maybe it is supposed to start from a clean slate. Neither could I find a reference of how to go about retaining those *.pol files for an unattended installation and thus posted here in hope for solution - other than moving the *.pol files once the instalation is complete and the user logged in - that is for a non-domain target.
 
Gave it another gowith

Code:
  xcopy /Y /I %SystemDrive%\tailor\del\gpo\pol\*.csv "%systemroot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit"
  xcopy /Y %SystemDrive%\gpo\pol\u_registry.pol %systemroot%\System32\User\registry.pol*
  xcopy /Y %SystemDrive%\gpo\pol\m_registry.pol %systemroot%\System32\Machine\registry.pol*
  xcopy /Y /I  %SystemDrive%\gpo\*.admx %systemroot%\PolicyDefinitions
  xcopy /Y /I  %SystemDrive%\gpo\*.adml %systemroot%\PolicyDefinitions\en-US

Curiously,

whilst the policies stipulated in the *.pol files been deployed during setup, evidently being present in the registry and having added a log output to XCOPY that indicates the files been copied the directory %systemroot%\System32 is:
  • void of its subdirectory \User
  • whilst \Machine been cleaned of its registry.pol
  • but Machine\Microsoft\Windows NT\Audit retained and with it the *.csv file
NTUSER.DAT would seem pointless either since it deals with the registry hive but not the *.pol files either.
 
Should have paid better attention to the destination path for the *.pol files. After correction

Code:
xcopy /Y %SystemDrive%\gpo\pol\u_registry.pol %systemroot%\System32\GroupPolicy\User\registry.pol*
xcopy /Y %SystemDrive%\gpo\pol\m_registry.pol %systemroot%\System32\GroupPolicy\Machine\registry.pol*

the *.pol are retained throughout the setup process. Sorted then, which is a bit of relief being able to migrate those files with NTL > XCOPY.
 
Back
Top