Home  
  Projects  
  About Us  
  Blog  
     
     
   
   
   
   

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.

b. Pick the profile that you set up on this workstation.

c. Click Next. The config program will extract the necessary list of users and build a batch file and some input files, putting them in a subfolder named after your Exchange server.

d. On the screen with the conflict.txt file listed, click Next

e. On the next screen, there are two parameters that need to be set:
i. The TZMove.exe path should be where the TZMove tool installed. Do not point to the TZMove.exe executable that was downloaded. The path should be C:\Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool\TZMOVE.EXE

ii. The log directory should default to c:\MSExTmz\%servername%
f. When you click Finish, a new directory will be created: c:\MSExTmz\%servername%, and the following files will be there:
i. Mailboxes_1.txt: This is the file that the Exchange/Outlook tool will parse to connect to and update calendars.

ii. Nonexistent.txt: This file is a list of users that did not have necessary parameters to be included in Mailboxes_1.txt. Copy the entries from this file and append them to the Mailboxes_1.txt file. Now go through the Mailboxes_1.txt file and remove entries that do not need updating, like the SystemMailbox and some of the mailboxes that you use for automated processes. Also, note that a good entry includes the following after the LegacyExchangeDN: servernameTime Zone. Copy that bit of text from the end of one line and paste it onto the end of every line that lacks that text until every line looks something like this:
/O=FIRST ORGANIZATION/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=TEMPDSTUSER server Pacific Standard Time

iii. MSExTmz_1.ini: This is the .ini file from which settings will be pulled for the actual calendar update. On the line called CommandLine, append the following switch: /ONLYCREATEDPREPATCH:2007-02-17T12:00:00Z - What this will do is only change the time on appointments that have been created before the date set here. In this example, I have used the date of February 17th, 2007, which is about when all the clients in this organization had the KB931836 patch installed. If you suspect that there is a wide variety of install dates for this patch in your organization, using this switch may not be the best idea. But if you do not use it, any new appointments created SINCE the KB931836 patch was installed will be incorrectly changed. So you have to decide which is worse.

iv. ConflictUsers.txt: This file is created but has not been populated with anything when I have run the tool.

v. Errors.txt: This file is created but has not been populated with anything when I have run the tool.

vi. MsExTmz_1.bat: This is the file you will run to actually update the appointments in your organization.
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.

b. An error that ends with 4005 says that a timezone could not be found. Do not worry about it. You will manually set the timezone in step 8.f.ii

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.

Labels:

 
Comments:
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.

Kudos,

-John Niebler
 
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]





<< Home