Hosting Reporting Services on a fully qualified domain name (FQDN)

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: 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 "", the fully qualified domain name is "". It therefore uniquely defines the device — whilst there might be many hosts in the world called "myhost", there can only be one "".

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 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 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.

  1. Open RSReportServer.config in a text editor.
  2. 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 instead.
  3. Open RSWebApplication.config in a text editor.
  4. Set ReportServerUrl to the same URL you specified in UrlRoot.
  5. Delete the value (but not the tags) for ReportServerVirtualDirectory.
  6. 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.


6 thoughts on “Hosting Reporting Services on a fully qualified domain name (FQDN)

  1. Ann

    I am facing problem while setting connection string in Report Service project.
    Problem is when I specify DNS name instead of machine name as the Server in the connection string.

    When I specify DNS name in the connection string it gives error that "A connection cannot be made.Ensure that the server is running" on click of "Test Connection"
    Also I am not able to view reports directly through IE. I.e. http:///Reports.
    When I access Reports, it prompts me to enter username/password. Even after specifying valid username, it shows me the prompt again n again.

    Is there some known issue with Reporting Service or with IIS setting not able to connect to a DNS name? I did not face with any issue when I specified DNS name in the connection string of Analysis Service project.

    I tried the settings mentioned in this blog but I was not able to connect to Reporting Service through Management studio. and when accessed through IE, it shows me the prompt.

    I also verified that:
    1: Ping with both machine name and DNS name returns same result.
    2: nslookup with both machine name and DNS name resolves to same IP.

    Awaiting some positive reply.

    Note: I am working with SQL Server 2005 Standard Edition.

  2. Stephane-Robert Langer


    Same problem here - can't access SSRS through http:///Report - it's asking for credentials. Works fine (well, almost but that's another story) through an IP. I've followed the steps in this document but still no success. Any other suggestions?


  3. Bob Wanner

    Has anyone found a solution to this name resolution issue?
    My problem is the opposite of Stephane-Robert's - I can access SSRS using DNS name. When I use the SQL HostName or IP address, SSRS starts asking for credentials.
    Additionally, when I browse the Reporting Server in IE, some of the links point to the IP address of the SQL Server and others point to the DNS name (

  4. Ralph Schwehr

    I have the same problem. If I use the servername in my accessing the reportserver everything works fine. I do need to keep the server name accessible as it is used in various applications.
    However, when I use a newly established DNS (FQDN) name that points to the reportserver I get log on prompts. I tried the method you suggested above but my applications will fail since they keep using the servername instead of the FQDN. Any suggestions?

  5. Thanks for documenting this. I believe that this helped us with a very similar problem.In your blog you said "Instead, just reboot the computer. This is the correct solution for security reasons that I'll explain later in this article." Can you explain why you recommend a reboot instead of iisreset?


Leave a Reply

Your email address will not be published. Required fields are marked *