Exception stack when trying to release a vNext template onto a machine in a domain with unrestricted PowerShell execution policy
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.AggregateException: One or more errors occurred. ---> Microsoft.TeamFoundation.Release.Common.Helpers.OperationFailedException: System.AggregateException: Failed to set execution policy or global variables on the machine. Consult the logs below for details of the error.
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 RemoteSigned -Scope Process –Force
CategoryInfo :PermissionDenied: (:) [Set-ExecutionPolicy], SecurityException FullyQualifiedErrorId :ExecutionPolicyOverride,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand ---> System.Security.SecurityException: Security error.
at System.Management.Automation.MshCommandRuntime.ThrowTerminatingError(ErrorRecord errorRecord)
--- End of inner exception stack trace ---
· Release Management Server 2013.3 above
· Deployment machine in a domain OU with PowerShell execution policy set as unrestricted
This is a by design behavior with Release Management. RM sets the execution policy at the process scope at remote signed and then proceeds with the deployment. This is done in the beginning of a vNext-deploy, to elevate the execution policy on production machines that usually have restrictive execution policy. This the reason for the command Set-ExecutionPolicy RemoteSigned -Scope Process –Force being executed.
On a machine with the execution policy set to un-restricted this command would fail. And due to this exception RM fails the release. If you see a similar stack during release you can confirm your execution policy by running this command in a PowerShell Get-ExectionPolicy –list and check on the machine policy and user policy. If it is unrestricted then you may have to check on the work around.
The behavior is by design and hence the work around would be to set the execution policy setting in group policy. But the first question you really need to ask would be to your AD admins – if the execution policy is forced from AD.
· If the un-restricted execution policy is being forced by the AD level group policy, then we need to change it there. The policy set at AD level would take precedence over the system setting and hence there would be no point in changing the values on the machine.
· If it’s a local setting, then you can change it on your local machine.
1. If it’s the local machine setting that you want to change run (Win+R) gpedit.msc. This will open the group policy editor.
If it’s the AD, you should check with your AD admins. You would have to change it from Group policy management editor from one of the domain controller machines and you may not have access. This link would be a good start on how to get there.
2. We need to make the same changes to Computer Configuration and User Configuration.
· Go to Administrative Templates/Windows Components/Windows PowerShell
· Double click this policy Turn on Script Execution
· Make it Not Configured or Disabled or you can set it enabled (RemoteSigned)
Note: This behavior may change in the future releases. Keep checking http://blogs.msdn.com/b/visualstudioalm/ for updates on features added each new release.
Content created by – Venkata Narasimhan
Content reviewed by – Romit Gulati