SSRS - report configuration
-
Hi team,
I have installed and configured SQL 2017 SSRS on a new server.
My question is -The web portal URL is accessible from the remote server, but when I try to access the URL from my own machine I get a message as
"Cannot reach the page, temporary DNS issue"
Any idea to fix this? Thanks!
From the Remote server :
But From My Machine:
-
Could be DNS or could be firewall.
From your machine, can you PING the remote server by name? If not, can you ping it by IP?
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
Yes I am able to ping the server name and IP from my machine. thanks
-
Then it is likely a firewall issue. Do you have port 80 open on the server to allow for HTTP traffic (or port 443 for https, or whatever port you configured if you are using non-standard ports)?
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
Oh ok, I see the port used is 80-on the http link for report(web portal URL) , how can I verify if this port is allowed for HTTP traffic ? thanks
-
if you haven't configured anything special, then port 80 is used for HTTP traffic.
If you want a SHORT TERM test, you can turn off the firewall on the server and see if it works on the client machine. If it does, then it is definitely a firewall issue. I say short term as turning off a firewall is never a good idea, but is OK for testing.
If it works, open up port 80 in the firewall and see if you can still access things. Fairly certain it is just a firewall configuration issue. If this is on a corporate network, you may need your IT team to open things up if it is blocked through a GPO or a hardware firewall.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
Thanks I added the port 80 to inbound rule and now able to access the link from my machine
-
Glad to hear you got it sorted out.
Thanks for reporting back!
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
My Windows OS team are saying they would like to place a certificate on the reporting services and use https so 443, would this work? or port 80 is always required for reporting service? So the site would be https://servername/reports_ssrs_browse
thanks
-
You can use a SSL certificate and HTTPS (ie port 443) with SSRS no problem. SSC actually has a good tutorial on this:
https://www.sqlservercentral.com/articles/configure-ssrs-with-an-ssl-certificate
In that tutorial it explains how to use a self signed cert for this. My preference is to not use self signed, but to work with your OS team to get a cert signed by your CA (Certificate Authority). If it is outside facing, then I'd recommend getting it signed externally. The reason I recommend this is if it is outside facing, they have no trust with your CA so they will get warnings while viewing the page. If it is signed by your CA, then internally they will get no warnings, but externally they would. If it is self signed, you will get warnings from every computer except the one hosting it.
If you are getting it signed internally, I would recommend getting the certificate set up with the description being the FQDN (fully qualified domain name) and an alternate name with the friendly name. FQDN would be something like servername.corporation.com whereas the friendly name would just be servername. This allows users to go to either https://servername.corporation.com/reports_ssrs_browse OR https://servername/reports_ssrs_browse and both will give no warnings. I imagine your OS team should know how to do this and how to make the certificate.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
Thank you so much Brain, wonderfully explained. I will suggest your recommendations with OS team , I'll post back.
-
I spoke to my OS team and they have installed a certificate issued by CA on the reporting server.
And also configured to use reporting service with
https://server.name.com/reports_ssrs
https://server.name.com/reportserver_ssrs
Both the links are accessible from outside the server.
But from inside the server itself I am getting a message as "This site is not secure" - For this my OS team member says the url and certificate name would need to match for the certificate warnings to go away and this is fine for local traffic, and no need to access the URL from inside the server.
My question is, is this ok and can we import reports from the URL outside the server or can we create new reports from outside the server?
Thanks
-
My advice - try it and find out.
Having the site not secure when accessing it locally is likely because you are connecting to "https://localhost/reports_ssrs", right? Connecting by server name should not have the "not secure" warning unless the certificate is bad. But since it works from your machine without that warning, I'm thinking the cert should be good.
Once the web interface is set up, I agree that you shouldn't need to log into the server again. Most, if not all, maintenance tasks can be done without logging into the server. Re-configuring some things may be a bit easier if you log in (such as reconfiguring SSRS), but the two big ones - services and event log - can be viewed without logging in.
Uploading and exporting reports can be done as long as you can access the web interface.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
https://localhost/reports_ssrs ==> Yes you are right , when trying to connect this way I get a message not secure.
Thanks for your advise and suggestions Brain.
I will also ask the application team on how they are planning to get the reports from the old reporting server 2012 to ssrs 2017, ie creating new reports or exporting from old to new.
Keep you posted!
Thanks again, I can now sigh of relief!
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply