Microsoft's top talent has been distracted since prior to the passage of Energy Act of 2005. They've had several major product releases (Windows Vista, Office 2007, and Exchange 2007) to contend with, and no one would argue that, in their business, pushing new products out the door drives revenue.
Microsoft management has to be sure that their people are working toward the interests of increasing shareholder value. Writing manicured patching tools, doing QA on those tools, and developing best-practices documentation on using the tools isn't going to drive revenue. Taking top-flight technical talent off of a new product launch to work on a patch also doesn't drive revenue. Further, one can rationalize, DST changes don't take effect until March, 2007, so the response can wait a bit... (Relative to Outlook and Exchange, my work would have been a lot easier if the underlying Windows patches had come out in, say, mid-2006. I'm guessing that others would agree with me. If nothing else, my users would have had more time to double-check their bookings. I think there would have been far fewer items scheduled in the new DST interval to have to contend with "re-basing" if Windows had been patched for the new DST back in mid-2006. I supposed I should've dug out TZedit.exe back then and just done it... *sigh*)
I've no doubt, based on the hurried, last-minute, and frequently revised response to the DST changes, that working on these patches has been some of the most un-sexy and undesirable work that Microsoft developers have had to do, and I can imagine that it's been put off again and again since the Act was passed.
Customers are going to have to live w/ the quality of the tools they get. Sure-- there's the remote likelihood that some Customers might be so upset at the quality of Microsoft's response as to look toward migrating to other software, but nobody can call the "other Microsoft" and get patches for Windows, Exchange, etc. Microsoft's position in the market is pretty secure, and mediocre response to the changes in DST isn't going to hurt them. Keeping the Customers happy enough to stay around (or, some would say, at a manageable level of dissatisfaction) by making a token effort to release mediocre patches is all Microsoft needs to do. It's cheap, too, since less technical talent has to be engaged in unprofitable patch development work.
The tools we're seeing for Exchange (with the numerous revisions, mistakes, retractions, and conflicting comments) remind me of the quality of Microsoft's "unsupported" Resource Kit tools. These Exchange DST tools have the feel of being raw, unfiltered output from developers, without the benefit of much QA. That's also a great indication that management hasn't engaged teams in a formal process of developing a response to the change in DST.
The character of the repeated revision to the KBase articles and tools related to the DST change have the feel of an in-house development team firing off emails to the IT department: "Hey, guys-- that last tool we sent you has a problem. Don't install it into a directory w/ spaces in the name... sorry!" That's all well and good, except that most Microsoft Customers aren't as skilled as the in-house IT department at Microsoft. When I looked at ther v1 Exchange "re-basing" tool, I commented to my business partner that it was highly unlikely most people were going to know how to get the "legacyExchangeDN" name of their server(s) (let alone the fact that the tool doesn't even call it a "legacyExchangeDN", but rather calls it the "Server Domain Name"). Somebody closer to the code for the tool would know what it was looking for. The tool should have just searched the Active Directory, pulled the necessary values out, and presented them in a friendly menu. The intended audience for the Exchange Calendar Update Tool was a technically proficient administrator-- not somebody with passing familiarity with the product. (Yes, yes-- I know that version 2 of the Exchange Calendar Update Tool is friendlier and better... and, apparently, can now handle spaces in the name of the installation directory...)
Microsoft thumbed their nose at all of us in the IT industry when they elected not to release a patch for Windows 2000 for DST. Their response, relative to Windows 2000, was as much a "marketing" effort to further the cause of forced "upgrades". (I know that Windows 2000 is in the "Extended Support" phase of its "lifecycle"...) Having written a bit of code to patch the Windows 2000 time zone entries in the registry, it's apparent that it would have taken almost no additional work, on top of the QA work already done for the Windows 2003 / Windows XP patches, to put a patch for Windows 2000 out the door. This is another indication, to me, that the mishandling of this situation was purposeful, on the part of management.
<soapbox>This is what happens when an enterprise uses closed-source software. If an enterprise really cares about being able to get "support" for a software application, it makes the most sense, to me, to use software that (a) has source code availability, and (b) is licensed such anyone qualified can be hired to work on that source code.
People seem to forget, when they commit to using closed source platforms to support their business, that Microsoft, and other closed-source software development firms, get to dictate monopoly pricing on "support" for their products. Customers are at the mercy of the software manufacturer's decisions about the quality and timeliness of the response to issues and incidents. I'd much rather be able to send out an RFP for changes, and choose the best bidder, than be stuck with a single choice to fulfill my needs.
There are almost no "consumer rights" in the world of software. Realistically, commercial, closed-source software should be approached with the attitude of "no warranty, as-is, if it breaks you get to keep the pieces", unless you've got a contract with the manufacturer that says otherwise.
</soapbox>Keeping track of time is hard to get right, especially when time zones and daylight saving time come into play. People have difficulty understanding the difference between items that are scheduled relatively or absolutely, with respect to a standard time. Perhaps it's not fair of me to pick on Microsoft, since as everyone has to deal with these changes, and other software manufacturers haven't gotten it right very quickly, either.
Microsoft bears the brunt of my ire for not making proper engineering decisions during the design of their products (Windows, Exchange, Outlook) to make these kinds of changes easier. It's not as though changes to daylight saving time haven't occurred before, and it's not as if they're a fringe element in the personal computer operating system market. (Perhaps a web browser is an integral operating system feature, whereas keeping track of daylight saving time should be left up to the ISVs...)
Many of my Customers have committed (by way of giving over lots of money) to using Microsoft products to form the basis for their IT infrastructures. It would have been nice if Microsoft had recognized that commitment (and the lots and lots of money), and developed quality patches and documentation much earlier in the game, instead of forcing us all to play "catch up". (I'm also glad to see that I'm not the only one who is complaining about this.)
