Tuesday, March 20, 2012

Reporting Services Login box appears when trying to deploy in SSRS 2005

Hi All,

I installed SQL Server 2005 SP2 recently. After that when I try to
deploy a solution in SSRS 2005, I get a dialog box with title:
"Reporting Services Login". It has my server listed as the first row:
"http://localhost/reportserver" and then it has two text boxes asking
for Username and Password.

I checked my IIS settings and only Integrated Security is checked for
the Reports Server folder (and for the entire website). I tried to
change that to Allow Anonymous Access = Checked, but still the same
problem.

Any ideas?

Thanks! GB

GB,

Just wondering if you ever resolved this problem... How'd do you do it?

I'm having the same symptoms and can't find a single post anywhere in which someone had a solution.

Thanks!

|||Me too. Exactly the same symptoms. Tried the same things to solve it too.|||i have face the same problem anybody is there to help us.?|||

You need to give rights in the report manager sites to the user.

Do not change it in IIS, it will do nothing.

If you have the rights to the report manager you can give access on specific folders or all folders to users.

http://yourservername/reports is the default link to the report manager. If you preferyou can use the "Microsoft SQL Server managment studio " to do the same thing.

If you are not an admin on the reporting services server contact your admin.

Good Luck

|||I have solve this problem, myself. The problem is that i have written the target server url only to http://localhost/ but when i change it to "http://localhost/reportserver" it work fines. so in this way all of you check your target server url to remove this problem|||I have been hoping for resolution of this problem. Having recently installed SS05, I have not yet got this sorted. I have followed generic instructions, incl. IIS set ups, deployment options (incl using http:\\localhost\ReportServer), but still get the credentials request. I have local admin rights to server\ using windows domain account. Could you be more explicit (sorry!) Paul about how to give necessary access to (which) folders, given I am using default settings?

Thanks for everyone's input on this.
Ken
|||

i keep getting EXACTLY the same issue. wasted 5 hours of the day trying to figure it out before i finally called in a troubleshoot request with microsoft.

will let you guys know what the problem is as well!

Xavier

(perth, australia)

|||I found this thread because I was experiencing the same issue described here. I just found a resolution, for my specific case anyway. It turns out that the report server path property was wrong in the reports project properties. I had to create the reports web site http://localhost:81/reports and I neglected to put in the port number in the properties so it was attempting to access a site that didn't exist.

My only suggestion would be to check the url of your report server very closely.

Good luck.
|||

still no word from MSFT.

Thanks scott for your advice,

I presume you inserted this URL in the "Manage Integration Settings"

http://localhost:81/reports

Then where "Grant Database settings, you entered the name of your server (no port included).

In my VM, the server name is CLEANSERVER2003

Instance is default (MSSQL)

I still get the same "Could not open DBASE with user name and password settings"

Any further info you could possibly give?

Cheers

|||

SQL 2005

I have the opposite problem. I am trying to deploy the solution and it is using some other login to try to deploy. This other login does not have the correct rights to deploy. How do I get Visual Studio to prompt for the login name and password when I am trying to deploy the solution. I have checked that the target is correct. I have deleted all cookies and internet files from my PC, removed all other (file share) connections to the server and rebooted. Still no luck - it still wants to use the old login id.

|||Works great for me! Thx!

PS: another solution that I found is here:

FIX: The Reporting Services Login dialog box appears repeatedly when you deploy a report on a remote computer by using Report Designer

http://support.microsoft.com/kb/842517

(not working for me)
|||

Paul.G. wrote:

You need to give rights in the report manager sites to the user.

Do not change it in IIS, it will do nothing.

If you have the rights to the report manager you can give access on specific folders or all folders to users.

http://yourservername/reports is the default link to the report manager. If you preferyou can use the "Microsoft SQL Server managment studio " to do the same thing.

If you are not an admin on the reporting services server contact your admin.

Good Luck

sry for the second post. This solution works for me.
|||

Paul.G. wrote:

You need to give rights in the report manager sites to the user.

Do not change it in IIS, it will do nothing.

If you have the rights to the report manager you can give access on specific folders or all folders to users.

http://yourservername/reports is the default link to the report manager. If you preferyou can use the "Microsoft SQL Server managment studio " to do the same thing.

If you are not an admin on the reporting services server contact your admin.

Good Luck

|||I've been fussing with this a couple days now myself. The fix, quite simply really:

In my particular case I install SQL 2005 as a seperate instance, so instead of

http://localhost/reportserve mine was http://localhost/reportserve$SQL2005

and that, in itself, was enough to break reporting services and query for the reporting serivces login again and again and again.

So, where do you fix it:

1. Open your project in SQL Server Business Intelligence Development Studio
2. Select the project menu followed by the properties of the project.
3. Change the TargetServerURL: To the appropriate path to your reportserver.

if your still not sure ( hard to believe but I suppose... ) open your IIS manager, expand the default web site and spot your reporting services virtual dir.

There you go ... what a pain in the ...

Regards from Indianapolis

No comments:

Post a Comment