Step by step run of the Exchange Calendar Update Configuration Tool (MSExTMZCFG.EXE)
Published Feb 14 2007 07:20 PM 31K Views

We have put together a step-by-step walkthrough on how to run the Exchange Calendar Update Configuration Tool (MSExTMZCFG.EXE). This is a server-side tool that can be used as part of the 2007 DST process for Exchange. We have also included some information about solutions for commonly seen errors when running the tool.

Please note that the KB article that talks about this package (KB 930879) has additional information about the tool as well as prerequisites and possible complications.

There are 2 files that are downloaded in the above package:

MSEXTMZ.exe - This file extracts time zone information from mailboxes on a server that is running Exchange Server. This file also updates mailbox calendars for a specified list of users by invoking the Outlook tool against each specified user.

MSEXTMZCFG.exe - This file is a configuration tool that describes most of the steps when you update an Exchange Server server.

Step 1: Prerequisites to running the Exchange Calendar Update Tool

1) Pick a client operating system. The Exchange tool will run on any of the following operating systems:

  • Microsoft Windows Server 2003
  • Microsoft Windows XP
  • Microsoft Windows 2000 (must have OS fix or must import registry entries from KB 914387).

2) Install Outlook 2003 or Outlook 2007. Create a profile that has rights to log in to any mailbox in the organization.

3) Install the OS DST Patch (KB 931836).

4) Install the Outlook Time Zone Update Tool (TZMOVE). Download from the Microsoft Download Center or from KB 931667.

5) Make sure that the .NET Framework v2.0 has been installed

Now you are ready to proceed. Click on screenshots below to see bigger versions if they are cut off in your browser window.

Step 2: Run the MSExTMZCFG.EXE, it opens up like this:

The "Server Domain Name" value is the server's LegacyExchangeDN from Active Directory. In order to get this information, you can use the utility such as LDP.EXE or ADSIEdit. The LegacyExchangeDN is in the following format:

/o=<Exchange organization name>/ou=<Administrative group name>/cn=Configuration/cn=Servers/cn=<Server name>

So something like this:

/o=Contoso/ou=First administrative group/cn=Configuration/cn=Servers/cn=E2003BE1

Step 3: Enter the Server Domain Name and press Next:

Possible issues at this stage:

- You might receive "Please Select the Valid Server" message box if the LegacyExchangeDN is not specified or is not in a valid format (extra spaces would be a problem too).

- You might receive the following errors in the MsExTMZ.log due to LegacyExchangeDN mismatch:

Unable open mailbox table for server /o=Contoso/ou=First Administrative Group/cn=Servers/dn=E2003BE1.  Error 0x80070057.

Unable open mailbox table for server /o=Contoso/ou=First Administrative Group/cn=Servers/dn=E2003BE1.  Error 80040115.

Step 4: Now you will get prompted for the Outlook profile name:

Possible issues at this stage:

1. Make sure that you select a profile with administrator privileges and the profile is configured in online mode.

2. You might receive "Unable to find mailbox timezone: Error 0x80004005" (you can check the msextmz.log for errors). This might happen if the mailbox has never been logged into. To resolve this, login to OWA for the user specified in the error message and create a meeting request or an appointment and try re-running the tool again.

Step 5: The tool names the text files it will create

1. Conflictusers.txt - this file will contain users that have Conflicting TimeZone entries

2. NonExistent.txt - will contain users who do not have their TimeZone information set.

Press Next.

Step 6: Specify the Time Zone and paths needed

Next you will get to Select Time Zones and specify the path to Outlook.exe and TZMove.exe:

Possible issues at this stage:

- When specifying the Outlook Time Zone Update Tool, make sure you select the TZMOVE.EXE which is about 304 KB in size rather than the download itself, which is about 8 MB in size.

- The TZMove.exe can be found in the following location: C:\Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool

- The Outlook registry Path should be pointed to the following location if you are using Outlook 2003 to run the utility:

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook

So after you specified the paths you should have something like this:

Step 7: Press Finish to finish the configuration

