Author: Chuck Arconi

Microsoft DST (daylight savings time) - "Unable find mailbox timezone:Error 0x800004005" and other errors and learning's.

So everybody is scrambling (including MS) to get these out. The server and workstation updates don't seem to be a problem but the Exchange thing is a BIG problem. So I gathered my recent experience and fixes as well as the KB articles you should be looking for.

NOTE: Please read all of the KB articles relating to this. I have skipped over the steps below that are covered really well in those articles. I focused on the errors that I received as I saw allot of other people having the same issues.

The Articles you should read through:

• http://msexchangeteam.com/archive/2007/02/14/435267.aspx
• http://www.microsoft.com/windows/timezone.mspx
• http://support.microsoft.com/?kbid=930879
• http://support.microsoft.com/kb/928388
• http://support.microsoft.com/kb/914387
• http://support.microsoft.com/kb/931667
• http://support.microsoft.com/kb/931836/en-us

The Demo you need to watch:

• http://msexchangeteam.com/archive/2007/02/21/435543.aspx
  

The Stuff you need to download:

• http://support.microsoft.com/kb/931836/

So after you have read through the KB Articles above and watched the Demo at the Exchange Team Blog here is a condensed version of the steps.

1. Install the DST patch/update on your Domain Controllers.
2. Install the DST patch/update on your Servers
3. Run The Calendar update tool (TZMOVE.EXE)
4. Install the DST patch for exchange on your Exchange server.
   1. Be aware that this patch contains several other updates as well (as indicated in this article). These "other" updates can cause some serious issues as they change "send as" permissions on some of your accounts.
      • This may also be necessary reading before you install the patch: http://support.microsoft.com/kb/907434/
      • And this: http://support.microsoft.com/kb/912918/
5. Install the DST patch/update on your workstations.

NOTE: Important information regarding the above, Microsoft changed the order to which Exchange gets patched. as pointed out to me by one of my visitors. You need to run the Calendar update tool BEFORE you patch your Exchange Server installation. Also the Workstation should be patched at the end. I've modified the steps above to reflect this.

So I have run the update on Windows 2003 servers and XP workstations both by hand and using WSUS server to deliver the patch through windows update. Both mechanisms worked fine with no problems.

Now for Exchange:

I had several big problems with the Exchange and client side of things. But I worked them out and here is what I ended up with as the final best practices.

1. Install the Exchange patch. Remember this will restart the information store and depending on how your system is configured (third party apps) you may have to reboot. In my case I had to reboot, even the front end servers.
2. If you are using Goodlink or BlackBerry there are special considerations. I use Goodlink and we had to go back and reset permissions as they were changed by the DST Exchange patch. (It actually stopped delivery of email to handheld devices for some of our users until we did this)
3. Setup your client system for Calendar updating: I have found a lot of confusion here when I talk to others about this. If you are not going to have your users run the update tool themselves then you will need to run it on the Exchange server to update everybody's appointments.
   1. Set up a workstation:
      • Install XP
      • Install .NET 2.0
      • Install Outlook 2003
      • Do not install Exchange Administrative console
      • Download the TZMOVE package
      • Download the Calendar update package.
      • Create a folder on the root of your system drive to hold the installable. I named mine "C:\DST"
   2. Run the TZMOVE.EXE executable

Stop here! Don't click OK!

Click "CANCEL"

NOTE: All you want to do is install the files and create the registry keys. Do not run the update tool.

3. Run the Calendar update package "MsExTmz.msi"

NOTE: Do not use the default path of "C:\program files\MsExTmz\" . If you do it will not work.

Ok so on the next 2 screens just click Next and OK to finish.

Now Prepare your tools to run: Follow the instructions listed in the Demo at the Exchange Team Blog and article 930879

4. Make sure you don't forget to check the reg key setting on the client system-

HKEY_CURRENT_USER\Software\Microsoft\Exchange\client\options\

