Blog: Exchange 2007

Problem

The use of Outlook 2003 in an Exchange 2007 environment seems to result in the Out Of Office assistant being out of sync. Duplicate or old Out of Office replies are sent back to sender.

Cause

The duplicate OOF messages are sent because the legacy rule is enabled on an Exchange 2007 server - as well as the new EXCHANGE 2007 OOF rule(s).

When OOFAssistant see an interesting mapiEvent for a mailbox for the first time on an EXCHANGE 2007 server, it disables the legacy OOF rule.  After that, it does not disable the legacy OOF rule again (unless the user changes the OOF settings with OWA or Outlook 2007).

When an Outlook 2003 user turns on OOF for the very first time, it creates the legacy OOF rule (enabled).  When turning OOF off/on, Outlook 2003 leaves the legacy OOF rule in place and just changes a mailbox property to enable/disable OOF messages.  Thus, if something (say OOFAssistant) had disabled the legacy OOF rule, it remains disabled when Outlook 2003 turns OOF off and on.

The problem appears in the following situation also: [more]

• A mailbox is created on an EXCHANGE 2007 server.  OOFAssistant sees some interesting mapiEvent related to that mailbox.  OOFAssistant runs code to disable the legacy OOF rule, but since Outlook 2003 has not created one yet, OOFAssistant does nothing.
• The user turns on OOF with Outlook 2003 for the very first time.  Outlook 2003 creates the new legacy OOF rule (enabled).
• OOFAssistant processes the change to the legacy OOF rule by creating the new EXCHANGE 2007 OOF rule(s).
• Duplicate OOF messages are sent.

In addition, Out of Office replies can be corrupted by the Blackberry Enterprise server.

Solution

1. Install Microsoft Exchange 2007 SP1 - this update checks and disables the legacy OOF rule every time it encounters an interesting mapiEvent
2. and Blackberry enterprise Server 4.1.5 MR1 or later (refer to http://www.blackberryforums.com/bes-admin-corner/112250-out-office-oof-corruption-blackberry-bes-exchange-2007-a.html for an explanation of the blackberry issue that is resolved with the fix)

Other Workarounds

Workaround #1:

The problem is more likely a problem with OOF rules. OOF is actually a server side rule in user's mailbox. It may corrupt, or damaged. When this occurs, we run Outlook with the /cleanrules switch to clear out the rules and recreate the OOF rule, so everything will then come back normal.

Workaround #2:

1. Launch the MFCMapi tool.
2. Open the Mailbox of the affected user.
3. Right click on the Inbox folder and select Open Associated Contents Table.
4. Select the Message Class column and find the IPM.Rule.Message and IPM.Note.Rules.OofTemplate.Microsoft messages.
5. Before deleting the messages you can take backup of the template message the user had set for his OOF rule.
6. Delete these messages for the affected user.

Workaround #3:

Set up OOF through OWA 2007

The Microsoft Exchange Server 2007 database portability feature allows a mailbox database to be mounted on any server in the same organization. In previous versions of Exchange, a database could only be mounted in the following places:

• Recovery storage group
• Server with the same name as the server that the database came from
• Another server in the same administrative group

The database portability feature removes the previous limitations and handles the issues that they presented. Database portability was implemented for the following reasons: [more]

• Reliability is improved by removing error-prone manual steps in the recovery processes.
• For a lost clustered mailbox server scenario, the clustered mailbox server needed to be recovered before clients could access Exchange databases.
• Exchange mailbox data is non-server specific, so accessing that data should also be non-server specific.
• Database portability reduces the end-to-end recovery times for various disaster recovery scenarios.

At the Extensible Storage Engine (ESE) level, Exchange databases are portable. However, Exchange Server 2003 imposes certain restrictions before bringing a database online at an alternate location that do not allow databases to be portable. Database portability removes all but one such restriction, which is that the database needs to be from the same Exchange organization. A portable database is of no use, unless clients can be redirected to the mailbox data at the alternate location. With the Microsoft Office Outlook 2007 and the Exchange 2007 Autodiscover service, clients are redirected to the new server when they try to connect.

Note: Database portability is only offered for Exchange 2007 mailbox databases. Public folder databases are not portable. This is because replication between public databases is controlled by each database being linked to and accessed through a specific server. The preferred way to move public folder data between servers is to replicate it rather than copy the database files to a different server. If you copy a public folder database to a different server, it will no longer replicate with other databases.

Exchange 2007 does not automatically update address lists, global address lists, or user objects subject to an email address policy. In Exchange 2003, recipient update services used to take care of this, but this services is not present in Exchange 2007. Now, you must use scheduled powershell commands to update address lists if they are build upon object attributes that can change from time to time. For example, the address lists of one of our customers are build to key on the "office location" user object attribute. However, if the attribute is changed, Exchange does not automatically recalculate the address list membership. The following scripts are a good way to keep them updated by scheduling them with the Window's scheduler: [more]

• Get-AddressList | Update-AddressList
• Get-EmailAddressPolicy | Update-EmailAddressPolicy

We recently ran across a problem where users trying to log on to Microsoft Office Outlook Web Access in Exchange Server 2007 would receive the following error message:
"A problem occurred while trying to use your mailbox. Please contact technical support for your organization."

If Show Details is clicked in this error message, a call stack including the following message appears:
"Exception message: Property Languages cannot be set on this object because it requires the object to have version 0.1 (8.0.535.0) or later. Current version of the object is 0.0 (6.5.6500.0)." [more]

After some research we found that this issue occurs when the msExchVersion attribute is not set correctly on the user object in the Active Directory. Exchange 2007 uses the msExchVersion attribute to determine the version of Exchange that user objects are associated with. If the version value is less than 0.1, Exchange 2007 considers the object "read-only" and cannot write changes to the object.

The msExchVersion attribute may not set correctly if you created the user's mailbox by using the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in instead of by using the Exchange 2007 Management Console, as was the case in this situation. 

To resolve this issue, type the following command at the Exchange Management Shell prompt:
Set-Mailbox User_Name -ApplyMandatoryProperties

To verify the msExchVersion attribute, type the following command at the Exchange Management Shell prompt:
Get-Mailbox User_Name | format-list ExchangeVersion

Microsoft has changed the query syntax for creating Exchange Address Lists and Email Address Policies in Exchange 2007. In Exchange 2003, all recipient filters were created with LDAP queries. In Exchange 2007, a new filter syntax called OPATH has been introduced. OPATH is easier to write and makes queries easier to understand, but any ALs or EAPs that are carried over as part of a migration from Exchange 2k/2k3 to 2k7 must be updated to use OPATH instead of LDAP. Here is an example of such a conversion:

LDAP: 
(&(&(&(&(mailnickname=*)(|(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))))))
(objectCategory=user)(physicalDeliveryOfficeName=morton*)))

