I had to make a tweak or two here or there, but I have to say overall I really like it.

I have yet to find an article on the web about configuring the AAM’s of a MOSS 2007 farm when an F5 BIG-IP is being used, so I thought I would write one up.  The awesome folks over at F5 have an excellent Deployment Guide that walks you through setting up your BIG-IP to deliver SharePoint 2007, but the guide does not cover Alternate Access Mappings.  It simply refers you to the aforementioned Microsoft article.  I do recommend using their deployment guide for your deployment, because it covers a lot and is good for most environments.  For the Alternate access mappings part though, I hope this article can help steer you in the right direction.

Lending a Hand

I would like to extend a helping hand to those in the BIG-IP and SharePoint 2007 communities.  If you are having problems with your AAM/BIG-IP configuration, post a message here or on the F5 discussion board “Advanced Design and Config”.  I will do my best to lend a hand and help you through the questions you may have.  I am not an employee of F5 Networks, but I am a community member and they have an excellent forum.  Here is a link to the discussion forum on F5′s DevCentral:

http://devcentral.f5.com/Default.aspx?tabid=53&view=topics&forumid=31

Environment Variables

The environment I am going to discuss here is moderately complex, so here are a few details to keep in mind:

1.  We use a F5 BIG-IP 6400 to load balance our SharePoint (MOSS) 2007 Farm.

2.  We have numerous web applications and each web application has its own unique IP address that is assigned to it in IIS on each front end web server in the farm.  (3 Front End Web Servers, 2 Index Servers and a SQL Cluster on the back end)

3.  One of those web applications has been extended in SharePoint, so that we can have two different authentication methods for the same web app.  Siteminder authentication is done on the externally accessible VIP and regular Windows authentication is done over the internal VIP pointing to that web application.

A How-To Example

Now to give you an example of how things can be set up. The web application I want to discuss is the one that has been extended.  For the purpose of this article, let us say that the URL for the web application is:

https://webapp.mycompany.com

On the F5 BIG-IP 6400 we have configured one VIP for external users to access and one VIP for the folks on the LAN to use.  On our internal DNS servers we have created entries that point webapp.mycompany.com to the VIP we have configured for people accessing the SharePoint site internally.  This VIP points to the web application that was extended and regular Windows Authentication is done on that site so that things are seamless to the end users.  No nagging login screens or anything like that.

The only caveat to this is that the site that you are accessing needs to be listed in an Internet Explorer zone that has the ”Automatic logon with current user name and password” setting checked.  Otherwise, your client PC’s will fail to authenticate and users will be presented with a login challenge.  We added the site in question to the our “Local” zone by simply using a WMI script that appends the entries to that zone in IE when someone logs on to the domain.   

Now how do you create the AAM’s for something like that?  I will let you in on a little secret that I have discovered over time while working with MOSS 2007.  I believe that THE KEY thing to remember about configuring AAM’s is that you want the most secure URL listed as the first AAM in the “Default” zone.  The first AAM listed in the default zone is the one that is used everytime that SharePoint does things behind the scenes.  When a user sets up an alert on a document library, when an administrator uses the site administrator links/functions, etc… ALL of the URL’s that are accessed, referenced or generated pull those settings from your AAM listing for that web application.  If you are accessing the site via https and your site admin links all point to http, you are going to have a bit of a long day.

So for our example web application the Alternate Access Mappings are: (in this precise order)

Internal URL https://webapp.mycompany.com Zone Default Public URL https://webapp.mycompany.com

Internal URL http://webapp Zone Default Public URL https://webapp.mycompany.com

Internal URL http://webapp.mycompany.com Zone Default Public URL https://webapp.mycompany.com

Now anyone on the internal network can easily access the web application using https://webapp.mycompany.com.  Also, there is another excellent benefit of doing things this way… Your marketing folks can still use short url names for internal marketing campaigns!  I assure you, the value of that cannot be underestimated.  Short URL’s are easier to remember, type and are therefore valuable.  Http://Webapp/Awesome is more effective, visually pleasing and cheaper to print up on banners than https://webapp.mycompany.com/awesome.  So if your company has projects that it promotes for internal use only, this sort of thing may be exactly what you need.

So how do you enable that?  All it takes are a couple of port 80 VIP’s, an iRule and some duct tape.  Yea… ok, so maybe no duct tape.  It’s really easy and I will share it in a future article provided there is interest.

Reminder

If you need help with your AAM/BIG-IP configuration, register and post a reply to this article or hop over to DevCentral at the link provided earlier and post your questions there.  I try to keep an eye on this site and those forums and will do my best to help out.

-The F5 Guy