Configuring Alternate Access Mappings and IIS Host Headers in Extranet Collaboration Manager (ExCM) 2010

by Matthew McBride

“Allow myself to introduce…myself.” – Austin Powers

I think of the above quote every time I run across this error supporting Extranet Collaboration Manager 2010:

(click on images to enlarge)

“Object reference not set to an instance of an object.”  What does that even mean?  Could there be a less intuitive error message?  Actually, don’t answer that….

This is one of the most common ExCM 2010 support tickets I see on a weekly basis.  In almost all cases it is caused by an incorrect Alternate Access Mapping for a zone and/or errors in the IIS Host Headers.

In the SharePoint 2007 world, you were forced to extend an existing Web Application in order to use Forms Based Authentication (FBA).  The original one was configured to use Windows Authentication and the extended one used FBA.  However, in SharePoint 2010 and the introduction of Claims Based Authentication, this is no longer the case.  So almost all installations of ExCM 2010 will look like this in Central Administration:

Notice that I only have one “default” zone that can use both Windows and FBA.

If you came from the 2007 world, or if you are just creating a new Web Application for test purposes, you probably just entered something very simple for a host header like this:

http://myserver

In my case I used:

http://demo

There’s nothing wrong with this approach until you decide to open your Web Application to the outside world and create an Extranet.  The intuitive approach to solving this would be to just add a new Alternate Access Mapping (AAM) such as this:

Seems straightforward enough until you actually try to access the URL:

Argh!

So what’s the problem and how do we fix it?  The first thing to understand is that each “Public URL for Zone” that appears under AAM MUST correspond to an existing zone for your Web Application.  In the case above, since no “Extranet” zone exists, SharePoint does not know where to direct requests for the “extranet.demo.com” URL.

To work around this, we can do a few things.  The simple solution is to select “Edit Public URLs” and configure the AAM to look like this:

Now if I try the URL again, I get my expected result:

But what if my environment required users or applications to still be able to access the “http://demo” URL?  How can we configure that correctly?  By adding an “Internal URL” like this:

Notice the “Default” zone highlight above.  This is another place I’ve seen administrators get tripped up because the intuitive selection might be something like “Intranet”:

But we must remember that we still only have the single “Default” zone for our Web Application.  After making the changes, our AAM screen now looks like this:

Observe the “Public URL for Zone” column.  They are identical for both entries.  However, the “Internal URL” values are different.  Any internal request using either Internal URL in that column will be sent to the Public URL.  So, entering either of the URLs below will send us to our site:

http://demo

http://extranet.demo.com

OK…so now we’re getting somewhere.  However, there is one last piece to consider in a real world scenario if we are going to open our site to the outside world…implementing SSL.

For the purposes of this post, I just created a self-signed certificate in IIS and then added a new binding to my site in IIS Manager:

Seems straightforward enough, right?  So let’s try to access our newly secure site:

What the Smurf?  Again, the error message is mostly useless because we know:

a)      That we have a Web Application using the “extranet.demo.com” URL

b)      That we typed the URL correctly

c)      That we just successfully applied an SSL Certificate in IIS

However, the last part offers a subtle clue:

“…the system administrator may need to add a new request URL mapping to the intended application.”

Aha!  It looks like we still need to tweak our AAMs one more time.  In the case of adding SSL, SharePoint still doesn’t know what IIS does…that the “https://” and the “http://” URLs both point to the same place.  So we need to use the AAMs to help it along.  To achieve this, we need to do two things:

-        Change the Public URL
-        Add another Internal URL

First, I will change the Public URL to reflect the secure URL and then add the unsecure URL as an additional Internal URL:

Now, our AAM page looks like this:

So we have three different Internal URLs all pointing to the newly secured site.  Entering any of them will basically do a SSL-redirect to the site:

 

Woohoo!

Hopefully, this will help you understand the mysterious “object reference” error should you run across it in the future.  The two most important things to keep in mind are:

-        Any Public URL entered in the AAM settings MUST correspond to an existing zone for your Web Application

-        SharePoint doesn’t always know what IIS knows, so AAM settings must be used to “teach” it

Good luck!