Not able to deploy report to SharePoint 2010 in integrated mode

Question

I am running SharePoint 2010 Enterprise with 2 servers in the farm (SharePoint and db server). They are both running windows server 2008 R2 and the SQL Server is also R2. I have installed the reporting services R2 add-on on to the SharePoint server. I have configured the report server on the SQL server and also installed the sharepoint on it and added to the farm. I am pretty sure I have configured reporting services on the central admin properly. I can browse to the reportserver fine too. The problem I have is that when I try to deploy my report developed in visual studio I get a pop up for credentials and no matter what I try for the user name and password, the pop up keeps coming back up and nothing happens.

The same question has been asked on MSDN, but no solution yet.

*********Update********

I understant it should be some permission issues , but I can use the same account to manual upload report to document library and it all work correctly. I am running VS2008 with admin right , the user is SPFarm admin , site collection admin to the current site , Sysadmin on the sql server and admin on the reporting server.What other permisions am I missing?

Answer 1

I've been dealing with this issue for a couple of months now and finally was able to resolve it. In my situation it was because I was using the same hostname for my reporting services URL and my SharePoint site URL.

My environment looked something like this:

SharePoint site for reports: http://mysphost/reporting

Reporting Service Integrated Mode URL: http://mysphost:80/ReportServer

So after searching through the logs I determined that when I was trying to deploy my reports Visual Studio was seeing that the hostname I was using was part of the reserved hostname of the report server (mysphost), and so it was treating the path /reporting not as a SharePoint site but rather a subdirectory in a native mode Report Server implementation (since we never actually have a way of telling Visual Studio that we are deploying to SharePoint or native mode it tries to detect on its own). The reason why we get the constant requests for authentication is because since Visual Studio believes we are trying to connect to a native mode instance it tries to find the web service at http://hostname/reportservice2010.asmx (if you're using SQL R2). SharePoint out-of-the-box does not allow for asmx files to be downloaded, and so it returns an access denied error, which in turn causes Visual Studio to prompt for better credentials.

In order to resolve this mess I added an alternate access mapping to my SharePoint site, http://sp.mydomain.tld and used that URL in Visual Studio to connect to my SharePoint reporting site and viola, it worked! Since I used an AAM that was different from the reserved URL for reporting services, Visual Studio did not assume that I was connecting to a native mode instance and instead looked _vti_bin/ReportServer for the files it needed to upload the reports.

So, after that long winded explanation the bottom line is that it will fail if you are using the same URL for your reporting services integration and your SharePoint site, so add a new URL to your SharePoint site by either adding a new name in your Alternate Access Mappings or extending the Web App onto a whole new IIS site.

I hope this helps, since I (like you) have not found an explanation for this issue anywhere.

Answer 2

This is may be due to the permission issue. Make sure you have a proper permission to deploy your report to the SharePoint Report Lib.

Answer 3

You should first consult the security logs on the server. This should tell you if the account is being rejected out of hand, or becouse is it simply a lower level permission. If it just reject the account entirely, you have a larger authentication issue and need to review the system log for trust related errors. If the latter, than you just need to track down which object is hanging you up.

The old standby's, Fiddler and MS Process Montior, may be able to aid your efforts.

Fiddler will report back on authentication requests and how/when they are failing. Sometimes this is enough to let you know why it is failing. You can use it server side as well, but it is more difficult to taget the traffic you are wanting to see. If interested, you could look at a tool like IISTracer, which will allow you to view HTTP headers.

If you need more detail than you can rely on Process Monitor. You can run it client side and server side. It can be difficult to sift thru the results, but there is a lot of detail to be had. While running the action on the client target Process Monitor at yoru browser activities. This will log all interactions locally. You should start Process Monitor on the server side as well. you can use the timestaps to corralate the client / server interactions. This will let you know if authentication is failing against a specific object (file, regkey, etc).