locked
There is a problem connectiong to the specified reporting Server SCCM 2012 SSRS RRS feed

  • Question

  • hi,

    I'm Trying to install reporting services point SCCM 2012,  I configured the site system role without problems, but when I tried to configure the report options I get this error:

    "There is a problem connectiong to the specified reporting, please check the conection and make sure SQL Reporting Service is running on the especified server. "

    The reporting service is running on remote server, I'm using SQL SERVER 2008.

    Two Questions:

    1: Which is the cause of the error?

    2: Which right permissions must have the reporting services point account?

    Thanks.

    Thursday, March 20, 2014 5:33 PM

All replies

  • The user that is installing SSRP needs these persmissions:
    - Read Access to site DB
    - Read Access to WMI on the site system

    The Reporting Service Point Account needs the following permissions:
    - a member of the Domain local security Group "Windows Authorization Access Group"
    - "Read tokenGroupsGlobalAndUniversal" permission set to Allow
    - "Log on locally" permission on the Computer Hosting the Reporting Services database

    Hope this helps.

    Friday, March 21, 2014 9:02 AM
  • Are you allowing port 1433 through the firewall?

    Which release of SQL Server are you using and have you applied the relevant minimum CU? Details here

    http://sccmentor.wordpress.com/2013/12/31/sql-server-site-database-configuration/

    Which version of SRS is installed? If 10.50.1600.1 you will need to get this updated to above 2500 level.

    http://www.mssccmfaq.de/2012/05/15/srs-not-detected-as-running/


    Cheers

    Paul | sccmentor.wordpress.com

    Friday, March 21, 2014 11:08 AM
  • Hi,

    The firewall is turn off in both servers, the SRS version is 10.50.4000.0

    Any idea?

    Tuesday, March 25, 2014 8:56 PM
  • HI,

    About this issue I have new information:

    When users are added or user rights are modified on the report folder by using Reporting Services Report Manager, Configuration Manager doesn't do nothing, if I use a new reporting instance with no user added, everything works OK, create security roles and add user to report folders.

    Any idea?

      

    Wednesday, April 9, 2014 3:27 PM
  • I was having the same issue as you and managed to fix by changing the reporting service to run as local account on SQL reporting server. Still trying to figure out why this fixed the issue, but it fixed it. Think user that the reporting service runs under needs to be in the local security group.


    http://www.scotmas.com

    Friday, October 30, 2015 1:28 PM
  • Hi,

    Did it get resolve? I am getting the same error.

    Vivek

    Wednesday, February 17, 2016 3:26 PM
  • I was having this error on my client-installed console. The server-installed console brought the reports up fine but my client installed console showed no reports. I found my answer at another site (windows-noob.com) where user severusx posted this. I hope it helps someone. It fixed my problem. I just had to import the self-signed certificate from the report server onto my client computer into the Trusted Root Certificates.

    I too had the issue where the reports worked directly on my SCCM
     server but not from a remote console.  I was able to correct this issue
     by examining the SmsAdminUI.log.  I noticed that every time i tried to 
    open the Reports tool it logged:
    
    
    [6, PID:4576][08/02/2013 17:05:14] :[ORLSCCM01.zerochaos.local] : The
     underlying connection was closed: Could not establish trust 
    relationship for the SSL/TLS secure channel.
    
    So what I did was open the SSRS Report Server page from my SQL 2012
     Server and export the self-signed certificate it used to secure the 
    Reporting Server page.  I then imported it into my PC's Trusted Root 
    Certification Authorities and it worked correctly after that.  To 
    correct the issue I would recommend that you install a certificate in 
    the SSRS Config Console that your workstations already trust, like from 
    an internal CA.

    Wednesday, February 8, 2017 9:55 PM