SQL Server Agent PowerShell subsystem job step fails when ExecutionPolicy has been set via GPO - by Nancy Hidy Wilson1

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 802686 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 9/27/2013 12:08:19 PM
Access Restriction Public


A default installation of SQL Server 2012 creates a SQL Agent job called syspolicy_purge_history which has a job step (3) that uses the PowerShell subsystem.  Apparently, this subsystem always attempts to run “set-executionpolicy RemoteSigned –scope process –Force” before executing the actual code requested in the job step command.  When the PowerShell ExecutionPolicy has been set at the MachinePolicy scope via a GPO, then this causes the PowerShell subsystem job step to fail as shown in the attachment.  We can reproduce this with any PowerShell Subsystem job step - not just the system job shown.  If a MachinePolicy or UserPolicy scope has been set via GPO (as shown in the attachment), then SQL Server should either not try to set a local scope or it should handle this error and continue to attempt to execute the PowerShell commands within the ExecutionPolicy dictated by the GPO.  
Sign in to post a comment.
Posted by Microsoft on 8/7/2017 at 2:11 PM
Hello, SQLPS.EXE has been updated for SQL2016, SQL2014 and SQL2012 in some recent CUs to address the issue you reported. See https://support.microsoft.com/en-us/kb/3122088 for more details.
Posted by Microsoft on 1/8/2014 at 8:47 AM
Thanks for the feedback. We triaged this issue and at this time do not plan to address this in a coming version of SQL Server.
Posted by Microsoft on 10/3/2013 at 12:04 PM
Hello Nancy.
Thank you for bringing this to our attention. We really do appreciate the feedback. We’ll investigate and get back to you.
-Walter A Jokiel, Program Manager, SQL Server (wajokiel@microsoft.com)