Welcome to Exchange Team Blog Sign in | Join | Help
Search
BlogsVideosPhotosFiles

Syndication

This Blog

Post Categories

Archives

Step by step run of the Exchange Calendar Update Configuration Tool (MSExTMZCFG.EXE)

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

Published Wednesday, February 14, 2007 4:20 PM by Exchange
Filed Under: , ,

Comments

 

Rob D. said:

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.
February 14, 2007 8:17 PM
 

Ben Winzenz said:

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.
February 14, 2007 11:03 PM
 

Jeff Guillet said:

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 Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool\TZMOVE.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.
February 15, 2007 9:43 AM
 

Ram said:

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
February 15, 2007 10:00 AM
 

Lee said:

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.

February 15, 2007 10:25 AM
 

Dan said:

Thanks guys for responding to my complaint. I will follow the guide and let you know if I see any issues.
February 15, 2007 10:28 AM
 

hs said:

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?
February 15, 2007 11:19 AM
 

Chris said:

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.
February 15, 2007 11:53 AM
 

Sean Kelly said:

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.
February 15, 2007 11:55 AM
 

Paul said:

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.
February 15, 2007 12:22 PM
 

Milan said:

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?
February 15, 2007 12:43 PM
 

Paul said:

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.
February 15, 2007 1:12 PM
 

Jeff Guillet, MCSE:Messaging said:

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.
February 15, 2007 1:15 PM
 

Brian said:

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?
February 15, 2007 1:23 PM
 

Jeff Guillet, MCSE:Messaging said:

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.
February 15, 2007 1:26 PM
 

Jeff Guillet, MCSE:Messaging said:

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.
February 15, 2007 1:28 PM
 

Paul said:

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.
February 15, 2007 1:41 PM
 

Brian said:

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.
February 15, 2007 1:48 PM
 

Tim said:

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
February 15, 2007 2:11 PM
 

Chris said:

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.
February 15, 2007 2:16 PM
 

Jeff Guillet, MCSE:Messaging said:

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.
February 15, 2007 2:25 PM
 

Rob d. said:

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?
February 15, 2007 3:11 PM
 

Mary Lou said:

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).
February 15, 2007 5:13 PM
 

James said:

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.
February 15, 2007 6:15 PM
 

Ben Winzenz said:

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
February 15, 2007 6:27 PM
 

E-Bitz - SBS MVP the Official Blog of the SBS "Diva" said:

The SBS'ized instructions for using this tool: http://msexchangeteam.com/archive/2007/02/14/435267.aspx
February 15, 2007 8:44 PM
 

Ramesh said:

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?
February 15, 2007 9:57 PM
 

Joel Stidley's Exchange and PowerShell Blog said:

What is better than snakes on a plane? The Exchange Calendar Update Tool on a VM. Well I haven't seen
February 15, 2007 11:30 PM
 

Joel Stidley's Exchange and PowerShell Blog said:

Andy mentioned that there would be a administrator tool to replace the client side tool built in to Outlook
February 15, 2007 11:32 PM
 

Fuzzyman said:

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.
February 16, 2007 6:20 AM
 

Sheri said:

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?
February 16, 2007 7:45 AM
 

Dave said:

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
February 16, 2007 8:38 AM
 

Ben Cavanagh said:

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)
February 16, 2007 9:41 AM
 

Keith said:

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
February 16, 2007 9:48 AM
 

steve said:

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?
February 16, 2007 10:18 AM
 

BK said:

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.
February 16, 2007 11:12 AM
 

Rob D. said:

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.
February 16, 2007 11:29 AM
 

MW said:

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,
February 16, 2007 11:34 AM
 

Anderson Patricio Blog » Blog Archive » Using the Exchange Calendar Update Configuration Tool (MSExTMZCFG.EXE) said:

PingBack from http://blogs.msexchange.org/patricio/2007/02/16/using-the-exchange-calendar-update-configuration-tool-msextmzcfgexe/
February 16, 2007 11:38 AM
 

Anderson Patricio .:. Get-news Exchange Blog said:

I've been reading a lot of questions about the MSExTMZCFG Tool in the forums of exchange community. Then,
February 16, 2007 11:40 AM
 

Exchange said:

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.
February 16, 2007 12:09 PM
 

Shawn said:

Paul...Your method of using a script run at logon is interesting.  Any chance you'd care to share some of your code?
February 16, 2007 12:22 PM
 

Exchange said:

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.
February 16, 2007 12:30 PM
 

Brian said:

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?
February 16, 2007 12:43 PM
 

Dave said:

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
February 16, 2007 1:31 PM
 

Ben Winzenz said:

Sheri,

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

February 16, 2007 1:46 PM
 

Raj said:

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.
February 16, 2007 1:49 PM
 

Sherman said:

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.