OPATH:
( ( ( Alias -ne $null ) -and ( ( ObjectCategory -like 'person' ) -and ( ObjectClass -eq 'user' ) -and ( recipientType -eq 'UserMailbox' ) ) ) -and ( ObjectCategory -like 'user' ) -and ( Office -like 'morton*' ) )

To save a lot of time by avoiding doing these conversions by hand you can use the LDAP to OPATH filter conversion script script provided by the Microsoft Exchange Team.

We recently experienced a very strange issue with Exchange 2007 CCR. We had the MNS cluster w/file share witness running and the CCR mailbox servers were all replicating nicely. However, at very random intervals, replication would just stop happening from the primary to the secondary node. During these times, I could not RDP to the server, but I could ping it and log on locally so it wasn’t frozen in the literal sense. File share FROM the machine worked, but file share TO the machine didn’t. Rebooting the passive node would fix the issue. After about 4 days of troubleshooting (2 of those with Microsoft), I think the mystery may be solved. It goes something like this… [more]

In Windows Server 2003 SP2, Microsoft introduced a new set of features collectively known as “Scalable Networking Pack”. This package of features includes a TCP Chimney Offload (TOE) feature, a Receive-side Scaling feature, and a NetDMA feature. Basically, this allows network card driver developers to implement offload features on the NICs so that the a certain portion of the network stack can be offloaded to the NIC card processor. It is a great idea, but unfortunately, the driver manufacturers haven’t implemented the technology correctly. Partly because the feature set is buggy and partly because the NIC drivers are not thoroughly tested. One of the worst instances of this situation is with Broadcom NICs (yes both HP and Dell use Broadcom chipsets). Generally, what happens is that the server starts exhibiting very strange RCP-related issues. RDP may not work, management via WMI may be broken, event log viewing will be VERY slow, etc. In my case, Exchange 2007 replication stopped working. So, if you notice these types of behaviors or experience any type of issue where RCP just doesn’t seem to be working correctly, set the following registry keys to 0.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPChimney
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableRSS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPA

Then reboot the server. This basically turns off any offloading features at the OS level.