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
 

Richard said:

I am running this procedure to test it in our small enviroment before rolling out to clients.  Seems that the other users are fine with the exception of 1 user.  Whenever I rerun the tool against her box I get this in the log:

[Original Time Zone]
(GMT-05:00) Eastern Time (US && Canada)

[New Time Zone]
(GMT-05:00) Eastern Time (US && Canada) (Update)

[Time Zone Update Log]
Type: Meeting
ID: 040000008200e00074c5b7101a82e00800000000000000000000000000000000000000004d0000007643616c2d556964010000004344303030303030384239353131443138324438303043303446423136323544363533353130423042353437364234373946374132424441303834394238424200
Subject: Weekly Staff Meeting
Old Start Time: Friday, June 10, 2005 2:00:00 PM
New Start Time: Friday, June 10, 2005 2:00:00 PM
Old End Time: Friday, June 10, 2005 2:30:00 PM
New End Time: Friday, June 10, 2005 2:30:00 PM
Recurring: Yes
Result: Error () (0x8004011b, 0x0, 0x0)



Anyone know why this might be failing?
February 19, 2007 3:41 PM
 

Tillman Smoot said:

Ok, I need some advice. I've put the correct Outlook 2003 registry path in but I keep getting the I keep getting the "Outlook key does not exisit" error message. Nice that it's mispelled too ;)

I have navigated to the key manually. It is there.
February 19, 2007 4:02 PM
 

Jonathan Merrill said:

I also am getting "Outlook kley does not exisit" error message.  Running it from a Vista x64 machine with Outlook 2007.  Been good up to thnis part.

Please help!
February 19, 2007 5:31 PM
 

Steven said:

I ran the tool against a user's mailbox earlier and my results match that of a 'Successful processing of the MSExtmz_1.bat' but the existing calendar entires he had for the last 3 weeks of Match are still wrong. Any ideas? He's running XP w/ Office '03. His outlook is in cached mode.

This is geting out of hand.

February 19, 2007 6:07 PM
 

Mark O said:

A few people have asked whether there are problems if a user's profile is configured in cached mode (Outlook 2003 on Exchange 2003 SP2). I'm in the process of researching the DST update for a site with 60 users. Obviously I'd prefer to not have to re-configure 60 Outlook profiles just to perform this update. Has anyone who has done the update with users in cached mode found this to be a problem? Does just the computer from which the Outlook Time Zone Update Tool have to be configured for non-cached mode or all of them? Any insight would be appreciated.

Thanks,

Mark O.
February 19, 2007 6:27 PM
 

Charles said:

I have been informed that the Exchange Calendar update tool can corrupt a user's mailbox if they have an appointment that spans the weekend.  i.e. and appointment that spans Friday through to Monday including  Saturday and Sunday.

Have you come across this issue and if so what advise do you suggest customers  take to avoid this issue?
February 20, 2007 8:02 AM
 

Bob said:

I'm also interested in the cached mode impact, if any, of running the exchange tool. I assume that when the changes are made on the servr-based calendar, they are sychned with the user's OST...but that's just a guess.

Thanks.
February 20, 2007 9:16 AM
 

Guy said:

Public Folder question

If users create appointments in public folder calendar and their Time Zones are different.

Which time zone should I run the Time Zone Tool as to update the PF?  the time zone as what the users are set to ?

Does each appointment have to be considered seperately ?
February 20, 2007 9:24 AM
 

Sherman said:

When I run MsexTMZ_1.bat it opens a Outlook sessions for ever mailbox it attempts to process.  Is this normal?
February 20, 2007 9:33 AM
 

dave said:

do you have to run the tool on  front end servers?
February 20, 2007 10:38 AM
 

nicatnite303 said:

Has anyone heard of or experienced any issues with Reminders still being off by an hour even after all the updates have been run?

Also, I haven't seen a definitive response to the Cached Mode questions too. Will it matter if we run the Exchange Update Tool, and clients are using cached mode? I would assume that the client would download the changes properly, but it'd be good to know in advance.
February 20, 2007 10:55 AM
 

dolphinsms said:

I am now getting the 80004005 error while running the tool in update mode.  Funny thing is that we have already processed many batch files without any problems.  No User Account changes, nothing changed other than workstation was locked then unlocked.  Now, we cannot get any more updates completed without that error on every mailbox.  We have logged off, rebooted, uninstalled/reinstalled, deleted Windows profile, etc.  This is on 2 separate workstations, using 2 separate Admin Accounts against 2 separate Exchange forests.  We are pointing to the current TZMOVE and running from correct directories.  Any clues?
February 20, 2007 11:46 AM
 

dave said:

do you have to run the tool in the same timezone
February 20, 2007 11:46 AM
 

Exchange said:

Dave,

You do not have to run this on FE servers
February 20, 2007 12:07 PM
 

HiED West Technology Briefings, News & Training said:

Updated DST Home Page Microsoft’s DST Home Page at http://www.microsoft.com/dst2007 has been updated
February 20, 2007 12:37 PM
 

nicatnite303 said:

Is there a comprehensive list of what time zones are making changes to their DST dates/times? Microsoft mentioned some 40 time zones affected in last Friday's webcast, but I can only find the following specifics regarding affected time zones:
All of the United States except:
Arizona, Hawaii, Puerto Rico, the U.S. Virgin Islands, and American Samoa Canada:

Canada and the United States share DST Mexico

Mexico will not be following the new DST 2007 rules

Does anyone know if there is a comprhensive list of affected TZ's anywhere?
February 20, 2007 1:08 PM
 

Bob said:

nicatnite303:
Have a look at this- http://support.microsoft.com/kb/928388/en-us

From the article:
The update that this article describes changes the time zone data to account for the United States DST change. This time zone update will also include changes for other related DST changes, time zone behavior, and settings. Some of these changes will occur in 2007, and some have occurred since these versions of Windows were originally released. The update that this article describes also includes some changes that have previously been released as individual hotfixes. An example of this is the Sri Lanka change in time zone offset. This update will also include some changes that have been individually documented in Microsoft Knowledge Base articles.
February 20, 2007 1:49 PM
 

nicatnite303 said:

Bob...
Thanks very very much. That is exactly what I was looking for.

nic
February 20, 2007 2:02 PM
 

Sherman said:

When I run MsexTMZ_1.bat it opens a Outlook sessions for every mailbox it attempts to process.  Is this normal?
February 20, 2007 2:39 PM
 

bummy said:

I think I already know the answer to this one, but I'm asking anyways.......Do you need to run this update if you are on Exchange 2007 with Outlook 2003 clients?
February 20, 2007 2:44 PM
 

Jay said:

Quoting :  
dolphinsms said:
I am now getting the 80004005 error while running the tool in update mode.  

I am also getting this error code unsing the CFG utility, however my mailboxes produce the following error:

"No success event found, treating as faillure"  ??

Any ideas?
February 20, 2007 4:06 PM
 

Satish said:

After running the msextmz_1.bat, the tool prompted me for a profile, and then the pop-up disppeared.  THEN, it ran through the list of users.  First one happened to be my manager, and within a minute, I started getting the meeting invite for the meetings that held in the past (recurring meetings).  It was scarey, and I rushed and cancelled the batch file command window.

When I opened the log file it created, it ran through about 19 of his meetings and in each and every one of them, the "old" and "new" start and end times are the same ! Is this normal?

Can someone tell me what specifically the admin (me) and the user as well as the meeting attendees for the user should expect as a result of running this tool?

All my users are in EST timezone.
February 20, 2007 4:56 PM
 

JNast said:

Anyone have any idea how long this process takes?  I have just under 1000 mailboxes...

Running Exchange 2003 with OUtlook 2003

Planning on running the Exchange Update not the Outlook update.
February 20, 2007 6:14 PM
 

Milan said:

We have just over 4000 mailboxes and we are estimating around 25 to 30 hours. of course the number decreases as you add more PC's to do the work.
February 20, 2007 7:57 PM
 

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

I'm copying an entire blog post because the info is really good.... for those who have Public folder
February 20, 2007 11:04 PM
 

Sherman said:

I receive this error message on every mailbox when running the update:

Processing Mailbox:/O=GAPAC/OU=BLUELINX/CN=RECIPIENTS/CN=TRMEILE
PRFFile set to C:\MsExTmz\MSExTmz-TRMEILE-0x08AFA0C7.PRF.
Spawned outlook process as pid - 2840.
Timezone set to CENTRAL STANDARD TIME.
Spawned worker process as pid - 3048.
Success Event not found in Application log, treating as failure.
Unable to process mailbox /O=GAPAC/OU=BLUELINX/CN=RECIPIENTS/CN=TRMEILE - 0x80004005
Error Processing Mailbox:/O=GAPAC/OU=BLUELINX/CN=RECIPIENTS/CN=TRMEILE - 0x80004005

PLEASE ADVISE
February 21, 2007 6:37 AM
 

Briam said:

Sherman, I had the same issue...(I think) ... I was using the wrong tzmove.exe  ...the correct one is in c:\program files\microsoft office\office12\office outlook time zone data update tool\tzmove.exe
February 21, 2007 9:05 AM
 

Tim said:

What worries me is that with over 9000 mailboxes to process, many users are going to get confused with the meeting requests being sent out after the tool updates calendar items.

We are worried that many users will simply ignore, or worse yet, delete the meeting request when after we run the exchange calendar update tool.
In our testing once the tool runs, the attendees are all showing as tentative. If the user ignores the meeting change request, they will continue to show as tentative, and the meeting will show in their calendar with the updated time.

If the user is being inundated with meeting requests, they may decide to instead delete all of the meeting requests from their inbox, effectively removing the meetings from their calendar. The same is true if the user is using a blackberry device and is deleting the meeting requests from the blackberry device because they are running out of space, or simply because all of the meeting updates are annoying them.

The end result being that out of 9000 users, many will end up doing this. It won't mater that we have told them not to delete the messages, and that they must accept the meeting appointments again, some will ignore, or delete them.

We need to be able to suppress the meeting request emails from being generated while running the Exchange Calendar update tool against mailboxes, as well as public folders.

I've seen in another blog post that the tool is being updated with this feature being included, is this true, and when will the tool be available? We plan to perform a test rollout in our test environment this weekend.

Regards,

Tim
February 21, 2007 9:33 AM
 

Brian said:

This may have been answered several times already, but if someone could give me just a yes/no answer I'd appreciate it.  We were planning on deploying all patches and running the Exchange tool this weekend in the following order:

a) Patch all servers
b) Patch clients
c) Patch Exchange 2000 with DST update
d) Run Exchange tool

We have decided to delay this one weekend as we want to coordinate it with our Goodlink upgrade and I hear there are some new Exchange tools coming.  Anyways, is there anything that would prevent us from still doing step "a" this weekend - Patching the servers with the DST patch and then waiting until next weekend to complete steps b through d?  If so, do we need to patch domain controller servers before member servers?  Can we patch all member servers this weekend and do the DCs, clients, and Exchange parts a week from now?  Thank you!
February 21, 2007 11:53 AM
 

Milan said:

Are there new Exchange tools coming?
February 21, 2007 1:49 PM
 

Exchange said:

Brian,

You would be better off applying the patches and running the tools rapidly one after the other as otherwise you can get into the situation where newly created appointments will look right but still get shifted during the tool run.

Milan - yes, there  is more on this comming. We know it is getting late and are working on it.
February 21, 2007 2:54 PM
 

KC said:

I'm geting an error when I click Finish saying "Outlook key does not exist.  Two other people have had the saem problem above but nobody has replied to them.  Can someone please help?
February 21, 2007 3:09 PM
 

dolphinsms said:

Ran the tool against several batch files, several hundred users then started getting this error.  Nothing has changed, but I cannot get this tool to work any longer.  Help!!!

No Event log records written - Treated as failure.
Unable to process mailbox /O=Bxxxx/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=mailbox - 0x80004005
Error Processing Mailbox:/O=Bxxxx/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=mailbox - 0x80004005
February 21, 2007 3:16 PM
 

Mikeo said:

I to am receiving the message "Outlook Key does not exisit.  Please make sure you have outlook installed"

are there any answers for this yet?

Thanks,
mike
February 21, 2007 3:41 PM
 

Brian said:

Exchange,

Thank you for responding.  Just one point of clarification-if we were to patch non-email related servers that have no bearing on email, wouldn't it be safe to patch those beforehand to eliminate some work on the day we actually do the email piece?
February 21, 2007 3:42 PM
 

Exchange said:

Brian,

Yes that would be fine of course. I was mainly refering to email related machines.

KC, Mikeo (and anyone else getting errors), I am trying to figure what could be causing this... in the mean time, I would suggest you call our support on this. DST support is free and our support engineers deal with those tools probably more than anyone else.
February 21, 2007 3:53 PM
 

The Wizard said:

Test Post - Please Delete Me
February 21, 2007 4:04 PM
 

tjcarst said:

I receive the following error when I run the tool:
Failed on open registry key Software\Microsoft\Office\12.0\Outlook - 0x80070002.
Error Processing Mailbox:/O=DOMAIN/OU=MAIL/CN=RECIPIENTS/CN=USER1 0x80070002
February 21, 2007 4:06 PM
 

tjcarst said:

The error 0x80070002 occurs in both of my setups.

I am using the virtual machine proficed by Microsoft.

I also receive this error with a Windows 2000/Office 2003 install.
February 21, 2007 4:28 PM
 

tjcarst said:

Also need to point out that my Outlook key is under HKEY_LOCAL_MACHINE, not HKEY_LOCAL_USER.
February 21, 2007 4:51 PM
 

Milan said:

Are there major changes on the Exchange Timezone Update tool V2? I am already installing it for testing.
February 21, 2007 5:16 PM
 

Mikeo said:

I to am receiving the message "Outlook Key does not exisit.  Please make sure you have outlook installed"
 Below is what you need to change

Change the default setting from:
Software\Microsoft\Office\12.0\Outlook
Software\Microsoft\Office\11.0\Outlook
and it should Run
February 21, 2007 5:33 PM
 

kryten98371 said:

This is what I get when I run the tool on a user's mailbox (not all users).

Type: Meeting
ID: <ID>
Subject: <SUBJECT>
Old Start Time: Monday, May 26, 2003 9:00:00 PM
New Start Time: Monday, May 26, 2003 9:00:00 PM
Old End Time: Monday, May 26, 2003 10:00:00 PM
New End Time: Monday, May 26, 2003 10:00:00 PM
Recurring: Yes
Result: Error () (0x80001023, 0x8004011b, 0x100e)

If I run tzmove on the users's machine, I get the error "The time for this appointment cannot be modified".  Has anyone else seen this?
February 21, 2007 5:38 PM
 

Mark said:

You mentioned that support calls were free for DST related incidents. Someone should probably let them know that!

I called on Monday and practically had to beg the support center to give me a complimentary support incident and I was only asking for clarification on the steps and how they were listed on Microsoft's web site. He finally agreed to send me through to the support group but told me I could not ask for any walk through or technical support help and could only talk about my issue with the details listed on the web site.
February 21, 2007 5:40 PM
 

Kat said:

Our school district is on Exchange 5.5 Enterprise & Windows 2000 Server & XP clients.  I would like to NOT apply any of the DST patches, and instead manually change the time on the Authoritative Time Server on March 11.My theory is that all of the appointments, meetings etc. will stay as scheduled.

Will this work?

(I would apply the XP &2K patches after 4/1, and we'll be upgrading this summer.)
February 21, 2007 5:52 PM
 

kryten98371 said:

No luck on my end with technical support.  The CSR said that the only choice I had was to upgrade.  She wouldn't send me to support!
February 21, 2007 5:52 PM
 

mjrobertson said:

great blog guys and thanks for the article.

I have been testing the tool in our labs without any problem.  I have a few questions though..  We have two exchange servers in Mexico that were previously set to central time.  After the new DST changes they will be moving to gaudajalara mexico city gmt -6:00.  When I run the tool against their servers it shows their time as "central standard", which is correct.  I understand that I can simply enter the new time in the mailboxes.txt file?  Is that correct?  If that’s the case what would I enter?  What is the correct syntax for the “gaudajalara mexico city gmt -6:00” time zone?  I understand that this would also be the case for the mailboxes that came back as nonexistent )I can copy the dn's from the nonexistent file into the mailboxes.txt file)?
Thanks!


February 21, 2007 6:38 PM
 

John said:

You have stated the version 2 will run much faster, from 3 MB per minutc  to 10 . I see that in the new tool the selection is now set to 0 seconds for profile creation delay
Is this what you are now recommending and is this is allowing the speed increase
February 22, 2007 12:46 AM
 

Rick said:

I noticed a couple of people asking about the error "failed to delete safe mode key  0x80070005".  I didn't see any response.  We are seeing the same error as we run the tool.  I'm just wondering if anyone found out what it means, and what needs to be done.  Thanks.
February 22, 2007 8:17 AM
 

Mark said:

I am a little confused, in your instructions you run this tool without having the "Extract Recurring Meeting Time Zones" unchecked (cleared). How do we update the users recurring meeting unless we check this box. If I have already run this tool once with the box unchecked, does it hurt if I rerun it with both boxes checked?

Also were do I find the Timezone Update tool V2?

Thanks
February 22, 2007 9:56 AM
 

Mark said:

Sorry had the question worded wrong.

I am a little confused, in your instructions you run this tool having the "Extract Recurring Meeting Time Zones" unchecked (cleared). How do we update the users recurring meeting unless we check this box. If I have already run this tool once with the box unchecked, does it hurt if I rerun it with both boxes checked?

Also were do I find the Timezone Update tool V2?

Thanks
February 22, 2007 10:06 AM
 

tjcarst said:

The old file had
PRFFile = C:\DST\daylight.prf

The new one has
ProfileName=Administrator

Do I specify PRFFile in the new file, using the old file format?  This is not documented very well.
February 22, 2007 10:13 AM
 

tony said:

just ran the tool and it works as posted. only thing, make sure your outlook is patched up using ms update.
February 22, 2007 10:29 AM
 

tjcarst said:

http://www.microsoft.com/downloads/details.aspx?familyid=A9336886-4B28-4010-9416-36D38429438D&displaylang=en
February 22, 2007 10:35 AM
 

tjcarst said:

http://www.microsoft.com/downloads/details.aspx?familyid=A9336886-4B28-4010-9416-36D38429438D&displaylang=en
February 22, 2007 10:35 AM
 

Ray said:

Hi,
I am having 2 separate problems.

I should probably mention our servers are still on 5.5 in case that makes a difference.

I downloaded and installed the first version of the exchange tool and have not been able to get it to update any single instance meetings. Basically all non-recurring meetings are being ignored. I have confirmed that I am not using the /onlyrecurring setting. I have also tried the /maxappts option. I have removed and re-installed the tool several times with no luck. Using TZMOVE by itself doesn't work on single instance meetings either. The recurring meetings are updated using either method. Is that locked in somewhere that I cannot find? Somewhere in the Registry perhaps?

So then I saw version 2 of the tool had been released. I tried that and now I cannot even get past the initial configuration screen. I get an error "Unable to retrieve the server distinguished name. The specified domain either does not exist or could not be contacted". I am using the same distringuished name as before! I uninstalled and tried the first version and that still works for the name so what can be the problem? I have removed/re-installed. I have also used LDAP to confirm I can actually contact the server from this workstation.

Any ideas or help are appreciated.
February 22, 2007 11:59 AM
 

Fred said:

The question still hasn't been answered as to whether or not cached mode users will have reminders off by an hour like OWA users.
February 22, 2007 12:51 PM
 

Karsten said:

Rick & tjcarst,
  We were receiving the same 0x80070002 error aswell. I reviewd my setup and saw that there was not Outlook profile created. After creating one for the user that has permissions to each mailbox, it worked.
This was in a test environment with the virtual machine setup.
Good luck.
February 22, 2007 12:57 PM
 

Carol said:

When I click on next after entering the server name I get an error  ''Unable to launch new process to execute MsExTmz.exe, Exception raised.  The system cannot find the file specified."  Any ideas???
February 22, 2007 1:32 PM
 

Chris said:

When I run the MSEXTMZCFG tool I get a screen that says: "The Exchange Calendar Update tool found user time zones that do not map to any Windows time zones.  Please specify the mapings."  Then it gives me a list of time zones with a selection box beside.  If I don't select anything my Conflictusers.txt file contains 3 people.  If I select time zones on this screen I get a few dozen users in the Conflictusers.txt.  After scanning the Mailboxes_1.txt I think it does a better job if I don't select anything on that screen.  What should I do?
February 22, 2007 1:35 PM
 

Chris said:

I was almost ready to run with the V1 tool now the V2 is available.  Is there any reason/advantage to running V2 over V1?
February 22, 2007 2:14 PM
 

Bill said:

Do we have to even run the Tool?  Or can we just have users delete calendar items that are in error and recreate them?
February 22, 2007 2:28 PM
 

Chris said:

The documentation for this is out of hand.  I was reading KB930879 ver 10.4 and it now says that you shouldn't install the 926666 patch until after you run the Exchange tool.  As I was reading it the doc was reved to ver 11!  Would it be too much to ask to have a revision history so you know what changed and don't have to keep re-reading everything?
February 22, 2007 3:19 PM
 

Ken said:

ON page 11 of article 930879 Revision 10.4. It states at the bottom of the page "What to do after you run the Exchange Tool" It states to install the following updates on the Exchange Servers

931836

and

926666

Everywhere else it states to run the updates on the servers and clients first.
Can you please explain this? Will this cause meetings and appointments to be incorrectly moved?
February 22, 2007 3:28 PM
 

tjcarst said:

Version 11.1 of KB


Known issues
• Updating the Exchange server before you run the Exchange tool

If you install the daylight saving time updates on the Exchange server before you update mailboxes, recurring meetings that are created by Outlook Web Access will not be updated by the Exchange tool. To resolve this problem, remove the daylight saving time update, run the Exchange tool, and then reinstall the daylight saving time update on the Exchange server.  

February 22, 2007 4:07 PM
 

tjcarst said:

I've already updated the server first, then ran the tool.  Looks like I"ll be doing it all again.  I am sure the original doc said to do it the way I did  This is so frustrating.
February 22, 2007 4:25 PM
 

Padraig said:

Anyone else getting the "HrProcessMailboxTable:Unable find mailbox timezone:Error 0x800004005" during time zone extraction process using MsExTmzCfg?? More than half of mine are coming up with it???
February 22, 2007 6:16 PM
 

Exchange said:

Padraig and others that had this error at that same stage:

"HrProcessMailboxTable: Unable find mailbox timezone:Error 0x800004005" during time zone extraction process is not a big deal, you do not have to worry about this much.

Simply add those users into mailboxes_1.txt, tab separated, in the format of "user <tab> server <tab> timezone". You can use Excel to make this easy (Excel is on the virtual machine that you can download from us with tools), hopefully most of your users are in the same timezone - then it becomes REALLY easy.
February 22, 2007 6:41 PM
 

The Donkey said:

When this process is complete, you will then see another prompt for information.  This is where you will need to tell the program where the ACTUAL TZMove.exe file and not the install package of the exact same name (Microsoft is dumb).  It is located here:



tzmove.exe (located in the \Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool\ folder.)

February 22, 2007 7:13 PM
 

Spider said:

I had some problems that others have mentioned.  May I suggest the blog video is welll worth 24 mintues to watch (http://msexchangeteam.com/archive/2007/02/21/435543.aspx). My basic problem was that when I ran the tool, only the first mailbox was getting updated.  Also, the screen filled up with multiple instances of Outlook.    I’m not sure what fixed the issue, but here is what I changed that worked:
1/ I had assumed that I had full access because I had given a security group I was a member of full access to the mailbox store.  I had no problem accessing everyone’s mailboxes from within Outlook. But just in case, I ran the script, as demonstrated in the video and KB930879, for the specific user account I was using.
2/ Instead of launching the tool’s batch file AFTER I had launched Outlook (as I had interpreted the instructions), I let the batch file launch Outlook.
3/ It probably didn’t matter, but I renamed the extend.dat file EXACTLY as described in the video… to extend.old.  Previously I had renamed it to something like extend-old.dat.

Some combination of the above got the tool to run successfully for me.  Your mileage may vary.
February 22, 2007 7:55 PM
 

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

Okay ... it's my fault. Really it is. I had this stupid idea that it would be really nice if the Trick
February 23, 2007 3:29 AM
 

Larry Heier said:

Hello,

I see MSKB 930879 now recommends applying the Windows OS and MSKB 926666 after running the rebase tool due to OWA issues with recurring meetings.  Since this is due to CDO, would the same apply for recurring meetings created in both Entourage and on Blackberry's/Good devices?

So if I am to read this now, is Microsoft now recommending:

1) Patch all clients and devices and all servers save Exchange systems and CDO related boxes.
2) Run Rebase tool (wait for version 3.0 that comes out next preferably which will fix resources too).
3) Patch Windows OS of Exchange systems
4) Apply MSKB 926666 on Exchange systems

Will the rebase tool eventually be able to understand and correctly move appointments that were setup before/after devices had their operating systems updated for DST?  Otherwise unless you patch all devices in an hour, appointments will be moved incorrectly.

Can you also detail the exact problems for people who unfortunately rain these tools early including V1 of the Exchange Calendar update tools.

Lastly it'll be nice if the Exchange/Outlook calendar tools could actually send an email updating each user after it scans detailing what it updates.

thanks for listening Exchange team,
Larry
February 23, 2007 6:24 AM
 

Larry Heier said:

Hello,

I see MSKB 930879 now recommends applying the Windows OS and MSKB 926666 after running the rebase tool due to OWA issues with recurring meetings.  Since this is due to CDO, would the same apply for recurring meetings created in both Entourage and on Blackberry's/Good devices?

So if I am to read this now, is Microsoft now recommending:

1) Patch all clients and devices and all servers save Exchange systems and CDO related boxes.
2) Run Rebase tool (wait for version 3.0 that comes out next preferably which will fix resources too).
3) Patch Windows OS of Exchange systems
4) Apply MSKB 926666 on Exchange systems

Will the rebase tool eventually be able to understand and correctly move appointments that were setup before/after devices had their operating systems updated for DST?  Otherwise unless you patch all devices in an hour, appointments will be moved incorrectly.

Can you also detail the exact problems for people who unfortunately rain these tools early including V1 of the Exchange Calendar update tools.

Lastly it'll be nice if the Exchange/Outlook calendar tools could actually send an email updating each user after it scans detailing what it updates.

thanks for listening Exchange team,
Larry
February 23, 2007 6:25 AM
 

John K said:

Hi
I really appreciate this blog, it gives me a much better understanding of what is happening.

We are ready to apply all the patches and update everybody's mailbox.
We ran the MsExTmz tool, we fixed any errors in the Mailboxes_1.txt file.

While running the tool, it could find all the users where in EST and said it didn't understand.  I selected GMT -5 and created the Mailboxes_1.txt file.

The Mailboxes_1.txt lists only Eastern Standard Time.  Is this correct?
/O=MS/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=John.Simit   MAILSERVER   Eastern Standard Time

I am going to try a couple of mailboxes, but I am confusion since the MSExTmz did not understand EST but it creates EST entries in the Mailboxes_1.txt file.

Thanks
February 23, 2007 7:24 AM
 

bummy said:

I'm sorry if this is a dumb question, but after I ran the MSEXTMZCFG (V2), my txt files with the mailboxes to update seem to be missing a character or 2 on certain people's mailbox names.  JSMITH, is listed as JSMIT, for example.  Is this right, or do I have problems with my files?
February 23, 2007 9:39 AM
 

Jesse James said:

There is going to be a v3 of the tool? I was gonna run this this weekend. I guess I should now wait? Where does it say there is going to be a v3 and what are the improvements?
February 23, 2007 9:56 AM
 

John said:

I'm getting this error on some of my users running  msextmz.exe is ver. 6.5.7899.0
Unable Open mailbox - 0x8004011C

most of the accounts are daily Outlook 2003 users, logging into the
domain daily
February 23, 2007 10:03 AM
 

boo dst said:

Jesse - by all means I would wait until next week (if possible) to perform this update. I think MS has underestimated the magnitude of this update and are very unprepared for the issues that will develop. I expect a v3 of the tool or a v2 of the Outlook tool within the week.
February 23, 2007 10:03 AM
 

Milan said:

I am in a similair scenario as some of the others here. We have already run V1 of the exchange tool with success but we were not impressed with the speed of the tool. Then with release of V2 were excited to hear that speed was doubled. I was setting up the lab this morning than I heard that V3 is in the pipeline. We have scheduled our DST upgrades for the weekend of March 2nd. Is there any clue that somebody here can give about the release date of Version 3 of Exchange Timezone Update Tool and Version 2 of the Outlook Timzeone Update tool?

Thanks!
February 23, 2007 12:33 PM
 

ninob said:

Milan and all,

I am not sure where the idea of the V3 of Exchange tool came from, I am not aware of that one... but the updated Outlook tool is slated to come out next week, should be early in the week.
February 23, 2007 1:10 PM
 

Milan said:

Well that goes to show the power of rumor! Thanks ninob. I will go ahead and test with V2.
February 23, 2007 1:25 PM
 

Lesley said:

I am on community chat with MS now.  And they said following:
Q: [50] There is some confusion as to whether there will be a v3 EXCHANGE tool released next week. Yes or no?

A: Yes, there will be an updated tool next week. It will address Resource Mailboxes with the Auto-Accept Agent, shared Public Folder Calendars. Reference: www.msexchangeteam.com/archive/2007/02/21/435543.aspx>
February 23, 2007 1:38 PM
 

JJay said:

Two years to prepare and we are having to deal with this...
February 23, 2007 3:15 PM
 

worg said:

I also get the following message just after starting the extraction in the msextmz.log file
HrProcessMailboxTable:Please log on to a profile with administrator privileges
followed by Unable find mailbox timezone:Error 0x80004005 for almost all mailboxes

I am running this as Domain admin, so is that profile for admin message just a standard message that pops regardless of what you log on as and can be safely ignored?
February 23, 2007 4:36 PM
 

DrStrangepork said:

really JJay.  People can bash open source software all they want, but Linux has had this fix in place for over a year now.  Microsoft didn't release  its fix until six weeks before the time change, and as if that wasn't bad enough, they're having to release a third version (at least) because the previous two releases fell short of requirements.

I respect Microsoft a lot, and I think in the big picture their products are very strong.  But this is the hokiest, most backward fix to a problem I have seen in a very long time.  Microsoft deserves to be flat out embarrassed by how poorly they have managed this entire process.
February 23, 2007 5:20 PM
 

Rob D. said:

Don't confuse Exchange tool with Outlook tool. The Exchange tool is at version 2, the Outlook tool is still version 1 (I think, it is tzmove.exe, dated 1/25/2007). The Outlook tool update will be released next week. You will need to update to the new version to fix resource mailboxes.
February 23, 2007 5:22 PM
 

Dan M said:

I have gone through the process without incident, thanks mainly to the video presentation on this same site. Take it slow and LISTEN carefully to the steps presented. There were several times that I got lost and was trying to perform actions on the Exchange server when they had shifted to the client machine or vice versa.
February 23, 2007 5:34 PM
 

Jared Shope said:

How can Microsoft PUSH kb931836 onto my users machines when it requires that I take a manual step (MSEXTMZ.EXE) to fix calendars?  Every day that goes by waiting for this program to work means that more and more appts have been entered after kb931836 and those will be broken by MSEXTMZ.EXE.  Thanks!
February 23, 2007 5:38 PM
 

Dennis C said:

