Update: Found a much, much better solution. If you’re looking for the correct fix for this problem, go here.
This is a technical note, mostly to get this into Google, and will be profoundly uninteresting to anybody who doesn’t have to slay the Exchange 2007 hydra. Let me begin, then, in the traditional manner of many fine and nerdy things with a reference to the Hitchiker’s Guide To The Galaxy:
It was, of course, as a result of the Great Ventilation and Telephone Riots of SrDt 3454, that all mechanical or electrical or quantum-mechanical or hydraulic or even wind, steam or piston-driven devices are now required to have a certain legend emblazoned on them somewhere. It doesn’t matter how small the object is, the designers of the object have got to find a way of squeezing the legend in somewhere, because it is their attention which is being drawn to it rather than necessarily that of the user’s.
The legend is this:
‘The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to
be impossible to get at or repair.‘
-Douglas Adams, “Mostly Harmless”
If there’s one guarantee about Microsoft products, it’s that for at least two years after they ship, nobody knows a goddamn thing about how they actually work or how to fix them when they break. The documentation lies to you, by omission or outright, and when implementors get these obscure, unhelpful and completely uninformative error messages and start asking questions in the world’s forums other people who should know way, way better by now start making stuff up trying to sound helpful. And after not-long any search for a solution to your actual problems gives you results full of half-truths and superstitious bullshit from people who’ve tried a bunch of things without actually understanding what they’re doing, that maybe worked but probably didn’t.
This is not be unique to closed-source or Microsoft software, for sure, but the staggering size and opacity of their products sure does make the situation worse. But I digress, because anger is the only exercise I get most days.
The problem is that an Outlook user can’t connect to the exchange server, and the extraordinarily useful error message says “Exchange server not available”. But it won’t tell you why it’s supposedly unavailable, and:
- that’s a lie, it’s very clearly available,
- it’s not a network problem, and
- it is limited to that user’s account, but
- they can get their mail through OWA just fine.
So basically all your first-line diagnostic tools will tell you that everything is fine, but a specific user will not be able to use Outlook for no obvious reason.
The reason, or at least what turned out to be our reason, is that the user has somehow exhausted their permitted number of MAPI connections, normally limited to 32, to the Exchange server. I believe, but have no proof, that this is a result of a user switching Cached Exchange Mode on and off, which is why we have seen it here so rarely. (Cached Exchange Mode, incidentally, is a sulfurous wellspring of pain, and you should never use it ever. It looks like it’s just one little box with a checkmark in it, but that’s a ruse, and in my mind I now refer to that option as a Lemarchand’s Checkbox.)
The next problem is that as far as I’ve been able to find out, there’s no tools or powershell-exposed functionality that will let you change a user’s MAPI connection state. There’s only one way to fix this problem, and you’ll love it, because it’s totally awesome and totally Microsofty.
You need to reboot the exchange server.
It’s so awesome.
Now, strictly speaking that’s not entirely true – you need, specifically, to restart the Exchange data store, but since that’s going to kick off all of the users connected to it while it restarts, “Did You Reboot?” is what it boils down to.