Alternate Access Mappings in SharePoint, what’s the big deal?

I’ve been involved in a project where SharePoint is hosted by a third party and consists of two front end servers and a back end database server. This site is accessed by a typical Internet style address, https://myapp.companyname.com. Do you spot something that might by caused confusion yet? Yes, it uses https. But that’s not the real fun part, as when it goes through the third party’s load balancer it gets turned into http://myapp.companyname.com.

This caused much teeth gnashing and anguish as this results in all the links from SharePoint being prefaced with http and the the load balancer is only capable  of translating some of the links back to https. So some links were prefaced with http and others with https. Fortunately a solution was at hand, Alternate Access Mappings!!!

Reading various blogs and articles gives the impression that this is deeply complex function of SharePoint but in fact it is simply a method to ensure all links point to the correct URL. In my case we needed to make sure that all our links started with https.

Now this is where I start to talk about zones. Zones enable us to access the SharePoint site from different parts of the network.

When the web application is created, the entered URL is  used to access the site by default. Unsurprisingly, this URL is entered into the Default zone as the public URL. And all is fine and dandy. But what if the site can be accessed by a second URL?

In most cases, you may simply wish to redirect this second URL to the standard public URL. This can be done by entering it as an internal address to the Default zone and now, when the second URL is entered, all the links returned will be translated to the public URL. And that’s all there is to it.

Our site was being accessed by the public address https://myapp.company.com, (well, obviously, not really, but in that format) so we realised this needed to be the public URL. But the incoming request was to http://myapp.company.com, which was not recognised by SharePoint. Adding  it as an internal URL in the Default zone caused all links to be translated back the the public URL and suddenly we had a fully operation site.

Unfortunately we hit another snag. We wanted to add an additional dedicated search indexing server but were unable to access the site using the default public URL from within the hosting companies own network. Alternate Access Mappings to the rescue again!

We needed to use an internal URL to access the SharePoint servers but if we simply added that URL to the Default zone, it would just spit the public Internet address out. We needed another zone.

The names of these zones are irrelevant, although they are conveniently named so it would be churlish to put an intranet address in the internet zone. We chose add the new Intranet URL to the Intranet zone as the public URL.

What this means is that a request sent to the intranet URL is now classed as in the Intranet zone and consequently, the public URL for the Intranet zone will be returned.

And that is that.

The are other advantages to separating your SharePoint site into different zones with their own unique URLs, you can tailor your content according the zone, for instance, offer the complete site to an Intranet address but a more limited access to the extranet, or Internet.

I shall have to look at that in more detail some time.

Stupid support calls #1

Just as I was about to leave, I got a call from someone in Canada who was having problems logging into a web application I support.

They could see the web page to login in to, so I knew there was no network problem and they could log in using someone else’s computer, so I knew it wasn’t an account problem.

So how do I tell her to take the caps lock off without being patronising?

IE6 must die

I’m going to try to write at least one post a day, but when you’ve done nothing all day but feel rotten all day at home there’s very little to say that I didn’t say yesterday. Until I noticed the #6 trending topic on Twitter was “IE6 must die”.

It is a sentiment I absolutely agree with and for a fuller explanation of why Internet Explorer 6 is holding back web development you should read the article at http://mashable.com/2009/07/16/ie6-must-die.

The problem is not people, but companies. Many people access the Internet at work and are often unable to install a different browser and so have no choice but to use IE6. Why do companies still use IE6? Because most still use XP and IE6 happens to be the browser that came with it. Consequently all their internal systems are designed for it and they are scared of breaking them by updating the browser.

The fact that pretty much any web application that runs IE6 will also run on IE7, and usually IE8 as well, is completely lost on IT departments for whom change is a bad word.

So, how do you convince a company to update the browser? Well, here are a couple of ideas I have.

Firstly, although browsing the Internet is often frowned on by companies, often there are some key external sites frequently used by the decision makers of a company (or used by those with a direct line to those decision makers). Things like hotel and flight booking systems. If those sites were to drop IE6 support I could guarantee you an order would come down that the standard browser would need to upgraded.

My other idea would be for the developers of company systems. Stop designing for it. Look at the additional functionality offered by more modern browsers and build your application around them.

You would have to sell the concept to the people paying for it, but imagine a web application that embraces tabs rather the using the single window of IE6. The ability to navigate to different parts of the application without the constant clicking of links and buttons or use of the back button, potentially losing data you’ve just entered, should be a compelling reason to embrace a tabbed interface.

As a software developer, it is usually my job to build applications that fit the client’s environment, but with a little subtle pushing you can potentially provide a far better solution if you treat the given environment as something that can be tweaked instead of being set in stone.