Curse you and your time zone tools, Microsoft!
Spoiled as I am by Linux and Mac OS X, I figured that updating Windows and associated Microsoft products would be as easy as running a script or downloading an update.
As if.
The problem, of course, is that M$ provided such easy solutions for the most current versions of Exchange Server, Windows Server, Office and the desktop OS (aka XP and Vista). At my workplace, we are still using Exchange Server and Windows Server 2000, and most of the client machines run Office XP and Windows 2000 Pro. Silly of me as the tech guy not to spend craploads of money to get the latest versions of all.
So the update solution for those of us stuck in the Stone Age is to download a set of “tools” provided by M$. The process is, to say the least, not intuitively obvious. After some false starts, I managed to get it right, with the help of a very useful (third-party) step-by-step guide here and liberal applications of Google searches.
The complexity results from needing to update the time zone details on the network domain controllers (DCs), the mail server, and the client machines, and then updating the Exchange database on the mail server. This last tool requires either (a) a client machine running either XP SP2 or Vista and Office 2003 or higher or (b) a client machine capable of running Virtual PC 2004 or Virtual Server 2005 to emulate a more modern Windows Server/Exchange environment. This latter is a free download from Microsoft here, although the link is temporarily unavailable at this writing. A virtual-server solution requires a boatload of RAM, which my desktop PC (with 512 MB) did not have, so I used option a..
If you have no machine available with XP SP2 and Office 2003 and none capable of running a virtual server, I suppose you would have to create or borrow one. Otherwise, as far as I can tell, you’re SOL.
Here is the procedure that worked for me, with the following network environment: DC and mail server both running Windows Server 2000 SP4, mail server running Exchange Server 2000 SP3, client machine running Office 2003 on XP Pro SP2. Results may vary.
- Update the time zone files on the servers, either by downloading Microsoft’s tool or one available at www.intelliadmin.com. The Microsoft solution is arcane and hard to locate for older server systems. I used IntelliAdmin’s tool, since it provides immediate confirmation whether the update worked. The same site has a Network Administrator tool to allow network admins to push the update out to client machines from a central location. There is a free version that will allow you to update three machines at a time. I used that tool, since I’m cheap and have relatively few desktop machines to update.
- Update the time zone details on the client machine you intend to use to work on the Exchange database. The IntelliAdmin tool works great. You can check if the client has been updated either by using the aforesaid Network Administrator tool from a server or on the client byright-clicking on the time display at lower right, selecting “Adjust Date/Time” and checking to see if “Eastern (or whatever) Daylight Time” is your time zone. To confirm, you can also click on the time zone drop-down menu and look for these two listings:
(GMT-06:00) Guadalajara, Mexico City, Monterrey -New(GMT-06:00) Guadalajara, Mexico City, Monterrey –Old.
If they are there, your PC is updated. - Make sure you have checked the “automatically adjust for daylight savings time” option, so that the servers report the correct time to client machines. [I forgot this little detail at first, throwing the times off by one hour on clients and driving my users crazy. Users could change the system time, but it would revert back to whatever the DC said it was.]
- Restarting the servers may not be necessary, but if you can, go for it. Besides, there always seems to be one Windows update or another that needs a reboot. Be sure all your servers have the time zone updates, especially if you have more than one DC or mail server.
- This step is critical for the Exchange calendar update tool to work properly (or at all). It took me several tries before I realized what I was doing wrong. To use the tool, you need to use an Exchange admin account with full access to all the mailboxes, so that this account can check and adjust the time zone settings for all users. I had forgotten (if I ever knew it) that Exchange Server 2000 by default does NOT give the admin full access and control. Even the Exchange System Administrator does not by default have full access to mailboxes. The M$ instructions merely tell the reader the account has to have full access rights, but fails to remind the reader how to set those rights. On the Exchange server, open up Active Directory Users and Computers. Select an existing admin account. Double-click on the account name to open up the Properties page. Click on the Exchange Advanced tab, then Mailbox Rights. Give the admin account “Full Mailbox Access.” Close the tab, then the Properties box. [You can create a new admin for this task, but Exchange Server 2000 pushes the Global Address List into the Offline Address List only once a day, by default at 5 am. You will need to wait at least until the next day to proceed with step 8.]
- Still at the Exchange server, make sure the chosen admin account is a local administrator (if appropriate — we have disabled local users on our servers).
- You should now be able to go to a client machine to use the Exchange calendar update tool. Remember, the client has to be running XP and Office 2003; earlier versions will not work. Login as the admin you created in step 5. It may not be necessary, but make this admin a local administrator for the client.
- Create an Outlook profile for the admin, if one does not already exist on the client. [If you have created a new admin account in step 5, you have to wait at least a day to create a profile. Outlook checks profile accounts against the Offline Address List, but Exchange only updates the OAL once a day at 5 am. Your new user can use Outlook Web Access and POP/IMAP clients to send and receive mail that first day, but not Outlook.]
- You have to download the Outlook calendar update tool (tzmove.exe) from Microsoft to the client machine. The Exchange tool uses the Outlook tool to do its work. Yeah, I know, seamless integration. Way to go, Redmond! You should probably run tzmove against your admin account to make sure it works.
- The calendar update tool uses a two-step process to adjust the time zones. First it uses the full-access admin account and tzmove to peek into each mailbox and extract the existing time zone settings, creating a delimited text file for the information. Then it uses that file and your input to push the correct time zone settings to the mailboxes. There are two versions of the tool provided in the download: a command-line version (msextmz.exe) that requires the user to manually edit a config file and a GUI version (msextmzcfg.exe) that performs the extraction and creates a batch file to perform the updates. I found the GUI version easier to use — there is a superb run-through at You Had Me at EHLO — but if you’re a CLI lover either version gets the job done. Microsoft’s instructions for the command-line version are here.
- The GUI version needs the name of the Exchange server; the NETBIOS name is fine. (The CLI version requires the legacyDN value for the server (the Active Directory/LDAP distinguished name), as in /o=YourOrganizationGoesHere/ou=YourAdminGroupGoesHere/cn=Configuration/cn=Servers/cn=ServerNameGoesHere.) Make sure the Extract radio button is checked and that the full access admin account name is in the Profile field. Click Next.
- If you have set everything up properly, the tool will now run through your Exchange Information Store and extract the time zone settings for all user accounts. You can watch the process in real time — if you’re really bored. For a large Exchange IS, the process may take a while. We have about 180 mailbox accounts; while I did not time the process, the extraction finished within 20 minutes.
- Run the newly created batch file, which will be in a subdirectory named for your Exchange server. For each user account with adjusted appointments, the batch file will log the changes to a text file for later reference.
- When the process finishes, make sure you go back to the Exchange server and remove full mailbox access rights from the admin account. Unless your organization has some compelling reason to allow such rights (Sarbanes-Oxley monitoring, for example), it’s generally a good idea to preserve your users’ privacy. Full access allows the admin account to read everyone’s email within Outlook or Outlook Web Access.
- Be sure to notify your users of the updates, so they don’t freak out.
These instructions may be a day late and a dollar short, since DST has already started, but I hope other admins will find them useful.
