locked
LocalGPO.wsf during OSD? RRS feed

  • Question

  • Has anyone been able to get the local policy to apply successfully during OSD? Seems like it will apply the security settings and update the UI, but not advanced audit config or enable the MSS settings to be shown in gpedit - even though it says it does in a command line output I forced it to do. Says everything is applied valid.
    Friday, May 21, 2010 5:23 PM

Answers

  • As mentioned in the previous response, the log you are capturing just lists commands/tasks executed by the tool. error checking is very limited... the tool does not actually verify that each and every task completes succesfully.

    From the output above, it looks like you have a custom install (different directory) and/or you have modified the script. This is all good, but the changes are more than likely not covered in our current test cases, so pinpointing what is interfering will be tricky. Are you observing any of the same behaviors when running the tool from \Program Files\LocalGPO from and elevated command prompt?

    You should not need to run regsvr32 after running the tool. The tool runs "regsvr32 scecli.dll" during the /ConfigSCE, so it seems that command isn't being carried out successfully from your environment. Assuming you are using Win7/R2, to verify the Audit Policy settings are being applied successully to Local Policy you can check the following folder on your computer:

    \Windows\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit

    You should see an audit.csv file that looks very similar to what is in the GPO backup under C:\Admin\SecurityPolicy\*****

    If the Audit folder does not exist or is empty... something is preventing the tool from completing this process successfully. I suspect the tool is not finding an environment variable defined for %TEMP%. Try modifying your script to ensure an environment variable exists for %TEMP%... point it to the C:\Admin\SecurityPolicy folder.

    If you send the contents of the C:\Admin\SecurityPolicy, we can try to duplicate what you are seeing.

    Monday, May 24, 2010 9:33 PM

All replies

  • To display MSS settings in GPEdit you need to run the following command:

    LocalGPO.wsf /ConfigSCE

    Running the following command will "hide" the MSS settings:

    LocalGPO.wsf /RestoreSCE

    After applying Advanced Audit from a GPO backup, you need to restart the computer for GPEdit/AuditPol to align.

     

     

     

     

     

    Monday, May 24, 2010 5:13 PM
  • Thank you sir - but not quite what I needed, here's some more details:

    I'm running a script during OSD that does LocalGPO.wsf /ConfigSCE. I verify this works because I'm piping the hidden output to a log. It says it edits the inf file and the settings should be displayed.

    In addition, I do a restore using the LocalGPO.wsf tool. It restores all of the Local Security Policy settings (even the MSS ones) and is visible on the first interactive user login. However, the MSS settings don't show in the tool. However, if I run the LocalGPO.wsf /ConfigSCE while logged in as a normal user, it says it has already been done.

    If I do the ResetSCE command, then the Config command, they show - with all of the set values. However, if I just do a regsvr32 /s scecli.dll while logged in right after my task sequence has edited the inf, it shows up. No need to reboot.

    With the auditpolicy, it doesn't appear to take hold during the task sequence. If I use the LocalGPO.wsf tool logged in as an admin after imaging, it works fine and updates the GUI. If I add an auditpol.exe /restore step to my task sequence using the CSV, it looks like it sets the settings, but it doesn't update the group policy editor GUI tool. They all say not configured.

    Monday, May 24, 2010 5:38 PM
  • The log you are capturing is only recording what tasks have been attempted by the tool... the current version has limited error logging, and no verification of an attempted task is performed.

    We have not tested running the tool from anything other than an elevated\administrator command prompt. The 2 things that come to mind that can interfere with the proper running of the tool are not running it with the proper security context, and not running it with the tool's folder as the current directory. I suspect that the current directory requirement is causing the tool to function incorrectly when calling it from a script.

    Running LocalGPO.wsf /ConfigSCE as a normal user will not work... this requires full admin rights to work correctly. Reboot should not be required for the MSS settings to display.

    The reboot I mention above is for the Advanced Audit to display/align properly with what AuditPol returns. Running AuditPol with a CSV is completely different that configuring the same settings using GPEdit... just using Auditpol will not result in any of the settings being configured/enforced via policy in GPEdit. When applying/configuring Advanced Audit Policy using LocalGPO and GPO backup you will need to reboot to ensure what you see in GPEdit and what Auditpol returns is the same.

    Monday, May 24, 2010 6:33 PM
  • Thank you sir - but here's some more info:

    I was referring to a log that I made with the >> command line argument to show if it did in fact get applied successfully during OSD. This is my output. I did have the directory issue before, but I fixed that by making sure it runs locally within its own directory.

     

    C:\Admin\SecurityPolicy>cscript.exe "localgpo.wsf" /ConfigSCE 
    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.
    Modifying the Security Configuration Editor to the include MSS settings...
    
    C:\WINDOWS\inf\sceregvl.inf updated with MSS specific registry keys and values.
    
    Registering SceCli.dll to complete SCE modification
    The Security Configuration Editor is updated.
    Security Configuration Editor has been modified successfully!
    C:\Admin\SecurityPolicy>cscript.exe "localgpo.wsf" /Path:C:\Admin\SecurityPolicy\****** 
    Microsoft (R) Windows Script Host Version 5.8
    Copyright (C) Microsoft Corporation. All rights reserved.
    Modifying Local Policy... this process can take a few moments.
    Applied valid INF from C:\Admin\SecurityPolicy\******
    Applied valid Machine POL from C:\Admin\SecurityPolicy\******
    Applied valid User POL from C:\Admin\SecurityPolicy\******
    Applied valid Audit Policy CSV from C:\Admin\SecurityPolicy\******
    Local Policy Modified!
    Please restart the computer to refresh the Local Policy

    So when I do this from within OSD (running as the system account, all other programs install fine with elevated privileges here) - it gives me this. Also, the "Security Policy" node under Local Security Policy gets updated. However, I don't see the MSS settings, and I don't see the Advanced Audit Policy config show in the GUI. Even after multiple reboots.

    If I do regsvr32 scecli.dll from an elevated prompt after logging in as an admin, I see the MSS settings. But I don't see the audit policy settings still.

     

    Monday, May 24, 2010 8:04 PM
  • As mentioned in the previous response, the log you are capturing just lists commands/tasks executed by the tool. error checking is very limited... the tool does not actually verify that each and every task completes succesfully.

    From the output above, it looks like you have a custom install (different directory) and/or you have modified the script. This is all good, but the changes are more than likely not covered in our current test cases, so pinpointing what is interfering will be tricky. Are you observing any of the same behaviors when running the tool from \Program Files\LocalGPO from and elevated command prompt?

    You should not need to run regsvr32 after running the tool. The tool runs "regsvr32 scecli.dll" during the /ConfigSCE, so it seems that command isn't being carried out successfully from your environment. Assuming you are using Win7/R2, to verify the Audit Policy settings are being applied successully to Local Policy you can check the following folder on your computer:

    \Windows\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit

    You should see an audit.csv file that looks very similar to what is in the GPO backup under C:\Admin\SecurityPolicy\*****

    If the Audit folder does not exist or is empty... something is preventing the tool from completing this process successfully. I suspect the tool is not finding an environment variable defined for %TEMP%. Try modifying your script to ensure an environment variable exists for %TEMP%... point it to the C:\Admin\SecurityPolicy folder.

    If you send the contents of the C:\Admin\SecurityPolicy, we can try to duplicate what you are seeing.

    Monday, May 24, 2010 9:33 PM
  • Jeff/Mike,

    The problem with the Audit settings not exposing in the GUI in 2008R2 or 7x64 is that the LocalGPO.wsf script is not disabling WOW64 file redirection. So the Audit.csv file is being copied to "\Windows\SysWOW64\GroupPolicy\Machine\Microsoft\Windows NT\Audit".  I was able to solve this issue by disabling WOW64 file redirection and running LocalGPO.wsf /ConfigSCE and then Running LocalGPO.wsf /Path: etc...

    Hope this helps. Let me know.

     

    -Charles King

    Thursday, May 19, 2011 5:18 PM
  • Be sure to re-enable file re-direction when done!
    Thursday, May 19, 2011 5:19 PM