Microsoft's Partner Webcast on 2/21 gave what seems to me to be much easier instructions for remediating the 2007 DST changes:
1) Apply MS O/S  Patch to Exchange Server (Exchange 2003 SP2)
2) Apply Windows XP O/S updates to Client Computers.
3) Apply Exchange CDO Patch (KB926666) to Exchange Server.
4) Run the Exchange Time Zone Update Tool against all affected users  and servers. (This was one of three options listed, but it suits my customer's environments.)
There was no mention of MSExTMZCFG.EXE, or creating Outlook profiles, etc. I admit I'm probably more confused about this stuff than anybody on the planet, so what am I missing here?
THANKS!!!
February 24, 2007 12:50 PM
 

Hollis said:

What if you missed the belatedly documented step about logging in with an account of administrative rights to all mailboxes, and instead only used an Outlook profile for the account with administrative rights?

Can I run the tool again under the different logon?  Or does that just mess things up more?

Thanks.
February 24, 2007 3:54 PM
 

Dean Chen said:

I ran MsExTmzCFG and generated the batch file. Then I ran a test account using the batch file, but couldn't get the log file for that user. what could be wrong? Why the log said "default timezone is not set?

HrReadConfiguration:Logfile opened as:msextmz.log
HrReadConfiguration:Reading Configuration.
HrReadConfiguration:Command Line:C:\Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool\TZMOVE.EXE /q
HrReadConfiguration:ServerDN:/O=Org_name/OU=Group_name/cn=Configuration/cn=Servers/cn=server_name
HrReadConfiguration:Output File is not set.
HrReadConfiguration:InputFile opened as:C:\MsExTmz\server_name\Mailboxes_1.txt
HrReadConfiguration:Error opened as:Errors.txt
HrReadConfiguration:Default Profile set to profile_name
HrReadConfiguration:Default Timezone is not set.
HrReadConfiguration:Searching Calendar for Timezone Information.
HrReadConfiguration:Per-Mailbox time limit:15 minutes.
HrReadConfiguration:Log Directory set to:C:\MsExTmz\server_name\
HrProcessInputFile:Processing Mailbox:/O=Org_name/OU=Group_name/CN=RECIPIENTS/CN=user_name
HrProcessMailbox:Timezone set to PACIFIC STANDARD TIME.
HrSpawnOLTool:Spawned worker process as pid - 2728.
HrSaveOutlookLogFile:Saved Log set to C:\MsExTmz\server_name\MSExTmz-user_name-0x00A1EB5A.LOG.
HrSaveOutlookLogFile:No log file was written for user.
February 24, 2007 4:33 PM
 

Active Directory Tool » Step by step run of the Exchange Calendar Update Configuration … said:

PingBack from http://activedirectorytool.com/step-by-step-run-of-the-exchange-calendar-update-configuration/
February 25, 2007 1:53 AM
 

Max said:

Dennis C.

I know exactly how you feel.  I have been working on this for 2 weeks in test lab and never got it to work.  But with some limited testing in production got it working.  No offense to the Microsoft support a lot of them have no knowledge of DST.  They have daily meeting and get some much information dumped on them nothing is sinking in and the information is changing daily.  The video demos to me are the best.  The link is below and towards the middle of the page.  
The patches are the simple part.  The procedure for DST and updating the calendars is the pain in the butt.   I can only tell you what I will be running in the next few days.
I am not going to talk about the patches those are the simple steps.  The only thing with those are do you install the CDO patch (KB92666) before or after the rebook procedure and I still have not figured out which is best.  I probably going after since it brings down the mailstores.  I am also staying away from Version II of the Exchange update tool, that testing did not go well.  I only have 5,000 Exchange 2003 users and 1,500 Exchange 2000 so the memory leak should not be an issue.  Plus it is confusing.  I also downloaded the Virtual server Microsoft created and that was a big help.  It has everything installed that is needed.  
The main issue I ran into was running the permission script which is a must.  The script does something that allows you to create these temporary profiles.  Not that is allows you to, it gives the permission needed.   Also the thing Microsoft has not motioned anywhere that I found is that if I scheduled a recurring meeting and run the rebook procedure it sends everyone in the meeting a new update for their calendars and the appointment must accepted to have the correct time.  Overall when you watch the video it gives a good representative of what to expect if nothing goes wrong.   The problem is what do you do is something does go wrong.  There are no links via Google or anything for help.  A lot of hours in the test lab got me familiar with applications and even then I did not get it to run.  
Good Luck…
http://msexchangeteam.com
February 25, 2007 3:36 PM
 

bummy said:

After I run the update on a small group of users, there is no log file created for each user.....doesn that mean things went successfully?    MY error log is empty, but I don't have anything that tells me it was successful.
February 26, 2007 11:37 AM
 

Milan said:

Any news on the release of the Outlook Timezone Update tool V2?
February 26, 2007 11:54 AM
 

Milan said:

We have set the weekend of March 2nd for the exchange portion to run. We have 4 exchange 2000 servers with about 1200 users on each. We have earmarked 1 pc per exchange server to run the process. We have conducted previous test with success (Exchange tool V1) but we are going to run one more test today using Exchange V2. Hopefully the Outlook tool V2 will come out before end of today.
February 26, 2007 12:39 PM
 

President Carter said:

Is there an estimate as to 'when' the new Outlook tool will be coming out?  We ran the updates this weekend, and are having NO luck getting resource accounts or Public Folders to update.  I've run the grant permissions script against all resource accounts, but cannot get those to update.  Every public folder I run the Outlook tool against tells me there are no items to be updated.  We have unchecked the "auto decline conflicting meetings" on all 300+ resource accounts..

I'm not sure what the ramifications will be, now that all users are patched, and the servers are patched... So until I'm able to rebase, all appointments created during the delta will be offset when I DO run the rebase.  ALSO, Does the new Outlook tool v2 still require me to have "auto decline" checked?  It currently remains unchecked across the domain, so users are able to book overlapping meetings.

Let's just say my boss is unhappy with the results thus far...
February 26, 2007 1:02 PM
 

Chris said:

Do we need to apply the KB926666 patch only to Exchange server in the US or does it need to be applied to all Exchange servers in the Org even if they are overseas?
February 26, 2007 1:53 PM
 

Colin said:

We are find that there are a high percentage of our user mailboxes ending up in the NonExistent.txt file.  Additionally, we have found that the time zone extraction is taking a very long time - 11 hours for some servers.

We are considering creating a script to extract the Legacy Exchange DN, Exchange Server and Time Zone from Active Directory.  We would use our location fields from Active Directory to map to the appropriate Time Zone and would still create a seperate file per server.  

This process would also make it easier to strip out our inactive/disabled users and would be much faster than performing the extracts.

Are we missing anything that would result in this method of extraction causing us problems?

February 26, 2007 2:37 PM
 

President Carter said:

We've also realized that a huge percentage (close to 50%) of our users are showing up in the NonExistent.txt file.  I'm not sure precisely what this means, and I'm not sure what action I should be taking on these THOUSANDS of users.
February 26, 2007 3:03 PM
 

Ben L. said:

I applied E2003SP2 and 926666 this weekend, and tried to run the Exchange Calendar Update Tool version 2 against our mailboxes, and while some of them updated, others didn't - and for the same shared meeting request. I've confirmed the client operating systems have all been updated for DST, and the Outlook versions are the same... any idea why a single exchange server with a single common meeting request would appear differently on two client machines both updated for DST? All in the same timezone? When both attendees accepted the updated request?

My confidence in this tool, based on my personal experience and the postings here, is almost non-existent.
February 26, 2007 3:19 PM
 

CJ said:

Can the exchange team or someone provide instructions for the VM?  I assume, it does not require running the msextmzcfg.exe.  Also - Does anyone have an example of an input file?  I want to create one just to test the update funtion of the msextmz.exe tool against a specific set of users. Thanks. Dazed and Confused.
February 26, 2007 4:45 PM
 

Scott said:

After following these guidlelines, I believe I have successfully patched our first of many clients.  My concern is, won't we have to run the patch against every new AD and e-mail box that we create, or will copying from a template of a patched user suffice?  
February 26, 2007 5:07 PM
 

Exchange said:

The hotfix for the Outlook tool is now available. Please see the following KB article:

http://support.microsoft.com/kb/933146

Please note that the original Outlook tool has to be installed before the hotfix is applied. The article contains information about new switches available in the tool. This IS what has been called a "V2" of Outlook tool, but it is not a new standalone version but is rather a hotfix for the original tool.
February 26, 2007 6:33 PM
 

Xerxes said:

James, I got the same error.  I finally decided that I was using the wrong LegacyExchangeDN.  Error 0x80070057 is the error I got.

Here is the document I used to get the correct ExchangeLegacyDN

http://support.microsoft.com/kb/301585

LDIFDE -F E:\LEGACY.LDF -D "DC=HEADQUARTERS,DC=MYCOMPANY,DC=COM" -R "(LEGACYEXCHANGEDN=*)" allowed me to get the exact LegacyExchangeDN and it worked.

Hope this saved some hair for you.
February 26, 2007 6:48 PM
 

Xerxes said:

http://support.microsoft.com/kb/930879/en-us actually works, it's the new version of the MsExTmzCfg.exe found here.
February 26, 2007 7:18 PM
 

TM said:

What is the best way to install both the TZupdate tool and hotfix and run the Tzupdate with the hotfix?  By default when I click on the update it launches tzupdate tool.  Should I just cancel, then run the update, then relaunch the tzupdate?
February 27, 2007 7:24 AM
 

jjexchange said:

We were able to run the tool in our production environment this past weekend, and thought some of you might benefit from what we experienced.

Firstly, during the extract, we also ran into many users showing as non-existent.  To rectify, we confirmed the time zones for each user (luckily, most of our users are in the Eastern Time Zone), then added them to the Mailboxes_x.txt with the correct time zone designations.

We have just over 1000 users, so we split the jobs up to run on 3 seperate servers with the tools installed.  2 servers were running version 2 of the Exchange tool, one ran the original (I found issues uninstalling the original on this server; instead, I kept the original).  The TZMove was also the original release.  Each server carried between 320-350 users.

When we ran, the V2 tool was finished in about 1-1/2 hours, while the original took over 2 hours.  However, it did manage to only error on 21 users, most of which were service accounts.

We did testing and had users on conferrnce calls over the weekend and on the Monday following.  All in all, we had a successfull run

Hope this helps
February 27, 2007 8:11 AM
 

Chris said:

FYI, we've found a couple of bugs in version 1 of the update tool.

First, it changes events in all years, not just from 2007 on.  For March 2006 my calendar shows events like "doctor at 9:30" starting at 10:00.  That's really bad if you're tracking things in your calendar.

Second, all-day events on March 11 don't seem to be getting corrected.
February 27, 2007 10:40 AM
 

Chris said:

Correction to my last post:  It's not that the update tool changed items before 2007, it's that it DIDN'T change them.  Therefore the Windows patch is skewing the times on those older items.
February 27, 2007 11:43 AM
 

Andrew said:

"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."

What if I get this for all 1300 mailboxes?!  I'm the only Exchange Admin and I certainly don't have the time to open each mailbox in OWA!
February 27, 2007 1:13 PM
 

Exchange said:

Andrew,

As mentioned above in comments (I know it is getting kind of hard to follow):

"Error 0x800004005" during time zone extraction process is not a big deal, you do not have to worry about this much.

Simply add those users into mailboxes_1.txt, tab separated, in the format of "user <tab> server <tab> timezone". You can use Excel to make this easy (Excel is on the virtual machine that you can download from us with tools), hopefully most of your users are in the same timezone - then it becomes REALLY easy
February 27, 2007 2:04 PM
 

Mike R. said:

Someone mentioned the error "Unable to process mailbox ..... 0x80004005" errors encountered when running the batch file
created by the MsExtTmz.exe app and they cleared it by changing their event log settings, somehow they were getting full.
This also worked for me, not sure why? but Kudos!
BTW, this is a great blog but SLOW..Maybe the comments can be moved to a different page?
February 27, 2007 5:26 PM
 

ninob said:

Mike R,

Yes, there are performance issues with this page... we never saw it before as we never had a post with this many comments... however, it seems to be IE 7 specific. IE 6 and err... some other browsers do not have this problem. I am still going to open a bug against IE 7 for this though. :)
February 27, 2007 5:50 PM
 

Colin said:

Has anyone been able to get the tools to work on an exchange 5.5 on an NT4 domain environment.  I am not able to get the cfg.exe part of the tool accept the server name
February 27, 2007 7:23 PM
 

Andrew said:

Did I miss something?  I didn't realize that meetings were going to be resent to attendees while this tool was running.  I killed the tool because our help desk was inundated with calls from panicking users.
February 27, 2007 9:03 PM
 

Scott said:

Well, second customer.  LegacyexchangeDN confirmed through ADSI and the trick posted by Xerxes, yet the tool will not accept it and says the server is not operational.  The only way to get it to do anything is FQDN, which provokes the "Error 0x800004005" during time zone extraction process, which, according to the admin; "is not a big deal, you do not have to worry about this much."  Even after moving non-existsant users to the batch file, I will not run the update just yet since Public Folders are rule with this customer and V3 is supposed to address this.  Any word?
February 27, 2007 9:12 PM
 

Allan said:

Colin,

I too am in an NT4 Domain/Exchange 5.5 environment and also road blocked. Using the newest MSEXTMZCFG.exe tool. I tried using exchange admin in raw mode and messed around with the DN properties and adding to the server name line in the tool. But no dice. I keep reading that it should take Net BIOS as well but I am also not having any luck on that. Lame...
February 28, 2007 12:36 AM
 

Exchange Monkey said:

It's also worth noting that version 2 of the Calendar just requires you to put the FQDN of the Exchange server. Just wasted an hour trying to figure out why it kept saying 'Invalid Server'.
February 28, 2007 9:58 AM
 

baker said:

V3 of the update tool?  Is this for real or just a rumor?
February 28, 2007 10:28 AM
 

Milan said:

Baker,

I think it's a rumor. V2 of the tool is a big improvement over the V1
February 28, 2007 10:38 AM
 

Chuck said:

I ran into big problems with the calendar update tool I kept getting the error "cannot process mailbox". I worked with MS support and resolved it. The steps I took are outlined here; http://www.arconi.com/DST_Update.html
February 28, 2007 12:32 PM
 

kikoplavdd said:

We're in the Pacific and Arizona time zones. When I run the tool against my AZ server, it shows that I can update for Pacific and Arizona time zones. Should I only choose to update for the time zone the server is located at?

Also, looking at the generated mailboxes_1.txt file, I see some Arizona users, but show that they are in the Pacific Time Zone. Should I correct these?
February 28, 2007 4:55 PM
 

TimDoug68 said:

I am getting the following error, right after the initial screen after I hit next and it does its extraction... Any ideads??

HrProcessMailboxTable:Please log on to a profile with administrator privileges.
HrProcessMailboxTable:Unable open mailbox table for server /O=xxxx xxxxxxxx/OU=FLLNET1/cn=Configuration/cn=Servers/cn=FLLNET.  Error 0x80070005.
February 28, 2007 7:20 PM
 

