none
Reporting Services 2012 for SharePoint and SQL Server Agent "Subscriptions and Alerts"

    คำถาม

  • After installing Reporting Services for SharePoint (Denali) in my test farm, I'm trying to configure the "SQL Server Agent" access for Reporting Services.  From Central Admin I'm going to the Reporting Service applicaiton configuration screen and selecting "Provision Subscriptions and Alerts".  I've tried both options on this screen.  I've manually executed the "download sql script" in SQL Server, as well as entering a user with SQL sys admin rights on the SQL server into the login fields on the screen.  The role and permissions have been created for the application pool service account, but Reporting Services is still trying to connect with the annonymous login because I'm getting the following alert each time I open the "Provision Subscriptions and Alerts" screen:

    Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

    The "status" on the screen still shows "SQL Server Agent State cannot be determined".  Has anyone else seen this? 

    Thanks!!

    1 กุมภาพันธ์ 2555 2:15

คำตอบ

  • I've seen this issue and the solution I've found is as follows:

    1. Set an SPN against the farm account for the central administration site. This should be in the format HTTP/servername if running central administration locally, and HTTP/CentralAdminURL if you've published central admin out (or both for completeness).
    2. Trust the farm account for delegation.
    3. IISRESET the SharePoint server(s).

    I've seen some discussions about adding the central administration site URL to the trusted intranet sites list, but that didn't help me when I tried it.

    Following the SPN/delegation configuration, my instance changed from 'SQL Server Agent State cannot be determined' to 'SQL Server Agent is running'.

    Andy

    • ทำเครื่องหมายเป็นคำตอบโดย mikea730 17 พฤษภาคม 2556 16:56
    17 พฤษภาคม 2556 15:36

