November 23, 2010 at 9:54 am
Evening all,
I'm having issues connecting to Reporting Services Report manager. The report server
Here's what I can / Can't do
On the Report Server:
- I can connect to Report Manager using http://MachineName/reports
- I cannot connect to Report Manager using http://MachineName.Domain.net/reports
On the My client machine:
- I cannot connect to Report Manager using http://MachineName/reports
- I cannot connect to Report Manager using http://MachineName.Domain.net/reports
- at one point I could connect to Report Manager using http://{IPAddress}/reports from my client machine, but this has now stopped.?!
If I do an nslookup from my machine name the correct IP address is returned.
I would appreciate any insights into what could be causing the issue and how to resolve the issue.
_____________________________________________________________________________MCITP: Business Intelligence Developer (2005)
November 23, 2010 at 11:39 am
there could be a variety of things goign on here... lets look at what you 've done and see where we can go from there...
First, is your machine on a public domain? You list domain.net. Is that really the TLD or is it mydomain.local or some such? Second, if it really is mydomain.net and it's publically exposed, are there firewalls in between your client and the SSRS instance? If so are they dropping/logging failed packets etc? What about the firewalls on the server itself and your client (windows firewall)? Same for any antivirus/HIPS/IDS on the client, network gateway and server?
On the Report Server:
- I can connect to Report Manager using http://MachineName/reports
- I cannot connect to Report Manager using http://MachineName.Domain.net/reports
when you use nslookup to resolve MachineName.Domain.net from the server what do you get? correct IP or not? Do you have any other websites installed? Host headers any other IIS settings that may affect this? Are they configured to filter requests n anyway URLScan or any other filters. you say you cannot connect to reportmanager with the FQDN, what error do you get? 404, 403 etc? check the IIS logs, what do they say about attempting to do that?
On the My client machine:
- I cannot connect to Report Manager using http://MachineName/reports
- I cannot connect to Report Manager using http://MachineName.Domain.net/reports
- at one point I could connect to Report Manager using http://{IPAddress}/reports from my client machine, but this has now stopped.?!
emphasis mine...
It seems like that is where you problem lies. Looks for a firewall, or somethign blocking access to the reportmanager website. something is not set properly in either IIS or the SSRS Config utility. What about other websites on that server? can you access them? what about the http://MachineName/reportserver site? Does you account have access to view the report manager site?
Hopefully this gets you pointed in the right direction or at least gives you a next step for troubleshooting.
-Luke.
November 24, 2010 at 3:01 am
Hi Luke,
to answer your questions....
- the machine is NOT in the public domain. It's on a private company network, using CompanyName.net for the domain name.
- There aren't any firewalls between my client machine or the server (and as per original post, I can't access the site even from locally on the server using the FQDN (Note: I have disabled Loopback Checking and StrictNaming as per articles http://support.microsoft.com/kb/896861 and http://support.microsoft.com/kb/281308/ respectively, as a colleague suspected that this may be part of the issue).
- nslookup on MachineName.CompanyName.net does return the correct IP address
- There are no other sites configured.
- I was using host headers, but in an attempt to resolve the issue I've removed host headers and set the site IP Address to All Unassigned TCP port: 80
- I've looked in the most recent log for the website and can't see any errors being generated when I try to connect using the FQDN.
- Using the FQDN I get the username and password prompt repeatedly, before receiving HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials. Internet Information Services (IIS)
- with the exception of specifying Integrated Security and the application pools for the Report manager and Report Server virtual directories on the site, all other site setting are default.
- via IP address - I can again get to the server and run reports...??
-lastly my account does have access to the Report manager, I can verify this by the fact that I can use my login credentials when connecting via IP address.
- I'll go back and check my IIS setting and SSRS config settings, but i'm a little stumped to be honest.
Taking my client machine out of the equation for a moment, why cant I use the FQDN from locally on the server?
_____________________________________________________________________________MCITP: Business Intelligence Developer (2005)
November 24, 2010 at 3:28 am
Hi again Luke,
Something else I've just tried is to setup another DNS record to point to the report server (as we have other RS that use DNS records like LiveRS.myDomain.net)
still with Reporting services untouched from below, my client machine connects 1st time and runs reports correctly, so it seems to be an issue that is more specific towards the use on the maching name using the FQDN.
So it would seem my report server configuration is ok, but maybe it's something at a machine/ IIS level
_____________________________________________________________________________MCITP: Business Intelligence Developer (2005)
November 24, 2010 at 6:56 am
dave-dj (11/24/2010)
Hi again Luke,Something else I've just tried is to setup another DNS record to point to the report server (as we have other RS that use DNS records like LiveRS.myDomain.net)
still with Reporting services untouched from below, my client machine connects 1st time and runs reports correctly, so it seems to be an issue that is more specific towards the use on the maching name using the FQDN.
So it would seem my report server configuration is ok, but maybe it's something at a machine/ IIS level
With this it really seems like it's something DNS related. OR at the very least naming related. If you can connect from your client with another DNS record, but you are getting 401s from your other dns record, you need to make certain that it's resolving to the same address. No chance there is an old Wins server with another IP that never got updated or hosts record or something overriding what you would be getting from your DNS server? What happens when you skip nslookup and just ping the server by the old (original) dns name? Does it ping the same IP that the new DNS name does?
-Luke.
November 25, 2010 at 1:09 am
I kind of agree with Luke. Almost sounds like you have a dupe IP and it can't route/resolve correctly. You can't even open SSRS on the server using the FQDN. I'm guessing but is your SSRS on a single server (standalone instance)? If it was on a web farm you could shut down the SSRS & IIS on one server and try to hit the other one but I guess we don't have that option to test out the issue.
There is something we did on our servers but they were behind a firewall in a private domain. We had 3 front end SSRS report servers (hardware load balanced). This is something we did on our servers.
Windows uses a HOSTS file (located in %systemdrive%/windows/system32/drivers/etc) to maintain a local list of web addresses. Any time a request is made for a URL, the HOSTS file will be checked before a request is made to a DNS server to resolve the name. Might at least get you working when your on the server.
By configuring the Reporting Services url to point to the loopback adapter, Report Manager can make calls to ReportServer without requiring name resolution.
1. Open the HOSTS file with Notepad1
2. Under the following entry:
127.0.0.1 localhost
3. Add the following entry:
127.0.0.1 localhost
127.0.0.1 <Reporting Services URL> # Description
Note: There is a tab between the IP and the assigned name.
Wouldn't hurt to double check IIS. Make sure your settings are correct. Click on Web Service Extensions and ensure that Active Server Pages is Allowed, ASP.NET v1.1.4322 Allowed and ASP.NET v2.0.50727 Allowed.
On the Report and ReportServer virtual directory check the properties and make sure in the Directory Security tab that you have Intergrated Windows authentication checked and the others unchecked, so on and so forth.
I would be interested in what you find when you ping by the IP address and FQDN. I know you said there's no firewall, but wouldn't hurt to try to do a telnet to test connectivity. It would totally eliminate the possibility of a network issue. Ex: telnet <reporting services url> 80, or telnet <IP address> 80. I think you said the URL resolves in nslookup. If you don't feel comfortable doing the telnet, might try tracert - tracert <ip address> and/or tracert <reporting services url>.
What happens when you try to hit http://reporting services url/reportserver? Same thing as /Reports?
Oh, have you looked in you SSRS logs, IIS logs and event logs for any messages that might give a clue to your issue? For instance might see if there any issues logged for problems getting response from your domain controller. If you happen to know the name of the domain controller try ping it from on the server.
I might have missed it from the other post but has the instance been installed for a period of time and is now doing this. Or is this a new install?
January 13, 2011 at 8:00 pm
Hi dave, have you solved this problem? any shared with us?
I suffered this same problem exactly but not no solution now.
January 14, 2011 at 2:30 am
hi leafsword,
to be honest I think we ended up changing a couple of things - the combination of which resolved the issue.
That said - I do have a few questions before I can try to help
Have you got kerberos access configured?
--> have you set up the computers for trusted delegation
Have you defined a used a server account for the Report Server application pool?
--> have you ensured this has access to SQL server
Have you check the webconfig reportserver url.
let me know and i'll see where your setup is different
_____________________________________________________________________________MCITP: Business Intelligence Developer (2005)
January 18, 2011 at 1:26 am
Thanks for your response, dave.
Have you got kerberos access configured?
[Yee] Yes
--> have you set up the computers for trusted delegation
[Yee] I don't know what does the mean.
Have you defined a used a server account for the Report Server application pool?
[Yee] No, how to define it.
--> have you ensured this has access to SQL server
[Yee] No.
The key point is that I cannot connect to report server on the local if I access it via domain url. Please see that in detail in this post:
http://www.sqlservercentral.com/Forums/Topic1047715-1632-1.aspx
Sorry to bother you. Thanks again.
BTW: I also read this article, but it does not solve my problem.
http://msdn.microsoft.com/en-us/library/cc281253.aspx#proxyfirewallRSWindowsNegotiate
January 18, 2011 at 2:54 am
If you are trying to using kerberos (Windows) authentication then you will definately need to set up Trusted Delegation for the Report Server (i.e. when a user connects to the report server, by trusting it for delegation, you are saying that the machine is trusted to pass on the user details to the next server in the chain - in this case it's likely to be the SQL server [this is still needed if it's the same machine]).
Having looked through what we done, our issue was down to a missing SPN record.
My best recommendation is that you take a look through the following sites/documents, which are what I used:
http://callumhibbert.blogspot.com/2009/02/kerberos-delegation-and-sql-reporting.html - provides a nice and clear overview of what is required for kerberos authentication
and definately look through:
Explains how to troubleshoot delegation issues that can arise in Kerberos authentication scenarios. Summarizes required infrastructure and describes Windows authentication scenarios - (this is a very useful document and helps you identify what is required for your scenario - it's what I used when setting it up.)
_____________________________________________________________________________MCITP: Business Intelligence Developer (2005)
January 18, 2011 at 7:54 pm
Thanks for your time.
Finally, this issue is caused by Loopback check. Please refer to this link:http://support.microsoft.com/kb/896861
Thanks again.
-Yee
January 19, 2011 at 3:06 am
No problem, pleased you resolved the issue.
_____________________________________________________________________________MCITP: Business Intelligence Developer (2005)
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply