Visual Studio Extension appears to fail to run PowerShell if execution policy set in GPO, 2.8.6 and 3.0

[cerebrate]

Opening Package Manager Console produces the message:

"Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of Unrestricted. Type "Get-ExecutionPolicy -List" to view your execution policy settings. For more information please see "Get-Help Set-ExecutionPolicy"."

But no PowerShell prompt ever appears. Similarly, attempting to install a package produces the same message on attempting to execute the script file from the package, followed by:

Install failed. Rolling back...

Attempting to upgrade an existing package instead produces:

Failed to initialize the PowerShell host. If your PowerShell execution policy setting is set to AllSigned, open the Package Manager Console to initialize the host first.

[feiling]

To help us investigate the issue, could you tell us:

• The build number of the operating system?
• What's the output when you open powershell and run Set-ExecutionPolicy -Scope Process ByPass?

[cerebrate]

Sure, whatever helps.

Build is the latest - 10240.

Output is:

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic at
http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): y
set-executionpolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by
a policy defined at a more specific scope. Due to the override, your shell will retain its current effective
execution policy of Unrestricted. Type "Get-ExecutionPolicy -List" to view your execution policy settings. For more
information please see "Get-Help Set-ExecutionPolicy".
At line:1 char:1

• set-executionpolicy -scope process Bypass

• - CategoryInfo          : PermissionDenied: (:) [Set-ExecutionPolicy], SecurityException
  - FullyQualifiedErrorId : ExecutionPolicyOverride,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand
  
  

(Execution policy is set to Unrestricted here by group policy on all the development machines; if it'll help, I can disable that for debugging purposes.)

[mwinkler]

Hi
I have the same issue here (Win7-64bit, VS2015RTM).
Our corporate domain policy are set to "RemoteSigned".
If i try to bypass with "Set-ExecutionPolicy -Scope Process ByPass" i get the same security exception as cerebrate.
This error prevents VS to install some nuget packages like EntityFramework, JsonNet.
In VS2013 (Update 4) there are no issues with the package manager.

[pbar]

Same issue here, on Win 8.1.
Both VS2015RTM (14.0.23107.0) and VS2013-5 (12.0.40629.00) are showing this problem. (I installed VS2013 update 5 yesterday. Before that, Nuget PMC was working just fine on VS2013-4.)

[last-Programmer]

Same issue here getting the error message Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of Unrestricted. Type "Get-ExecutionPolicy -List" to view your execution policy settings. For more information please see "Get-Help Set-ExecutionPolicy"

Unable to install/update packages in solution

[joswalt]

Same issue on Win 7-64bit, VS2013 Update 5). Nuget PMC was working before I ran Update 5.

[rob-hayes-volusion]

Same here. Anybody find a fix?

[JaredShaver]

Same configuration as joswalt and experiencing the problem. It also occurs in Visual Studio 2015 RTM.

Here is the output of my Get-ExecutionPolicy -list

                                                  Scope                                             ExecutionPolicy
                                                  -----                                             ---------------
                                          MachinePolicy                                                RemoteSigned
                                             UserPolicy                                                   Undefined
                                                Process                                                   Undefined
                                            CurrentUser                                                   Undefined
                                           LocalMachine                                                   Undefined

[rossipedia]

Are those of you experiencing this on computers that are joined to a domain? It seems as though the GPO setting for ExecutionPolicy might be affecting this. Output on my machine (joined to a domain):

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy    Unrestricted
   UserPolicy    Unrestricted
      Process       Undefined
  CurrentUser       Undefined
 LocalMachine       Undefined

[JaredShaver]

@rossipedia Yes I am joined to a domain. This all worked prior to Update 5 being installed in VS2013. I have coworkers who are joined to the same domain who have not installed the update and are able to load NuGet package manager just fine.

[pbar]

@rossipedia - Same here (I am on a domain, and it worked fine prior to VS2013-5)

[rob-hayes-volusion]

Same as @pbar and @JaredShaver. I did the temp fix/delete from here to get back up and running. https://powershellpanda.wordpress.com/2013/12/01/override-gpo-for-powershell-execution-policy/ No telling when/if it will come back.

[rossipedia]

@RHayes990 hooray! That worked, thanks!

[pbar]

Thanks @RHayes990, that temp fix works for me too. Here's a quick like regedit script to do it.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell]
"ExecutionPolicy"=-

[joswalt]

I am on a domain as well. Here is my listing:

Get-ExecutionPolicy -list

        Scope    ExecutionPolicy
        -----    ---------------
MachinePolicy       RemoteSigned
   UserPolicy          Undefined
      Process          Undefined
  CurrentUser          Undefined
 LocalMachine          Undefined

Also, why would this change with Update 5. These settings have not changed.

[rossipedia]

MachinePolicy apparently takes the highest precedence. Not exactly sure what VS 2015 is doing differently from VS 2013.

[rossipedia]

Also, I'm pretty sure this isn't restricted to Windows 10, as a co-worker on Windows 8 encountered the same thing.

[cerebrate]

@rossipedia Yes, also joined to a domain. @RHayes990 's fix works for me, too, when also expanded to cover the HKCU: equivalent of that key.

[joswalt]

Removing the entry for the MachinePolicy fixed the issue for me for now. I'm not sure what else that may impact that needed the MachinePolicy to be RemoteSigned.

Get-ExecutionPolicy -list

        Scope    ExecutionPolicy
        -----    ---------------
MachinePolicy          Undefined
   UserPolicy          Undefined
      Process          Undefined
  CurrentUser          Undefined
 LocalMachine          Undefined

[SathishN]

Removing the value for the MachinePolicy fixed for me as well.
E.g:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell]
"ExecutionPolicy"=

[StefanSchoof]

Setting the milestone only to 3.2.0 seems to underestimate this bug. As far I can see this affects many users in enterprises (all in a domain?) and nuget is not operational without a workaround. Without nuget it is not possible to create a new Web Project. So this is the first impression of the VS2015 RTM for this users.

There is also a stack overflow thread with this problem: Nuget PMC policy settings

[damiarnold]

This is definitely a bug with the VS2013 2.8.6 version (2.8.60610.756). Reverting back to NuGet Package Manager 2.8.5 on VS2013 fixes the issue for me, right now. In my case, there were domain GPOs that enforced the use of RemoteSigned for the execution policy.

This issue was not present in whatever version of NuGet package manager I was using in VS2015 RC edition, but the latest 3.0.60624.657 version that came with the VS2015 RTM is definitely affected by this same issue. I'll be investigating the registry settings overrides, next...

This is definitely a show stopper for developers in security-conscious domains.

[JaredShaver]

Editing HKLM is not an option for developers who are not administrators.

[csharpfritz]

We have done some research and have acknowledged this issue as being introduced as part of a bug fix that was submitted for the 2.8.6 and 3.0 RTM. The issue listed with the known issues on our blog post announcing the 3.0 and 2.8.6 releases We are going to recommend users follow the workarounds that have already been suggested and a fix is scheduled for the 3.2 release.

[NickCraver]

@csharpfritz What is the timeline on 3.2? This affects every domain-joined developer in many companies (including here at Stack Overflow). If 3.2 is more than a week away I think your team needs to re-evaluate and release a fix much sooner. This is a critical issue and needs to be treated as such.

[cerebrate]

I have to concur with @NickCraver and @damiarnold. While I can use the workaround temporarily, long-term use of it risks breaking other things that depend on the domain policy being set. I don't think it can be prioritized too highly under the circumstances - maybe even to the point of its own interim release.

[oising]

Easiest/correct fix in my opinion is the swap out the PSAuthorizationManager for a default "null" AuthorizationManager in the NuGet managed runspace when you initialize the host. This will not affect ISE or powershell.exe hosts. I blogged about this a couple of years ago:

http://www.nivot.org/blog/post/2012/02/10/Bypassing-Restricted-Execution-Policy-in-Code-or-in-Script

InitialSessionState initial = InitialSessionState.CreateDefault(); 

// Replace PSAuthorizationManager with a null manager
// which ignores execution policy 
initial.AuthorizationManager = new
      System.Management.Automation.AuthorizationManager("NuGet"); 

// Extract psm1 from resource, save locally 
// ... 

// load my extracted module with my commands 
initial.ImportPSModule(new[] { <path_to_psm1> }); 

// open runspace 
Runspace runspace = RunspaceFactory.CreateRunspace(initial); 
runspace.Open(); 

RunspaceInvoke invoker = new RunspaceInvoke(runspace); 

// execute a command from my module 
Collection<PSObject> results = invoker.Invoke("my-command"); 

// or run a ps1 script     
Collection<PSObject> results = invoker.Invoke(@"c:\program files\myapp\my.ps1");

For the moment, you can probably get away with running the following script once in the nuget host via the interactive window and it will henceforth ignore group policy enforced polices (and every other scope too.)

