I am giving you this information because I found it the most useful hub for AAM data in SharePoint 2007. But rather than just Tweet it over I wanted to state clearly that there is probably no reason ever to be using this in a live production environment. If you find you are reading this late a night or on the weekend and you are trying AAM to get a live farm working you are probably already in trouble.
The one time I was going to use AAM was to allow the Central Admin server to work on the URL for the Intranet in a farm. In pre-production we got this working using AAM, but the difficulty caused us to step back and speak to some of the more level heads on our team. What we decided was that AAM would impose a great deal of risk on the project and we answered back on the requirement. Once we explained the risk to making your Central Admin a mapping to your intranet URL the client understood and we simply dropped the requirement.
So with that warning please feel free to read on.
To avoid many questions and simplify troubleshooting, I would suggest this order when configuring AAM, which worked for me so far :Click here to read full post: How to configure Alternate Access Mappings (AAM) successfully - From The Field
- Understand what AAM is, and what is it being used for in your particular case. (Read the blog posts below).
- Create a top level site collection in the application that you are trying to configure ( like http://mymossserver )
- Browse the site, make sure it works
- Complete the network configuration for the alternate URL that you are planning to use ( like http://intranet.mycompany.com ). If you do not know how to do this part, get your network administrator involved. This is a fundamental requirement to get it working.
- Create the host header entries on IIS for the web application you are trying to configure. If you do not know how to do this, get your IIS admin, or system admin (whomever configures IIS in your environment) involved. This is a fundamental requirement to get it working.
- Then browse the site using the new url you have configured. If you have configured it correctly, you should be able to browse the sharepoint site with the configured URL ( http://intranet.mycompany.com ), but redirected to the default zone mapping you have at this point ( http://mymossserver )... This means the network is capable of transporting the request to IIS, and IIS is capable of handing the request to the correct SharePoint web application.
- Then add the AAM for the desired zone in central admin, and make sure you have ONE mapping configured for each zone. (intranet zone in this case) Beware, the default zone will be selected when you open the page, you probably want to CHANGE IT...
- Browse the site with the new URL (http://intranet.mycompany.com). Voila ! Note: If you added two mappings to the same zone, you will see the exact same symptom of getting redirected to the first URL mapping in that zone...
Blogged with the Flock Browser