SQL Server Agent作业步骤问题：PowerShell/CMD类型执行失败排查

这种情况我之前踩过好几个坑，直接在PowerShell里跑顺得很，一放进SQL Server Agent作业步骤就罢工，核心原因基本都绕不开权限、执行上下文或者环境差异这几个点，咱们一个个捋：

1. 运行权限上下文不匹配 #

SQL Server Agent默认用的是SQL Server Agent服务账户，不是你登录Windows的管理员账户——哪怕你手动选了“Run as”某个代理账户，也得确认这个账户权限够：

• 如果你的脚本要操作本地文件、系统资源，得给Agent服务账户（或代理账户）对应的Windows权限，比如读写目标文件夹、执行特定程序的权限；
• 如果要操作SQL Server本身，得确保这个账户有对应的数据库权限，比如EXECUTE、ALTER ANY JOB这类；
• 举个典型例子：你本地PowerShell能读写C:\Temp，但Agent账户可能没权限访问这个文件夹，直接就报“拒绝访问”。

2. PowerShell执行策略限制 #

你本地的PowerShell执行策略可能设成了RemoteSigned或Unrestricted，但SQL Server Agent调用的PowerShell（尤其是旧版SQLPS模块）可能用的是更严格的Restricted策略，直接阻止脚本运行。
解决办法很简单，在作业步骤的PowerShell脚本开头加一句：

Set-ExecutionPolicy RemoteSigned -Scope Process -Force

用-Scope Process只会针对当前作业步骤生效，不会修改全局的执行策略，很安全。

3. 环境变量差异 #

你本地PowerShell的环境变量（比如PATH里包含了某个工具的路径）和SQL Server Agent服务账户的环境完全是两套。比如你本地能直接调用7z.exe，但Agent环境里找不到这个工具的路径，自然跑失败。
排查方法：在作业步骤里输出Agent的环境变量，和本地对比：

Get-ChildItem Env: | Out-File "C:\Temp\AgentEnv.txt"

缺啥补啥就行，比如在脚本里手动添加路径：

$env:PATH += ";C:\Program Files\7-Zip"

4. 作业步骤类型选错了 #

注意！SQL Server Agent里的PowerShell类型作业步骤默认用的是旧版的SQLPS模块，不是你本地的PowerShell 7或新版PowerShell。如果你用了新版语法（比如ForEach-Object -Parallel），在SQLPS里直接报错。
解决办法二选一：

• 改用CMD类型作业步骤，直接调用系统的PowerShell执行脚本：

  powershell.exe -ExecutionPolicy RemoteSigned -File "C:\YourScript.ps1"
  

• 或者在PowerShell作业步骤里明确指定新版PowerShell的路径，比如：

  & "C:\Program Files\PowerShell\7\pwsh.exe" -ExecutionPolicy RemoteSigned -File "C:\YourScript.ps1"
  

5. 别用相对路径！ #

本地跑脚本时的相对路径是你当前的工作目录，但SQL Server Agent的默认工作目录是C:\Program Files\Microsoft SQL Server\MSSQLXX.MSSQLSERVER\MSSQL\Binn，你写的.\MyScript.ps1在Agent环境里根本找不到。
所有文件路径都要写绝对路径，比如C:\Scripts\MyScript.ps1，别偷懒。

6. 抓错误日志才是硬道理 #

要是还是找不到问题，一定要加错误捕获，把具体报错信息存下来：
在PowerShell脚本里加：

try {
    # 你的核心脚本内容
} catch {
    $_ | Out-File "C:\Temp\JobErrorLog.txt" -Append
    throw  # 抛出错误让Agent标记作业失败
}

也可以直接去SQL Server Agent的日志里找线索，一般在SQL Server Management Studio > SQL Server Agent > Error Logs里。

内容的提问来源于stack exchange，提问作者Gena