ghc1973 said:

I am getting the following errors on the majority of our mailboxes when running the Exchange Calendar update tool in extraction mode:

HrProcessMailboxTable:Processing mailbox /O=BSHSI/OU=EDC FRONT-END/CN=RECIPIENTS/CN=CAKEYMON.
HrFindCDOTimezone:Warning:CDO Session timezone exceeds known index - Ignoring.
HrProcessMailboxTable:Unable find mailbox timezone:Error 0x80004005.

Any ideas?
March 1, 2007 9:10 AM
 

Brian said:

Hi everyone,

I'm trying to update our Outlook tool to V2 and every time I run it it says "the installation of this packaged failed", and that's it.  I even tried it on a clean XP system with .Net and outlook 2003 and V1 of the tool.  Any suggestions?

Thank you,

Brian
March 1, 2007 12:37 PM
 

Jane said:

Hi Brian,  I had similar problem.  For me installing MS installer (msiexec) version 3.1 fixed the problem with failed hotfix install.
March 1, 2007 1:16 PM
 

Brian said:

Jane,

That did it.  Genius!  Thank you for sharing that helpful piece of information.

Brian
March 1, 2007 1:36 PM
 

Mark said:

I am trying to use v2 to export the user information, but it is failing to find the server.  Server is exchange 5.5.  I read that v1 worked for this.   Anybody have a link to a downloadable copy of v1 so I can try that?   Thanks..  - Mark
March 1, 2007 2:20 PM
 

Edward Conde said:

I am running the virtual image that was offered on the support site. I was able to gather mailbox information from 2 of my 3 exchange servers. The third keeps giving me this error: Unable log onto mailbox:Error 0x8004050. I am using the same account (Admin) as I did on the other exchange servers. What could be going on? Doesn't make any sense that it runs on 2 but not the last one??

Thanks!
March 1, 2007 3:28 PM
 

Daylight Savings Time adjustments — Can Microsoft make this any harder « David Strom’s Web Informant said:

PingBack from http://strom.wordpress.com/2007/03/01/daylight-savings-time-adjustments-can-microsoft-make-this-any-harder/
March 1, 2007 4:07 PM
 

C. Frank Bernard said:

In an NT4 domain environment with a single Exchange 5.5 server (servicing users in a single Time Zone), when I start MsExTmzCfg and specify the netbios name of the Exchange 5.5 server (which successfully pings to its internal/private IP address) and click Next, I get: "Unable to retrieve the server distinguished name. The specified domain either does not exist or could not be contacted."  So if I specify the server's FQDN and click Next, I get: "Unable to retrieve the server distinguished name. The server is not operational."  So I too want to know either how to get V1 or if I should wait for V3.
March 1, 2007 4:15 PM
 

Nick Waringa said:

I have a few comments. This was a very informative article, it helped immensely in preparing my company for this. However I ran into 2 issues, I am sure everyone else has experienced:

1) Appointment notification storms get bounced to all my users when I perform the rebase.

2) My users have no idea what was changed and what should stay appropriate etc....

A couple suggestions for those that may run this.....

1) Expect a lot of appointment notifications being bounced to your users, make them aware of this before you run it! This may also cause space issues for those with extremely tight quotas and large mailboxes.

2) I may look into writing a script that sends my users a copy of the transactions logs that are spit out for each one of them. This will help users to identify the changes made to their calendars. This could probably be accomplished easily through a vbscript. anyone tried yet?

-Nick
March 1, 2007 5:18 PM
 

Kryten said:

Some of our users are getting a lot of cancellation notices.  Some "swear" that appointments are disappearing off of the Executive's calendars.  I'm assuming that if an appointment has already been canceled, it will send another notice.  Anyone else seeing this?  One assistant has seen over 150 notices (both cancellations and appointments), and she is freaking out.  
March 1, 2007 7:19 PM
 

Sivrais said:

Tests that I have run using v2 on regular-user AD accounts are changing "all day events" to multi-day events that are not checked as all day events...  Anyone see this kind of behavior?  Exchange 2K3-AD
March 1, 2007 9:56 PM
 

Kevin said:

I've experienced similar issues like that as well.  I started updating the XP clients last week with KB931836, which updates the workstation Daylight Savings Time start and end dates.  I’ve found in my testing that appointments that were already in exchange before the client was patched were one hour off, whereas appointments posted after the client patch are at the correct time.  Now when I run the tool the pre-patched appointments are right and the post-patch appointments are off.  

Also found that all day events that normally go from 12:00 to 12:00 can display from 11:00 to 11:00 making them look like multi-day events.  

Probably would have been best to patch everything all at once instead of over a few days.  What a mess. . .
March 2, 2007 9:11 AM
 

President Carter said:

Wow... After using the same workstation to fix all of our remote sites... I was getting "unable to process mailbox" 0x80004005 on anything I tried.  It was the event log being full.  The default "overwrite events older than 7 days" just needed to be changed to Overwrite as needed (and drastically increased from 512k).  I hope this helps someone else... it was a lovely use of 3-4 hours of my time...
March 2, 2007 9:41 AM
 

President Carter said:

I like how 0x80004005 means anything from "I can't find timezone data on this user" to "you're using the wrong tzmove.exe" to "your event log is full dummy"
March 2, 2007 9:43 AM
 

Scott said:

Kevin:

I experienced the same thing.  In fact, I'm experiencing odd results across the board with no clear explanation.  As a test, I updated my local patch to 931836, without the Outlook patch.  I also created a post-patch test calendar entry for 9:00am, March 13th.  I set the system clock ahead to roll over to the new DST successfully.  I then opened Outlook.  My test appointment was still 9:00am (as I set it in the post-931836 world), but my other 8am PRE-patch calendar items were all at 9:00am now when they were previously set to 8:00am.  Okay, fine.  I'll just run the Outlook Update tool and those should be fixed.  Right?  Wrong.  After running the patch, it did NOT rollback my pre-931836 8:00am dates to the right time.  Those stayed at 9:00am.  What DID happen was my test post-931836 9:00am March 13th calendar item rolled back an hour to 8:00am.

This is not good.
March 2, 2007 11:22 AM
 

Kevin said:

Scott:

That is strange.  I’ve also an issue similar to what you described.  In my case, the few people I couldn’t get fixed in my test environment had both the initial XP patch KB928388 as well as KB931836.  I tried uninstalling both and just applying the most recent patch (KB931836). Unfortunately this changed some appointments from being what I thought was correct to being one hour off.  I finally just manually moved the appointment, since it wasn’t reoccurring it didn’t give me issues. Not sure if it was just and isolated incident or something bigger.
March 2, 2007 11:50 AM
 

Scott said:

I have the answer!  If someone sent you a calendar item and their Inbox has NOT been patched with the Exchange or Outlook tool, then IT WILL be off an hour even if your Inbox and machine is patched.  Once you patch that sender's Inbox and you accept the resulting moified meeting or calendar item, then those items WILL get adjusted properly.

Patching your Inbox only affects calendar items YOU made, not what others made for you or on your behalf.

Hope this helps.
March 2, 2007 12:11 PM
 

Reese MCSE said:

Here's the problem. If a user from Pacific Standard Time (PST) has a calander item during the extendended DST period from accepting a meeting request from a user in Eastern Standard Time (EST), even after updating the OS's with the DST patch and then running theExchange calander update tool, the items aren't updated.

Anybody seen this or have a fix. Much appreciated..
March 2, 2007 9:34 PM
 

Milan said:

I ran the rebasing tool in production last night. Four exchange 2000 servers with 2 PC for each server with about 1200 mailboxes on each. Took about 2 1/2 hours with minimal errors. We thought it would run four 5 hours but we overestimated the amount of appointments in the delta period for the enterprise.
March 3, 2007 7:27 PM
 

cimama said:

We have applied all patches in the correct order, and everthing looked good at first. However now we have noticed that invitees to recurring appointments see the appointment differently, and that individual users see the appointment differently depending on if they view the appointment via Outlook, OWA, or their Blackberry.

Here is an example for a recurring appointment:
Organizer (desktop and calendar patched): sees appointment correctly from Outlook, OWA, and Blackberry
Attendee #1 (desktop and calendar patched): sees appointment 1-hr late in Outlook, 1-hr late in OWA, and correct from Blackberry
Attendee #2 (desktop and calendar patched): sees appointment correctly in Outlook, 1-hr late in OWA, and correct from Blackberry

To resolve the issue, all a user needs to do is open the series in Outlook and go to Actions - Recurrence. (There the appointment shows correctly! In other words, even though Outlook shows it as 3-4pm, opening the appointment lists it as 2-3pm.) Click OK on the Recurrence info, then re-save the appointment. Everything now appears fine, even though the user made no changes to the appointment. All the user has done is open the recurrence window and click OK.

Any help or advice would be greatly appreciated.
March 4, 2007 11:28 AM
 

Slow! said:

Are you folks aware of how poor the load times are for this freakin' webpage?!?!?!?!?!?
March 4, 2007 6:09 PM
 

ninob said:

Slow!,

We are aware of it... it is actually a IE 7 issue (I am guessing this is what you are using as that is the only way I reproduced this problem). If you use any other browser (including IE 6) - you will not have this problem. I have filed a bug with IE on this.
March 4, 2007 6:20 PM
 

Milan said:

Everything went well but one problem. Overlapping appointments were not updated. What is the procedure to repair this scenario?
March 5, 2007 9:56 AM
 

