Matthew McDermott

Matthew is a principal consultant for Catapult Systems. A Microsoft MVP (SharePoint Server), Matthew blogs about SharePoint and Microsoft technologies related to collaboration, web content management and productivity.

Notable Blogs

MVP Blogs

AAM and SSL Termination

Scenario

A few days ago I knew nothing about SSL Termination, the Cisco ACE load balancer or Alternate Access Mapping. (OK, I lied, I knew enough about AAM to hate it. Mostly because I just don't get it.) I was struggling with the following scenario. Spencer Harbar and Shane Young lead me down the right path.

SSL Termination and Load Balancing

We use alternate access mapping to handle the routing of requests to the two web applications Intranet and MySite. This configuration is a result of the Cisco Ace Load Balancer that is handling the SSL termination and request forwarding. The end user types in https://intranet.company.com and the load balancer handles the SSL part and forwards the plain old http request to SharePoint. This diagram shows the set up.

The load balancer handles the SSL encryption and address translation. The web front ends only need to handle the HTTP traffic. Once the web applications are built you must configure Alternate Access Mapping to enable SharePoint to respond to the correct addresses. I knew all this, but found the AAM user interface a challenge to really understand. In this case we need the configuration to use a Public URL of https://intranet.company.com and an Internal URL of http://intranet.company.com.

AAM Configuration

The alternate access zone for Intranet should contain only one address: https://intranet.company.com.

A new Internal URL is required to handle the http traffic. Select Add Internal URL and ensure that you have selected the right AAM Collection. Enter the address http://intranet.company.com and add it to the Default zone.

Perform these same steps for http://mysite.company.com.

Your Alternate Access Mapping settings should now look like this. Note that the different Internal URLs map to the same Zone and the same Public URLs for Zone.

Search Settings

Depending on how you created your web applications you may need to change the start addresses of your Content Sources. In our case we changed them all to crawl on https.

References

AAM on TechNet

http://technet.microsoft.com/en-us/library/cc261814.aspx

Cisco ACE Information

There is nothing in here for SharePoint but it has some handy info for your network folks.

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigration_09186a0080908161.pdf

Posted by Matthew McDermott on Tuesday, 5 Aug 2008 02:58

21 Comments | Filed under: Administration, MVP, My Sites, People who Rock

Bookmark this post with:

Comments

On 30 Sep 2008 01:11, Benjamin Athawes said:

Thank you SO much for this!!! Saved me after hours of frustration with AAM :-)

On 24 Feb 2009 09:27, Dhiren Amin said:

