Execution policy can prevent scripts from running. It is designed to be a user preference setting, so you should always be able to change the effective execution policy. In some environments, though, group policy forces settings on you and may prevent running scripts.

In such a case, it might be an option for you to reset the internal PowerShell authorization manager. Once you replace it with a default instance, you can run PowerShell scripts regardless of any previous execution policy setting:

$context = $executioncontext.gettype().getfield('_context','nonpublic,instance').getvalue($executioncontext); $field = $context.gettype().getfield('_authorizationManager','nonpublic,instance'); $field.setvalue($context,(New-Object management.automation.authorizationmanager 'Microsoft.PowerShell'))

Remember: this is not a security issue. Execution policy is meant to be controlled by the user. It is not a security boundary.

Twitter This Tip! ReTweet this Tip!

  • This is not meant to be controlled by the user, no more than a user has control of any other enterprise risk management policy / configuration/ product setting. No, more than a enterprise user installing there on AV or host-based firewall solution or disabling said same.  If it's your machine, do as you will, in a corporate environment, there are reasons those settings are there, and if you are making attempt to circumvent the corporate risk management policy, you are putting the enterprise at risk which they are trying to mitigate. You do not need to change the host system environment (computer level) to run scripts. IMHO execution setting should be set per session and all scripts should be signed with a corporate PKI signing cert. I don't agree with orgs who try to block PoSH use holistically, that just serves as a detriment to enterprise deployment, management efforts and even security monitoring / remediation / forensics. PoSH use is a requirement for virtually all of MS enterprise products and services. So, PoSH should be controlled as to who can use it, on what and where. Yet, the normal everyday office user would 99.99999, not ever need to use PoSH. Administrators would of course. If you are trying to circumvent this, then this probably means you are not an admin in the enterprise, and doing this sort of thing, as noted by swallen621 could result in an RPE (resume producing event). If they set the GPO for it to be restricted / not used, then, if they are wise, then the have set a GPO enterprise -wide for PoSH monitoring. Which means you will be discovered when an alert is triggered by the monitoring effort or the next security audit.

  • If your administrator has set a group policy to set the execution policy, circumventing this, could lead to unemployment. So, it may, or may not be a security issue. It can definitely be an HR issue though.