|
|
You're in the
sql server reporting services
group:ReportManager works fine until I modify the FQDN
sql server reporting services:
I don't know how I can succinctly express my problem other than I've got all
the latest bits for SQL Server 2000, Reporting Services, service packs, etc... installed. I have Share Point Portal / IIS 6 / Windows 2003 / SQL Server 2000 all installed on same box. I followed all directions to install Reporting Services correctly under this configuration and, lo and behold, everything worked as advertised. After I got the above stack working under a non SSL mode, I proceeded to setup an SSL only option for IIS. No biggie. Everything works just fine! I created a CA key using OpenSSL and signed my IIS cert request and installed into IIS and Share Point and SQL Reporting Services are all very cool with this. Of course, I installed the CA cert in my Trusted Root Authorities on the server and my client. So what's the problem, right? Well I want to do the unthinkable. I want to expose my Reporting Server on the Internet behind an ISA server (in the DMZ). So to make this work, of course, everyone on the planet needs to use an FQDN rather than my local machine name. There's lots of advice on the net and in various technet articles from MS about how to do this. Just update the ReportServerUrl in the ReportManager app config file. I did that. Some people believe you should update the UrlRoot in the ReportServer config file. I've tried that and all combinations to no avail. So the deal is if come into the ReportManager virtual using anything other than the local host name of the machine I get one of two errors (after a long timeout): 1. Underlying connection was closed: could not establish trust relationship with remote server. -or- 2. Underlying connection was closed: unable to connect to the remote server. I think I've tried everything I can think of. I don't think it could be SSL related because SSL works if I setup the Reporting server config files to be based upon the local host name of the machine. My virtual directories in IIS only permit SSL connectivity to both Reports and ReportServer virtuals. I also have played around with the SecureConnectionLevel parameter in both config files (making it something like "2" in each to no avail). I'm beat! I've tried any and all combinations and just cannot seem to change the name by which I can access the report server. Oh, in case you are curious, the FQDN of the internal server is something like "server1.edc.local". If I setup the config files to come in either via "server1" or "server1.edc.local" (hey, that's a FQDN, right?) then all works fine. The FQDN for the server on the internet will be something like "www.edc.mycompany.com" which has no relation to the Active Directory domain name (which ends in .local). Of course, this FQDN gives me serious fits. Any ideas on what to try next?
[quoted text, click to view]
"Jasper Smith" wrote: > What's the name on the Certificate used for SSL? Sounds like this > http://support.microsoft.com/default.aspx?scid=kb;en-us;823177 from the > error you are seeing. I neglected to mention (somehow) that as I've tried both the inside and outside FQDN attempts I do have two certs. I have a cert for the inside (local) FQDN -- this one works as I said. When I flip all the configs around to be using the outside FQDN, I use a cert for IIS that exactly matches (case and all) the outside FQDN. No go. I even restart IIS and the Reporting service thinking this might be it, but nothing. Any other tricks to try?
[quoted text, click to view]
"Jasper Smith" wrote: > What's the name on the Certificate used for SSL? Sounds like this > http://support.microsoft.com/default.aspx?scid=kb;en-us;823177 from the > error you are seeing. So the kb article talks about two scenarios. My certs match the URL I am coming in on (as previously stated in a prior post), but the other scenario seems more like what I have. From the kb article: "Other scenarios exist also. For example, some networks use a different name-resolution scheme for internal versus external clients. In cases where the certificate is issued to a server with a public URL (such as www.adatum.com) and with intranet applications, the internal Domain Name System (DNS) Server provides a different name for the same server (such as www.internal.corporate.adatum.com). Requests for this Web service over SSL may fail. This change is made to enhance the security of Web services that use SSL." The kb article subsequently states a possible remedy in unclear terms, as follows: "You can change the name-resolution scheme so that DNS provides the same name for a server. The same name for the server must be used whether the server is referred to from in the company or from outside the company. For example, assume that a certificate has been issued to the URL www.adatum.com. Any Web service application that is referred from outside the organization is called by using the external DNS resolution schema (www.adatum.com). When an intranet Web service application is called, the internal DNS translates the name of the site as www.internal.corporate.adatum.com. Therefore, any request for the Web Service over SSL may fail unless you change the name-resolution scheme. " So what does this really mean? Does it mean I can fix it somehow in DNS (which I run out of my local AD) or does it mean I must rename my AD domain (which is edc.local right now) to something that permits me to put the server in the proper DNS zone (in this case mycompany.com). What I am looking for right now is a quick fix without having to forklift my AD into a new domain name. Any thoughts on what it means to change the name-resolution scheme and what that translates to? Regards,
[quoted text, click to view]
"Jasper Smith" wrote: > Is it just Report Manager giving the error, can you access the Report Server > web service ok (i.e. just go to https://externalname/ReportServer) and run a > report from there or do you get the same error? Yes, you can access the report server directly using either scheme (internal or external FQDN scheme). This has always seemed to work so the problem is limited to the ReportManager only as it is using the .NET Web service technoloy that is really really mad about something. Geesh -- I hope this gets easier with reporting services because I'm no script kiddie and I feel like setting up reporting services to work in a real internet setting is daunting to say the least!
What's the name on the Certificate used for SSL? Sounds like this
http://support.microsoft.com/default.aspx?scid=kb;en-us;823177 from the error you are seeing. -- HTH Jasper Smith (SQL Server MVP) http://www.sqldbatips.com I support PASS - the definitive, global community for SQL Server professionals - http://www.sqlpass.org [quoted text, click to view] "John" <John@discussions.microsoft.com> wrote in message news:B6A8E286-2598-44AC-9E82-49C219ADACC0@microsoft.com... >I don't know how I can succinctly express my problem other than I've got >all > the latest bits for SQL Server 2000, Reporting Services, service packs, > etc... installed. I have Share Point Portal / IIS 6 / Windows 2003 / SQL > Server 2000 all installed on same box. > > I followed all directions to install Reporting Services correctly under > this > configuration and, lo and behold, everything worked as advertised. > > After I got the above stack working under a non SSL mode, I proceeded to > setup an SSL only option for IIS. No biggie. Everything works just fine! > I > created a CA key using OpenSSL and signed my IIS cert request and > installed > into IIS and Share Point and SQL Reporting Services are all very cool with > this. Of course, I installed the CA cert in my Trusted Root Authorities > on > the server and my client. > > So what's the problem, right? Well I want to do the unthinkable. I want > to > expose my Reporting Server on the Internet behind an ISA server (in the > DMZ). > So to make this work, of course, everyone on the planet needs to use an > FQDN > rather than my local machine name. > > There's lots of advice on the net and in various technet articles from MS > about how to do this. Just update the ReportServerUrl in the > ReportManager > app config file. I did that. Some people believe you should update the > UrlRoot in the ReportServer config file. I've tried that and all > combinations to no avail. > > So the deal is if come into the ReportManager virtual using anything other > than the local host name of the machine I get one of two errors (after a > long > timeout): > > 1. Underlying connection was closed: could not establish trust > relationship > with remote server. > -or- > 2. Underlying connection was closed: unable to connect to the remote > server. > > I think I've tried everything I can think of. I don't think it could be > SSL > related because SSL works if I setup the Reporting server config files to > be > based upon the local host name of the machine. My virtual directories in > IIS > only permit SSL connectivity to both Reports and ReportServer virtuals. > > I also have played around with the SecureConnectionLevel parameter in both > config files (making it something like "2" in each to no avail). > > I'm beat! I've tried any and all combinations and just cannot seem to > change the name by which I can access the report server. > > Oh, in case you are curious, the FQDN of the internal server is something > like "server1.edc.local". If I setup the config files to come in either > via > "server1" or "server1.edc.local" (hey, that's a FQDN, right?) then all > works > fine. > > The FQDN for the server on the internet will be something like > "www.edc.mycompany.com" which has no relation to the Active Directory > domain > name (which ends in .local). Of course, this FQDN gives me serious fits. > > Any ideas on what to try next? > > John
Is it just Report Manager giving the error, can you access the Report Server
web service ok (i.e. just go to https://externalname/ReportServer) and run a report from there or do you get the same error? -- HTH Jasper Smith (SQL Server MVP) http://www.sqldbatips.com I support PASS - the definitive, global community for SQL Server professionals - http://www.sqlpass.org [quoted text, click to view] "John" <John@discussions.microsoft.com> wrote in message news:9FEE56AF-913A-4496-9D6A-C0FFCDA2C143@microsoft.com... > "Jasper Smith" wrote: > >> What's the name on the Certificate used for SSL? Sounds like this >> http://support.microsoft.com/default.aspx?scid=kb;en-us;823177 from the >> error you are seeing. > > I neglected to mention (somehow) that as I've tried both the inside and > outside FQDN attempts I do have two certs. I have a cert for the inside > (local) FQDN -- this one works as I said. When I flip all the configs > around > to be using the outside FQDN, I use a cert for IIS that exactly matches > (case > and all) the outside FQDN. No go. I even restart IIS and the Reporting > service thinking this might be it, but nothing. > > Any other tricks to try? > > John
Anyone have any thoughts on the following I posted late last week to this
group? Specifically, the kb article (823177) states the following: "You can change the name-resolution scheme so that DNS provides the same name for a server. The same name for the server must be used whether the server is referred to from in the company or from outside the company" So I have done essential what this kb article suggest. The internal FQDN host name on my box is server1.edc.local. Outsiders access this server via my DMZ ISA server using the URL https://www.edc.mycompany.com. So in addition to my outside DNS resolving www.edc.mycompany.com to my front-end ISA server, I setup a split-DNS on the inside that resolves www.edc.mycompany.com to the same IP address as server1.edc.local. This *does not work* though. I still get the same error the KB article describes. So what I am looking for is, do I have to renamed my local AD domain to something like edc.mycompany.com and then rename server1 to www to get this to work? Is that what the article's plan of action entails or is there something else I can try? John [quoted text, click to view] "John" wrote:
> "Jasper Smith" wrote: > > > What's the name on the Certificate used for SSL? Sounds like this > > http://support.microsoft.com/default.aspx?scid=kb;en-us;823177 from the > > error you are seeing. > > So the kb article talks about two scenarios. My certs match the URL I am > coming in on (as previously stated in a prior post), but the other scenario > seems more like what I have. > > From the kb article: > > "Other scenarios exist also. For example, some networks use a different > name-resolution scheme for internal versus external clients. In cases where > the certificate is issued to a server with a public URL (such as > www.adatum.com) and with intranet applications, the internal Domain Name > System (DNS) Server provides a different name for the same server (such as > www.internal.corporate.adatum.com). Requests for this Web service over SSL > may fail. This change is made to enhance the security of Web services that > use SSL." > > The kb article subsequently states a possible remedy in unclear terms, as > follows: > > "You can change the name-resolution scheme so that DNS provides the same > name for a server. The same name for the server must be used whether the > server is referred to from in the company or from outside the company. > > For example, assume that a certificate has been issued to the URL > www.adatum.com. Any Web service application that is referred from outside the > organization is called by using the external DNS resolution schema > (www.adatum.com). When an intranet Web service application is called, the > internal DNS translates the name of the site as > www.internal.corporate.adatum.com. Therefore, any request for the Web Service > over SSL may fail unless you change the name-resolution scheme. " > > So what does this really mean? Does it mean I can fix it somehow in DNS > (which I run out of my local AD) or does it mean I must rename my AD domain > (which is edc.local right now) to something that permits me to put the server > in the proper DNS zone (in this case mycompany.com). > > What I am looking for right now is a quick fix without having to forklift my > AD into a new domain name. Any thoughts on what it means to change the > name-resolution scheme and what that translates to? > > Regards, >
John,
I am hoping this message will find you. Basically, you need to change the links in the Reporting Services configuration file to match that of your external link. There are 2 folders under C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportManager and C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportManager and ReportServer, look for RSWebApplication.config and RSReportServer.config respectively and change to (ie https://www.mydomain.com/Reports). Just have to make sure that www.mydomain.com on the internal network resolves to the INTERNAL ip address of the web server hosting Reporting Services and sounds like you may have done that. Basically, INTERNAL clients pings www.mydomain.com will get 10.0.0.5 and EXTERNAL ping www.mydomain.com will get 208.11.111.111. Gluck. [quoted text, click to view] "John" wrote:
> Anyone have any thoughts on the following I posted late last week to this > group? Specifically, the kb article (823177) states the following: > > "You can change the name-resolution scheme so that DNS provides the same > name for a server. The same name for the server must be used whether the > server is referred to from in the company or from outside the company" > > So I have done essential what this kb article suggest. The internal FQDN > host name on my box is server1.edc.local. Outsiders access this server via > my DMZ ISA server using the URL https://www.edc.mycompany.com. > > So in addition to my outside DNS resolving www.edc.mycompany.com to my > front-end ISA server, I setup a split-DNS on the inside that resolves > www.edc.mycompany.com to the same IP address as server1.edc.local. > > This *does not work* though. I still get the same error the KB article > describes. So what I am looking for is, do I have to renamed my local AD > domain to something like edc.mycompany.com and then rename server1 to www to > get this to work? Is that what the article's plan of action entails or is > there something else I can try? > > John > > "John" wrote: > > > "Jasper Smith" wrote: > > > > > What's the name on the Certificate used for SSL? Sounds like this > > > http://support.microsoft.com/default.aspx?scid=kb;en-us;823177 from the > > > error you are seeing. > > > > So the kb article talks about two scenarios. My certs match the URL I am > > coming in on (as previously stated in a prior post), but the other scenario > > seems more like what I have. > > > > From the kb article: > > > > "Other scenarios exist also. For example, some networks use a different > > name-resolution scheme for internal versus external clients. In cases where > > the certificate is issued to a server with a public URL (such as > > www.adatum.com) and with intranet applications, the internal Domain Name > > System (DNS) Server provides a different name for the same server (such as > > www.internal.corporate.adatum.com). Requests for this Web service over SSL > > may fail. This change is made to enhance the security of Web services that > > use SSL." > > > > The kb article subsequently states a possible remedy in unclear terms, as > > follows: > > > > "You can change the name-resolution scheme so that DNS provides the same > > name for a server. The same name for the server must be used whether the > > server is referred to from in the company or from outside the company. > > > > For example, assume that a certificate has been issued to the URL > > www.adatum.com. Any Web service application that is referred from outside the > > organization is called by using the external DNS resolution schema > > (www.adatum.com). When an intranet Web service application is called, the > > internal DNS translates the name of the site as > > www.internal.corporate.adatum.com. Therefore, any request for the Web Service > > over SSL may fail unless you change the name-resolution scheme. " > > > > So what does this really mean? Does it mean I can fix it somehow in DNS > > (which I run out of my local AD) or does it mean I must rename my AD domain > > (which is edc.local right now) to something that permits me to put the server > > in the proper DNS zone (in this case mycompany.com). > > > > What I am looking for right now is a quick fix without having to forklift my > > AD into a new domain name. Any thoughts on what it means to change the > > name-resolution scheme and what that translates to? > > > > Regards, > >
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |