PowerShell execution policy GPO issue

My workplace just added a group policy to Turn On Script Execution in PowerShell and set it to “Allow Local and Remote Signed”. This went out to our Octopus Deploy instance and all of the servers with a tentacle installed.

This caused massive issues as deployments that took a minute were now taking upwards of 20 minutes as each step took around 10 minutes to start executing, we also experienced the same slow issues with health checks. We have now reverted the GPO but I believe you guys could add some kind of check to see if a group policy is active, or at least stop this slowness occurring?

One of our PowerShell developers said: “but it has become apparent that because of the way Octopus Deploy uses PowerShell, it tries to reset the execution policy to ‘ByPass’ whenever it runs, which now obviously fails because the machine sees a GPO set and blocks the change (and rightly so).”

If you guys need anymore information please ask.

Hi Ben,

Thanks for letting us know. As you mentioned, we bypass the execution policy usually, and we can’t run under policies that require signing. I don’t think there’s much we can do about it, but as you said, we might at least be able to detect the policy and log a warning or do something better than we currently do. We’ll look into it. Thanks again for letting us know.


Following up on this as the issue appeared again in our environment. Our GPO was set to allow remote signed and any local scripts, how come Octopus cannot run under this as surely anything distributed with Octopus is signed, and the scripts we execute are local?


Hi Ben,

The problem is determining what to sign the scripts with. We could sign them with our own self-signed certificate, but you’d need to add that to your trusted publisher store on each machine. Or you could provide us with a certificate/private key and we could sign them for you.

However it’s not that simple. Octopus doesn’t just invoke your script - we generate an intermediary bootstrapping script which we call, and that calls your script (that’s how we load variables into the PowerShell context). We’d have to sign every one of those layers. That means passing the private key to the remote machines and all the way down the stack. That’s quite a lot of work involved for something that isn’t a very common configuration, which is why we haven’t done it yet.

Hope this sheds some light,