I've been told to be less "luvvie" in my blogging (Thanks Salty!) - so here's a good old fashioned moan.
For the last three months, I've been pretty much delving under the hood of Active Directory - far more than I tried before. And I have one word for you. "Euch!".
For instance, In Active Directory, on the person object, there's a number of very interesting properties. Last Login time, Last Logout time, Last time password changed, etc. Very useful stuff. But - for performance reasons I guess - these properties are not replicated to all Domain Controllers (DC's). You have to sweep through all the DC's in your domain to figure out when users last logged in/out, etc on each DC.
Now, back in 1992, this might have been acceptible on Novell 3.11. After all, there wasnt much idea of using all your file servers in a unified domain. (Oh - at that time, I was IT Services manager in the oil biz, and had one 250-user server that was up for more than a year at a time. Bliss. My world was Novell, ccMail, WordPerfect, 1-2-3. And it all worked, all the time).
(And dont get me started on actually retrieving these objects. For some reason, the Redmond architects of this decided that everything internally should be a COM object. So even on a back-end process, perhaps without many applications installed on the server (thus negating the whole point of COM), you still have to chuck these huge, fragile COM objects around. Has no-one in Redmond heard the "KISS" mantra - Keep It Simple, Stupid?)
Here we are, 15 years on. And we still have the same problems. Now I wouldnt mind if the AD Person object wasnt updated every minute, or even every hour. So why doesnt AD (in this day and age) replicate this stuff around on a low-usage cycle - a "low priority" replication if you like. Or even better, put them in there as a set of child nodes - one for each DC. That'd reduce the replication conflicts, yeah? (Sorta like using child Notes documents in response hierarchies.. Everyone can contribute to their own documents)
Simplicity ? No. This is why its difficult to scale Microsoft tools. They shake and bake these things together in a single environment (Redmond) and have little or no thought to scalablilty or slow WAN links. Replication - especially on top of the fragile JET engine (AD runs one variant, Exchange the other) - will always be an "adventure".
I mean. Look at the clustering model for Exchange. Even Exchange 2007 - 10 YEARS after Exchange v5.5 came out. A shared hard drive. Yeah. Try running one of those monsters over a WAN link - and you'll see what I mean. Which makes DR for Exchange particularly hard/expensive/fraught. It amazes me that folks actually try and implement this stuff. Oh - and if you get a good sized environment going - say 70,000 users in a large bank - just be very very careful. This is why one site I know of has all of its Exchange 2003 servers on "intensive care" status, and the only help they're getting from MS is "Upgrade to 2007". Appalling.
So folks, when confronted with a new CIO who just wants to get his "90 days change" tickbox and suggests switching to MS products - show him the bottom line costs in terms of increased support personnel, more servers, more monitoring. Perhaps this'll get through his short-term attention span..