SharePoint Multiple Domain Name Best Practice

Russ,

Generally speaking, the proper way to do this is with option #1: extending the web application. There are a couple of big reasons for this:

1. Probably the most important reason to use option #1 was mentioned by Moo in his post (above): the settings that are maintained in IIS (for example, host headers) are also tracked within SharePoint. Unless there isn't another way to handle a particular IIS setting from SharePoint (binding an SSL certificate is a good example), it is strongly recommended that all IIS changes be managed by actions and configuration within SharePoint. Making changes in IIS without updating SharePoint's backing configuration oftentimes results in extremely weird behavior. One of the jobs of the SPAdmin service (Windows SharePoint Services Configuration service) is to apply changes you make within SharePoint to IIS and across a farm (if multi-server); it's best to let this service do its job.

2. When you extend the web application, you associate the new URL with a particular zone (Internet, Extranet, Intranet, or Custom). When building links to other SharePoint sites within the farm, SharePoint will attempt to use a URL for the site that lines up with your current zone. For example, if you were to extend web app A to the Extranet zone, and web app A contains links to web app B, then SharePoint will attempt to use Extranet zone links for web app B if they are available -- not the default zone links. If web app B isn't extended to the Extranet zone, there is a fallback process (all the way to the default zone) that is used to assign a link ... but it's important to know that this is going on behind-the-scenes.

An alternate approach would be to associated an additional hostname with the default zone URL you already have via the Alternate Access Mappings (AAM) functionality built into the platform. Before doing this, though, there's one very important consideration to bear in mind: each zone (again: Default, Intranet, Extranet, Internet, or Custom) can only have on public URL associated with it. In your example, abc123.com is the Default zone public URL. You could use AAMs to then map www.abc123.com as an additional entry point to the Default zone ... but when you do so, all links on the page will refer back to abc123.com. So, the first page request could arrive through www.abc123.com, but clicking any of the links on the page that post back to the site will send requests to abc123.com. In essence, this makes the AAM useful for really only the first call (unless you're using something like ISA Server's SharePoint publishing functionality -- but that's another story and off-topic).

I'm skeptical that option #2 would even work. If SharePoint isn't aware of the hostname associated with a site (that is, it is only assigned in IIS), it has no way of knowing where the content from that site should be drawn from. SharePoint doesn't operate like a traditional file-backed web site; the URL is parsed by SharePoint's virtual redirector to pull content from the appropriate content database backing the site. If IIS has a hostname but SharePoint knows nothing about it, I would expect no content to get retrieved and an error condition to result.

I haven't tested it, but I would expect option #3 to work for the initial entry into the site. After that, all page requests and links would go to the redirected target.

I hope that helps!

I would use option 3, because that ensures that any metadata or links stored in SharePoint are for a single hostname - thus, if you decide to remove the secondary hostname later on for whatever reason, you do not have an issue with dead links.

If the only thing you need this second hostname to do is go straight to this sharepoint site then I would personally use option 2, its quick and easy and it will send that URL straight to that site, but its an IIS change, so sharepoint knows nothing about it. If you need sharepoint to be aware of this URL then you may want to use one of the other two optiosn.