Let's start with a fairly common situation. Your company uses SharePoint as its intranet. You only have one domain, so you can keep things simple on the DNS host names. You call your site SP2010. Then, for what ever reason, you need to make your site resolve to the fully qualified domain name (FQDN), SP2010.MyCompany.com. Easy enough, right? First you attempt to hit the site with the FQDN. You get the IIS 7 Welcome screen, or a 404 error.
You check the Application log on your SharePoint server and find an error that says:
A request was made for a URL http://SP2010.MyCompany.com which has not been configured in Alternate Access Mappings. Some links may point to the Alternate Access URL for the default zone http://SP2010. Review the Alternate Access mappings for this Web application at http://CENTRALADMINISTRATIONADDRESS/_admin/AlternateUrlCollections.aspx and consider adding http://SP2010.MyCompany.com as a Public Alternate Access URL if it will be used frequently.Ok... Awesome.
You go to Central Administration, click on System Settings, and then Configure alternate access mappings, and are greeted with the AAM page.
Things are a little confusing here. To be honest, this page is just plan awful, especially if you have never made an AAM in SharePont 2010. After you know a little about what is going on, it makes more sense, but at first look... Terrible.
There are several buttons across the top allowing you to edit Public URLs and adding internal URLs and Mapping to External Resources. Don't worry about these for now.
The first thing we need to do is to change the view so that we only see the URLs for the Web Application that we are working with. On the right side of the screen, use the drop box to change the view from "Show All" to "SP2010." You click on the drop box and click the button that appears. A selection screen shows up, and you can pick the AAM collection that you will be working with. AAM collections are named according to the Web Application that contains them, so we click on SharePoint - 80, the name of our Web Application. Straightforward right? Ha! At least they give us the default URL so that we know a little bit about what is going on.
Now the AAM screen is back with just the URLs we are worried about.
What to do? First things first... We click on Edit Public URLs. (Disclaimer: After I get done with all of this, you are going to ask why I do my change this way, an not just add an Internal URL. You could. I am configuring this way to demonstrate the differences in zones and use the most confusing pages so that the explanation is clear, and can be used in multiple situations. It also looks a lot cleaner to have your FQDN as the public URL. ;-P)
If the AAM page was bad this page is much much worse.
What now??? It looks like we could just add a new URL here and everything will be cool right? No. Microsoft should have had some sort of validation or something here, because you can't just add a URL for a zone. You have to create the zone first. And... zones are not created in this area. If you want to create a new zone, you have to extend your Web Application in to a new IIS web site. If you add a URL in to one of the zone boxes provided, and try to hit the site, SharePoint and IIS don't know what to do with the traffic. If you are using Host Headers, you are likely to get the IIS 7 Welcome screen. If you are using ports or individual IP addresses, you are likely to get 404 or access denied errors. All this page does is tell SharePoint that traffic for a specific zone will come in over a specific URL. Nothing else.
Right now, we only have one zone defined for this Web Application, the Default zone. So, we can adjust that one. Change the default URL to have the FQDN address, and click Save. Remember that NO validation, other than a check to see if URL that you have saved matches another URL in any collection, is done on these URLs. SharePoint doesn't add anything to IIS in terms of bindings. No host headers are added. Your URL could be completely bogus, and SharePoint won't care.
Now we can do something that is actually pretty cool. In SharePoint 2010, you can have a many to one relationship with internal URLs to a single public URL. So, really you can define any URL you want for your SharePoint sites. As long as you add them to IIS and DNS. More on that later. For now, click on Add Internal URLs.
Here we get a new and somewhat less confusing page, but Microsoft gives us enough ambiguity and lack of validation to hang ourselves with.
Enter in any URL you wish. In our case we want the short URL of http://SP2010. The area that can get us in to trouble, again, is the Zone drop box. Remember we only have one zone defined, the Default zone. So even though you can change the zone, if you haven't extended your web application to create that zone, DON'T CHANGE it from Default. Click save and you go back to the AAM screen, provided that the URL you typed isn't in use by another Web Application.
You now see that we have definitions for both URLs, associated with the same Public URL. This is all we need to do to define our AAM. There is a bit of housekeeping you need to do though...
What we have just done is a SharePoint specific activity. It changes how SharePoint routs its own traffic and how SharePoint handles its own authentication. What we did does NOT change how DNS or IIS works. Those are separate process. If your URLs are not registered in DNS you will need to contact your DNS administrator to add them for you. If you are on your own for DNS work, and you don't know how to add a Host record (also called an "A" record), go here: DNS How To from Technet
For adding a host header in IIS go here: How to add a Host Header binding from Technet
If you have DNS, IIS, and AAM all configured correctly you now have your site set up to use both the short host name and FQDN for SharePoint. You also know some more about SharePoint zones, and how you can very quickly, and easily, add a URL to a SharePoint site.