After you press Close on the above screen, the Configuration tool creates a folder named by the server name in the C:\MSEXTMZ directory. This folder will contain the following files:

Mailboxes_1.txt - This is the list of mailboxes that will be processed when the batch file is run.

MSExTmz_1.bat - This is a batch file that will call the C:\msextmz\msextmz.exe to process the MSExtmz_1.ini file

MSExTmz_1.ini - This is the INI file which is created by the utility based upon the input specified by us while running steps 1-6 above. If for some reason the update doesn't run, this ini file can simply be modified instead of running through the entire config tool again.

NonExistent.txt - This file contains the list of mailboxes which do not have Time Zone Information (like System Mailbox / SMTP Mailbox / System Attendant mailbox etc) or any mailboxes that have not been logged into yet.

The folder will look like this:

A sample snapshot of MSExTmz_1.bat:

A sample snapshot of MSExTmz_1.ini:

A sample snapshot of NonExistent.txt:

Step 8: run the MSExtmz_1.bat file:

Successful processing of the MSExtmz_1.bat will look something like this:

All of this information is also being logged into the msextmz.log (as specified in the .ini file).

Possible issues at this stage:

If you get a bunch of errors with a code of 0x80004005, there are a few things to check:

- That the Outlook tool is installed

- Make sure the correct TZMOVE.exe has been selected in step #5 above

- Try to run the tool from the following location: C:\Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool

For steps that you should do before and after running of the Exchange tool, other options that you have and related FAQ, please see the Exchange Server and Daylight Saving Time (DST) 2007 TechNet article.

- Ben Winzenz, Nino Bilic, thanks also to Suresh Babu D

286 Comments
Not applicable
Thanks for the tips. We have had a couple issues. First, our legacyExchangeDN field is <empty> for our mailbox server. No problem, we just used the host name and the default from the sample ini file.

Second problem, we have multiple users in the nonexistent.txt file. These users have logged-in to their mailbox, so the timezone should be set. Is there a way to fix this? Can we set their timezone programmatically, or have them do it in Outlook somehow? It will be painful if we have to have these users run the tzone tool manually.
Not applicable
Rob,

You'll notice from the extraction screenshot that there is an option to extract time zone information from recurring meeetings.  It is more intensive to do this, and takes longer, so it isn't recommended to start with that, but when you are having problems getting the time zone information, you can give this option a try.

The other option that you have is that if you know what the time zone is for those users, you can always manually put that user and time zone information into the mailboxes_1.txt file, using another known good user as the template.
Not applicable
Rob,

If worse comes to worse, you can run the Outlook TZMove utility silently using a domain logon script.  That's the way we're doing it.

First you push the TZMove.msi to users or computers using a Software Distribution GPO.  Then you run the logon script:

"C:Program FilesMicrosoft OfficeOffice12Office Outlook Time Zone Data Update ToolTZMOVE.EXE" /q

This has the advantage of users in different time zones running the tool themselves (silently) using their local time zone.  Helps a lot if you have users from different time zones on the same server.
Not applicable
Is there a Way to Run the tools in a test / readonly mode to find # of Meetings, # Attendees . Our chanllenge is to find out if we wil saturate the networks when we run the tools
Not applicable
I've already run this in our labs and didn't notice any huge hit to our servers like I was expecting.  I suppose if I'd run a dozen machines, but even then I don't think it'd be terribly bad.  

I did notice that it stays on each mailbox as long as the timeout you have set, even when it's updated every appointment already.  I figured it would move on when done.

I had questionable results determining users timezones.  Some who were in Central came up as possibly being in either Central or Eastern.  That didn't help me much.  I also found that in my case, searching recurring appointments was a must or that Central user would have come up as Eastern.

For a large organization, it'll take some effort.  Also, if your users have manually adjusted the effected meetings backward an hour to compensate for the perceived error, this tool will shove those meetings backward an hour as well.  :(  Darn users.

