通过代理执行 SSIS 时代理帐户失败
最近,当我创建一个 SQL Server Agent(2008) 作业来使用代理帐户执行 SSIS 包时,它失败并显示以下错误消息。这个例外是关于什么的?是什么原因造成的以及如何解决?
错误信息 以用户身份执行:blaw。无法为作业 0xD5A5 的步骤 1 创建进程(原因:客户端不拥有所需的权限)。这一步失败了。
注意:-它与代理服务帐户运行良好。
谢谢
Recently when I created a SQL Server Agent(2008) job to execute a SSIS package with proxy account, it failed with the below error message. What is this exception about? What causes it and how do I resolve it?
Error Message
Executed as user: blaw. The process could not be created for step 1 of job 0xD5A5 (reason: A required privilege is not held by the client). The step failed.
Note:-It is working fine with Agent Service account.
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我现在也在努力让它发挥作用。您尝试查看这些资源吗?
http://support.microsoft.com/kb/918760
http://technet.microsoft.com/en-us/library/dd440761(SQL.100) .aspx
http://technet.microsoft.com/en-us /sqlserver/ff686764.aspx
I am trying to get this to work right now as well. You try looking at these resources?
http://support.microsoft.com/kb/918760
http://technet.microsoft.com/en-us/library/dd440761(SQL.100).aspx
http://technet.microsoft.com/en-us/sqlserver/ff686764.aspx
您没有具体提到如何进行身份验证,但无论如何,这里有一个用于创建登录名、凭据和代理并向 SSIS 包授予权限的脚本:
You've not mentioned exactly how you're authenticating, but regardless, here's a script for creating a login, credential and proxy and granting permissions to SSIS packages:
刚刚解决了这个问题并得出了不同的解决方案。全球安全政策阻碍了这一进程。事实证明,出现此问题的开发服务器意外地应用了比运行良好的生产服务器更为严格的策略。不确定该策略下的哪个覆盖权限导致了该问题,但限制较少的策略仍然解决了该问题。基本上,请咨询您的 Active Directory 管理员,看看本地安全策略是否在出现问题的服务器上被锁定。
Just worked through this issue and came to a different resolution. A global security policy was getting in the way. It turns out the development server that was presenting this issue accidentally had a much more restrictive policy being applied than the production counterpart that was working fine. Not exactly sure which overridden permission under the policy was causing the issue, but a less restrictive policy resolved the issue nonetheless. Basically, check with your Active Directory admin if the Local Security Policy is locked down on the server presenting the issue.