Reporting Services Tip #2

Mon Aug 9, 2004 by Tara Kizer in sql-server-reporting-services

Reporting Services Tip #2:

The easiest way to install Reporting Services is to have the Report Server and SQL Server on the same server. It's the easiest way, but it certainly is not the best. IIS should not be installed on the database server for performance reasons. Now this isn't true for small systems, but I rarely work on small systems so this is a general rule for me. Due to this rule, the Report Server must be installed on a different server as it relies on IIS. And yes this way requires the Report Server to be licensed as well as SQL Server.

During the installation of the Report Server, you may receive the following error when SQL Server is not installed on the same server:

This error occurs when the installation is trying to connect to the SQL Server to install the databases used by Reporting Services. You might be wondering why it doesn't just use the account that you specified in the installation wizard, but that account isn't used for the installation but rather for Reporting Services when it is installed. By default the credentials of the person logged into the server is what is used for installing the databases. I'm not sure why I have received the error as my account has local admin privileges on the database server and sysadmin fixed server role in SQL Server. For some reason, the credentials don't get passed correctly as I see from SQL Profiler the NT AUTHORITY\ANONYMOUS account trying to log in.

To get around this error, you can specify a SQL account (readme file says you can use Windows account but I've only had success with a SQL account) instead. You do this from the command line or by modifying template.ini file. Here is the command line way:

setup /i “D:\setup\rsrun.msi“ RSSETUPACCOUNT=sa RSSETUPPASSWORD=sapwd

Change the path for rsrun.msi if needed.

For the template.ini file way, there are two lines that will need to be changed:

There are two lines that will need to be changed in the template.ini file:

RSSETUPACCOUNT=sa
RSSETUPPASSWORD=sapwd

The template.ini file is located at the root of where you are installing Reporting Services from. If you are running this from a CD, you might find it easier to use the command line way as you won't be able to modify the file on the CD.

I've specified the sa account in both ways. It can be any account that has sysadmin privileges.

For Reporting Services service pack 1, you must do the command line way as there is no template.ini file:

sp1setup RSSETUPACCOUNT=sa RSSETUPPASSWORD=sapwd

You can not pass these parameters to the self-extracting sp1 file (SQL2KRSSP1-ENG.EXE). You must manually extract the files, then run the command line option.

Legacy Comments


Cris 2005-06-03	Reporting Services Hello, I did the custom security extension example (Forms Authentication), and when I submmited the logon button, I received the answer: HTTP 401 unauthorized. I had debuged the source code and saw that the cookie is never passed to the explorer and the process never go to the funcions of authentication extension, like Logon User. I had checked all configuration files, the username and password, and every thing is all right Please Help me

Tara 2005-06-03	re: Reporting Services Tip #2 I'm not sure what you are referring to with this tip.

Wanderer 2005-06-07	re: Reporting Services Tip #2 Tara, In your example, you use SA as the SQL Account used. Is that necessary, or did you just use it for ease of explaining? I have seen this inability to resolve the user in other areas - but no solution. I'd love to know what caused this...

Tara 2005-06-07	re: Reporting Services Tip #2 You have to use an account that has sufficient privileges to create the RS databases on the SQL Server. So I use sa.

Madhusudhana.Rao 2005-10-27	re: Reporting Services Tip #2 I WOULD LIKE TO HOW TO ACCESS THE PARAMETERS IN REPORTING SERVICE. that is say i pass a url with parameters from an aspx page to the reporting service. how do i access the value in the reporting service. pls help

kbiel 2006-01-11	re: Reporting Services Tip #2 It's likely that the domain account credentials are not being passed to SQL Server because of the one-hop rule. Most likely, the setup program is using SSPI to communicate with the service and the service is in turn attempting to connect to SQL Server using SSPI. If you had Kerberos turned on for your domain and the user account that you attempted to use, this problem would probably go away.