Not applicable
Thanks guys for responding to my complaint. I will follow the guide and let you know if I see any issues.
Not applicable
What happens if we get the error ""Unable to find mailbox timezone: Error 0x80004005" and it is fixable using the recommendations in this article, but but that defeats the purpose of running a tool on exchange? On another note, almost everyone is detected as eastern time zone, which is where the exchange server is, but we do have users in other timezones which are not detected properly.  Are the 2 problems related or seperate and what will happen if we run the exchange tool without fixing the 0x800004005 error and leaving the users as detected?  most users run in cached mode, which i think is why we get the error?
Not applicable
Regarding Jeff's suggestion of running the Outlook tool in the logon script, I was in favor of that method myself, but there's a problem I haven't been able to solve.  If a meeting organizer doesn't log in for a while, neither the attendees nor the conference rooms will have their calendars updated.  The conference rooms are the biggest problem.  We use direct booking and were planning to work around the problem of conflicting meetings by temporarily setting the room calendars to allow double booking.  We couldn't leave them like that for long enough to allow everyone to log in and update their meetings.  The only other way to handle it would be to delete the conference room calendars' meetings for the four new DST weeks, and I'm not sure how risky that might be.  Comments and ideas welcome.  This whole thing is just a no-win situation.
Not applicable
Ccould somebody address why the Exchange tool works the way it works? Why is it necessary for this tool to be a pretty hacked up wrapper around TZMOVE?

Presumably since this tool is meant to be run against an entire server, Microsoft could have spent a fraction of the two years developing a tool that directly manipulated the mailboxes instead of doing it through TZMOVE. It seems like it'd be a lot faster and more reliable to provide a tool that required you to shutdown your backend servers, run it directly againstt their data stores, and then bring them back up afterward.

What is the reasoning behind this approach? It is pretty terrible, in my opinion.
Not applicable
Our thoughts for our large organization:  Skip the Exchange update tool; there's too many exceptions and it runs too slow (it would take us weeks to update all of our calendars, even with 6 simultaneous instances running.)  Run the Outlook update tool via the logon script, inside of a VBS wrapper.  First the VBS needs to make sure the OS patch is installed, then check to see if MAPI is set to prompt for profile upon starting Outlook (if that's turned on, silent mode isn't going to work.)  If those tests pass, then run the Outlook tool in silent mode.  Scrub the Event Log afterwards to see what appointments failed to be updated, then stick a pretty HTML email in the user's Inbox with a status report, and list which appointments they may need to touch manually (based on Event Log data.)  If profile prompt is turned on, we launch the Outlook update tool in interactive mode -- we communicate ahead of time what to do when this happens.  In either situation, we also log status for that particular user to a central location on the network, and that status is also checked the next time the user logs on to make sure it doesn't run twice.  We'll use the central logs to also identify who hasn't logged on in a while, etc, and handle those on a case-by-case basis.  We haven't been able to find any other way that works effectively in a large environment to get everyone updated quickly and accurately.
Not applicable
Paul's method is interesting. One problem we have is that a good portion of our users use Citrix to access their outlook. Any users out there have this same scenario?
Not applicable
Citrix shouldn't raise a concern if the logon script still executes ... you just may have to modify the delivery mechanism (perhaps VBS scripts aren't allowed, etc.)  Maybe take the same functionality, compile it into an assembly (.NET or VB or something), deploy to the Citrix servers and have the logon script run it locally?  In the past Citrix hasn't created too much of a hassle for us, we just had to tweak the delivery a little.
Not applicable
Chris, you're right in that you're going to have exceptions.  With large organizations, this is inevitable and cannot be helped.  In those cases, a manual workaround will have to be implemented.

1. Logon to the network as the user from a machine with the TZMove software installed.

or