function Disable-ExecutionPolicy {
    ($ctx = $executioncontext.gettype().getfield(
        "_context","nonpublic,instance").getvalue(
            $executioncontext)).gettype().getfield(
                "_authorizationManager","nonpublic,instance").setvalue(
        $ctx, (new-object System.Management.Automation.AuthorizationManager `
                  "Microsoft.PowerShell"))
}
Disable-ExecutionPolicy

The above function does invoke reflection, yes, but it works in powershell v3, v4 and v5. It does not require administrative rights.

[abpatel]

This worked for me on a domain joined machine without having to futz around with registry or GPO settings:

Set-ExecutionPolicy -Scope LocalMacine ByPass

[rossipedia]

@abpatel that solution is only applicable if you don't already have a LocalPolicy or GroupPolicy setting for ExecutionPolicy. What is your output for Get-ExecutionPolicy -List ?

[csharpfritz]

We are planning a fix to be released next week that will address this issue. Please watch this space for updates.

[csharpfritz]

A hotfix is now available to install and we are confident it will unblock you. Please grab the install from one of these locations appropriately:

2.8.7 for VS 2013:
https://github.com/NuGet/Home/releases/download/2.8.7/NuGet.Tools.vsix

3.1.1 for VS 2015:
https://github.com/NuGet/Home/releases/download/3.1.1/NuGet.Tools.vsix

We will publish these to the Visual Studio gallery next week.

[meh-uk]

FWIW I updated to Visual Studio 2013 Update 5 on Friday evening and it pulled down the troublesome version of NuGet so it wasn't working this morning with the same errors as above.

However when I installed 2.8.7 from the links above the problem went away and all seems to be behaving itself :).

Thanks guys for getting a patch out so quickly!

[JohnsonY2013]

Owh~, the hotfix is very helpful. It works for me.
I was stuck in this issue for a whole day.

[govind-mukundan]

Well I've installed VS2015, package manager console 3.1.1.0 and Powershell 4.0. But NuGet is stuck at "Initializing Power Shell Host" for ever.

[tmorrow-hyphensolutions]

3.1.1 for VS 2015 fixed it for me.
But I had to go to GitHub and download it instead of the link in this conversation for some reason.
https://github.com/NuGet/Home/releases/

I had to run the install as admin so it would not hang;
Otherwise, NuGet is stuck at "Initializing Power Shell Host" forever.

[govind-mukundan]

Yeah it does work, turns out my issue was that I was using posh-git and had the following script configured:

. 'C:\Users\govind.mukundan\Documents\WindowsPowerShell\Modules\posh-git\profile.example.ps1'

if ($host.Name -eq 'ConsoleHost')
{
Import-Module PSReadline
}

Removing the script, solved the hang issue.

[piers7]

FWIW SQL Server Agent has the same bug when running PowerShell agent steps, and it's taken me about 6 months working with Microsoft Premiere Support to get them to admit it's a bug, whereas you guys fixed it in a matter of days. Admittedly it's a more critical issue for you guys, but still, credit where credit's due.

[mortb]

This did work for me. I had a reinstall of VS2013 update 5 and package manage stopped working, after the hotfix above it does. Great :)

[Stazia]

It worked for me as well:) thank you!

[Sunitasahoo]

This version worked for me :) Thank you so much.
2.8.7 for VS 2013:
https://github.com/NuGet/Home/releases/download/2.8.7/NuGet.Tools.vsix

[thecopypaster]

Joswalt and Satish's steps worked for me.
Removing the value for the MachinePolicy fixed for me as well.
E.g:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell]
"ExecutionPolicy"=

[ghost]

csharpfritz 2015 Patch worked for me. Thanks a bunch. Cheers.
Win8 VS 2015 V.14.0.
3.1.1 for VS 2015 (Posted By: csharpfritz ):
https://github.com/NuGet/Home/releases/download/3.1.1/NuGet.Tools.vsix

[Sivaani]

Excellent csharpfritz. Worked for me. Thank you so much for sharing this.

[traktraktrugui]

I'm was having the same problem as you.
If you have using some scripts in powershell that changes the prompt, will have problems.
In my case, I was using posh-hg, and sometimes Enumerator-Prompt

[ethan-deng]

2.8.7 for VS 2013:
https://github.com/NuGet/Home/releases/download/2.8.7/NuGet.Tools.vsix

works.

[gitberry]

@RHayes990 your link worked for me as well. Thanks!

[stunney]

I have installed the latest NuGet VSIX for VS 2015 and I am still unable to create a simple ASP.NET WebAPi project :( I'm on a corporate dev environment where LocalMachine and UserPolicy settings are locked. How can I get around this?

[shuklavijay]

I was experiencing the same issue. Below is how I resolved it.

Open Visual Studio > Tools > Extensions and Update > Updates -

In my case it was asking to update "Nuget Package Manager for Visual Studio 2013".

After update and restart, the issue got resolved.

[egurb]

@csharpfritz thanks for the fix link!

[Gheims]

Get-ExecutionPolicy -list

    Scope ExecutionPolicy
    ----- ---------------

MachinePolicy - Undefined
UserPolicy - Undefined
Process - Undefined
CurrentUser - RemoteSigned
LocalMachine - Unrestricted