"PickLogonProfile" value should be "0"

5. Set the Outlook profile to open without prompts - This is a big gotcha. Here is the only way I could get this to work.
   1. Go to control panel and open the "Mail" object.

2. Delete any profile that exists.
3. Create a new profile and name it "admin". Use the account you granted "send as" permissions to.
4. Open outlook and make sure it doesn't prompt you to choose a profile. If it does; at the profile selection screen click "options" and check the box "Set as default profile". Let Outlook continue to open.
   2. 

5. Close Outlook and re-open it to make sure that it does not prompt you to choose a profile. It it doesn't, close it.

6. Go to the following folder -"C:\Documents and Settings\admin profile\Local Settings\Application Data\Microsoft\Outlook"

   • NOTE: the "admin profile" is just the name I used. This will be the location of the profile you are logged on as, the account that will run the update.

7. Find the "extend.dat" file and rename it to "extend.old". Don't delete it, don't name it "extend.old1" or .txt or anything other than ".old".

8. Your done with Outlook for the time being.

   • NOTE: If you run the "bat" file to test or for another "run"  you will have to run through this procedure again as it will reset the profile and start prompting again.

6. As of right now when I run this it works great, but, resource mailboxes that have the Auto Accept Agent running start hammering everyone with appointment updates and decline notices. I am trying to work this one out and will post it here as soon as I do. Maybe the next release of the "update Tool' or the next one, or the next one...
7. When you run "MsExTmzCfg.exe" - you need to enter the information in a certain way to get the tool to work (at least I did, with MS support on the line with me)
   
   1. In the "Server Name" box enter the friendly name i.e. the NetBIOS name.
   2. When you reach the screen "Calendar Update Configuration" (shown below) you need to browse to the folder representing your version of Outlook  (mine was version12 ) "C:\Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool\TZMOVE.EXE" and select the 'tzmove.exe" file.

 This file is only 304kb or so, also I tried placing the file in the "DST" folder I created AND the root of "C" that didn't work. It only liked it if it was in that folder?  Don't ask just do it. ( the screen shot below shows what I'm talking about.)

8. Update to calendar tool- 
   1. The KB Article location is:  http://support.microsoft.com/kb/933146
   2. The hot fix download is: (http://download.microsoft.com/download/1/5/b/15bcbfca-5570-4c44-8ddf-e3c4cfa84ed8/tzmove2007-kb933146-fullfile-x86-glb.exe)
   3. I installed the update to the tool by downloading it and double clicking it.  It will find where it's supposed to place files. You will notice a new DLL in the tzmove.exe folder location.

There are some new command switches you can use to resolve some of the issues that plagued the previous version. Read the KB article (933146) to get all of the switches and their proper usage.

The command I used was; "TZMOVE.EXE /q /FORCEREBASESUPPRESSEXCHANGEUPDATES"

This allowed updates to be sent to meeting / appointment participants who resided outside of the company or our Exchange environment but not to those inside the company ( a huge problem in prior testing.)

Also it forced the resource mailboxes (those being managed by Auto Accept Agent) to be updated without pounding everyone with acceptance messages.

NOTE: There is some funny behavior your going to have to watch for. When running the update bat file you will see new log files appear for each mailbox the the utility successfully moves appointments for. This is good because it gives you a log for each mailbox. I printed this out and gave it to the "testers" (read victims) so they could compare with their calendars in case they lost a meeting. But the time shown in the Log for the appointment is GMT not whatever your time zone is so that caused some confusion (as shown below)

NOTE: When you run the MsExTmzCfg.exe and it completes there are 5 files created under a new folder in the "C:\MsExTmz" folder. It will be the same name as the exchange server you are running it against, something like "C:\MsExTmz\MyExchangeserver"

The files are: ConflictUsers.txt, Mailboxes_1.txt, MSExTmz_1.bat, MSExTmz_1.ini, NonExistent.txt

In the MSExTmz_1.ini is where you will add  "/FORCEREBASESUPPRESSEXCHANGEUPDATES"

The line it's on should be pretty obvious. If you look at the screen shot below that's the file.

(Click the image for a larger view)

Another NOTE: I ran this recently and one thing you should be aware of is that after your BAT file is completed there may be an error log with some accounts that it failed on.

I added the time zone info to the end of every mailbox listed in the error log and then renamed the log to "Mailboxes_1.txt".

Then I ran the bat file again (MSExTmz_1.bat). After doing this several times I was able to access every one of the "error" mail boxes and move their appointments.

Example:

(errors.txt)- /O=MYDOMAIN/OU=COMPANY/CN=RECIPIENTS/CN=WWOOD

I added "    myserver     Pacific Standard Time" to the end of the line so it looked like this:

"/O=MYDOMAIN/OU=COMPANY/CN=RECIPIENTS/CN=WWOOD    myserver     Pacific Standard Time"

I did this on every line. Then I renamed the file to "Mailboxes_1.txt" and ran "MSExTmz_1.bat" again.

NOTE: Upon first deployment I noticed that some of the systems were having issues and that the time was still off by one hour on appointments within the new DST time period. I followed the instructions below that are listed in the Q article 914387

I took the script and placed it into a GPO that I already have for my users that calls the logon script. I added it as a second script and let that stay in place for a couple of days. This resolved the issue for most of the systems.

1. Click Start, click Run, type notepad, and then press ENTER.

2. Copy the following code, and then paste it into the Notepad document.

Set objSh = CreateObject("WScript.Shell")

'Get the StandardName key of the current time zone
szStandardName = objSh.RegRead("HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\StandardName")

'Enumerate the subkeys in the time zone database
const HKEY_LOCAL_MACHINE = &H80000002
Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
szTzsKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones"
objReg.EnumKey HKEY_LOCAL_MACHINE, szTzsKeyPath, arrTzSubKeys

'Step through the time zones to find the matching Standard Name
szTzKey = "<Unknown>"
For Each subkey In arrTzSubKeys
    If (objSh.RegRead("HKLM\" & szTzsKeyPath & "\" & subkey & "\Std") = szStandardName) Then
        'Found matching StandardName, now store this time zone key name
        szTzKey = subkey
    End If
Next 

If szTzKey = "<Unknown>" Then
       'Write entry to the Application event log stating that the update has failed to execute
       objSh.LogEvent 1, "DST 2007 Registry Update and Refresh failed to execute on this computer.  Time zones failed to enumerate properly or matching time zone not found."
       Wscript.Quit 0
End If

'Launch control.exe to refresh time zone information using the TZ key name obtained above 
objSh.Run "control.exe timedate.cpl,,/Z" & szTzKey

'Get current display name of refreshed time zone
szCurrDispName = objSh.RegRead("HKLM\" & szTzsKeyPath & "\" & szTzKey & "\Display")

'Write entry to the Application event log stating that the update has executed
objSh.LogEvent 4, "DST 2007 Registry Update and Refresh has been executed on this computer." & chr(13) & chr(10) & chr(13) & chr(10) & "Current time zone is: " & szCurrDispName & "."

*********************************************

For Systems that still showed up with the issue of appointments off by 1 hour

I found through WSUS (Windows Update Server) that some of the affected systems still didn't receive the update patch. I manually ran the update and that fixed it for those. you can get that download through article 931836. The link is at the top or you can download the XP patch here: http://www.microsoft.com/downloads/details.aspx?familyid=66F1420C-DF2D-400B-A8A9-EF9061A9A3CA&displaylang=en

This will have to be run by the user or you. This was the final fix for me. I still had a couple of users that could not be fixed by any means, they had to be moved manually. I had one user that was off by 3 hours during that DST window?

Good luck!

Well that's all I have for now, I will be updating this as I get new info.