2. Use the Exchange tool (MSExTMZCFG.EXE) to run against the exceptions.
Not applicable
If this has been covered in other areas I apologize - I have tried searching!  In any case, we are running Exchange 2000 and we are going to be testing this tool in a lab this afternoon on a few mailboxes.  My question is this - it appears that if we run the tool either via Outlook or the "server" tool, we will most likely run into resource conflicts (ex. Conference rooms) because of double booking issues.  I assume the server tool does nothing different to address this?  I did read a post somewhere that mentions running the tool first against all resources and then running it against users?  Is this the recommended approach and if so is it just a matter of modifying the text file to just include those resources and then later on run the tool again and exclude the resources?
Not applicable
BTW, one potentially HUGE problem in the MSExTMZCFG.EXE tool that hasn't gotten much press is the following:

"Reminders appear later than expected

Meeting reminders for mailboxes that are updated by the Exchange tool will not be updated if Outlook has never connected to the mailbox in Online mode. In this situation, reminders will appear one hour later than expected."

If you have users that only access Exchange via OWA, they will be affected by this.  This does not happen if you use TSMove.
Not applicable
Brian, if you're using AAA (Auto Accept Agent) for your resources, you're going to have a problem with AAA declining the updates as conflicts.  The current workaround is to turn off AAA, log into each resource mailbox and manually except the updates.

