If you try to automate as much as possible your solution deployment, you'll likely enjoy having your alternate access mappings deployed in a structured and repeatable way.
Turns out that it's quite easy and manageable by stsadm without doing some custom development.
To add an internal url to your web application :
stsadm -o addalternatedomain
-urlzone Internet -incomingurl http://agentABC.company.com
And to add a public url :
stsadm -o addzoneurl
-urlzone Internet -zonemappedurl http://www.company.com
Quite handy and something we can add to our little batch files that deploy our SharePoint solutions.
As a SharePoint developer, I don't have to play too much with all the administrative tasks when I'm outside of my VMs as our IT service is responsible for ensuring the proper health status of the production facing site. So stuff like Alternate Access Mappings, Bindings and Server Name Mappings were quite new for me.
So, here is a small reminder of the steps that I did to have my site collection accessible through a fake public url (eg : http://www.company.com
) instead of http://sharepoint-dev-01
and ensure the search results are returned properly using the right url.
- Edit the host file on the server, make 127.0.0.1 point to http://www.company.com
- Edit the IIS binding (inetmgr -> point the relevant website entry -> bindings and add a new one with www.company.com as the host name on port 80 (all ip addresses unassigned)
- Add an Internet Alternate Access Mapping for your computer name (in my example : http://sharepoint-dev-01)
- Fire up your browser and access your website through the new url (you can launch Fiddler and have a look at all requests / responses to ensure everything is properly mapped
The most important part is now what to do (or what to avoid) to ensure that your search is working as you would expect it to do. The general idea is to stick with the server name as the host name instead of already playing with the AAM name. The alternate access mapping created previously will take care of all url rewritting so do not do like me and don't mess your content source or scopes with the fully qualified domain name !
- Ensure your content source is pointing to the server name instead of the fully qualify domain name (eg : http://sharepoint-dev-01)
- Ensure all relevant scopes are using the server name instead of the fully qualify domain name on your folder rules (eg Folder = http://sharepoint-dev-01/be-en/products/)
- Make a full crawl
- Enjoy your search results being served with the fully qualified domain name when your search page is accessed through http://www.company.com
It must be possible to adapt url of the search results through the "server name mappings" configuration screen but I've never been able to make it work as expected. I guess the main culprit was the fact that I mixed fqdn and server name at various place which confused the search service.
I'll never stop learning 🙂