y2dst and exchange

Computers and servers seemed to update okay. I’m still tracking down a few boxes as I realized kerb isn’t working on them, but for the most part everything took it’s updates and everything else required the normal flip of the dst hour by hand (such as pbx’s).

OTOH, there’s this little tool we sometimes use in companies called exchange. This tool contains calendars, with appointments, which have times. These times, are affected by DST. So be it.

Fortunately for us, microsoft has PILES of documentation. DST Home base, KB 931836, 926666, 930879, 931667. They also revealed late in the already late process (many tools didn’t come out until Feb 2007) after some people had already prepared for this that it totally screws up resource mailboxes, which require another process.

Fine. The server patch and exchange patch when okay, but the calendar update tool? Take a close look at this kb article. How long does it take you to figure out the order of steps you should follow? The TOC is pretty useless and misleading.

I eventually figured out that “How to manually configure and run Msextmz.exe” is the “how to be an exchange hacker because we didn’t see this issue ever coming up”, also known as: “How to use some scripts to make tab delimited text files of all your DNs, matching up a load of timezones in a crapshoot fashion and hoping it all works out in the end.”

I instead used “How to run Msextmzcfg.exe” which is this little vb looking app that does some of the above work for you, dumping out a bunch of text files everywhere (mostly in a hostname folder, btw, use netbios names). I checked the “extract recurring meeting information” box even though it warns of the increased overhead. We have < 100 users. Be aware of the serious list of “things this shit does not do right” in this article:

“A time zone may be ambiguous”

Our tool often doesn’t do shit in PST

“There is a limit on the number of mailboxes that can be processed per server”

This can only do 65,535, obviously that’s because of a variable, but we’re parsing tens of thousands of DNs from a text file at this point, you’re already screwed.

“There may be conflicts with conference room assignments”

this shit totally screws up resource rooms, use a bunch of other utilities to fix this. i really only have one room that matters, so I just opened it up in outlook myself.

Unclear caveats:

1) you can’t install these tools on an exchange server, or even a machine that has the exchange management tools installed, which it considers and exchange server.
2) the tools tie into outlook, have outlook installed.
3) tzmove.exe which is needed, isn’t really referenced. I believe this is what actually ties into outlook and you download this separately. If when you run the batch script, which you’ve pointed to tzmove, you get an error 0x80004005, it’s because tzmove is an installer, not the real tzmove. Run the installer, cancel the program when it’s ready to do something, and then point the config file back at: “C:\Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool”.
4) the grant permissions script at the end of the file wasn’t interested in working for me. it just kept spewing out syntax until I realized it wanted an input file. check this out instead.
5) in case you didn’t notice, this doesn’t scale at all. Microsoft’s idea of scaling this small utility appears to be splitting up the work on a bunch of VMs on whatever hardware you have kicking around. VMs provided here. Note I thought this was a great laugh, and didn’t download it. Maybe you’re supposed to download it, and it isn’t just a joke.

Hopefully you’ve already lived through this, but if not, good luck. I’m still waiting for emails this morning asking what the hell I did to everyone’s calendars over the weekend.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.