Configure Report Server Issue: Database Setup

  • OK - I've been working on this for 2 days and I'm stumped...

    We've been using SRS 2005 for a little over a year where the installation has always been Services and database on a single server. Now we have a need to have the services on a separate server from the database (should be simple). Everything was going well (configuration-wise - using the Configure Report Server GUI tool) until I get to the Database Setup.

    I set up the SQL login (with the sysadmin server role) on the remote SQL Server and then clicked "New..." on the Config tool (on the SRS server). The databases (ReportServer, ReportServerTempDb) were created successfully (and I gave the SQL login account access to both databases and set the RSEExecRole); however, when I try to apply the configuration -  the final task: Setting Connection Info for Reporting Server fails:

    The database connection settings have not been saved. Your Reporting Server may still not operate properly until appropriate settings have been applied.

    System.Runtime.InteropServices.COMException (0x800706B3)

       at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)

       at System.Management.ManagementObject.Get()

       at ReportServicesConfigUI.WMIProvider.RSReportServerAdmin.SetDatabaseConnection(String server, String database, ConfigurationCredentialsType credsType, String userName, String password)

    So, I'm currently out of ideas as to how to resolve this issue. This is a test scenario in preparation for our production environment where the SRS will be running in our DMZ and the ReportServer database will be behind the firewall - in order to service extranet report requests. Given the challenges of that environment - I was really hoping to not get hung up on the supposedly simple stuff.

    Any help/insight would be greatly appreciated!

    Glenn

  • As another attempt:

    I deleted the remote SQL Server ReportServer and ReportServerTempDb databases and uninstalled/re-installed the SSRS (SQL) Components from the Report Server. When I reconfigured the Database connection I now get a warning (versus a failure error) as:

    Setting Connection Info for reporting Server

    Although saving the database connection succeeded, the report server cannot access the internal information about this deployment to determine whether the current configuration is valid for this edition. If you are configuring a scale-out deployment, that feature is not supported by this edition. To continue, use a different report server database or remove the encryption keys from the current database before initializing the report server.

    ReportServicesConfigUI.WMIProvider.WMIProviderException: The report server cannot open a connection to the report server database. A connection to the database is required for all requests and processing. (rsReportServerDatabaseUnavailable)

       at ReportServicesConfigUI.WMIProvider.RSReportServerAdmin.ThrowOnError(ManagementBaseObject mo)

       at ReportServicesConfigUI.WMIProvider.RSReportServerAdmin.ListReportServersInDatabase(RSReportServerInfo[]& serverInfos)

    • Since this information was "successfully" saved: where does the information get saved (I looked in the C:\Program Files\Microsoft SQL Server\MSSQL.1\Reporting Services\ReportServer... .config and .xml files but found no database connection information)?
    • I believe that this is not a scale-out deployment (but rather a distributed deployment). I'm using SQL Server 2005 SP2a Standard Edition. This test deployment is within the same domain on two separate servers.
    • Since I'd like to continue (but have not yet changed the default encryption key configuration) - I looked in the ReportServer.dbo.Keys table and found

    MachineName  InstallationID                                  InstanceName  Client   PublicKey   SymmetricKey

    NULL                   00000000-0000-0000-0000-000000000000   NULL                   -1          NULL             NULL

    NPDEV22V            16735428-8684-47ee-92b6-3a84555737a5   MSSQLSERVER      1           <binary data><binary data>

    So... should I remove the NPDEV2V key???

    Still looking for insight

    Glenn

  • Hi,

    I am having a very similar issue, and am getting the error message below:

    System.Runtime.InteropServices.COMException (0x800706B3)

       at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)

       at System.Management.ManagementObject.Get()

       at ReportServicesConfigUI.WMIProvider.RSReportServerAdmin.SetDatabaseConnection(String server, String database, ConfigurationCredentialsType credsType, String userName, String password)

    Have you found any solutions?

    Beth

  • Hi Beth -

    The whole issue for us came down to the way in which the certificate was installed on the Report Server. Once I got that straightened out the database connection setup worked as advertised.

    Glenn

  • Hi Glen,

    Thank you, I will investigate.

    Beth

  • I am having the same issue, can you elaborate on your certificate issue?

     

    Thanks,

    Jodie

  • http://support.microsoft.com/kb/842421

    Explains how to redo the certificate key (*.snk)

  • Hi

    I get the same error message as Beth above, but this is the first install of RS 2005 on the server. The microsoft support link assumes it was working and then broke but mine never worked!

    i simply installed RS on a server that already had the database engine installed. I then applied SP2. Then i opened the RS configuration manager and when trying to set the database setup options like i've done 100 times before on other machines i got Beth's error!

    Any help would be much and urgently appreciated!

    Guy

  • I am having the same problem as Glenn. Could some body help me with this issue. thanks!

  • Just food for though. Once you run through the DB setup if you get the error where the connection string isn't saved try changing the Credentials Type to something other then service credentials. I changed it to Windows Credentials hit applied and of course failed. I then changed it back to the Service Credentials and hit apply, no errors. Not sure if this will solve your issue but it helped on this end. I've never seen this error when setting the RS DB up. Hope this helps somebody.

    Cheers,

    Z

  • Hi guys,

    ran into the same problem last week. Today I came back to work and investigated...

    When you switch to 'Windows Credentials', RS Config inserts the credentials in the rsreportserver.config - encrypted of course. My assumption from the error messages was that the user (Administrator) running RS Config might use a different key than the account ("domain\SqlRSSA") responsible for retrieving data from the Reporting database... I remembered setting up config file encryption for an ASP.NET project, where I had to log in as "Asp.Net working process" to do the encryption (MS recommendation).

    So I temporarily added the domain account to the administrators group (so 'he' could connect remoteley), logged in with the account's credentials and started RS config. Under "Database setup" I set up a database (what else...) in Sharepoint integrated mode, typed in the credentials - and it ran!

    From a different machine I browsed the report server - looked perfectly. So I again logged in as admin, removed SqlRSSA from the Administrator group, refreshed the RS config tool - still all green. The report server still responded from outside. I was glad.

    Until I restarted the server. Since then the same problems - failed initialization. So much for the "different keys" theory.

    I again added 'SqlRSSA' to the admin group - and again it all worked. So

    - mismatching user keys are not the issue as I cross-tested with a DB set up as "Administrator".

    - obviously administrative rights are necessary to read the used (machine) key...?

    Still I suspected it is in no way best practice to provide a subordinate service account with admin privileges. Further search in the logs gave one more hint: "The service account has not been granted the needed login _type_"... ok, the machine is domain controller as well - login only for administrators by default. Should this solve everything?

    So I granted login to the good old 'SqlRSSA' - the next error message gave me the creeps: Access (to the reporting services database) denied. I was about to shoot the server through the lungs.

    Now it's time for the final clue: In the small printed of the MS installation guide for reporting services http://msdn.microsoft.com/en-us/library/aa179363(SQL.80).aspx it is written:

    * If the remote SQL Server instance runs as Local System, you can use Windows credentials and any valid domain account to connect to the report server database.

    * If the remote SQL Server instance runs as a domain user, you must specify that same domain user account for the report server connection.

    Indeed I had planned to use different domain accounts for the relational engine and the reporting services... so back to RS config, switched the RS user to the existing SQL domain account, gave login rights to it and - it works!

    Hope this can be of help to you - wasted three days on this issue.

    Cheers,

    Juergen

  • Hey Z,

    Your suggestion so far has worked. I changed the credentials management from Windows Credentials to Service Credentials, hit "Apply," and so far don't have errors. Earlier I have had the exact same error mentioned above, and I'm running Reporting Services on SQL 2005 for a SharePoint 2007 installation. Let's see if it holds...

    Thanks,

    Stephan

  • Thanks! Thanks! I had planed an upgrade on a test server and redone it several times. But on the production server upgrade of SQL 2000 it did not go so well. After a std install I received scale-out errors when I was not trying to do anything associated with scale-out. It turned out to be an extra entry in the Key table. I searched for hours before I found enough information here to help me figure it out.

  • Add Named Pipes to you installation and the upgrade works.

  • Add Named Pipes to you installation and the upgrade works.

Viewing 15 posts - 1 through 15 (of 25 total)

You must be logged in to reply to this topic. Login to reply