This blog describes how you can setup your SharePoint Services environment using a FQDN. For a full explanation about what a FQDN is, you can read my previous post about Hosting Reporting Services on a fully qualified domain name (FQDN).
For this example I will modify the host file to use portal.mikeglaser.com as a FQDN. On Windows-based computers, this file can be found in the systemrootSystem32DriversEtc folder. Trough Microsoft Internet Information Services (IIS) you configure the Default Web Site, so it's only accessible through portal.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 my SharePoint Services sites using the FQDN. All WSS V2 sites works like a charm, but the WSS V3 sites gives me all kinds of errors.
SharePoint WSS V2 can run in host header mode. After installing WSS but before doing anything in the Administration pages, go to the command prompt and navigate to the Program Files/Common Files/Microsoft Shared/web server extensions/60/bin folder. Run the stsadm.exe tool to create the database using this syntax:
stsadm.exe -o setconfigdb -ds <database server name> -dn <database name> -hh
Once the configuration database has been created, you can then create the sites. Make sure the server's hosts file is updated to specify the domain names you would like.
stsadm.exe -o createsite -url http://portal.mikeglaser.com -ownerlogin <domain><username> -owneremail <email address>
In this example I'm not interested in host header mode and a normal installation of WSS does not require this to run. This way its possible to approach all your sites on a IIS web site using a FQDN, after configuring the host header value in IIS.
Host header mode in SharePoint V3, allows you to create multiple domain-named sites in a single Web application. In Windows SharePoint Services version 2, when scalable hosting mode was enabled, you could extend only one Microsoft Internet Information Services (IIS) Web site. Now, with host header mode, you can have host header-based site collections on multiple Web applications, so you're no longer limited to extending just one IIS Web site. In fact, you can have a mix of path-based and host header-based site collections in the same Web application. In addition, you do not need to specify whether you want to use host header site collections when creating the configuration database. Instead, you can now specify whether site collections should be host header-based or path-based when creating the site collection.
This allows you to then host both host header sites and normal corporate mode sites on the same web application and same farm.
In this example I'm not interested in host header mode, but a normal installation of WSS does require some configuration steps to run. This way its not immediately possible to approach all your sites on a IIS web site using a FQDN, after configuring the host header value in IIS.
When I open portal.mikeglaser.com in Internet Explorer and profiling my SQL Server, WSS V3 executes the following statement.
exec dbo.proc_getSiteIdOfHostHeaderSite @HostHeader=N'portal.mikeglaser.com'
This stored proc will give a result of 0, because SharePoint isn't configured to use this FQDN. To do so, open your Central Administration web site and change the Alternate Access Mappings of your Web Application. This option can be found under operations.
You can change the default URL to notify WSS or add an additional URL to the list.
When you finished doing the previous steps, SharePoint Services will function with a FQDN.
As you can see it's not that hard to use a FQDN with SharePoint Services, but you gotta know how.