SSRS - 无法确定作业所有者是否具有服务器访问权限 [SQLSTATE 42000]（错误 15404））
SQL Server Reporting Services，在 SSRS 中，计划似乎永远不会触发，但是查看 SQL 代理会发现与无法解析用户帐户相关的权限问题。
似乎 SQL 代理并不依赖于缓存或任何巫毒 Windows 神奇的工作方式。
链接文本 此处列出了修复... 编辑 -
以上是我用来解决此问题的修复程序，是否有人找到此问题的任何其他解决方法或解决方案？
默认情况下，SSRS 生成的计划似乎以此虚拟用户帐户运行。如何更改此默认值？ SSRS 是否以服务运行的用户身份创建作业？
谢谢 莱姆斯
SQL Server Reporting Services, in SSRS it seems like Schedules never fire, however a look at the SQL Agent reveals a permission issue related to not being able to resolve a user account.
Seems SQL Agent does not rely on caching or whatever voodoo Windows magically works.
link text
Fix is listed here...
edit --
Above is the fix I used to workaround this issue, has any one found any other work arounds or resolutions to this issue?
It seems that by default the SSRS Generated Schedules are run as this phantom user account. How do I change this default? Is SSRS creating the jobs as the user the service runs as?
Thanks Remus
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我遇到了同样的问题。这是我修复它的方法。
问题描述
当设置 SSRS 报告订阅在给定时间运行时，我会等待时间过去，然后发现“上次运行”时间戳没有更改。我的订阅似乎尚未运行。
相关故障排除信息
SSRS 报表订阅作为报表服务器 Web UI 在幕后为您创建的 SQL 作业执行。
在查看为我的报告订阅创建的作业时，我发现它总是失败并出现以下错误：
<块引用>
作业失败。无法确定作业 0814588B-D590-4C45-A304-6086D5C1F559 的所有者（域\用户名）是否具有服务器访问权限（原因：无法获取有关 Windows NT 组/用户“域\用户名”的信息，错误代码 0x5。[SQLSTATE 42000]（错误15404））。
在 Sql Server 配置管理器中，我可以看到“SQL Server Reporting Services”服务被配置为使用 AD 用户帐户运行。
在 Sql Server 配置管理器中，我可以看到“SQL Server”服务被配置为使用本地 Windows 帐户运行。
正如 @Remus Resanu 指出的，SQL 错误 15404 是指 EXECUTE AS 上下文无法模拟时的异常。
正如 @Remus Resanu 指出的，SQL 错误
解决方案
宾果！ #4和#5是问题的关键。 SQL Server 服务（本地 Windows 用户帐户）尝试对 AD 中的用户“domain\userName”进行身份验证，但它无法执行此操作，因为它没有访问 AD 资源的权利/权限。
我将 SQL Server 服务更改为 AD 用户帐户，重新启动 SQL Server 和 SQL Server 代理服务，重新运行 SQL 作业，天哪，成功了！
I was running into the same issue. Here is how I fixed it.
Problem description
When setting an SSRS report subscription to run at a given time, I would wait for the time to pass and then find that the "Last Run" timestamp did not change. My subscription appears not to have run.
Relevant troubleshooting info
SSRS report subscriptions are executed as SQL Jobs that the Report Server web UI creates for you behind the scenes.
When looking at the job that was created for my report subscription, I saw that it always failed with the error:
In the Sql Server Configuration Manager I could see that the "SQL Server Reporting Services" service was configured to run using an AD user account.
In the Sql Server Configuration Manager I could see that the "SQL Server" service was configured to run using a local Windows account.
As @Remus Resanu pointed out, the SQL error 15404 refers to an exception when EXECUTE AS context cannot be impersonated.
Solution
Bingo! #4 and #5 are the key to the problem. The SQL Server service (a local Windows user account) was trying to authenticate the user "domain\userName" in AD, which it could not do because it does not have the right/permission to access AD resources.
I changed the SQL Server service to us an AD user account, restarted the SQL Server and SQL Server Agent services, re-ran the SQL job and, blamo, success!
我做了两件事，现在可以正常工作了。
1) 进入“SQL Server 配置”，更改“SQL Server 代理”-“登录身份”以匹配上面的“SQL Server”。
2）其次，打开“Microsoft SQL Management Studio”，在“SQL Server Agent”处，展开“作业”，您应该能够看到您创建的作业。右键单击它并转到“属性”。
3) 更改所有者以匹配上面的“SQL Server 代理”。
之后，我可以毫无问题地执行维护计划。
I did 2 things and it's now working.
1) Go to "SQL Server Configuration", change the "SQL Server Agent" - "Log On As" to match the "SQL Server" above.
2) Secondly, open "Microsoft SQL Management Studio", at the "SQL Server Agent", expand the "Jobs" and you should be able to see your created job. Right click on it and go to "Properties".
3) Change the owner to also match the "SQL Server Agent" above.
After, I'm able to execute the Maintenance Plan without any issue.
15404 是 EXECUTE AS 上下文无法模拟时的异常。造成这些错误的原因有很多。最常见的原因是：
ACCESS_DENIED）ERROR_NO_SUCH_DOMAIN），正确的解决方案始终取决于错误代码，这是尝试获取模拟用户身份令牌时的操作系统错误：首先在 系统错误代码表（或启动windbg，执行环回非侵入式内核调试连接并进入！error，这是我更喜欢的原因更快...）。
那么，约翰...您是否真的有疑问，或者只是随机发布了部分信息？
15404 is the exception when EXECUTE AS context cannot be impersonated. Reasons for these error are plenty. The most common reasons are:
ACCESS_DENIED)ERROR_NO_SUCH_DOMAIN)The proper solution is always dependent on the error code, which is the OS error when trying to obtain the impersonated user identity token: one searches first for the error code in the System Error Codes table (or fires up windbg, does a loopback non-invasive kernel debug connection and goes !error, which is what I prefer cause is faster...).
So, John... do you actually have a question, or just posted a random piece of partial information?
只需按照图像中的步骤操作
Just follow this steps in images