Andrew said:

I ran the calendar update tool, but I'm getting 0x8100270D errors.  Anybody have any ideas?
March 5, 2007 10:18 AM
 

Milan said:

Thanks exchange team for all your help. Without this blog this DST exercise would of been a nightmare.
March 5, 2007 10:41 AM
 

Dalmatinac said:

A question about 92666 and Exchange 2003 Message Tracking.  We noticed recently that in the Exchange 2003 Message Tracking logs that the time stamps are one hour later than the time the server processed the message.
March 5, 2007 11:15 AM
 

Dalmatinac said:

A question re the DST updates and Exchange 2003 Message Tracking.

We noticed recently in our Exchange 2003 message tracking logs that all messages transiting the server are being logged 1 hour later than the system actually processed them. (i.e. the message is logged immediately, the time stamp is one hour later).  We noted this behaviour on an Exchange 2003 SP2 server that has both 926666 & 931836 applied and another Exchange 2003 SP2 server that only has the older 928388 hotfix applied as of right now.

Anyone else seeing this ?


Sam Tudorov
March 5, 2007 11:28 AM
 

Dalmatinac said:

A question re the DST updates and Exchange 2003 Message Tracking.

We noticed recently in our Exchange 2003 message tracking logs that all messages transiting the server are being logged 1 hour later than the system actually processed them. (i.e. the message is logged immediately, the time stamp is one hour later).  We noted this behaviour on an Exchange 2003 SP2 server that has both 926666 & 931836 applied and another Exchange 2003 SP2 server that only has the older 928388 hotfix applied as of right now.

Anyone else seeing this ?


Sam Tudorov
March 5, 2007 11:28 AM
 

Dalmatinac said:

(correction to last post)

A question re the DST updates and Exchange 2003 Message Tracking.

We noticed recently in our Exchange 2003 message tracking logs that all messages transiting the server are being logged 1 hour later than the system actually processed them. (i.e. the message is logged immediately, the time stamp is one hour later).  We noted this behaviour on an Exchange 2003 SP2 server that has both 926666 & 931836 applied and another Exchange 2003 SP2 server that only has the older 928388 hotfix applied as of right now.

Anyone else seeing this ?


Sam Tudorov
March 5, 2007 11:31 AM
 

Ben Winzenz said:

Milan,

I haven't seen that specifically.  Could you provide more details on the specifics of the overlapping items?  Were they appointments, meetings, or recurring meetings?  Created before or after the OS of the workstation was patched with 931836?
March 5, 2007 12:29 PM
 

Ben Winzenz said:

Reese MCSE,

The user in PST needs to accept the updated meeting request from the Organizer in order for the meeting to be updated on their calendar.  Until they do that, it will appear incorrectly.  There is no fix because this is expected behavior. Have the user in PST check their inbox (or deleted items?) for an updated meeting request from the other user in EST.
March 5, 2007 12:32 PM
 

TenBrink Tech said:

Yep, I know, there's probably a nice PowerShell way to do this. But I was looking for quick and I know...
March 5, 2007 1:42 PM
 

DDoorlag said:

I can confirm the message tracking logs on my system (with 926666 & 931836 applied) are exhibiting the same behavior - messages show as 1 hour later than the time the system actually processed them.
March 5, 2007 1:53 PM
 

Chuck said:

This page is crazy slow and I'm using IE 6.0
March 5, 2007 2:39 PM
 

Matt said:

Funny... I actually went and installed FireFox to view this Microsoft page.
March 5, 2007 2:45 PM
 

going_nuts said:

If I updated windows on friday, and a user created a meeting on sunday for march 14th at 12:00pm, and I ran the msextmz update today, will that meeting appear incorrectly as being set for 11:00 AM?  Does this get adjusted when DST actually happens?
March 5, 2007 3:15 PM
 

Craig said:

What is the best method to deal with the mailboxes that show up in the conflict file?  The users with multiple time zones?  How can I set a default time zone for those users?
March 5, 2007 3:21 PM
 

Kevin said:

I just updated our environment exchange 2003/outlook 2003 environment this weekend.  Here’s some things to look out for.  

Some appointments that were initially correct before the debase changed to being incorrect afterwards.  Two big things to check to resolve this issue: check for xp patch (kb931836) and ‘refresh’ the time zone.  For some reason or another, if I went in and unchecked the box at “Tools, Options, Calendar Options, Time Zone” in outlook, closed out of outlook and then went back and checked it again once I logged back in, it resolved most of my issues.  Not sure if it’ll work everywhere, so take it for what its worth.

We also had issues with reoccurring appointments that were not kicking off emails from the meeting organizer, even though it fixed it on their calendar.  After the organizer sent an update manually, the appointment was fixed.
March 5, 2007 4:04 PM
 

Ben Winzenz said:

going nuts,

The answer is that it depends on what kind of meeting you create.  If it is a recurring meeting, then no, it will not be updated.  If it is a single instance meeting or appointment, then yes, it would be incorrectly updated and set for 11:00am.  The reason is that recurring meetings have time zone information stamped on them, whereas single instance items do not have any time zone.  When the time zone update tools run against single instance items, it must treat them ALL as suspect even though some may have been created using the correct time zone information.
March 5, 2007 6:16 PM
 

Ben Winzenz said:

Criag,

You can manually place users from the conflict.txt file into the mailboxes_1.txt file.  You would then need to manually specify the server and the time zone that you want to use for those users and make sure each section is tab-delimited.
March 5, 2007 6:17 PM
 

Kryten said:

Make sure you check your user's timezone.  We had one user that was set to Tijuana instead of Pacific.  Her calendar was wrong, and she kept sending out meeting changes, so hers was correct while everyone else was incorrect.
March 5, 2007 6:40 PM
 

Absoblogginlutely said:

We received an email from Verizon to inform us that the Monitorsync software that synchronizes Exchange with Verizon's web service (and then cellphones) also needs a patch for daylight savings time. Great timing with less than a week to go!...
March 5, 2007 8:44 PM
 

Daylight Saving Time - Technical Chats said:

Q: I would like to run the FORCEREBASESUPPRESSALLUPDATES switch for a bulk set of mailboxes. I'm having
March 6, 2007 3:21 AM
 

bummy said:

I'm hoping someone here can answer this question since I'm getting conflicting answers from MS.

Do you need to run a calendar update of any flavor if you are running Exchange 2007?
March 6, 2007 10:06 AM
 

Microsoft Higher Education Tech NE said:

Here's some updates for DST. I also have access to premier support information if you have questions
March 6, 2007 4:52 PM
 

Cevans said:

I am getting a load of 0x80004005 when running the exchange tool with the /FORCEREBASESUPPRESSALLUPDATES switch.  If I take the switch out it works.  How can I suppress the updates?
March 6, 2007 5:30 PM
 

ninob said:

bummy,

It depends on which client you use... please see this:

http://support.microsoft.com/gp/cp_dst
March 6, 2007 8:10 PM
 

Status said:

So you've probably heard about the upcoming changes to the effective dates of Daylight Savings Time (if not, you're going to be late for work on Monday).  If you deal with IT at all, you've probably also heard all the comparisons between this and the
March 7, 2007 10:03 AM
 

Brucem said:

I ran v2 of the Exchange tool , and it took 1.5 hours to process 1000 mailboxes.  Just over half of he mailboxes had no items to change (as reported by the event log).  So far I've had one report of a wierd problem.  His output file looked like:

[Original Time Zone]
(GMT-03:30) Newfoundland

[New Time Zone]
(GMT-03:30) Newfoundland (Update)

[Time Zone Update Log]
Type: Meeting
ID: 040000008200e00074c5b7101a82e00800000000e0f0a147315fc701000000000000000010000000c5cc3ada0028de45b98fda467a2d4328
Subject: Single email
Old Start Time: Monday, March 12, 2007 12:00:00 PM
New Start Time: Monday, March 12, 2007 11:00:00 AM
Old End Time: Monday, March 12, 2007 1:00:00 PM
New End Time: Monday, March 12, 2007 12:00:00 PM
Recurring: No
Result: Success

The actual original start time for this appointment (in his calendar) was 9:30 a.m. and after the tool ran was switched to 8:30 a.m and an update was automatically sent out to all attendees.  The reason he found out about the problem was that people emailed him saying they couldn't made the 8:30 a.m meeting.  This completly contradicts the info in the output file.  He only had two changes made to his calendar (only one is shown here).  Anyone experience a similar problem?
March 7, 2007 10:11 AM
 

Scott said:

I am receiving this error, any help would be greatly appreciated:

HrProcessInputFile:Processing Mailbox:/O=REMOVED/OU=FIDELITY/CN=RECIPIENTS/CN=SLL
HrProcessMailbox:Timezone set to EASTERN STANDARD TIME.
HrSpawnOLTool:Spawned worker process as pid - 3428.
HrScanEventLogForSuccess:Success Event not found in Application log, treating as failure.
HrProcessMailbox:Unable to process mailbox /O=REMOVED/OU=FIDELITY/CN=RECIPIENTS/CN=SLL - 0x80004005
HrProcessInputFile:Error Processing Mailbox:/O=REMOVED/OU=FIDELITY/CN=RECIPIENTS/CN=SLL - 0x80004005

1. I am using ver. 2 of the tool.

2. Could the EvenLogforSuccess becausing an issue?

3. On the KB article it says that the Legacy DN could be incorrect, but the file set that itself when I entered the simple server name (EXCHANGE2003)

