This blog describes how you can setup your Reporting Services environment using a FQDN. A FQDN is an unambiguous domain name that specifies the node's position in the DNS tree hierarchy absolutely. To distinguish an FQDN from a regular domain name, a trailing period is added. ex: somehost.mikeglaser.com. An FQDN differs from a regular domain name by its absoluteness; a suffix will not be added.
For example, given a device with a hostname of "myhost" and a domain name of "mikeglaser.com", the fully qualified domain name is "myhost.mikeglaser.com". It therefore uniquely defines the device — whilst there might be many hosts in the world called "myhost", there can only be one "myhost.mikeglaser.com".
Host name resolution is the process of resolving a host name to an IP address before the source host sends the initial IP packet.
Step 1 Local host name
The configured host name for the computer as displayed in the output of the Hostname tool. This name is compared to the destination host name.
Step 2 Hosts file
A local text file in the same format as the 4.3 Berkeley Software Distribution (BSD) UNIX etchosts file. This file maps host names to IP addresses. For TCP/IP for Windows XP and Windows Server 2003, the contents of the Hosts file are loaded into the DNS client resolver cache. For more information, see "The DNS Client Resolver Cache" in this chapter.
Step 3 DNS server
A server that maintains a database of IP address-to-host name mappings and has the ability to query other DNS servers for mappings that it does not contain.
For this example I will modify the host file to use www.mikeglaser.com as a FQDN. On Windows-based computers, this file can be found in the systemrootSystem32DriversEtc folder. As with all virtual directories, you can further customize the report server and Report Manager virtual directories through Microsoft Internet Information Services (IIS). Besides this I will also configure the Default Web Site, so it's only accessible through www.mikeglaser.com. This can be done by changing the default identification and adding the FQDN as a host header value.
After doing so, I open the both Reporting Services applications using the mine FQDN.
The first URL will still work, but second URL will give you the following error, "The request failed with HTTP status 400: Bad Request." as you can see in the next picture. This error will not occur if you didn't configured the IIS Web Site to work with a host header value.
To configure the report server or Report Manager to use a FQDN, you must also edit the configuration files.
- Open RSReportServer.config in a text editor.
- Append the port number to the UrlRoot setting in the rsreportserver.config file. For example, if Urlroot is set to http://server/reportserver server, set it to http://www.mikeglaser.com/reportserver instead.
- Open RSWebApplication.config in a text editor.
- Set ReportServerUrl to the same URL you specified in UrlRoot.
- Delete the value (but not the tags) for ReportServerVirtualDirectory.
- Save both files.
When you finished doing the previous steps, Reporting Services will function with a FQDN.
As you can see it's not that hard to use a FQDN with Reporting Services, but you gotta know how.