Updates and Solutions
Using the Exchange Calendar Update Tool for DST issues on SBS networks
Saturday, March 3, 2007
There is a lot of confusion out there about DST updates, and part of the confusion is the fact that some solutions that are appropriate for the small business space aren't appropriate in an enterprise environment, and visa versa. Most small business consultants I have talked to are just distributing the Outlook Calendar Update tool to their users rather than centrally resetting the company appointments. Additional concerns are raised when you realize that the main DST patches were auto-deployed to users two weeks ago, and any new appointments created since then will be improperly altered if the Outlook Calendar Tool is run against them in the standard fashion this week. I have navigated these issues, and I would like to share what I have done.
I have run the Exchange Calendar Update Tool (version 2.0 (KB933146 updates the tool to v.2)) at two sites of 50+ users on servers running Exchange 2003 with SP2 and KB 926666.
Working assumption: all systems were set up for Automatic Updates or for regular Microsoft Updates and all workstations got the KB931836 patch within a few days of each other. I had already installed the KB926666 patch on the Exchange servers.
This was my process:
1) Download the following to a share on the server: Outlook Calendar Update Tool, Exchange Calendar Update Tool, and hotfix KB933146.
2) Create a new user in the domain called TempDSTUser. Do not add it to any groups besides the default Domain Users group.
3) Go to the Mail Store and add that TempDSTUser to the permissions list on the store root. By default the user will have Send/Receive-as permissions on all mailboxes, unlike any account that is a member of the Domain Admins group.
4) Check a bunch of systems and get an idea for what day KB931836 was installed. In my networks, it was usually installed on Feb 17th, 2007.
5) Log onto a workstation that has been patched with KB931836 and has Outlook 2003/2007 installed. Logon using the TempDSTUser account.
6) Use the Mail control panel tool to set up a new profile for the user pointed at the Exchange server. Make sure that it does not use cached mode. Make the new profile the default.
7) On the workstation, install all the tools and the hotfix in the order that they are listed above. Do not use the default directory for install (c:\program files\MsExTmz), instead use c:\MsExtmz. A Microsoft video demo warned about problems with using the default path.
8) Once installed, run c:\MSExTmz\MSExTmzCfg.exe
a. Input the server name. If you ran the hotfix mentioned above, the wizard should ask you for a Server Name, not a LegacyDN path.9) Run the MsExTmz_1.bat file and watch it parse through the Mailboxes_1.txt file. It will open each mailbox, search for appointments, and make changes. If there are no appointments that meet the criteria, it will say No Log File was written for user. If it finds appointments to change, a new logfile will be created in the C:\MsExTmz\%servername% directory with the name of the user in it. You can open these file to see exactly what was updated, which is a huge help when working on post-update questions with particular users.
10) What you see in the script running window will also be written to a text file called MsExTmz.log so that you can look through it for errors. Here are some you might run into:
a. An error that ends with 4011D usually means that the user account you are using was not set up with permissions on the user mailbox properly. Make sure you followed my steps 2 and 3 properly.
That is about it. I am still working on a good process for updating Public Folder calendars. The Outlook Calendar Tool is used to do this, and I will post my process soon.
I would be happy to get feedback from some of you who have also worked out your own methodologies.
I was reading through your instructions and they were very informative, I do like the added command line which is specific to the date the patch was installed. The one question I do have, is once all this is done, do the calendars move ahead 1 hour right away or does this take place once the daylight savings has occurred.
If the DST fix patch is in place, then appointments created before the DST patch for the interim period will be ahead by an hour already. If you run the update tool, the appointments should be returned to the proper time.
I ran msextmz according to what you said, it said it was creating logs, but the logs do not appear in the folder!! Weird. Am I doing something wrong??
Also, the switch did not work for me, I tried it without a date, tzmove did not run...
Also, some people have pointed out that I didn't mention the KB926666 patch. Sorry about that. I would run that before launching into my process. If you did my process first, well, go ahead and run it afterward. I don't think the difference will be particularly significant, given what I've read from the Exchange team.
Logs are only created for users that actually had appointments in their calendars.
The switch will only run if you've installed the hotfix for the TZMove tool. Read carefully the section at the top that lists the downloads.
Hello.. I get these errors when running my msextmz.bat file even though the timezone is specified in the .txt file ?
HrProcessMailbox:Unable to process mailbox /O=SPECIALIZED LOAN SERVICING/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=JRAPHAELSON - 0x80004005
Anonymous: What are you getting in the error log? Normally if you take the users from the error log and properly format them with the server and timezone again and replace the contents of the mailbox_1.txt (or whatever it's called) with that text and run the .bat file again, it will process those users.
Just wanted to say "Thanks!". I spent the better part of the day trying to understand MS's methodology. In the end you included things that just plain weren't included in their instructions.
I am also getting what the previous anonymous said. Users with Outlook 2003 and above are fine.
HrProcessInputFile:Processing Mailbox:/O=abc company/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=JOE_COOL
HrReadTimezoneFromRegistry:Failed opening timezone registry key 'Software\Microsoft\Windows NT\CurrentVersion\Time Zones\CENTRAL STANDARD TIME ' - Error 0x80070002.
HrProcessMailbox:Error 0x80070002 - Unable to Read timezone CENTRAL STANDARD TIME .
I am continually getting these errors but I have followed everything to the bone. User has send as permission on information store, is not a domain admin but local admin of exch box. Any ideas?
HrProcessInputFile:Error Processing Mailbox:/O=UFCTV/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=KNUZZI - 0x8004011C
Local admin of Exch box?
Go to your mailstore and get properties on it. Go to the security tab. Does that user have all rights on the Store? That's the only thing that matters. And that user can't be a member of any group that has a "Deny" on the send/receive-as.
Yes, they have full rights to the store. However, I made them a member of Administrators group (not Domain Admins) do I need to remove?
Again: Does that user have all rights on the Store? That's the only thing that matters. And that user can't be a member of any group that has a "Deny" on the send/receive-as.
Your answer lies in what you see in the Send-As/Receive-As rows of the permissions list. If the user has those rights on the store, then permissions is not what is causing your problem.
I still have not run the DST fix for Exchange because I was getting mixed reviews from people and hearing horror stories. Is this fix mandatory? There are users in my organization with calendar problems right now. Do the instructions above still work or is there an updated version? Any help would be great.Post a Comment
Subscribe to Post Comments [Atom]