Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SSRS - Unable to determine if the owner of job has server access [SQLSTATE 42000] (Error 15404))

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

like image 848
john.da.costa Avatar asked Dec 15 '09 04:12

john.da.costa


1 Answers

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

  1. SSRS report subscriptions are executed as SQL Jobs that the Report Server web UI creates for you behind the scenes.

  2. When looking at the job that was created for my report subscription, I saw that it always failed with the error:

    The job failed. Unable to determine if the owner (domain\userName) of job 0814588B-D590-4C45-A304-6086D5C1F559 has server access (reason: Could not obtain information about Windows NT group/user 'domain\userName', error code 0x5. [SQLSTATE 42000] (Error 15404)).

  3. 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.

  4. In the Sql Server Configuration Manager I could see that the "SQL Server" service was configured to run using a local Windows account.

  5. 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!

like image 85
Vince Horst Avatar answered Nov 14 '22 21:11

Vince Horst