I finally got around to moving the OWA 2003 proxy at work to Apache 2 (from Apache 1.3). It was ridiculous how much easier it was to get working in Apache 2. I should have done this months ago.
Expect a HOWTO coming soon.
Also... I'm currently trying to get Exchange 2003 RPC over HTTP to work through Apache 2. It's ugly. I'm either missing something very obvious or this is going to be quite difficult. A friend suggested we set up an ISA server (as it has an RPC over HTTP proxy built in). I know... I should've strangled him (yeah... you Shawn! ;-) ).
Getting RPC over HTTP working through Apache may require a special plug-in. That could be fun (OR NOT!).
Oooohhhh! I found a nasty bug in my Apache 2 version of the OWA front-end proxy. Apparently, the Apache proxy doesn't like it when percent signs (%) are used in the URI. You see... Microsoft thought it would be a good idea to call up each email by using the subject line as the key (as opposed to... oh... THE TRULY UNIQUE IDENTIFIER every Exchange message has). Because of this, we get all sorts of interesting characters in the URIs (like spaces and percent signs and other things one should never use). I made a small kludge that seems to work well. I'll include that in the forthcoming HOWTO.
UPDATE (Thu Jun 23 11:10:46 JST 2005):
I've put this off for too long. I'll see if I can get this done today.
UPDATE (Thu Jun 23 22:16:11 JST 2005):
The HOWTO is posted. You can find it at
So, you've got a few (or more) Unix boxes (Linux, *BSD, whatever) running on your network that provide nontrivial services for your network, cutomers, or users. You and maybe
one other administrator are actually learned Unix idols. The rest? Well, let's just say Unix isn't their bag. They were raised on another OS and really don't have the desire to learn a real one (they're not dumb, they just don't do Unix). Let's call them AOSAs (Another OS Admins).
There will come a time (when you're not present) when an AOSA will need to reboot one of these boxes because it is not fucntioning properly (however unlikely). A reboot may fix the problem, but what went wrong? What was broken? Often, certain information helpful to understanding what "broke" and how to prevent it from happening again is lost during a reboot. If only the AOSA could have saved a few stats before rebooting...
Another adventure you'll get to experience is the O'dark 30 telephone call. Considering the AOSA has no Unix experience, you'll more than likely have to drive in to your office as you'd go crazy trying to walk an AOSA through CLI commands over the telephone. Wonderful!?!?
Never fear. There is a way to help yourself and the AOSA in both of these situations and many more just like them. Enter pdmenu