Friday, March 09, 2007

HOW BAD CODING HURTS OTHERS: AN EXAMPLE

I like daylight savings time. I love having the light in the evenings during the summer. It makes the baseball games much more pleasant not to mention how much more time you can play with or have the kids play outside. It’s a sign of spring. Loosing that hour in the spring is quite a pain but I really do like having the daylight hours match the sunlight.

In case you haven’t noticed (and believe me some of you haven’t). (Well actually. Now that I think about those who will probably be reading this, I have to take that back. I’m sure all of you, that I know that will see this, HAVE noticed so let me try this whole paragraph again.)

In case you haven’t noticed (and believe me there are potentially some people who might possibly one day read this page who haven’t noticed) this year the daylight savings time has been extended. It start earlier in the spring and it ends later in the fall. This by itself is nice. If you are in charge of patching a Microsoft Exchange server or two – it’s definitely not nice.

Let me explain: In order to patch the Windows 2000 clients – I had to update them to the latest security patch level and run some regedits.

In order to patch the Windows XP clients – I had to update them to the latest patch levels by running the Windows Update utility.

In order to patch the Apple OSX clients – I had to update them to the latest patch levels by running the Software Update utility.

In order to patch the Windows 2000 servers – I had to update them to the latest security patch levels and run some regedits.

In order to patch the Windows 2003 servers – I had to update them to the latest patch levels by running the Windows Update utility.

In order to update Exchange Server 2003 – I had to download and install the Exchange calendar update tool and download and install the TZMOVE.exe tool and download and install the patch to the TZMOVE.exe tool. Then run the MSextmzcfg.exe to extract all calendar data from the server we were working on. Run the batch file that produced. Then edit the .ini file associated with the batch file to include a different flag and run the batch file again. Then edit the mailboxes.txt (which is the data file associated with the batch file) file to include all the files that the MSextmzcfg.exe tool marked as non-existing. Re-run the batch file….twice, once with each option from before. Then edit by hand a new mailbox.txt file with the names of any resource mailboxes on your server, edit the ini file with a secret undocumented flag and run the batch file again to update resources. Then go to the exchange server and make sure that it is patched to the latest service pack level, and download and install the CDO update (why they call it CDO I’ll never know). In my case this update returned the result that I wasn’t patched to SP2 even though I clearly was. Beat head against wall. Discover that because I did an in-place upgrade from Windows Server 2000 to Windows Server 2003 that there are three registry keys that need to be deleted. Remove the keys, reinstall Exchange SP2, re-run the Exchange CDO update, and reboot the exchange server. Open up outlook and manually check your calendar – notice that almost all of your appointments have been changed to reflect the date correctly but a few haven’t. Open each of the wrong ones manually, click the recurring tab, click OK, click save. Do that for each one that is wrong and you are done.

*starts singing* Which one of these is not like the other, which one is different, can you tell? */stops singing*


I think I’ve found what castle I need to storm. I’m pretty sure I can find pitchforks, torches and mobs of other to help me. But first I need to go and do this whole process on the other server.

No comments:

Site Meter