Your Solutions - Exchange 5.5 & DST
David Parker (Edmonton, Alberta) |
Exchange 5.5 and 2003
In the last few weeks, as you are all aware of, DST patching has been the main goal of every admin from Halifax to Victoria to Tuktoyuktuk. There are a lot of things that need patches and updates and some of those things are not supported anymore. Exchange 5.5 is one of those things as it was retired on January 10, 2006 after almost 10 years of service (RTM was mid 1997. Unfortunately there are some people who, for one reason or another, are still running unsupported OSes and applications. I've been there, in fact one company I used to work for was still running Lotus Notes 4.6 for a few users when I left (and 8" floppies too)! Hey it happens, lack of time and money are real issues that often get in the way of upgrades. So where does one turn when one needs support for an unsupported OS or application? The community, that's where.
About a week ago, Colin from the Edmonton User Group, passed my contact information do David Parker who had recently started working with a mid sized company in Alberta. The migration plan was in place to move to Exchange 2003 but the timing of the project meant patching Exchange 5.5 to handle the DST issue. As Exchange 5.5 is unsupported I couldn't do much but poke around for some resources and guide David to some of my favorite places to go in times of need. David emailed me a few days later saying he got it to work, he was able to patch his Exchange 5.5 server to handle the DST issue and I asked him to share his knowledge so that it may help those others struggling with what to do with Exchange 5.5. So in David's own words here it goes!
Note: Remember this is unsupported, test, test, and test again. Oh and sacrificing a small animal to the Sysadmin gods helps too :)
Our current configuration is Exchange 5.5 server running on Windows 2000, with Outlook 2000 clients running on XP, AD 2003, and a mission critical connection to a RightFax 8.5 server running on NT 4.0. Yeah, don’t say it, I also ride a bus pulled by a Brontosaurus. We are upgrading next month, but that was too late for us, so we had to get this all to work with Exchange 5.5.
Now the big question, could we do it? Microsoft Knowledge Base article 926666 states: “If you are running …, Exchange Server 5.5, …, contact the Microsoft account manager or the Technical account manager for more information.” No help there. We had a special $500 support call set up explicitly to answer that question. After 5 minutes setting up the support call, and agreeing to sign away my first born, the call went:
Tech: “So what product can I help you with?”
Me: “Exchange 5.5 and DST patches.”
Tech: “Sorry, that product is no longer supported. Have a nice day.” ( I hope it wasn't this abrupt :) )
Well, no help there. So, we are flying blind, and have to try to wing this.
First question, do we need the infamous $4,000 patch? We deiced no, as we are not running OWA or any other CDO connector object. You only need the magical patch if you are using OWA on 5.5 or some other application that relies on CDO (BES Server for example). Do we need the OS patch for the clients? Yes, but make sure that they do not get into the wild of your network. Two things to watch for:
1 – That it is not wrapped into your new PC image early.
2 – There are two updates to watch for, the old KB928388 and the new KB931836
If either gets on your client machines early, when Outlook 2000 runs, it does not tag appointments with the time zone info. As a result, even thought these machines are now offsetting them correctly, the Exchange update tool will not know this, and in silent mode, will move them incorrectly by 1 hour.
Now, on to the real fun, KB930879 and Msextmz.exe. We started off with version 4.3 of the KB, and version 1 of the MSExTMZCFG.Exe tool. It was a simple run of a GUI based tool to extract the DN and Time zones of all out mailbox information. Yet I started to run this in a lab environment on Thursday Feb 22. Yet it would not work. It wanted the name of the Exchange server to run against. Fair enough. Yet no server name known to computing would work. NetBIOS name, Host name, UNC name, FQDN none worked. The KB said to use the LegacyDN name. But wait a minute; LegacyDN is x.500 style from Active Directory. Exchange 5.5 does not know about AD and vice versa.
So, next step is to run the Exchange 5.5 admin program in raw mode (admin.exe /r) and show the Exchange 5.5 x.500 name from the exchange 5.5 DS. Nope that did not work either. Tried every Exchange 5.5 site I could find, called everyone I could think of, but no go. Next day, Friday Feb. 23, and using version 11.1 of KB 930879 (which is explicitly stated to support Exchange 5.5) and version 2 of MSExTMZCFG.exe, there is still no progress, but now I get 2 different error messages. The KB now says we can use a friendly name. No friendly name works, and I verbally try quite a few unfriendly names, and none of them work either. Here I am, an MCSE:Messaging (aka Must Consult Someone Experienced in Messaging), and I am stalled for 2 days trying to fill in a server name field on a GUI tool. Our proposed cut over of Feb. 24 is of course postponed.
Monday, Feb 26, and we still do not have even a lab solution. So, the problem is that the tool appears to be going to AD to find the Exchange 5.5 server. How to let AD know about it? So, we toss on an ADC and 2-way connection agreement. No joy, the LegacyDN remains unpopulated. So now we get desperate. In the lab we add an Exchange 2003 server to the Exchange 5.5 site and AD. It works! We now have the glue to tie Exchange 5.5 to AD. Now the MSExTMZCFG.exe tool runs as advertised.
We are lucky. We already have AD in production, and have done the planning and know what we want for our Exchange 2003 production server. So on Wednesday, Feb 28, we run production ForestPrep, DomainPrep and install our empty, production sever into a virtual partition on a workstation. Then we run the config tool and extract our mailbox DN’s and Time Zone info. Prep the files on Thursday. And Friday night, Saturday morning we use SMS and Wake-on-LAN to push the client OS patch to the clients. While another team member patches Citrix. While I run 1+6 copies of Msextmz.exe on 6 virtual machines to update the mailboxes.
And it worked. We had one mailbox with issues because it received the XP OS patch early. We knew of this and worked with the client to minimize hassle. We had one mailbox blow up. The person unfortunately requested a name change on Thursday, after the extract, but before the update. Opps, a special run fixed her calendar, sort of. Her 7 appointments were fixed. But the 117 meetings she had been invited to were the real problem. The meetings remembered her now non-existent name, and the updates all bounced. And the last problem, some clients were upset because when they opened the calendar on re-occurring meetings, the calendar showed the year 4500. This must be the end date for no-ending meetings. (Microsoft knows something about the end of the world that the rest of us are unaware of?) Just have them go to the day in question and all is well.
And the last bit of info. By version 16.0 of KB 930879 Microsoft pulled Exchange 5.5 from the list of supported products. But it can be done, if you bring an Exchange 2003 server in to tie everything together.
Very cool David and thank you for sharing!