ตอบทั้งหมด

  • Hi,

    1. please go to central administration > security > general security > configure service account to set the service account for reporting service 2012 service.

    2. please to go to central administration > manage service applications > select your reporting service 2012 service application > click the administrators in the ribbon to add your users into it.

    3. You can also create a new application pool for reporting service 2012 service application with the special service account to give a try.

    4. make sure your configre reporting service and sharepoint 2010 intergartion properly

    http://msdn.microsoft.com/en-us/library/bb326356.aspx

    Regards,

    Seven


    • แก้ไขโดย Seven M 3 กุมภาพันธ์ 2555 9:26
    3 กุมภาพันธ์ 2555 9:24
  • Thanks for your reply!

    1) Looks like the new Reporting Services does not run as a Windows Service so it's not listed in the "Configure Service Accounts" pulldown.  As a result, I don't see how to set the service account.  It's only assigned to an application pool.  I installed it into an existing application pool and that application pool "is" in the list and has a domain service account already assigned.

    2) Which users need to be in here in order to configure the "Provision Subscriptions and Alerts" screen?  I already have the farm admin account which is the account I use when running Central Admin.

    3) As mentioned in #1, I've installed Reporting Services into an existing application pool with other service apps.

    4) This link is for Reporting Services 2008 R2 which is very different install process.  But I did follow the SQL Server Reporting Services 2012 RC0 installation instructions and the Reporting Services is functioning correctly with no errors.  I'm just not able to configure the sceduling the alerting with interfaces with the SQL Server Agent.

    Thanks!

    3 กุมภาพันธ์ 2555 23:33
  • Reporting services still has its own service when running in native mode.  However when integrated, it runs as a service in sharepoint.

    Seven said to go to central administration, as in Sharepoint Central Administration.  I'd start there and do as he instructed.

    Hope this clears things up.

    7 กุมภาพันธ์ 2555 14:15
  • Same problem.  Have you found a solution?

    Mario

    7 กุมภาพันธ์ 2555 22:14
  • No,  I have yet to hear from anyone, other than you, that has also installed the new Denali reporting service apps.

    I guess we are the first ones!  :)

    My reports work with no problems, so I know the new Service Applications are installed correctly and working.

    7 กุมภาพันธ์ 2555 22:20
  • Agree.  However, I am very surprised that no one has raised this issue.  Seems clear to me that the Install / Configure process has changed since 2008.  Anyway, here is a link to my post.  I will definitely let you know when / if I receive a response.  If I don't receive a response by the end of the week, I'll create a service request against my MSDN account and will definitely keep you in mind.

    Here's my question:

    http://social.technet.microsoft.com/Forums/en-US/sqldensetup/thread/fd88bdcc-fc15-4716-b638-c07b268e50c9


    Mario

    7 กุมภาพันธ์ 2555 23:54
  • thanks!  I appreciate that!!

    I read your post.

    Yes, the installation process has changed completly.  All the Reporting Services now run as "Service Applications".  SQL Server is only used to house the new reporting services databases.  There are 3 databases now that get created when you "provision" the new RS service applications.  You need to do a files only install, and then provision and start the service apps on the application tier.  There are no RS Windows Services.   Ironically, I find the new Reporting Services to be "much" easier to install.  I provisioned the service apps using the example powershell scripts and it worked great!  So much easier than the old Reporting Services. 

    8 กุมภาพันธ์ 2555 0:04
  • Someone sent this to me.  I was unaware of this addition to the library.  I worked through the install and it resolved my issue.  Best of luck to you.

    http://msdn.microsoft.com/en-us/library/hh231687(v=sql.110).aspx


    Mario

    8 กุมภาพันธ์ 2555 18:15
  • Mario,

    thanks for the update!

    If you go to Central Admin  "Application Management-->Manage Services Applications", then click on the Reporting Service Application.  Then go to "Provision Subscriptions and Alerts"  are you able to enter a SQL Server admin login in  the "Allow Reporting Services to Use SQL Server Agent" section?  If this works, the status "SQL Server Agent state cannot be determined" should go away.

    This is the issue I'm having.  Even though the SQL Server security has been set up for the Reporting Services application pool domain account, Reporting Services still does not connect to the SQL Agent using the application pool domain account.  Reporting Services continues to use 'NT AUTHORITY\ANONYMOUS LOGON' when it tries to connect instead of the Application Pool domain account that Reporting Services is running in.

    Thanks,

    Mike

    8 กุมภาพันธ์ 2555 19:30
  • Add the central administration URL as Local intranet sites in Internet Explorer and check if you have the same issue. I had the same problem and this was my resolution.


    MCITP|MCTS SharePoint| SharePoint Performance blog

    • เสนอเป็นคำตอบโดย DNA88 19 พฤศจิกายน 2556 13:57
    10 พฤษภาคม 2555 9:35
  • I've seen this issue and the solution I've found is as follows:

    1. Set an SPN against the farm account for the central administration site. This should be in the format HTTP/servername if running central administration locally, and HTTP/CentralAdminURL if you've published central admin out (or both for completeness).
    2. Trust the farm account for delegation.
    3. IISRESET the SharePoint server(s).

    I've seen some discussions about adding the central administration site URL to the trusted intranet sites list, but that didn't help me when I tried it.

    Following the SPN/delegation configuration, my instance changed from 'SQL Server Agent State cannot be determined' to 'SQL Server Agent is running'.

    Andy

    • ทำเครื่องหมายเป็นคำตอบโดย mikea730 17 พฤษภาคม 2556 16:56
    17 พฤษภาคม 2556 15:36
  • Thanks!  I suspect this is the issue.  When I run SPCA locally on the application server, it works with no problems.
    17 พฤษภาคม 2556 16:56
  • To Expand Upon this comment...Make sure you've included the CA URL on your loopback exceptions (or disable the loopback). I ran into a similar problem as a result of securing (https) my CA URL.
    12 สิงหาคม 2556 14:31
  • After setting the SPN and activating delegation, I still got this Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' -message.

    So I decided to check from the IIS management console what authentication providers are set for SP Central Adm. To my surprise, the NTLM -option was on top of the list. As soon as I changed the Negotiate-option as first provider,I got this:

    SQL Server Agent is running -message.

    Bw, Sami N

    28 สิงหาคม 2557 11:51