DST 2007: Unable find mailbox timezone:Error 0x80004005
This article deals with understanding and troubleshooting the famous ” Unable find mailbox timezone:Error 0x800004005 ” while extracting time zone information from users during the extraction mode of the Exchange Calendaring Tool.
(Author’s note: information has been gathered from many sources and we’ve scrubbed the data as best as possible.)
Table of Contents
· DST 2007 bulletin: Unable find mailbox timezone:Error 0x800004005“ 1
· Why do we run the tool in extraction mode?. 2
· What happens when running the tool in extract mode. 2
· Potential reasons for receiving the “Unable find mailbox timezone:Error 0x800004005” for a user during extraction mode. 3
· Perquisites. 3
· Workarounds. 4
· Summary. 4
· Appendices. 5
· Using CSVDE instead of the Exchange Calendaring Tool for user Time Zone Extraction. 5
· Using a Script to Add a Reoccurring Meeting to users mailboxes. 5
· Credits. 7
We run the Exchange Calendaring Tool in extraction mode to gather a list of Mailbox Distinguished Names, the server name the user’s mailbox is located on and lastly the time zone in which the user’s mailbox resides.
The reason for this is that we need to populate a .txt file with a list of users for rebasing purposes. The list will be used specifically to rebase user’s calendar items that fall within the extended DST period.
If your customer has only one Time Zone than this step is not as crucial because you can group them all together and manually add the time zone information in using Excel (or very manually with copy and pasting within the .txt file).
NOTE: Some companies have opted to go another route with regards to gathering this user data other than the Exchange Calendaring Tool. They have accomplished this task by performing a dump of the directory for this information. An example of this is via a CSVDE export will be provided at the end of this article.
In short this step of Extraction via our tool is to make gathering this key data on users (for rebasing purposes) a simpler process for our customers.
When the Exchange Calendaring tool is run (using the Outlook tool) in extract mode, the tool is going to look for the following user information on a particular Exchange Server:
· Users mailbox distinguished name
· Users Home Server
· Users Time Zone
The way in which the tool captures the user’s Time Zone information is by checking the following:
· Reoccurring Meetings during the Extended DST period
· CDO (Time Zone information is hard-coded in CDO)
o The method on gathering Time Zone data for a user is based on if there are reoccurring meetings within the Extended DST periods,
The most likely reason that there is no time zone info retrieved is that the mailbox is not the organizer of any meetings that fall in the delta period and therefore don’t need to have their mailbox rebased. The second most likely scenario is that they have only single instance meetings in their mailbox.
If your customers receive “Unable find mailbox timezone:Error 0x800004005” in the error log and it is for the majority of their user community you might want to turn up diagnostic logging. Turning up diagnostic logging to the maximum will help you determine your next troubleshooting steps. To turn up diagnostic logging to the maximum add the line “LoggingLevel=666” in the “MsExTmz.ini” file underneath the line containing “Logfile=msextmz.log”.
Save and close the MsExTmz.ini and rerun the extraction process. The “msextmz.log” file will contain greater and more understandable details on a per user basis.
NOTE: The log will tell you exactly why getting time zone information for a user has failed!
Potential reasons for receiving the “Unable find mailbox timezone:Error 0x800004005” for a user during extraction mode
· Those users do not have any calendar items they organized in the transition period.
· Those users do not have recurring meeting items in their calendar, only single-instance appointments (single instance appointments do not have any Time Zone data embedded).
· The tool was unable to find any time zone values in the mailbox of that specific user.
o To resolve this issue, try adding “ReadCalendarTimeZones=1” (without the quotation marks) to the Msextmz.ini file to force the tool to examine recurring calendar items for time zone information. You can create a new input file by using the DNs from the error log that you received from the last run.
· You are referencing Tzmove.exe from the wrong directory.
o To resolve this issue, extract the downloaded installation file into the folder where Msextmz resides or update the Msextmz.ini to include a full path to where Tzmove.exe is installed on the workstation that you are using.
NOTE: When you download the Time Zone Data Update Tool for Microsoft Office Outlook, the Tzmove.exe file is the installer for the actual tool. Referencing the installer will cause errors when you run Msextmz.
· The account that you are using to run Msextmz does not have full mailbox permissions and has not been delegated the correct Exchange permissions.
o To resolve this issue, run the “Grant Mailbox Permission” script from an Exchange Server computer.
o Give the account you are using for Extraction “SendAs” permissions via ADSIEdit on the server object (or even go as far as the OU if necessary).
For the multiple time zones:
· Traveling users have different time zones depending on the client.
· The customers BES server is centralized and its logon visibly causes time zone differences.
Other potential reasons for the error:
· Malformed Legacy DN’s.
o Use ExInteg to identify.
· Please ensure that you have the proper “SendAs” permissions
· Ensure that you application log file has plenty of room (each mailbox processed will create one entry in the application log file – running out of space can halt the extract process).
If there are calendar items that require rebasing and you did not receive any time zone information for them (and you have tested your “SendAs” permissions) you can simply take the contents of the “mailboxes_.txt and the “nonexsistent.txt” and merge them into a new”Mailboxes_1.txt (making certain that any missing data such as time zone values are added – use Excel, it’ll make it much easier).
If the Server has been patched with the DST 2007 OS update, the Client workstations have been patched with the DST 2007 OS update, the Exchange Servers have been updated with the CDO patch and there are no calendar items within the extended DST period then there is no rebasing to be done and you are fine! No further action is required…
Basically, if the above is true regarding patching and the Extraction mode of users fail because there is no meeting’s to rebase you are in good shape and have done your job.
Any new meetings that those users will create are going to be fine because they have the new Time Zone definitions.
In short, you only need to worry about meetings that are in the extended DST period that were created prior to the DST OS patching of the servers, and workstations.
You can perform a CSVDE export to CSV to gather the user’s mailbox DN, and the city in which the user resides. Why this is important is that you are able to tell the time zone in buy the city the user is in. With a CSV file you can easily manipulate it in Excel and build your own .txt file for updating / rebasing purposes.
And an example of a csvde command that works great is as follows:
· csvde -f UsersCities.csv -r “(&(mailnickname=*)(msexchHomeServerName=/o=Northwind Traders/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=EXBE01))” -l LegacyExchangeDN,l
o NOTE: you will obviously have to change my Exchange servers Legacy DN for your own.
After you have created this .csv file you will want to use Excel in order to sort by city. Please ensure that the .txt file you ultimately create has each user’s details in the following format:
· (tab separated), in the format of
o user <tab> server <tab> timezone
If you are interested in using / testing a script for adding reoccurring meetings to your user base (in order to gather time zone data from the extraction procedure) you can test a new script that has come into my possession thanks to Tom Kudla. The script needs to run under the user’s credentials, so a logon script should and would be optimal.
Copy the following contents into notepad and save as a .vbs:
‘The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any ‘kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a ‘particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall ‘Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, ‘without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the ‘use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
‘Last Updated: 1/28/2007
‘The following sample script looks for a special appointment with the subject *Meeting to assist with DST*. If the appointment it is found the script does ‘nothing. If the appointment not found, it creates a recurring appointment. This could possibly be called from a logon script to silently create a ‘recurring appointment for the user. This would allow the user’s time zone to be detected Exchange Data Update Tool during extraction mode. Note: You’d ‘ ‘have to run the extraction with the option enabled to look for recurring meetings. This script would need to execute under the user’s context.
‘If you have terminal server or Citrix users, I would to verify that this works OK. I believe it would but want to be sure. You could consider using
‘a GPO to target certain users with a special logon script.
‘Note: If a user happened to be traveling and changed their time zone on the OS, the recurring meeting would be created under that time zone
‘This should be a minor occurrence for most companies but I wanted to point this out.
‘The script creates one recurring appointment on 11/11/2006 at 3:00 AM, with no reminder. The recurrence ends on 11/18/2006.
‘I did not choose this date for any particular reason. I tested this on outlook 2003 and outlook 2007.
‘The file needs to be renamed to .vbs to run.
Const olFolderCalendar = 9
Const olAppointmentItem = 1
Const olRecursWeekly = 1
Set objOutlook = CreateObject(“Outlook.Application”)
Set objNameSpace = objOutlook.GetNamespace(“MAPI”)
Set objAppointments = objNameSpace.GetDefaultFolder(olFolderCalendar)
Set objAppointment = objAppointments.Items.Find(“[Subject] = “”*Meeting to assist with DST*”””)
If TypeName(objAppointment) = “AppointmentItem” Then
‘Appointment not found create it
Set objAppointment = objOutlook.CreateItem(olAppointmentItem)
objAppointment.Start = #11/11/2006 3:00 AM#
objAppointment.Duration = 30
objAppointment.Subject = “*Meeting to assist with DST*”
objAppointment.Body = “*Special DST Meeting*”
objAppointment.Location = “”
objAppointment.ReminderMinutesBeforeStart = 0
objAppointment.ReminderSet = False
Set objRecurrence = objAppointment.GetRecurrencePattern
objRecurrence.RecurrenceType = olRecursWeekly
objRecurrence.PatternStartDate = #11/11/2006#
objRecurrence.PatternEndDate = #11/18/2006#
set objProperty = nothing
set objNameSpace = nothing
set objRecurrence= nothing
set objAppointment= nothing
set objAppointments = nothing
set objOutlook= nothing