title: SSRS Subscription in SQL Agent Failing - Unable to determine if the owner of job has server access
body: <p>I have done much searching on this without a solid solution. </p>
  
  <p>I just set up a new SSRS instance on the same server as my SQL 2016 instance. Everything is running fine report wise, etc. The problem is that when a report is scheduled, it creates a Sql Agent Job in SQL Server, and the SQL Agent is erroring out with the following:</p>
  
  <blockquote>
    <p>The job failed. Unable to determine if the owner
    (MyDomain\ReportService) of job 17F8E31D-0838-4829-8C3C-E3FE5BBD3483
    has server access (reason: Could not obtain information about Windows
    NT group/user 'MyDomain\ReportService', error code 0x5. [SQLSTATE
    42000] (Error 15404)).</p>
  </blockquote>
  
  <p><strong>Current setup:</strong></p>
  
  <ol>
  <li>SSRS using an Active Directory account as the service account called
  Report Service</li>
  <li>Sql Server 2016 Engine is using an Active Directory account as the service
  account called SqlService  </li>
  <li>Both SSRS and SQL Database are on the same machine </li>
  <li>I double checked that SqlService is SysAdmin and has all other
  permissions, and non-SSRS jobs run fine</li>
  </ol>
  
  <p><strong>From my research, I can solve this in one of three ways:</strong></p>
  
  <ol>
  <li><p>Change the SSRS SQL Agent job created by SSRS to be owned by SA (by
      default the job is owned by MyDomain\ReportService). The problem
      with this is that I would have to do this every time a user creates
      a new subscription via SSRS or create an ongoing script because SSRS
      by default will use the service as the owner. And I KNOW that this
      was not done at my previous employer.</p></li>
  <li><p>I could make the SqlService a
      domain administrator. I don't want to do this for security reasons,
      obviously.</p></li>
  <li><p>I could give the SqlService "SeImpersonatePrivilege"
      (Impersonate a client after login) on my domain via the security
      policy. This also works, but there seems like there would be a
      better way, and I would think this is also a security risk as
      setting this doesn't explicitly limit SqlService to only
      impersonating the ReportService.</p></li>
  </ol>
  
  <p><strong>So, my question is hopefully from those who have set SSRS up, what is the best practice for allowing SQL Server to run the SSRS subscriptions?</strong> It's possible that something in our environment is messed up permissions wise, but I guess mostly I'm looking for advice on how <em>should</em> this be set up. Thank you greatly in advance. </p>