It’s a matter of 32-bit redirection.
Calls to the \Program Files or \Windows\System32 are automatically redirected to \Program Files (x86) or \Windows\Syswow64. This is to maintain backwards compatiblity.
You’ll need to use the ‘x64 files’, ‘x64 folders’, ‘native files’, or ‘native folders’ inspectors to get to those paths.
Try these to see the differences…
q: exists file "c:\windows\system32\grouppolicy\machine\registry.pol"
q: exists native file "c:\windows\system32\grouppolicy\machine\registry.pol"
q: exists x64 file "c:\windows\system32\grouppolicy\machine\registry.pol"
In the Action, you’ll need to add the line
action uses wow64 redirection false
on any line before a ‘wait’ or ‘run’ command to have the processes spawned off as 64-bit rather than 32-bit.
That said, registry.pol may well be locked. It’s been a while since I tried it but one workaround I’ve used a few years ago was to first move registry.pol to a new file (the ‘move’ is allowed because the file handles remain the same, any processes locking the file just keep reading it from their existing handles) and a second task to delete the moved copy of it.