In order to understand what is going on, I need to go back to the SQL Server Agent and check the logs there. When you create a Report Server Subscription on a Schedule it creates a new Job for this Schedule and this Job initiates the Event that triggers the scheduled report(s) to run.You can read more about it here.
First I need to identify what Job ID is behind the schedule I want to investigate. The Jobs are created using a Unique ID (GUID) and in order to link the actual report to its schedule ID I run this SQL on the Reporting Server Database (Normally called "ReportServer_INSTANCENAME"):
select s.Description, us.UserName, s.LastStatus, s.LastRunTime, c.Path, uc.UserName, rs.ScheduleId, from ReportServer.dbo.Subscriptions s join ReportServer.dbo.Catalog c on c.ItemID = s.Report_OID join ReportServer.dbo.ReportSchedule rs on rs.SubscriptionID = s.SubscriptionID join ReportServer.dbo.Users uc on uc.UserID = c.ModifiedByID join ReportServer.dbo.Users us on us.UserID = s.OwnerId
Going back to the Job, I can see from the Job History it doesn't even get to the first step of the Job. Since this is AX, the Job is run under the same account as the Business Proxy Account. That is how SSRS normally is configured in relation to AX. The error from the history log actually says "the owner of job does not have server access". The job is actually set to run in the context of a user that does have server access, but somehow (a bug maybe) this is ignored by the SQL Server Agent.
The solution is:
- Change owner of the job to the SQL Server User that has the necessary permissions to run the report
- Grant the SQL Server User permissions to operate on the the Report Server Database (It does needs permissions to inject data, however I gave it full db_owner permissions)
- Test the job by doing a manual run
If the job still fails, you can investigate the Job history for any errors.
No comments:
Post a Comment