Are you getting “Internet Explorer cannot Display the Web Page” for your Shared Service Provider administrative page?

Recently, I was performing a relatively simple SharePoint installation on a client’s network – a two-server virtual farm using VMs running Windows Server 2008 and SQL 2008, IIS 7.0 with 4 GB ram. We finally got it working and proceeded to create our site collection. When we went back to configure our shared services in the SSP admin page, we could not access it. It simply gave us an error “Internet Explorer cannot display the web page.” After many very quiet expletives (I was with a client, after all), I proceeded to troubleshoot by checking the host header properties in IIS, the configuration of the SSP, and the alternate access mappings (just to be sure) and all looked fine. There was no explanation as to why it would suddenly quit working. I retraced my steps. We had installed SharePoint, created our required three web applications, configured search, enabled Excel Services, created the associated SSP and called it http://SharedServices/, and created our site collection. (Now, you experienced web and network admins are probably saying “Well, of course…”).

But for those who are not experienced with DNS or other possible network challenges (and many SharePoint admins “fall into” their jobs with little or no training in this area), the answer was not so clear.

The problem was that we gave our SSP a “friendly” name by adding a host header. A host header allows users to type in something that they can easily remember, such as http://MySharedServices instead of http://ssp:35648/ssp/admin.  We do this all the time for our main SharePoint site collections so our users can type http://MyGreatPortal.com instead of http://servername:80/default.aspx. The difference is that we know what we are going to call it and our network admins (bless their hearts) add it to DNS so that it could resolve no matter where the page was accessed from on the network. Because this is an administrative page, it didn’t occur to me to do that.

Since this page would most likely only be accessed from the server it lives on, there was really no reason to add it to DNS (although that certainly would work). A workaround for this is to add the global IP for the machine to the hosts file and associate it to the friendly name you will use to connect to the SSP Admin page. To do this, access the host file found in <windir>\system32\drivers\etc\hosts (typically <windir> is C:\WINDOWS).

Open the hosts file with Notepad and towards the bottom, type in the IP address (unless you are using a specific IP for the site, 127.0.0.1 is the global IP for the machine), hit the tab key and enter whatever friendly name you are using in your Host Header.

Save and close the file. Open your SSP page and it should display with no problem.

Of course, the alternative is to create your SSP with NO host header and eliminate this issue altogether.