February 16, 2007 1:53 PM
 

Ben Winzenz said:

Ben,

Running the cfg tool requires that you have rights to log on to all mailboxes.  There are several methods for granting those permissions, one of which is the vbscript.  Another method is to simply grant Receive As at the Mailbox Store level for the account you want to run the tool as.  Receive As = Full Mailbox Access.  If the account you are using has an inherited Deny for Recive As, then you can edit the Deny and place an explicit Allow.  Explicit permissions will override inherited.

If indeed Send As is required (which I'm not sure it actually is), then you can grant that easily at the domain level.  In ADUC, make sure you have the advanced view shown, then go to the security tab on your domain properties.  Go to the Advanced permissions, then add the account, and under the "Apply Onto" section, select "User Objects".  You will then see the Send As permission listed.  In my testing, however, I have not required Send As rights in order to run the tool in update mode.
February 16, 2007 1:58 PM
 

Ben Winzenz said:

Steve,

you are spot on regarding the requirements.  Mailboxes don't have administrative rights, users do.  Mark that one up to being in a hurry to get the information published. :-)
February 16, 2007 1:59 PM
 

Joel Bryan said:

We're getting when trying to run the Exchange update tool in our lab:  "Unable to launch new process to execute MsExTmz.exe..."
February 16, 2007 2:00 PM
 

Ben Winzenz said:

Sherman,

A few things.  First, if your user account is listed in the nonexistent.txt, it simply means tha tthe tool wasn't able to detect the time zone information.  The cfg utility includes an optional checkbox to try and detect time zone information using Recurring Meetings.  That isn't checked by default because it takes longer.  Have you tried running the tool using that option?

Second, if you know the time zone for those users in the nonexistant.txt file, you can simply copy them into the mailboxes_1.txt file and populate the required information (server, time zone).

Hope that helps.
February 16, 2007 2:05 PM
 

Ben Winzenz said:

Joel,

In the config tool, it sounds like you are pointing to the wrong tzmove.exe.  Make sure that you are pointing to the file in the c:\Program Files\Microsoft Office\Office 12\tzmove.exe.  If you are pointing to the other one, the unzip dialog will appear, and when that is closed you will receive an error like the one you see.
February 16, 2007 2:07 PM
 

Joel Bryan said:

Where do I change the location?  When I update the MSExTMZ.DST file, it gets overwritten when I start the tool again.  Is there a regedit I need to do?
February 16, 2007 2:43 PM
 

Joel Bryan said:

I added a path statement for the location of tzmove.  I can run it from a cmd line.  Msextmzcfg still gives the same error:  "Unable to launch new process to execute msextmz.exe, Exception raised: The system cannot find the file specified".
February 16, 2007 2:55 PM
 

Sherman said:

Ben Winzenz,

I did select the detect time zone option but 60 percent of my calendars come back as noexistent.  I will have about 1200-1300 mailboxes that I would have to manually enter the server and time zone.
I have no idea how I would go about implementing the manual process with users in four different time zones on four different servers.  Is there any specific senario that causes the users to show up in the nonexistent.txt?
February 16, 2007 2:55 PM
 

Tom said:

What does the error "failed to delete safe mode key  0x80070005" mean?

Thanks,

Tom
February 16, 2007 3:12 PM
 

Tim said:

In the 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 calendars in public folders is to have a sysadmin with permissions for the public folder calendars 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?

The documentation says to update a public folder calendar, the user must run the outlook tool in Interactive mode and then manually select the calendar to update. Can this not be scripted somehow? With over 200 calendars buried throughout the public folders, it is very difficult to find the calendars, and how would one easily ensure calendars do not get missed? These calendars are not set up as resources, they are meant for direct booking.

Does ayone have any suggestions on how they are dealing with their public folder calendars? I'm certainly open to suggestions. We have 6 exchange backend servers and 2 front end owa 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
February 16, 2007 3:33 PM
 

Exchange said:

Raj,

Yes you will still need to run the tool.
February 16, 2007 4:19 PM
 

Joel Bryan said:

I'm a bonehead.  I missed the part where MSEXTMZ.MSI had to be run first before running the config tool.  Do you think you could add that line to the document above?

Thanks!
February 16, 2007 4:38 PM
 

Eric said:

Im interested in the comment about - 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.

All our users run in cached mode. Does this apply?
February 16, 2007 4:53 PM
 

Susan said:

"I am also getting "Failed to delete safe mode key - 0x8007005".  How do I correct or fix that?
February 16, 2007 5:31 PM
 

nicatnite303 said:

I was just in the DST webcast from Microsoft and they glossed right over the potential issue with reminders still being off even after everything is updated. I think that's not a good thing since it might be a potentially serious issue. Does anyone have any more information regarding this?

Has anyone on the Exchange Team tested this?
February 16, 2007 5:38 PM
 

Mike Lagase said:

A link has just been posted at http://msexchangeteam.com/archive/2007/02/16/435378.aspx on "How to find public folder calendars and their owners?"
February 16, 2007 6:03 PM
 

Jeremy Green said:

Any other ways of granting a user Full Mailbox Access and Send As rights to all mailboxes besides the VB script provided by Microsoft and then later retract those rights?
February 16, 2007 6:40 PM
 

Ben Winzenz said:

Sherman,

The issue with detecting time zones is that the tool looks for specific properties on the mailbox.  These properties are populated under the following scenarios.
1.  User logged on with Outlook 2007
2.  User logged on with OWA 2007
3.  User logged on with OWA 2003/2000 and specified the time zone under the Options.
4.  CDO-based application that interacts with the mailbox (i.e. BES, Goodlink).
Optionally, you can set the tool to detect recurring meetings.  The guideline here is that the user MUST be the organizer of a recurring meeting, otherwise no information can be detected.

Unfortunately, this means that there will be many companies that end up with many mailboxes for which time zone information cannot be detected.  In order to address this, you can manually add user for which no time zone has been detected into the mailboxes_1.txt, and manually specify the other parameters (server, timezone).  When you then run the tool in update mode, it should work in the same manner against the manually entered users.
February 16, 2007 7:06 PM
 

Greg said:

So I have several remote users that are showing up in the ConflictUsers.txt as I'm suspecting and that's because the server is in the PST time zone and their Outlook client isn't. Correct??

Would the best course of action to have those users run the tzmove.exe locally? Or if I wanted to be a nice admin... Add their mailbox to my profile, change my time zone to match theirs and then run tool on their selected Calendar?

Thanks,

Greg
February 16, 2007 7:45 PM
 

Satish said:

Many of you would want to know what the value is for "server domain name".  It is the the legacyexchangedn.  Here is how you will find it.

1.
Open an Active Directory editor, such as ADSI Edit.

2.
Expand Configuration [DomainName], and then expand, CN=Configuration,DC=DomainName,DC=DomainSuffix.

3.
Expand CN=Services, and then expand CN=Microsoft Exchange.

4.
Expand CN=OrganizationName, expand CN=Administrative Groups, and then expand CN=AdminGroupName.

5.
Expand CN=Servers.

You will see the value on the right pane.  You can also just right click on the server you are interested in, and select properties, and scroll down to legacyexchdn value.

Copy it to a notepad and save it - this way if you need it again, it is there without the hassle.

Also, (i have not tried it), if you just want to focu on one fo the mailstores, you can keep expanding the storage groups from the above ADSIedit window, and pull the dn value taht way.

Also, if you are just setup the msextmzcfg.exe, you will run into the file not found error.  The trick is to install the msextmz.msi also.  Then it will work.

MS could do lot better in putting these types of instructions, somehow they think everyone in the world is using Exchange 2007, and write their instructions to it.  Very sad....(read the MS IT story on microsoft.com/dst2007 if you dont know what i mean.

HTH, Satish

February 16, 2007 8:07 PM
 

Ben Winzenz said:

Greg,

Conflict Users typically show up because users have selected different time zones.  For example, if a user has selected PST when using OWA, but they have EST set in Outlook.  It has nothing to do with what time zone the server is set to.  To correct this, you would simply need to identify the correct time zone for that user, then add them to the mailboxes_1.txt with that time zone.

You can of course run tzmove, or have them run it, but it's not necessary if you don't want to.
February 16, 2007 8:59 PM
 

Rob said:

For those of us in locations that do not observe DST (Arizona, Hawaii, etc) can we just get away with doing the Windows/Exchange updates and not the appointment updates??  In my own testing it appears that my calendar appointments were not affected by the DST patches.  Anyone else in a similar situation?

TIA,
Rob
February 17, 2007 2:52 PM
 

Sunny Sharma said:

I have been following this for a while and thought i'd try and help out with some VBScript code that lists the LegacyExchangDN for all servers.

You can then copy and paste it into the box asking for the "Server Domain Name".

Hope this helps,
Sunny


'=====================================================================================================
' VBScript Source File -- Created with Notepad(TM)
' NAME: GetLegExcDN
' AUTHOR: Sunny Sharma, Fujitsu
'
' VERSION: 1.0  17/02/2007 - Initial version.
'
' COMMENT: Enumerates ALL Exchange Servers for their legacyExchangeDN attribute  
'=====================================================================================================

' Ensure the host is CScript.exe as there will be many Exchange Servers to display
If (Not IsCScript()) Then
WScript.Echo "Due to way this script outputs information, you must use the CSCRIPT.EXE engine to launch this script."
WScript.Quit
End If

'Configure the ADSI connection
Set objRootDSE = GetObject("LDAP://rootDSE")
strADsPath = "LDAP://" & objRootDSE.Get("configurationNamingContext")
Set objConfiguration = GetObject(strADsPath)
Set oConnection = CreateObject("ADODB.Connection")
Set oRecordset = CreateObject("ADODB.Recordset")
Set oCommand = CreateObject("ADODB.Command")
oConnection.Provider = "ADsDSOObject"
oConnection.Open "ADs Provider"

'Get All Exchange Server Names with LeagcyExchangeDN value
strQuery = "<" & stradspath & ">;(objectClass=msExchExchangeServer);cn,legacyExchangeDN;subtree"
oCommand.ActiveConnection = oConnection
oCommand.CommandText = strQuery
oCommand.Properties("Page Size") = 100
Set oRecordset = oCommand.Execute
WScript.Echo "There are in total " & oRecordset.recordcount & " Exchange Servers"
wscript.Echo
wscript.Echo "Exchange Server Name" & vbtab & "legacyExchangeDN"
While Not oRecordset.EOF
sExchServerName = oRecordset.Fields("cn")
sDN = oRecordset.Fields("legacyExchangeDN")
wscript.echo sExchServerName & vbtab & sDN
oRecordset.MoveNext
Wend





'==========================================================================
'Functions
'==========================================================================

Function IsCScript()
' check whether CScript.exe is the host
If (Instr(UCase(WScript.FullName), "CSCRIPT") <> 0) Then
 IsCScript = true
Else
 IsCScript = false
End if
End function
February 17, 2007 3:46 PM
 

SunnyS said:

Forgot to mention that if you want to use the script then copy & paste all the code into notepad.  Save the file as C:\GetLegExcDN.vbs (ensure not as .txt).  Open a command prompt and enter the following :
CSCRIPT C:\GetLegExcDN.vbs

If you want to output to a log file then:
CSCRIPT C:\GetLegExcDN.vbs > c:\out.txt

In my environment Authenticated Users have sufficient rights to read this information - your mileage may vary.

If this was useful or you have an improvement then let everyone here know!

HTH,

Sunny
February 17, 2007 5:05 PM
 

Sarah said:

Like Tom and Susan, I am also getting the Failed to delete safe mode key error.  Does anyone know what causes that?

Thanks,

Sarah
February 18, 2007 2:38 AM
 

Tom said:

Re: Failed to delete Safe Key.  Make sure you have logged off and back on as the user account to update the local admin security token
February 18, 2007 3:50 PM
 

Tom said:

Re: Failed to Delete Safe Key.  Or try from a different client machine.   For some unknown reason XP SP2 works sometimes, and other times it doesnt.
February 18, 2007 5:16 PM
 

subject: exchange said:

Preserving Nickname Cache in Exchange Migrations Apple challenges Microsoft Exchange Google to Replace
February 19, 2007 4:40 AM
 

Sherman said:

Ben ,

Thanks for the infomration!  
When I run MsexTMZ_1.bat is it normal to open my a Outlook 2003 client for every mailbox it processes?
February 19, 2007 6:30 AM
 

Guy said:

any updates to  this .... ?

Exchange said:
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.
February 16, 2007 12:30 PM
February 19, 2007 8:49 AM
 

Sherman said:

We have Exchange 5.5 and probably won't purchase the cdo patch because it cost to much for us to purchase the support contract to be eligible to buy the $4000 dollar patch.  We have purchased an EA and license for Exchange 2007 and are going to upgrade in the next couple of months.  Of course, time is not on our side for DST 2007.  We know this will affect OWA but will it also effect communication of our BES server to exchange?  
February 19, 2007 9:26 AM
 

Sloan said:

I ran the Exchange tool against some test mailboxes that consisted of reoccurring meetings and personal individual meetings. All the reoccurring meetings looked as expected however all the individual meetings meets showed 1 hour behind durring the delta period. Is this not supposed to update individual meetings? (ie: Eye app at 10am)
February 19, 2007 10:33 AM
 

Exchange said:

Guy,

AAA stuff is published here: http://msexchangeteam.com/archive/2007/02/16/435404.aspx

Sherman,

This problem should not affect BES communication with Exchange however there will be a problem with appointments being off.
February 19, 2007 12:31 PM
 

Nagesh said:

Susan with regards to "Failed to delete safe mode key - 0x80070005" error, get the .Net 2.0 which is required for MSEXTMZ.exe to run.. http://www.microsoft.com/downloads/details.aspx?familyid=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=en
February 19, 2007 12:50 PM
 

Pablo said:

Does anyone know if this kills exceptions to recurring appointments/meetings?  We have a master calendar with class schedules on it and I don't want to break any exceptions (cancelled classes).
Also, is there any way to search for exceptions to recurring appointments so that we can easily identify things to watch for?
February 19, 2007 1:02 PM