Thank you in advance
March 7, 2007 11:33 AM
 

Scott said:

I found this on Google, but I do not quite understand step 2 -- if anyone could help with that:

"OK to resolve this issue of the error 0x8004011d follow these steps.

1. Dont use a pre-exsisting admin account, create a new one and put it
on the
exchange server and the computer you are using to do the update. You
will also have to add them as a local admin user on the exchange
computer and the computer you are doing the update on.
2. Once this is completed, goto Exchange system manager and add the
user you created on the local computer and the domain user to have
full access(everything!) to the store.
3. as soon as you do this, you may have to wait sometime for the
changes to be made depending on the size of the db.
4. once you have this setup, go the computer you are running the
update from and log into it as the user you just created on the
domain.
5. Now add the mail account for the user you created. You can
do this from the control panel. You will run the update with this
account.
6. once this user is created run a test with about 5 users in the
Mailboxes_1.txt so you dont have to wait so long for it to error out.
7. If you did this correctly your error will go away and the
mailboxes
will be updated.

You can use ADSI or system manager to setup the permissions on the
store. I used ADSI.

KC"
March 7, 2007 4:31 PM
 

Derek said:

I have just run the tool against my Exchange server in reporting mode. About 10-15 percent of the accounts are suuccessful. Most return this error but I haven't found anything on it yet...

HrProcessMailboxTable:Unable log onto user mailbox:Error 0x80040305.
March 7, 2007 5:52 PM
 

ninob said:

Derek,

Please see up there, search for "Exchange said:", there is a reply on what to do with those.
March 7, 2007 5:55 PM
 

Daylight Saving Time - Technical Chats said:

Q: I would like to run the FORCEREBASESUPPRESSALLUPDATES switch for a bulk set of mailboxes. I'm having
March 7, 2007 6:09 PM
 

Dalmatinac said:

A question for Microsoft re the DST updates and Exchange 2003 Message Tracking:

We noticed recently in our Exchange 2003 message tracking logs that all messages transiting the server are being logged 1 hour later than the system actually processed them. (i.e. the message is logged immediately, the time stamp is one hour later).  We noted this behaviour on multiple Exchange 2003 SP2 servers that have both 926666 & 931836 applied. The same issue was also noted by another contributor in this blog.

Microsoft ?


Sam Tudorov
March 7, 2007 7:32 PM
 

ninob said:

Dalamtinac,

Please see this: http://blogs.technet.com/dst2007/archive/2007/03/07/exchange-2003-message-tracking-off-by-one-hour.aspx

Short version: this is a ESM display problem rather than the actual message tracking log issue.
March 7, 2007 7:38 PM
 

Exchange said:

Scott,

I am thinking (not 100% sure though) that #2 that you mention means that you need to create an account (or use an account) that has rights to log on to all mailboxes.

We have a KB article out there how to create an account to run Exmerge, that'll do just fine. You do not have to give that account too many rights, that step #2 would have you give a bit too much so it seems...
March 7, 2007 7:41 PM
 

Someone Crazy said:

i'm getting the 'HrProcessInputFile:Error Processing Mailbox:' '0x80004005' error message when i use the 'FORCEREBASESUPPRESSALLUPDATES' switch, on an account that does have full access to all objects in exchange (tested it with multiple mailboxes' however it seems to run without that switch (basically doesn't complain) ..

any ideas on what may be causing that.. i see some people have posted that error message with some suggestions stating that it is the wrong TZmove.exe but the file that i have is '12.0.4518.1029' and is the only one i'm able to find.. i'm able to run it without any problems per mailbox but i have quite a bit of mailboxes to run on... any suggestions would be helpfull..

regards,
March 7, 2007 7:47 PM
 

Bill Smith said:

I got one of these the other day, it works

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&ih=019&sspagename=STRK%3AMEWA%3AIT&viewitem=&item=290091688592&rd=1&rd=1

This shows you how to expose the registry keys at the root level.

You need create  a new account to make msextmz run
March 7, 2007 10:32 PM
 

Bryan McNally said:

This is an overly complicated load of bollocks.
March 8, 2007 12:56 AM
 

Dalmatinac said:

Nino, Thanks for the link. We set the date on one of our test servers
to after March 11th and we noted that the Message Tracking Logs displayed the correct time.
hvala/ Sam Tudorov
March 8, 2007 1:43 AM
 

bacmallard said:

I have posted my V2 steps here in alot of detail
with alot of gotchas to get through DST and the answers for the
0x80004005 error during extraction

http://fetchblue.spaces.live.com
March 8, 2007 2:07 PM
 

pie8ter said:

I have IE 7.0 and Windows XP SP2.  I am not sure if there is a problem with this website.  But when I open this page, my whole system freezes.  It becomes extremely slow to scroll up or down.  If I scroll down, the image under "Step 2" opens up on its own browser window.  We have two T1 lines and plenty of bandwidth.  So I don't think this is a internet connection issue. I finally endedup using Firefox without any problem.  
March 8, 2007 6:58 PM
 

ninob said:

pie8ter,

I have filed a bug against IE7 on this.
March 8, 2007 7:31 PM
 

jeff said:

Still seeing the error: "failed to delete safe mode key 0x80070005"

all suggestions here tried, still woes.
March 8, 2007 10:04 PM
 

I_T_4ME said:

First of all. THANK YOU for this BLOG. It was very helpful.
I have found it easier to adjust the output.txt file than the Mailboxes_1.txt file. I stop the MsExTmzCfg program after the first NEXT>. Then I edit the output.txt file with the missing time zones. Then I run the MsExTmzCfg program again and select to Skip Extraction and use the Output.txt file. This allows me to double check the time zones...if they are not the correct format, I will get prompted to select the MS time zone from the drop down selections later in the MsExTmzCfg program.
March 9, 2007 4:45 PM
 

chisro said:

Thanks for the video-you guys did a great job!
I am running the exchange calender update tool and the server name keeps coming back as an invalid server. I have copied it directly from the adsiedit tool and pasted it in the box. Instead of using the entire path, can I just use the hostname of the server instead? Am I missing something obvious? I don't see any obvious spaces in the path and I used the same path for the msextmz.ini file and it worked without a problem. I am burnt..any ideas?
March 9, 2007 5:47 PM
 

I_T_4ME said:

chisro

V2 - the newer version you only have to put the hostname.
March 9, 2007 6:24 PM
 

TLM said:

I'm banging my head against the wall - I can't get past the first step... the need for the LegacyExchangeDN.  I've used ADSIEDIT and even verified it with the script someone posted above... this client's LegacyExchangeDN is /o=ESCRO/ou=first administrative group/cn=Configuration/cn=Servers/cn=SERVER

But the program keeps telling me invalid server check again BS... after 2 hours of trying to figure this out - I'm really killing myself here... I've got .Net 2.0 installed - all updates etc... running as a domain admin on a XP SP2 workstation in the domain.  What the hell am I doing wrong???
March 9, 2007 6:56 PM
 

TLM said:

I T 4ME - that was it!!!  Our posts crossed!  I should have just tried that - gotta hate tools that don't get documentation updated!!!!  AGH!
March 9, 2007 7:03 PM
 

pie8ter said:

I have IE 7.0 and Windows XP SP2.  I am not sure if there is a problem with this website.  But when I open this page, my whole system freezes.  It becomes extremely slow to scroll up or down.  If I scroll down, the image under "Step 2" opens up on its own browser window.  We have two T1 lines and plenty of bandwidth.  So I don't think this is a internet connection issue. I finally endedup using Firefox without any problem.  
March 9, 2007 7:43 PM
 

Clark said:

We have already run the DST OS patch on all our XP and Win2K clients and we have also run the TZMove.exe file on all of them. Is there still a need to do anything on the Exchange Server end?

I'm a little confused about why I need to run TZMove.exe again in the instructions on this page.

Thanks!
Clark
March 9, 2007 10:38 PM
 

Mike said:

Site killed my computer when tried to view with IE7, once I switched to FireFox all was good and the info was great!
March 12, 2007 12:19 AM
 

Rob said:

Site also killed my computer on IE6 - also switched to Firefox, noticed about 15% cpu utilization for it (compared to 100% for IE6).

The Possible issue I hit cost me a couple of hours (problem/fix below) - I wonder if this was in the update instructions, they should have been more clear about the location of the tzmove.exe. I did a search and copied it to my c: drive and was trying to run it from there without success for quite a while...

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

- Try to run the tool from the following location: C:\Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool
March 12, 2007 2:17 AM
 

Exchange 2003 Public Folder calendars and Daylight Saving Time change - Error said:

PingBack from http://www.errorforum.com/microsoft-office-error/16166-exchange-2003-public-folder-calendars-daylight-saving-time-change.html#post20019
March 28, 2007 5:32 AM
 

Kicking and Screaming I am Bloggin » Blog Archive » I have just spent the weekend in DST HE!! said:

PingBack from http://blog.sbs-rocks.com/?p=6
July 20, 2007 8:40 AM
New Comments to this post are disabled

News

This blog and its contents are provided "AS IS" with no warranties, and they confer no rights. Use of any included script samples are subject to the terms specified in the Terms of Use.
New! Would you like to suggest a topic for the Exchange team to blog about? Send suggestions to us.

Exchange Server 2010 - Get the Release Candidate

Poll:

Other Exchange Blogs from MSFT

Other Cool Places

International

[MS] Exchange Blogs

[MVP/Community] Blogs/Sites