blog.wansend.com

March 29, 2007

Exchange 2003 & 5.5 DST Patches

Filed under: Exchange 2003 — wansend @ 8:38 pm

All mail servers have been patched with the latest DST changes.  Workstations, however, are having a problem with calendar appointments being off by an hour for the rest of March. This Outlook 2000/2003 problem has a patch.

Description of problem: http://technet.microsoft.com/en-us/library/bb267339.aspx
Patch: tzmove.exe
Warning 1: Must already have XP/2000 DST patch for this to work (current updates)
Warning 2: Must be logged-in as an Administrator

I’ve fixed the Exchange 5.5 server on Windows 2000 Daylight Savings issue by updating it’s registry as described in http://support.microsoft.com/kb/914387

Step 1: Unzip tzupdate.zip onto a Windows 2000 PC. You must be an Administrator.
Step 2: Import global registry changes by right-clicking on Tzupdate.reg –> merge
Step 3: Run refreshTZinfo.vbs to apply the registry change locally. The script does not run verbosely.
Step 4: Verify with Regedit \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
DaylightStart REG_BINARY 00 00 04 00 01 00… should now be 00 00 03 00 02 00…
StandardStart REG_BINARY 00 00 0a 00 05 00… should now be 00 00 0b 00 01 00…
Check that the new numbers are on the PC.  These numbers are specific to Pacific Standard Time.

I tried running the Mail third DST patch, but it is already installed with Exchange SP2.  Here’s a guide that outlines all the patches: http://exchangepedia.com/blog/2007/02/dst-2007-understanding-what-needs-to-be.html

Apparently there is a calendar bug with calendar events created a long time ago.  Each old recurring calendar event needs to be reset to a more current date for the new daylight savings time to work properly.

Exchange 2003 changing postmaster @domain1.com to @domain2.com

Filed under: Exchange 2003 — wansend @ 7:44 pm

When your active directory domain doesn’t match your email address, you have problems. One of them is that your NDR and delayed mail warnings come from postmaster@domain1.com when it should be from @domain2.com. The fix can be found in your MMC:

JerrysMMC – Console Root\DOMAIN1 (Exchange)\Recipients\Recipient Policies\Default Policy –> Properties –> E-Mail Addresses (Policy) tab –> SMTP @domain1.com Change to SMTP @domain2.com. When you click ok, it will ask you if you want to update all users. I answer No. Answering yes will change all users affected by the policy to the new domain, which can be very bad.

Even if you have other Recipient Policies, the Default Policy determines the source of NDRs.

A Google search for this topic gives unintelligible answers about event sinks or solicits third party software.

NDR = Non DeliveRable email

Lastly, if the postmaster@domain2.com email resolves as a secondary address for a user’s account, Exchange will change the email to the primary address for the user – after about a day. This can be a plus if you want to change the NDR from-address to an address other than postmaster. In my case, I had to move the postmaster@domain2.com name over to another user so it could be the primary email address.

Welcome to the Wansend.com Blog

Filed under: General — wansend @ 7:29 pm

Welcome to the wansend.com blog. This blog mostly contains technical research by Jerry Toomey relating to the following:

  • Cisco Routers
  • Cisco PIX firewall
  • Microsoft 2003 Server
  • Microsoft Exchange 2003 Server
  • Other CCIE & MCSE items
  • Banking, Housing Bubbles, LDS Church, & other personal items of interest

blog.wansend.com

Filed under: General — wansend @ 6:46 pm

Welcome to blog.wansend.com, part of www.wansend.com

Blog at WordPress.com.