SSIS包部署至SSISDB后SQL Agent执行脚本任务报错排查

这种本地调试正常、部署到SSISDB后SQL Agent一执行就炸的问题真的很磨人，我帮你梳理几个最容易踩坑的配置点，大概率能定位到问题：

1. FTP/文件系统的权限是重灾区 #

虽然你已经把SQL Agent服务账户改成了专用Windows账户，但要注意：这个账户是在SQL Server所在服务器的上下文运行的，不是你开发机的账户！

• 如果是访问FTP服务器：要确保该Agent账户能通过FTP协议正常登录、读取目标文件（可以在SQL Server机器上，用这个账户登录FTP测试）。
• 如果是访问共享文件夹：必须给该账户分配共享权限（至少读权限）和文件夹的NTFS权限，而且路径要用UNC格式（比如\\DevMachine\FileShare），不能用开发机的本地路径。

2. 脚本任务的运行上下文要对应 #

如果你的SQL Agent作业步骤是用SSIS代理账户（不是SQL Agent服务账户本身）执行的，那得同步给这个SSIS代理账户也配置文件/FTP的访问权限。另外，有些脚本任务会用到特定的系统API，可能需要给Agent账户授予「本地登录」或者「访问网络资源」的权限，可以在SQL Server机器的本地安全策略里调整。

3. 文件路径别踩坑 #

本地SSDT运行时用的路径，放到SQL Server机器上可能完全不可用：

• 绝对不能用开发机的本地路径（比如C:\MyFiles\data.xml），SQL Server机器上没有这个路径；
• 必须用UNC路径或者SQL Server机器能访问的网络路径，而且要确保Agent账户能解析到这个路径（比如开发机的共享要在SQL Server机器上能正常访问）。

4. SSISDB的权限不能忘 #

检查执行包的作业账户是否有SSISDB的足够权限：

• 至少要属于ssis_admin角色，或者有对应包的执行权限；
• 如果包用了环境变量，要确认部署后环境变量的值已经正确映射到SQL Server环境下的实际路径/FTP地址，别还是开发机的配置。

5. 先抓详细错误日志再说 #

别只看“脚本任务报错”这个模糊信息，去抓更详细的日志：

• 开启SSIS包的详细日志，或者查看SQL Agent作业历史里的错误详情（比如是否是「文件找不到」「权限拒绝」这类具体错误）；
• 去SQL Server机器的Windows事件日志里找相关记录，Agent账户访问资源时的权限问题通常会在这里留下痕迹。

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