I'm attempting to create a SQL Agent job that will run a PowerShell script that is saved on my system. However, the job fails with the following error:

A job step received an error at line 1 in a PowerShell script. The corresponding line is 'g:\PowerShellShare\Get-LastDBBackups.ps1'. Correct the script and reschedule the job. The error information returned by PowerShell is: 'AuthorizationManager check failed.

If I add the proxy account to local admins, it works, so it appears to be a permissions problem (leaving the account in local admin isn't an option for my environment).

The Windows Security log shows multiple Audit Failures with Event ID 4656 every time I run the job, all of them are from the proxy account attempting to access an object:

Object Server:      SC Manager
Object Type:        SERVICE OBJECT

A quick sc sdshow scmanager showed that Authenticated Users should have the access to scmanager:


Most puzzlingly, if I RUNAS the proxy account on the server and run the script, it runs just fine. It doesn't matter what script I attempt to run via the SQL Agent Job, attempting to execute any script results in the same behavior. I can however run other PowerShell commands, just not execute any scripts.

Hoping someone has run into this before and could point me in the right direction.

UPDATE: It seems the major problem is that when I'm executing from the SQL Agent Job, my proxy account isn't a member of the interactive implicit security group. It looks like that group is granting the proxy whatever permissions it needs to run the job successfully when I test it using RUNAS. I'm not able to track down all the permissions this group allows.

The Audit Failures I was seeing were for the WinHttpAutoProxySvc and CryptSvc services. I used sc sdshow and sc sdset to modify the permissions to those specific services so that the Authenticated Users permissions matched those of the Interactive Users group. The audit failures are now gone, but I still get the same error message in SQL when I execute the job.

  • 1
    What about the location of the script and the working directory? Are the permissions on both of those set such the script should have permissions to access and run with the account it's running under? And is it possible to change those to a location that everyone or all users have permissions to access and execute from? Dec 28 '12 at 20:36
  • The script that you want to execute from SQL Agent has to be accessible by the service account that the SQL Server Agent is using. So if you want the script to reside on your system, seperate from the SQL Server instance, the account has to have access to your system and the directory.
    – user47078
    Dec 28 '12 at 20:41
  • The script is in a directory the proxy has access to, and the working directory is the same (I changed it to a different directory just to be sure). I can RUNAS the proxy and execute the script fine, it's only when I attempt to run it from within a SQL Agent Job step that I have these problems.
    – MaddHatter
    Dec 28 '12 at 20:42
  • @ShawnMelton: The agent has access to the folder. I added the Agent account to local admins just to be doubly sure, to no effect.
    – MaddHatter
    Dec 28 '12 at 20:44
  • How are you calling the script within the Job Step?
    – user47078
    Dec 28 '12 at 21:00

Check your execution policy within Powershell; sounds like it might be failing because the default setting is "Restricted", which only allows Powershell to run as an interactive shell, and does not execute scripts at all. See the following link for details:


EDIT: Just realized the above link only describes syntax for "Set-ExecutionPolicy"; this link should provide some additional context also:


  • Created a job with: Get-ExecutionPolicy, what I got in return was: A job step received an error at line 1 in a PowerShell script. The corresponding line is 'get-executionpolicy'. Correct the script and reschedule the job. The error information returned by PowerShell is: 'Access denied The log is full of the 4656 errors as well. But I happen to know the execution policy is RemoteSigned, and that this script is not from the interwebs
    – MaddHatter
    Dec 28 '12 at 20:36

I know this thread is a bit old. I found this while i was troubleshooting a powershell agent job. I THINK the powershell its referring to in an agent job is powershell for SQL. You would need to set that execution policy by right clicking on something in SSMS and choosing start powershell.

I get this error running a job as powershell. If i make the job an Operating System (CMD) job it works by kicking off script with the command as: powershell.exe -File D:\Script Folder\myscript.ps1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.