This does not happen if you use Outlook's direct booking feature for resource mailboxes.
Not applicable
Jeff -- I thought the suggested workaround for the AAA was to modify the configuration file to change the conflict resolution setting?  This is precisely my frustration with this entire situation ... every time a MS resource speaks up, it's a different story about something.  If your suggestion refers specifically to the Exchange 2000 environment only (based on Brian's note) than I apologize for the rant -- but I wish folks would start speaking in specifics!  Every day (literally I kid you not, it's been every weekday for over two weeks now) I receive new information from some MS channel that suggests a change in guidance on things.
Not applicable
Please excuse my ignorance, but is there an AAA in Exchange 2000?  Also, by direct booking do you mean that a user opens the calendar directly?  If so, then we don't have it set up that way.  We have the calendar options set for the resource to Automatically accept meeting requests and reject duplicate bookings.  So I guess based on that information my original request of whether or not we need to update the resources first still applies.  Thank you.
Not applicable
In the MS KB article 930879 (running the Exchange Calendar Update tool) it notes that the tool does not update any calendars in Public Folders. Looking through our public folders I have counted over 200 calendar folders that will need to be updated.

Am I reading this correctly in that the only way to update any calendars in public folders a sysadmin with permissions for the calendars will need to run the Outlook tool manually? Since the Exchange tool is basically the same tool with a wrapper around it, can the Exchange tool not be run to update the calendars instead?

Does ayone have any suggestions on how they are dealing with public folder calendars? I'm certainly open to suggestions. We have 6 exchange backend serversand 2 front end servers with about 9000 mailboxes in total to look after.
All users are in the EST time zone.

Users connect via OWA, Citrix/OWA, Outlook 2000 / Outlook XP, and Outlook 2003. Some users are in Cached-Exchange mode in 2003.

Thanks,

Tim
Not applicable
Brian, there are three ways (AFAIK) to set up a conference room that automatically accepts meeting invitations.  One is to set up a PC that is logged in as the room and set to automatically accept meeting invitations sent to it.  Most people don't use that method because of the hardware it requires.

The second way is to run the autoaccept script.  The advantage is that you don't have to remember to invite the room as a resource; the disadvantage is that you don't find out immediately whether the room accepted.

The third way is called direct booking.  You have to invite the room as a resource or it doesn't work.  If you search the Knowledge Base for that phrase, you'll find articles on it.
Not applicable
Paul - I understand your frustration very well because I'm living it, too.  I've been on MS web pages that have literally updated *while I was reading them*!  In any event, either workaround will work (turn off AAA or modify the config file).  Whatever

you do, there's going to be double-bookings and, worse, holes in the calendar where meetings should be until the meeting organizer runs TZMove.



Brian - AAA is an add-on for Exchange 2000.  It's available here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=3D0884E6-C603-491D-BF57-ACF03E046BFE&displaylang=en.



My testing and experience shows that if you use direct booking, a resource mailbox will accept a double-booking, or conflict, even if the resource mailbox is configured to decline conflicts.  I believe this is because the updates that are generated are not

normal updates.  Did anyone notice that the updates that TZMove or the MSExTMZCFG tools generate don't show as "Update: our meeting", like a regular update does?



PS - Just to be clear, I don't work for MS.  I'm an MCSE:Messaging consultant working for a MS Gold Partner.  I've been working on DST solutions for customers from 100-10,000 users.

Not applicable
Ben & Jeff, thanks for the guidance. As we only have 250 users, manually editing the nonexistent.txt and adding those users to the mailbox.txt file will probably work for us.

As for rooms using the AutoAccept agent, does the statement "Environments that manage resource accounts by using the Exchange Auto Accept Agent can set the conflict level to 3 to allow for conflicting meetings" still ring true? Or should we indeed turn off AAA and manually update meetings?
Not applicable
Back to reminders. If you turn that off, once all of the users are updated, will the reminders fire correctly automatically or do they have to be manually reset by the organizer & Send Update? (this would be for Outlook 2002 on Exchange 2003).
Not applicable
Anyone find a fix for the error:

Unable open mailbox table for server /o=Contoso/ou=First Administrative Group/cn=Servers/dn=E2003BE1.  Error 0x80070057.

Been working with MS Support for a week now with nothing.

Thanks.
Not applicable
Rob,

Regarding the comment about Auto Accept Agent, it is inaccurate.  There is unfortunately no way to configure AAA to allow double bookings.  The end result is that you may have some meetings which get declined if there is overlap.  To prevent that, you would need to unregister the resource mailboxes from AAA.

We may have also found another workaround, so stay tuned.  I think we will be posting a separate blog topic on dealing with resource mailboxes.

Ben
Not applicable
The SBS'ized instructions for using this tool: http://msexchangeteam.com/archive/2007/02/14/435267.aspx
Not applicable
So, what happens if the Time zone on the input file is wrong?  

We have a very poor OWA usage (<3%) and with the recurring option set in the the tool, a couple of dry runs (on 2 servers) yielded only 10 to 15% in the input file.  

So, if we change the text file data to say EST (for a user in Pacific time), what happens to the calendar when the batch file runs?  Does his calendar get "rebased" by 1 hr or 3 hrs?
Not applicable
What is better than snakes on a plane? The Exchange Calendar Update Tool on a VM. Well I haven't seen
Not applicable
Andy mentioned that there would be a administrator tool to replace the client side tool built in to Outlook
Not applicable
Andy mentioned that there would be a administrator tool to replace the client side tool built in to Outlook
Not applicable
I'm glad you came out with this, alas, a  day after I figured it out for myself. At least it confirms that I am doing the right thing. I was dissapointed that the KB article or the download did not have these steps. I lost about two days trying to test the tool. I could not even run the config program until I tried it on another PC and a message saying that I need .NET Framework installed. That was the clue as to why everything wasn't working. Plus, pointing to the wrong tzmove.exe (I found the answer in a Google Groups posting). It seems like this was really rushed to production without QC. Say what you want about MS, but they are usually flawless at this stuff.
Not applicable
First, I want to say Thank you! This is the best post for describing the actual process that I've seen.
Second, I have one question. I'm planning on running 10 workstations at minimum to do all the mailboxes over next weekend. I would adjust the mailboxes_1.txt to a list of users for each workstation. Other than that, do I have to do anything special to run all the instances?
Not applicable
As soon as I run the .bat file Outlook opens and prompts for a username and password. I'm logged on as the administrator and I've tried using that username and password with no avail. I'm running Exchange 2003 and Outlook 2003. Am I getting this error because something has gone wrong in step 2 (Create a profile that has rights to log in to any mailbox in the organization) How can I verify that the admin account has rights to log in to any mailbox?

Thanks
Not applicable
The cfg tool is not documented in
kb930879.  Your instructions above to not
talk about applying permissions.  Send as
and full access are not available by
default- even to a Exchange Full Administrator
Does the cfg tool preclude the need to
run the vbscript included in the kb?  (which
I haven't gotten to work yet)
Not applicable
Ben,

I would definitely appreciate any information on a workaround for AAA resource mailboxes.  Un-registering and then re-registering would be a nightmare in our environment.

Thanks for the information in this blog, although I only found it after deciphering the KB article and hashing some of the vagueness.

-Keith
Not applicable
A point of clarification on the requirements for running the tool. The Outlook profile that is being used does not carry the administrative rights required but the account that is the logged on user. So although you could have used a mailbox for a generic user, as long as the account you have logged in with has the system-wide FMA and Send As rights the tool will run.

Or have I missed something here?
Not applicable
Regarding AAA, I thought I just had to configure AutoAccept.config.xml to change to 3 to allow more than double bookings.  If this is not the case, what's the solution?  Do I really have to unregister them and go into each mailbox to send updates?  

Please adivse,  

Thanks.
Not applicable
Sheri,

In repsonse to your question, when you run the MSEXTMZCFG.exe tool, you need to set the Concurrency setting to 10. That will give you 10 mailbox files.
Not applicable
All our users run in cached mode. Does this mean the Exchange Calendar Update tool will not work? Are there any other issues I need to be aware of using cached mode?

Regarding AAA. Will there be the same issues with this if we use the Outlook tool via login script?

Thanks,
Not applicable
Not applicable
I've been reading a lot of questions about the MSExTMZCFG Tool in the forums of exchange community. Then,
Not applicable
Dave,

Open up Outlook and then go to File > Open > Other Users Folder - that should tell you if you have the rights to open other user's mailboxes using the account that you have logged in as.
Not applicable
Paul...Your method of using a script run at logon is interesting.  Any chance you'd care to share some of your code?
Not applicable
On questions regarding AAA / Direct Booking and resource mailboxes - something is coming, but we need a little more time. In few hours we'll have a post on this and will cover several ways to go about resource mailboxes.
Not applicable
Will any of that post on the resource mailboxes be applicable to Exchange 2000?  We have each resource mailbox set up to accept meeting requests automatically.  Do we need to log in to each resource mailbox and uncheck the option to decline resource conflicts?
Not applicable
Regarding Pacific Time Zone issue. Does this mean I need to do this reg hack on all machines in Pacific Time zone whether I run Exchange too or Outlook too.?

A time zone may be ambiguous

Recurring calendar items that are created by using DST 2006 rules in the Pacific (PST) time zone in Outlook 2003 or in an earlier version of Outlook are not updated by the Outlook tool. This problem affects MSEXTMZ.exe because MSEXTMZ.exe runs the Outlook tool.

To work around this issue, change the registry to remove the Mexican time zones on the computer that is running MSEXTMZ.exe. Run MSEXTMZCFG.exe in Update mode, and then restore the Mexican time zones in the registry. To do this, follow these steps.
Not applicable
I'm pretty new to this whole being an Exchange admin thing, and I've been tasked to fix this whole DST mess... Is there a quick and easy (or at least just easy) way to create a profile that has rights to log in to any mailbox in the org (Step 1, substep 2) If someone with the knowledge could post some step by step directions, it would be HUGELY appreciated!!

Thanks
Dave in Iowa
Not applicable
Sheri,

You should be all set to run it this way.  There is nothing special that I am aware of.

Not applicable
If i have exchange 2003 and all my users (5000+) in EST zone only do i still need to run this tool?

We have already appplied 931836 to All servers and workstations.
Not applicable
Exchange Calendar Update Tool to correct the DST issues
   

Question: I'm in the middle of using the Exchange Calendar Update Tool to correct the DST issues.  I'm able to extract the current time zone data and receive many users on the NonExistent.txt output.  What do I do for these users?  How do you correct it so you can run the tool on their mailboxes?

The doc simple says these users do not have time zone information in their mailbox.

So what does that mean?  My mailbox happens to be one of these and I know I have recurring meeting that are effected and are off by one hour.

Version history
Last update:
‎Jul 01 2019 03:24 PM
Updated by: