Trouble accessing Reporting Services using NLB cluster name

Question

Trouble accessing Reporting Services using NLB cluster name

AbdulGafoor GK

Old Hand

Points: 367
More actions
April 14, 2017 at 11:47 am

#322963
Dear All,
I am experiencing a strange issue. I got 2 servers with SSRS installed and configured in Scale-Out deployment. Both servers are part of a NLB cluster, which just load balances traffic on port 80. Cluster name is added in DNS manually. Below is brief of configuration and issue I am facing
- NLB cluster node 1 IP: 10.10.10.11
- NLB cluster node 2 IP: 10.10.10.12
- Cluster name and IP: SSRSCL1, 10.10.10.15
- Both nodes are joined in Scale-out Deployment list in SSRS configuration window, if this info is relevant to this particular issue.
- A static DNS forward lookup entry exist as SSRSCL1.contoso.com pointing to 10.10.10.15
- Both nodes when ran command 'ping ssrscl1' returns correct IP, which is 10.10.10.15
- When I browse using both, http://10.10.10.15/ and
- When I browse using both, http://10.10.10.15/ and http://SSRSCL1.contoso.com/, I am able to browse the IIS default page from either of the servers.
- When I browse ssrs IN CLIENT machines with either http://10.10.10.15/Reports/ or http://SSRSCL1.contoso.com/Reports, I am able to browse the reports fine with currently logged in Windows user
- When I browse ssrs IN SERVER with http://10.10.10.15/Reports/, I am able to browse all the reports fine with currently logged in Windows user.
- But when I browse ssrs IN SERVER with http://SSRSCL1.contoso.com/Reports/, it keeps asking me user name password. No matter how many times I provide correct user name and password.
I already tried following to find a solution, but failed so far.
- Given a entry in hosts file pointing SSRSCL1 to 10.10.10.15 to avoid a travel to DNS servers. It didn't resolve the issue.
- In SSRS Configuration window, I changed listening IP specifically to 10.10.10.15. Didn't resolve the issue.
Any idea what is causing this issue?Post new topic
Thanks to all

Viewing 4 posts - 1 through 3 (of 3 total)

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

Sue_H SSC Guru Points: 90860 More actions · Answer 1

Usually it's the clients having the problems...but it could just be different OUs and different policies for servers vs PCs.
Whenever I hit that issue, the first thing I always try is to just use IE, right click on IE and run as administrator. Even if you are in the local admins group do the run as.
You could also try adding the sites to the trusted sites in IE if the run as with IE doesn't work - not likely the issue but worth a try.
Does any of this involve different domains?

Sue

AbdulGafoor GK Old Hand Points: 367 More actions · Answer 2

Tried all that Sue. All tests were done on IE running as Administrator. http://SSRSCL1.contoso.com/Reports/ doesn't have any issues browsing from any client as well as servers except 2 servers where SSRS is installed. All servers are in same OU and no policies are applied on that except Default Domain Policy.

Sue_H SSC Guru Points: 90860 More actions · Answer 3

AbdulGafoor GK - Friday, April 14, 2017 2:10 PM
Tried all that Sue. All tests were done on IE running as Administrator. http://SSRSCL1.contoso.com/Reports/ doesn't have any issues browsing from any client as well as servers except 2 servers where SSRS is installed. All servers are in same OU and no policies are applied on that except Default Domain Policy.

The Servers may be in the same OU but are the PCs and the Servers in the same OU. That is what I meant by different policies for PCs vs Servers. Generally the servers would be in one OU and the PCs would be in another different OU and each OU would have different policies. And that could be one of the differences with it working from PCs but not the Servers.
Have you checked the log in the \Reporting Services\LogFiles directory? Have any changes been made to any of the .config files?
If company policies allow, you could try creating a local account on the server, give it the same permissions as your domain account and then from your PC add that local account as a Systems Administrator in SSRS. Then log onto the server with the local account and try that local account to access SSRS.

Sue