The following action script is working successfully on Fixlet Debugger, but when I run it via fixlet, it does not create a new “GroupPolicy” folder on "C:\WINDOWS\System32"
action uses wow64 redirection {not x64 of operating system}
delete __createfile
delete resetgp.bat
createfile until _eof
RD /S /Q “C:\WINDOWS\System32\GroupPolicy.old”
move C:\WINDOWS\System32\GroupPolicy C:\WINDOWS\System32\GroupPolicy.old
RD /S /Q “C:\WINDOWS\System32\GroupPolicy”
echo n | gpupdate /force
_eof
Do you end up with a folder named C:\WINDOWS\sysWOW64\GroupPolicy.old
Any clues/errors from the client logs while taking the action script?
If you manually run resetgp.bat by double clicking, does it give the desired result?
Instead of using System32 you could instead try sysnative which is a virtual folder way to reference the correct location without disabling redirection.
… hmm actually I’m seeing examples where they do just use wait or waithidden with a BAT file directly, so maybe not? I generally prefer to call CMD directly and pass it the BAT file to run, though I forget how to do that at the moment.
I just tested your script on my Windows 2016 x64 box on BigFix 10.0.0 and it seems to work as I expect.
The 64 bit native system32/GroupPolicy folder is renamed, as expected and the 32 bit version is untouched.
Screenshots to help explain
Starting State - Green box is the native system folder, the one that I think you want to change
Looks like a few extra parameters might need to go into the gpupdate invocation?
One more detail.
When I run gpupdate /force from a command line on my Windows 2016 box, the Group Policy folder is not recreated. (Even after a reboot)
GroupPolicy is usually a protected folder, and you might often have issues deleting it as the OS / Group Policy Client will have the directory or it’s files locked for reading. If that’s the case you’ll get intermittent success or failure just based on what other processes on the machine are doing at the time.