I followed the same steps, but we are experiencing DNS error messages or error when browsing to a site without specifying a filename (such as https://computer_name/site_name), but you are able to access the site if you browse directly to a specified file within the site (such as https://computer_name/site_name/pages/default.aspx).

On 25 Feb 2009 07:26, Matthew said:

It could be a couple things, but I would start tith name resolution from DNS to the load balancer to IIS and ensure that the IIS host headers are correct for the IP addresses that you configured on the load balancer. Check your welcome page settings too. HTH,

On 25 Feb 2009 01:25, Dhirne Amin said:

I checked everything you suggested and it seem like everything is setup correctly. It seems like when I try to access https://computer_name/site_name, sharepoint redirects it to http://computer_name/site_name/pages/default.aspx and we are not allowing any traffic on port 80 on the loadbalanncer, thus causing DNS error. According to AAM on Tenet, I might have alternate access mappings configured incorrectly.

On 26 Feb 2009 07:35, Matthew said:

OK, that is different from what you said in your previous comment. It sounds like you still don't have AAM set up correctly. Look closely at the second to last image. Your Public URL should BOTH be HTTPS.

On 27 Feb 2009 11:05, Bryan said:

I have my MySites arranged like so: https://mysites.foo.com Default https://mysites.foo.com http://mysites.foo.com:8084 Default https://mysites.foo.com The requests come in through a load balancer that strips the SSL and forwards to HTTP on port 8084, much like your solution above. It all works greate EXCEPT that the "This List" contextual scope dissapears from my search widget (the "This Site" scope remains). If I remove the AAM and hit the site directly on HTTP port 8084, the scope returns and works as expected. Do you have a similar loss of functionality? If not, any ideas on what I might have missed?

On 27 Mar 2009 03:33, Tushar Agarwal said:

Thanks for very informative post. I still have some issue with my AAM though. I wanted my internal users (inside network) to use http://office.domain.com and external users are being redicted to https://office.domain.com via bluecode SSL termination. For external users everything is fine once I follow steps in your post. I setup default public zone URL to https://office.domain.com and one internal url in default zone to http://office.domain.com Now problem is that I am not able to browse http://office.domain.com on WFE and so search is not able to find this and crawl is throwing error. Any idea how to fix? My internal users are not being redirected to https and so with above arrangement in AAM they are not able to access site with any of following URLs: http://office.domain.com https://office.domain.com

On 10 Apr 2009 03:52, Brian H said:

I am also experiencing the problem the Bryan above is. Any thoughts on that or maybe Bryan could reply back if he's been able to fix it? Thanks!

On 13 Apr 2009 12:19, Bryan said:

Sadly, I have not fixed it. I've further determined that if your AAM swtiches protocols or ports (i.e. from http to https or port 8084 to 8083) it starts breaking. Changing the url (from say foo.com to bar.com) but leaving the ports/protocol alone works fine. No ideas on what to do about it yet, though.

On 14 Apr 2009 07:36, Matthew said:

Bryan, have you applied the Infrastructure Update or are you running the February CU? The IU breaks some elements of AAM that are fixed in August.

On 14 Apr 2009 10:31, Bryan said:

I have both the IU and Feb CU. To my knowledge (from using the SharePoint Team Blog) I am completely up to date. I spent a long night with the Microsoft.SharePoint.Portal DLL, Reflector, and Notepad (to manually trace MSIL). The problem looks like it occurs in CreateChildControls in the SearchBoxEx control. When you're running an AAM, HttpRequest.Current.Request.Url comes in as your "untranslated" link - http://mysites.foo.com:8084 from above - since that's what your browser actually saw on the URL. Unfortunately, tp build the "This List" context, the control tries a SPWeb.GetFolder on that untranslated link. Since my internal DNS is set to automatically send the name "mysites.foo.com" back out to the load balancer, we now get a request to the balancer on HTTP port 8084 - which the balancer rightfully refuses as being on the wrong port (it's looking for 443 from the outside). So, the GetFolder fails and throws an exception (which SharePoint adds to the m_Error field in the control but apparently never displays), then continues on its merry way with the scopes from the SSP. Upshot: if your internal DNS/balancer will properly route the unmapped link, or you're not using AAM at all, or you trick things with your hosts file, you'll work fine. If not, it silently disappears with no warning. It seems the best we could do is subclass the control, properly look at the URL and add the entry back in as needed. Alternatively, convince your networking folks to redo the internal DNS/firewalls. Please try to poke holes in this theory. It's been a long time since I traced "assembly" (or MSIL), so I may have done something wrong and just confused myself.

On 15 Apr 2009 11:46, Brian H said:

I have the February CU installed. It was actually installed last night and the problem still exists.

On 29 May 2009 12:08, Brian H said:

This problem still exists after SP2 and the April CU. :(

On 31 May 2009 07:34, Matthew said:

Brian, You are the first I have heard with this problem. I would begin by testing with a clean site collection. Also, Why run the MySites on any port other than 443 or 80? I find that port numbers confuse users. I'll be that it resolves if you use either 443 or 80. You can also take a look at Spence's blog for more. http://www.harbar.net

On 01 Jun 2009 09:35, Brian H said:

The Brian/Bryan comments are messing things up. :) I have mysites on 443. The other BrYan doesn't. I have duplicated this problem in our test envirnment as well. It has been driving us nuts. I'll probably end up with a Microsoft Incident.

On 01 Jun 2009 09:50, Brian H said:

I also want to mention that keywords don't seem to work either. I imagine it is due to the same cause. Another thing I haven't mentioned yet is if I browse to the address from the server locally (bypassing ISA but using the same url), search works right. It is only when it goes through ISA does the dropbox not show the other search scopes. I don't think I'm doing anything out of the ordinary but it still surprises me that I haven't found anyone else that has experienced it.

On 02 Jun 2009 07:19, Matthew said:

Brian, sounds like you are on the right track. There are several ISA + SharePoint whitepapers. I would check your configuration.

On 07 Jul 2009 04:06, club penguin said:

I followed the same steps, but we are experiencing DNS error messages or error when browsing to a site without specifying a filename (such as: https://computer_name/site_name), but you are able to access the site if you browse directly to a specified file within the site (such as https://computer_name/site_name/pages/default.aspx).

On 17 Jul 2009 10:11, Bryan said:

Good news! Apparently the June 2009 CU fixes the "This List" problem above: "When you try to do a search in a SharePoint site, the scope "This List: Name of list, doclib etc." for a particular listis missing. This issue occurs because you are using the Extended Web Applications and the Alternative Access Mapping (AAM) settings." I've not tried it yet, but at least Microsoft noticed.

On 18 Dec 2009 03:21, Brian H said:

The June CU didn't fix it for me but the December 2009 CU did. I just confirmed it on our test farm. Once I installed the update, the other scopes appeared. On production, I got around it by doing SSL to SSL instead of terminating it. It doesn't look like that is necessary anymore.

On 19 Dec 2009 07:50, Matthew said:

Brian, THANKS for the update. I am happy you got it fixed (and posted back the fix!)