Peter Seale's weblog

Thursday, June 05, 2008 4:49:58 AM UTC 

Those of you looking for something to amuse you will be sorely disappointed. Reading over this post even bored me, and I just finished writing it! Yeah, this one's for the search engines to pick up.

By posting this, I've become the world authority on Cisco NLBs with SharePoint

…which is sad.

I'm posting this partially as informational content, but partially because I'd be interested to find out if anyone else in the world searches for it.

So here goes.

Introduction: All SharePoint Tutorials Assume You're Using ISA Server

This is something that's annoying, especially in situations where they refer to ISA as "NLB". The SharePoint admin companion book is one place I can call out as guilty…

So, I'll point out before you go looking elsewhere that unless otherwise specified, the other guys' tutorial assumes ISA. You've been warned.

What I'm doing: please critique via comments

Since there is no posted content anywhere else in the universe, I'm just going to say what we're doing. This sort of thing is incredibly dry, so we'll do this lazy and concise, bullet-point style:

• New SharePoint "health check" web application, running on another (hopefully firewalled) port.
• Anonymous access is on. This is important! I don't think it's possible to have our Cisco NLB attempt NTLM, so we have to fall back on "nothing".
• This is not the same IIS Web Site as our main web application.
• Double-check to ensure IIS logging is off for this site. You don't need the logs, but whatever, you make the call, bigshot. Maybe those logs are more valuable than I will ever know.
• This is not even the same content database. I created a new (incredibly small) content database just to run the health check.
• Created a site collection, and
• Underneath the site collection, created a new blank site.
• Enabled anonymous access on the site - full access to the site, so that our health check actually works.
• Health check URL: /_layouts/mobile/mbllists.aspx - this is the where we're redirected if visit the mobile (./m) page of any site.Page looks roughly like:
   
• Tell the health check to
• visit this page
• expect a HTTP code 200 response (i.e. "it's good"). I don't think checking the page content is important, but if you want, knock yourself out with that.

Why it's important to go through all this trouble

I will say we've had trouble with our NLB health check because we (at the time) had not set it up to test every dependency. Our first attempt, a static HTML page, didn't even run on the same app pool as our main SharePoint web application…so when the app pool started throwing Out Of Memory exceptions, the NLB health check remained blissfully ignorant. Footnote: we fixed this problem by implementing overlapped recycling; definitely check it out if interested.

Even later, when running a static page on the same app pool, we were still not testing the database connection (and/or AD authentication!).

We also didn't want the health check page to be a "heavy" page (e.g. the portal home page). I briefly experimented with creating a minimal aspx page, but this "mobile view" serves the same purpose—a light page that pings the database. And hey, it's built in!

Feel free to give advice

If I'm missing something obvious, definitely let me know. If not, also definitely let me know :) I just don't know, and I'm not sure exactly where to look, so…blast away.