Configure The Alternate Access Mappings...

A question often asked when exposing an internal site out to the Internet is, "why do I have to extend my original web app into  a new zone with an intermediary internal URL to publish to a public URL, can't I simply add a public URL to a new zone for the already existing web app?"

The answer is no as described in mistake #3 in the Plan alternate access mappings article.

In short, if a web application was created with a host header then IIS will only listen on that host header and the request for the new URL will never get to SharePoint. The recommended approach would be to make the web application listen on a different URL by extending the web application into a different zone which creates a second IIS site and provides the opportunity to configure a host header for the extended site to listen on (this would form the internal URL, and a public URL in the same zone should be defined). 

Although technically speaking, if a host header wasn't defined when the web application was originally created, and IIS was blindly listening on port 80 this wouldn't be a problem and we could simply add a public URL in the same zone as the original web application.....so we may believe.....

Whilst a fellow PFE was onsite with a customer, some strange behaviour in SharePoint  was experienced.

The customer was reporting that even though they had multiple web applications serving content and that all the web applications were hosted under their own application pools, only one w3wp.exe process was on each of their web front end servers.

We had initially thought that this was because of their AAM configuration, as they had entries pointing to specific servers. In other words, we thought we would find that only certain servers would have multiple w3wp.exe processes as the AAM redirected the users to a specific server and not to NLB.

However, after digging into AAM, DNS name resolution, application pool configuration and so on, it turns out that in fact, only one w3wp.exe process was serving content for all the web applications in the environment.

The following diagram explains the configuration of web applications, worker processes, AAMs and Content DBs in the environment:

The problem was that although users were hitting content hosted on WEB APPLICATION 2 we could only see 1 w3wp.exe process with PID (6148). That worker process corresponded to WEB APPLICATION 1, not WEB APPLICATION 2 – Don’t get me wrong, users were requesting data from WEB APPLICATION 1, but they were also requesting data from CONTENT DB 2 which was attached to WEB APPLICATION 2.

Long story short, it turns out that the AAM mapping for WEB APPLICATION 2 (INTERNET ZONE) was created in the AAM page. They never extended the web application to use the loadbalancedurl2.net address. They just created the new zone via AAM page. Because it was never extended, when the client resolved the loadbalancedurl2.net address from WEB APPLICATION 2, the address was resolved to their WFEs IP address, but IIS would accept the request via the website on PORT 80 (http://loadbalancedurl2.net:80) – which corresponds to WEB APPLICATION 1. This essentially meant that WEB APPLICATION 1, listening on port 80 was accepting all requests from users that used the load balanced URLs for all the web applications in the environment.

WSS_Content2 is only actually served thanks to the absence of host header on WEB APPLICATION 1 thus permitting PID 6148 to receive all incoming requests on port 80 and route as “best effort”. And as you may have guessed by now, this only works because both web applications are using an application pool with the same login.  If each web application’s application pool had a unique login, then WEB APPLICATION 1 would not be able to access the content database for WEB APPLICATION 2 and vice versa.

As outlined in the second paragraph of this post, the proposed resolution and recommended approach would be to have an extension of each of the applications into another zone, ideally  having hostheader mapped to public url (or whatever it might be http://mossserver:85 in this case), if the reverse proxy device exposing the web application is NOT forwarding the host header. This will isolate user / proxy traffic on a specific process and no longer serve the multiple Content DBs through the  single web application.

Configure alternate access mapping

Each Web application can be associated with a collection of mappings between internal and public URLs. Both internal and public URLs consist of the protocol and domain portion of the full URL (for example, https://www.fabrikam.com). A public URL is what users type to get to the SharePoint site, and that URL is what appears in the links on the pages. Internal URLs are in the URL requests that are sent to the SharePoint site. Many internal URLs can be associated with a single public URL in multi-server farms (for example, when a load balancer routes requests to specific IP addresses to various servers in the load-balancing cluster).

Each Web application supports five collections of mappings per URL; the five collections correspond to five zones (default, intranet, extranet, Internet, and custom). When the Web application receives a request for an internal URL in a particular zone, links on the pages returned to the user have the public URL for that zone. For more information.

Manage alternate access mappings

1. On the top navigation bar, click Operations.
2. On the Operations page, in the Global Configuration section, click Alternate access mappings.

For information about how to perform this procedure using the Stsadm command-line tool, see 

Add an internal URL

1. On the Alternate Access Mappings page, click Add Internal URLs.
2. If the mapping collection that you want to modify is not specified, then choose one. In the Alternate Access Mapping Collection section, click Change alternate access mapping collection on the Alternate Access Mapping Collection menu.
3. On the Select an Alternate Access Mapping Collection page, click a mapping collection.
4. In the Add internal URL section, in the URL protocol, host and port box, type the new internal URL (for example, https://www.fabrikam.com).
5. In the Zone list, click the zone for the internal URL.
6. Click Save.

For information about how to perform this procedure using the Stsadm command-line tool.

Edit or delete an internal URL

Note:
You cannot delete the last internal URL for the default zone.

1. On the Alternate Access Mappings page, click the internal URL that you want to edit or delete.
2. In the Edit internal URL section, modify the URL in the URL protocol, host and port box.
3. In the Zone list, click the zone for the internal URL.
4. Do one of the following:
   • Click Save to save your changes.
   • Click Cancel to discard your changes and return to the Alternate Access Mappings page.
5. Click Delete to delete the internal URL.

Edit public URLs

Note:
There must always be a public URL for the default zone.

1. On the Alternate Access Mappings page, click Edit Public URLs.
2. If the mapping collection that you want to modify is not specified, then choose one. In the Alternate Access Mapping Collection section, click Change alternate access mapping collection on the Alternate Access Mapping Collection menu.
3. On the Select an Alternate Access Mapping Collection page, click a mapping collection.
4. In the Public URLs section, you may add new URLs or edit existing URLs in any of the following text boxes:
   • Default
   • Intranet
   • Extranet
   • Internet
   • Custom
5. Click Save.

Map to an external resource

You can also define mappings for resources outside internal Web applications. To do so, you must supply a unique name, initial URL, and a zone for that URL. (The URL must be unique to the farm.)

1. On the Alternate Access Mappings page, click Map to External Resource.
2. On the Create External Resource Mapping page, in the Resource Name box, type a unique name.
3. In the URL protocol, host and port box, type the initial URL.
4. Click Save.