The Sent time stamp on email messages may be incorrect when you sign in to Microsoft Office Outlook Web Access or in to Microsoft Outlook Web App. Additionally, the time on meeting requests may also be incorrect.
This issue can occur if all the following conditions are true:
You are in a region that does not follow daylight saving time (DST).
The server that is running Microsoft Exchange Server where the mailbox is hosted is located in a region that follows DST.
To work around this issue, set the time zone on the Exchange Server to a region that matches the Coordinated Universal Time (UTC) zone of the country where the server is located. Make sure that the UTC zone for that country does not follow DST.
You may also have to set the time zone in Outlook Web Access or in Outlook Web App. To do this, follow these steps, as appropriate for your situation.
Microsoft Exchange Server 2010
Log on to Microsoft Outlook Web App.
Click Options, and then click See All Options.
Under Current time zone, click the time zone that you want.
Microsoft Exchange Server 2007
Log on to Microsoft Office Outlook Web Access.
Click Regional Settings.
In the Current time zone box, click the time zone that you want.
This issue does not occur when you use Microsoft Outlook because Outlook uses the time zone information from the client operating system.
Week numbers do not match between OWA and Outlook calendars in the English and French versions in an Exchange Server 2007 environment
Description of Update Rollup 6 for Exchange Server 2007 Service Pack 3
After you install this update rollup, Exchange Server 2007 OWA provides an option to select when the week numbers start.
Outlook connects to an old Exchange server after you move a mailbox from an Exchange Server 2007 server to an Exchange Server 2010 server
Microsoft Exchange administrator has made a change that requires you to quit and restart Outlook.
Additionally, the user also encounters the following symptoms:
- After the user restarts Outlook, Outlook continues to connect to the old server.
- If the user runs a repair on the profile, the same error message is received.
- If you use the Test-EmailAutoConfig cmdlet and specify the user’s mailbox, the correct information of the mailbox configuration is returned.
- If Outlook is running, this issue is recovers by itself in 30 minutes or more.
- The error message does not occur after the user manually updates the profile with the new mailbox server, or creates a new Outlook profile.
- This issue occurs in Exchange Server 2010 Release to Manufacturing (RTM) and Exchange Server 2007 earlier than Service Pack 3 (SP3).
- The old Exchange server sends its own name as the new homeMDB server in the ecWrongServer response name. Therefore, Outlook continues to connect to the old Exchange server.
- The old Exchange server provides a referral to the new Exchange server. But the profile still shows the Exchange server as the old Exchange server.
- When you view the General tab in the Connection Status, there is a referral to the new Exchange server.
Delay in updating the Profile
If Outlook is running, this issue eventually resolves by itself in 30 minute or more. This is especially true if the user has many connections to other servers, such as shared folders or shared mailboxes and Calendars. This is an indicator that Mailbox Cache Age Limit is set to a value that is too high.
This issue can be corrected by reducing the cache expiration time, for more information, visit the following Microsoft website:
To change the Mailbox Cache Age Limit value, follow these steps:
- On the Exchange Server Mailbox servers, click Start
Collapse this imageExpand this image
, type regedit in the Start Search box, and then press ENTER.
- Locate and then click the following registry key:
- Right-click ParametersSystem, click New, and then click DWORD (32-bit) Value.
- Type Mailbox Cache Age Limit, and then press ENTER.
- Right-click Mailbox Cache Age Limit, and then click Modify.
- In the Base tab, select Decimal.
- In the Value data box, type a positive integer to specify the Mailbox Cache Age Limit in minutes. The default value is 2 hours (120 minutes).
Time to update profile
After you reduce the Cache limit to a value such as 15 minutes, you may still experience delays in updating the profile.
The reason for this delay is that the Exchange server cache array on the client is currently limited to 16 entries at a time. Each entry expires in 60 seconds. The client behavior is to verify an entry that is close to expiration and replace it with the newest requested server. If there are many connections at the startup of the Outlook client, the new home server may not be inserted into the array for several minutes. A minute or more delay in updating the Outlook profile is common.
Note If the old Exchange server is turned off before you restart Outlook, clients cannot connect to the new homeMDB server if the profile is not updated.
For more information about a similar issue, click the following article number to view the article in the Microsoft Knowledge Base:
A mailbox that was moved from an Exchange Server 2007 server to an Exchange Server 2010 server cannot be accessed by using Outlook
For more information about how to obtain the latest Service Pack or Update Rollup for Exchange Server 2007, visit the following Microsoft website:
For more information about Exchange Server 2010 Servicing, visit the following Microsoft website:
Public folder read/unread status is lost after a public folder on a second Exchange Server 2007 server is added as a replica folder
- You have two servers that are running Microsoft Exchange Server 2007 in the same Exchange organization.
- A Microsoft Outlook 2010 user accesses their mailbox on Exchange server ServerA.
- The ServerA mailbox user’s mailbox store has the default public folder store configured on the same server, ServerA.
- You create a public folder on a second Exchange server, ServerB.
- The user who has the mailbox on ServerA reads some posted items in the public folder. (The public folder currently exists only on ServerB.)
- The read/unread status of posted items is retained as expected for that user.
In this scenrio, after you add a replica of the public folder to the public folder store of ServerA, all the items for the user are set incorrectly as unread.