Monday, 15 December 2008

ISA Server: Publishing MOSS with ISA Server 2006 SP1: Lessons Learnt

Note: a version of this article updated for SharePoint 2010 is available on my new blog site here.

1. Introduction

Hi! This is officially my first blog post, not only in this particular blog but ever. I would provide an introduction, but I am almost certain that most of you are only looking at this as a result of a Google search for "publishing MOSS using ISA server 2006" (or something along those lines). Guilty? I thought so.

As such, I will skip the intro and get down to business. Following are some notes that I made whilst attempting to (and eventually successfully) configuring ISA Server 2006 to publish a series of MOSS portals. Although I could go into detail on how I carried out each step, I have decided to give an overview to begin with and respond to any requests the general public may have ("Could you show me how to get SSL bridging to work?" etc).

2. Acknowledgements

To start with, I must give due credit to those articles which helped me most whilst setting up ISA Server 2006 to publish a secure MOSS environment. Obviously you can find these for yourself using a search engine, but I thought it useful to show a concise list of those I found most informative:
3. Lessons Learnt

Most of us have heard the saying Keep It Simple Stupid (KISS). In configuring ISA Server, and particularly whilst attempting to configure SSL termination (so as to forward HTTP requests to the published MOSS Server), I realised KISS is probably the most concise way of summarising the lessons I learnt:

3.1 Proceed with care when installing ISA server remotely *Important!*

In case you didn't know, ISA Server is designed to function as an industry grade firewall. This means that unless you have configured it correctly, it will try its hardest to stop anything and everything from accessing it and the published servers it is protecting. This means you are locked out if the server is not configured to allow remote administration. I learnt this the hard way and had to drive to our MOSS farm to manually correct the issue - make sure you don't make the same mistake.

The key to preventing yourself from being locked out is to:
  • Before installation: add exceptions for RDP and file / printer sharing in the Windows Firewall prior to installation.
  • After installation: define "Remote Management Computer Sets". This means adding your IP address to the list of trusted remote management addresses. More detail on this can be found in the Technet article listed in the "acknowledgements" section of this post.
3.2 Install ISA Server 2006 SP1 from the beginning

I know - this sounds like an obvious one. But if you are as keen to get ISA server up and running as soon as possible you may be tempted to skip the updates. Don't do it. ISA Server 2006 SP1 includes a host of new features, but the most useful one has to be the ability to test a new publishing rule (you will see what I mean if you haven't yet installed SP1 and are having difficulty troubleshooting a given publishing rule).

3.3 Ensure AAM is configured correctly

This is, from what I have gathered the number one mistake made when troubleshooting ISA / MOSS publishing scenarios, particularly when using SSL termination (see the lesson below). Ensure you read and follow the Microsoft article on planning AAM in the "acknowledgements" section above. From my experience, I can say with great certainty that most issues you will encounter (particularly with regard to SharePoint document library functionality) will be related to an incorrect AAM configuration.

3.4 Use SSL bridging where possible

I spent a significant amount of time and effort attempting to get SSL termination (or off-box termination as it is commonly known) working due to my belief that SSL bridging would result in significant processing overhead. Before you make the same mistake, try SSL bridging for yourself in your own environment. In most cases, you will find the overhead is negligible and it could potentially save you a lot of wasted hours / hassle for the following two reasons:
  • SSL termination means the forwarded URL will contain HTTP rather than HTTPS. You will find that in most cases (assuming AAM is configured correctly), SharePoint will work just fine in this configuration. However, in my case I kept finding small niggling issues that required a fix (note that this is particularly the case if you use custom web parts that may store URLs in a database). An example of a problem with standard MOSS functionality was trying to export to a spreadsheet from a SharePoint list (if you think you have got SSL termination working correctly, try this for yourself to make sure).
  • SSL termination means that the channel from your ISA box to your MOSS farm is not secure. There are mixed opinions on whether this is a real security issue, but suffice to say I prefer to be able to (honestly) tell clients that "128 bit encryption is used end-end over a secure SSL channel". Sure, you may pass penetration testing and clients may not ever find out if you are using SSL termination, but there is always "what if".
3.5 Authenticate at the ISA server

Again, this sounds obvious. ISA server provides a perimeter defence mechanism and one of its main benefits is the capability to prevent unauthorised traffic from ever reaching your web servers. To be more specific, do not select "All Users" from within the users tab of any given publishing rule unless you really want anonymous users to access your MOSS site. OK - IIS will still prompt for authentication, but if you want to save bandwidth and CPU cycles, ensure "All authenticated users" is selected.

If, like me you have an environment where you want some areas of your MOSS site to be accessible anonymously (i.e. no authentication), I recommend you create a separate "Public" publishing rule. Ensure you define only those paths (in the "Paths" tab of the ISA Server publishing rule) you wish to be accessible by Joe Public.

By specifying that only "Authenticated users" can access your MOSS servers, you are effectively telling ISA server to communicate to your authentication provider (in my case AD) directly. Valid credentials are then forwarded (delegated) to your published web server.

3.6 Use ISA server monitoring functionality

This one has been almost essential for me. ISA Server 2006 SP1 includes numerous monitoring features, but by far the most useful for me was the "Logging" tab. This tab shows all requests passing in and out of the ISA server and is invaluable when troubleshooting a connectivity issue. Having problems updating Windows? In all likelihood ISA server is blocking HTTP access to the outside world. Not able to ping the ISA server even from within your farm? It's likely you haven't added those servers to the "Remote Management" computer set. Whatever the problem, it is likely that ISA Server's real-time logging capability will assist you.

3.7 Utilise the Windows "hosts" file

As I'm sure many server administrators will know, the hosts file is a valuable tool for forcing a computer to ignore DNS for a particular hostname and use a manually configured IP address. It can be handy to test the ISA server is forwarding requests to your published MOSS server correctly without having to modify the public A-record right away. The file itself is located in C:\Windows\System32\drivers\etc - I normally modify it using notepad.

4. Conclusion

In this post we took a look at some of the lessons I personally learnt whilst publishing MOSS using ISA server 2006 in a real world environment. Depending on whether I receive any comments I will most likely publish future blog posts. If you found the post useful, have a question or have a constructive criticism please let me know! I will in the future be posting about all things MOSS related (not just ISA server) so please subscribe if you are interested.

Cheers, Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on

Add this blog to your
Technorati Favourites