Stress Alternate Access Mappings …  If you are a SharePoint Administrator I am certain you have heard of these.  Articles about Alternate Access Mappings (AAM’s for short) abound on the Internet, Microsoft even has a three part blog article titled “What every SharePoint Administrator needs to know about AAM”.  Why a three part blog article?  Well, mainly because AAM’s can be very confusing to configure and they vary from deployment to deployment.

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

Share

26 comments so far

Add Your Comment
  1. Any idea if AAM’s would have anything to do with errors accessing the Web Content Editor webpart after putting an SP2007 site behind an LTM6400 running 10.0.1?

    We made the move to put an existing Sharepoint 2007 site behind an LTM 6400 running 10.0.1, and using SSL Offloading.

    The move went great, the Application Template made it super-easy… EXCEPT, now when the site admins log in and try to edit pages using the Content Editor Webpart in IE8, they get:

    “Cannot retrieve properties at this time”

    If we take the F5 back out from in front of the site, we’re good. Recommendations I’ve seen say to either restart IIS (no change), or to re-extend the site (sounds messy), but all assume and point to ISA being the problem, which I only mention as it sounds like there’s a problem with the SSL to HTTP traffic translation

    Did I miss something?

  2. Hello meandmybigip,

    You might want to check out the blog article Microsoft put up about AAM’s, as I remember them talking about ISA server to some degree or another. You are saying there seems to be an https to http traffic translation issue. What URL is getting passed back when people receive the “Cannot retrieve properties at this time” message? Where is your SSL termination done, on the BIG-IP or elsewhere?

    Sorry for the slow response to the thread, work has been rather brutal lately :)

  3. Hi F5 guy,
    I do notice in your configuration that you only specified DEFAULT zone. However in the case of extranet/internet scenarios where externals would need to connect via HTTPs but rather internals only from via HTTP (no need for the added performance hit in case of SSL) it does not function as expressed here!
    I did found a simillar article http://corinnalo.blogspot.com/2007/06/sharepoint-moss-2007-with-ssl.html which seems following more on the recomandations!

    Thank you kindly,
    C. Marius

  4. Hello c_marius,

    There is more than one way to skin a cat! Zones are generally just used for separating out your different methods of authentication. Since we have defined all of our AAM’s to use the default zone, we control access by aiming our internal DNS to specific a specific VIP which in turn is mapped to an extended web app with its own IP. External clients are sent via a different route and they hit the web application at a different IP. The one that our external clients hit is protected by Siteminder and the one that is used internally is not.

    Sorry that I didn’t prove helpful in your case, but hopefully the other link you provided proved to be useful to you. Thank you for that, it was a good read.

    Have a good day!

  5. Really nice posts. I will be checking back here regularly.

  6. we are running moss 2007 on two virtual WFEs behind an F5. we have the main portal made on port 80, and that is running well. We have now made a new application which we have on port 20737. We would like to extend this new application onto a new subdomain. We have made the extention to port 80 with host header using the subdomain. when testing on the server from IIS manager, we see both sites and the one application pool. When we look at the IIS site, we can click on “browse” and get the site from either virtual server. From outside the server, we get the F5 service unavailable error message. our DNS points to the F5 for the subdomain. Can you suggest some areas to check to help figure out how to get this work properly??

  7. Hello Ed Weill,
    In my dealings with MOSS 2007, whenever we Extend a site we also supply it its own IP address. We then set those IP’s up as nodes, assign them to a pool and create a corresponding virtual server for them. We then create internal DNS pointers for folks on the LAN that basically aim the new URL to the new virtual servers.

    Did you make those host header changes within IIS or did you use the MOSS Central Administration site? I don’t recommend making changes to SharePoint by directly editing or changing things in IIS. Otherwise you run the risk of hosing your farm. There are a few select things you can do, but I would stay in the Central Admin until you are really familiar with SharePoint.

  8. Thanks for this post. It’s very interesting. In my configuration I would like to use one URL for all access – internal and external. It is an employee intranet site. Windows auth will be used internally and externally. Let’s say, for now, I don’t care about having a short URL. So, the URL will always be webapp.domain.com.

    I have set up two VIP’s on BigIP. One for internal traffic and one for external. I would like for external traffic to require SSL (terminated at BigIP), and internal traffic to not require SSL. It doesn’t appear SP makes this possible with the current AAM technology (sounds like SP 2010 does though). Do you agree or do you think it’s possible? I need AAM to fix up the links with https when necessary but it has no way of knowing when it should rewrite versus not rewrite. I tried rewriting the links at the BigIP level but there’s just too much goofy stuff SP does so it’s impossible to get everything rewritten. I concluded that it’s not possible to rewrite the links outside of SP.

    Thanks!

  9. Hello Mike,
    It is possible to pull off exactly what you are a saying. You would need to modify your companies INTERNAL DNS to map to the unsecure VIP and modify the EXTERNAL DNS to point to the secure VIP. In SharePoint create your site and aim the secure VIP at it. Then extend the same site and aim the unsecure VIP at it. You would need to create 2 VIP’s for the secure stuff to work properly, one that listens on port 80 and another that listens on port 443. On the VIP that listens on port 80 you can use a simple http-to-https iRule that redirects all your requests to the VIP listening on port 443. Feel free to e-mail me at: TheF5Guy at thef5guy dot com if you have any more questions or need more specifics.

  10. […] Administrator on MOSS 2007 Alternate Access Mappings and BIG-IP […]

  11. Hi,
    I have the same requirement to configure AAM. The reason is i have created a sharepoint site with actual url http://intranet.mycompany-global.com. Due to the decision of management i need to switch the url to http://link.global.mycompany.com.
    Below are the configuration i did.
    Intranet URL http://link.global.mycompany.com. Zone Default Public URL http://intranet.mycompany-global.com .
    The complaint i got is people accesing Public URL is slow.

  12. UPDATE: It’s been a while, and I seem to have missed the updates to this, as my feed was pointing to the new site, but we just finally figured out our AAM issue (and YES in fact, it was AAM after all!)…

    As outlined prior, it turns out to fix the AAMs, we had this:

    https://server | Default | https://server
    https://www.server.com | Internet | https://www.server.com
    http://www.server.com | Intranet | http://www.server.com

    but it should have been:

    https://server | Default | https://server
    https://www.server.com | Internet | https://www.server.com
    http://www.server.com | Internet | https://www.server.com

    A point of note that had us discouraged that we were going in the wrong direction for a while, you can’t just change the zone one the existing Public URL entry by changing the value in the drop-down in Central Admin, you have to actually remove it, then use Add Internal URLs to get the new one in.

    Success came in part from this article, even though ISA isn’t involved for us, it got us thinking the right way: http://blogs.technet.com/isablog/archive/2008/10/02/unable-to-check-out-a-document-in-moss-2007-published-through-isa-server-2006.aspx

  13. Hey MeandMyBigIp,
    I am glad you were able to resolve your issue with the AAM’s. Those things can cause such a headache! Also, thank you for the link to the tech net article. I bet it will also come in handy for others. Thanks for sharing :)

    -TheF5Guy

  14. We are trying to monitor our sharepoint 2007 sites through the F5 using http. It is currently set to use the tcp monitoring. However, if IIS were to stop working the tcp would not recognize this server as down. Traffic is sent to a dead server. When we set the monitoring to the base http the sites show as down and no traffic is sent there.

  15. Hello

    I was wondering what is your iRule, does it uses HTTP::redirect?

  16. In response to Dan, what we’ve done is setup two monitors for our SP2007 site that have worked well. One if them is a content-less .NET Header page (fast, small, lightweight to execute) and issue a HTTP POST to it, looking for a specific response from it. This verifies that .NET is answering requests (better than just a TCP socket connects: more specific). It’s an HTTP type monitor that looks like this:
    POST /_layouts/mycompany/_HealthCheck.ashx HTTP/1.1
    Host: http://www.mycompany.com
    User-Agent: Mozilla/4.0
    Pragma: no-cache
    Accept: */*
    Content-Length: 0

    The monitor is configured to look for a specific string that this page returns if it suceeds.

    IN addition, since this will respond even if the SP database isn’t functioning, we run a second monitor on our F5 SP pool that checks for database health. We post to /Pages/default.aspx (with similar syntax to the previous monitor) which returns a friendly error message if the database couldn’t be reached, saying \Cannot connect to the configuration database\. This monitor is marked \Reverse\ meaning if the expected content is returned, the monitor should fail, which is the reverse logic you’d normally use.

    Combined, these two monitors cover us with fairly specific and precise checks of multiple aspects of the environment.

  17. HI
    i have a medium moss 2007 farm behinf F5 and the clinet request to have an extranet with SSL
    should i configure the SSL on the F5 or on the 2 front end or on both and is there and document that list the steps to do that

    thank you
    Mohamad

  18. Hi,
    If you don’t mind, I really need to understand how you did this: Siteminder authentication is done on the externally accessible VIP and regular Windows authentication is done over the internal VIP pointing to that web application.

    We are trying to use sharepoint for a mobile app, and must use Siteminder in external connection scenarios. Can you share the details. I’ve only seen an ISS hack (aka modle) on the web that enables this functional gateway.

    Noce site! Thanks.

  19. Hello Ed,

    The way we have it set up is if you are coming into the network from an external network is that it will go to a VIP and the application is protected by siteminder. If you are on the internal network, an internal DNS mapping will take you over to a different VIP that is aimed at the extended web application that is not protected by siteminder.

    We also created an iRule for the externally facing VIP that looked for the user-agent string. When it saw that the user agent string was that of an Office 2010 application it would forward the traffic over to the extended web application that was not protected by siteminder. That way people using Word and Excel could post documents and download documents to the web site with out having log into siteminder each time and/or get blocked by siteminder.

  20. Hi Naladar,
    Thank you. If I understand correctly, you solved for this by simply using a VIP that was protected by SiteMinder. Was the extended site set up to use WinAuth/NTLM ?

    Thanks again,
    Ed

  21. That is correct Ed.

  22. Hola Tngo una granja de 3 Front Ends, 1 SQL y un servidor de index, se balancea con F5 pero tenemos el problema de que cada que entramos a alguna página se tarda mucho en responder (alrededor de 3 a 4 minutos) cuando en la small farma original no tardaba nada.
    Los FE son virtuales al igual que SQL.
    Tambien nos pasa que al estar trabajando en la página y darle refresh, aparece el mensaje de \Internet explorer no puede encontrar la página\, los chicos del F5 proporcionaron logs y se muestra como pareciera que mientras buscar cual FE le responda, encuentra uno apagado y se sigue al siguiente, hasta que de nuevo los encuentra como prendidos y es como responde la aplicación, mi pregunta es: El comportamiento es del balanceador? como puedo resolverlo?
    Gracias de antemano.

  23. hello,
    we have 2 app servers and 2 WFE, it seems to be working fine when we switch to the F5 environment using both servers, but when i try to access a webservice wihitn the servers ex: http://f5server/_vti_bin/getuserprofile.asmx it just doesn’t work. is says unautorized access.
    any thoughts?
    i have the f5 environment added to the AAM as an extranet. i dont know if i need to add both of the WFE servers on the Zone, please advise
    i read in another post that it could be possbly to the loopback feature but i’ve already added the hosts to the registry BackConnectionHostNames,
    these are my AAM configuration:
    Internal URL Zone Public URL for Zone
    http://enet Default http://enet
    http://WFEServer2 Intranet http://WFEServer2
    http://enet2010 Internet http://enet2010
    http://enetf5 Extranet http://enetf5

    any help would be appreciated. thanks

  24. That certainly seems like a lot of different names to access the same environment. In my experience we do not use the server names in AAM’s. What I would recommend is calling your web service using the http://enet AAM that you have setup as the default.

    To test whether or not you have the AAM’s setup correctly, open the site up using the hostname of the URL that you want to run the web service queries to and then use some of the admin functions, like adding users to the site, etc… if any of those fail it is likely due to having an incorrect AAM setup.

  25. F5Guy,
    In your article you say \The only caveat to this is that the site that you are accessing needs to be inside of the \LOCAL INTRANET\ zone inside of IE. WARNING: NOT THE TRUSTED SITES LIST!!! \
    We usually have the opposite effect, as our trusted zone has the setting for automatic login with credentials checked. Was there some other reason for this?

  26. Thanks for the feedback! If that is how you have the trusted zone setup then that is the way to go for certain. Our zones are setup a little differently with the idea that we place more trust in the local zone because it is local and has been vetted and probably is an inhouse application like SharePoint. The trusted zone is treated like a third party apps zone. The automatic login with credentials checked is definitely what it hinges on though. I will update the article with the specific setting as it certainly makes more sense for them to check that setting directly.