Exchange Geek's Weblog

I'm a Geek!

Archive for the ‘Transport’ Category

You cannot edit a transport rule if one or more of the recipient addresses are disabled or removed in an Exchange Server 2007 server

Posted by Milind Naphade on 24/06/2011

Been through such thing before? Well, it was a brain teaser for me for a while. One of my team mates contacted saying they are unable to edit a transport rule configured to BCC emails marked to a particular mailbox.

The situation was like this. Customer has a transport rule which adds 4 recipients as BCC recipients into emails sent to a mailbox named Application Support (application.support@exchange.local). Now, One of these intended BCC recipients resigned and his mailbox was deleted immediately. As a result, emails sent to application.support@exchange.local started bouncing to the senders with an NDR stating the email was not delivered to a user named U Gardner (u.garnder@exchange.local). Indeed, it was annoying for everyone to receive NDRs on each email sent to Application Support mailbox.

Off course, customer contacted our support team to fix this problem. We faced a new issue to be fixed before the NDR could be.

After locating the transport rule they found that they were not able to edit it so that they could simply remove the problem user from the actions page of the transport rule wizard. When right clicked on the rule they never got an option to edit the rule.

Microsoft confirmed this as a problem with Exchange 2007 SP2 systems and it is fixed in RU2 for Exchange Server 2007 SP2 here http://support.microsoft.com/kb/976195

Customer is on Exchange 2007 SP2 currently so it was impractical for us to install RU2 just to resolve this problem. So, we took a little way around 😉

Below are the steps:

  1. Open ADSIEDIT and connect to your configuration partition.
  2. Browse to CN=Transport,CN=Rules,CN=Transport Settings,CN=<Org Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local
  3. Locate the transport rule in the result pane of ADSIEDIT that has a problem
  4. Right click the transport rule and go to properties.
  5. Locate the attribute msExchTransportRuleXml in properties of the transport rule.
  6. Click on edit button.

XML of the rule in AD looks like below:

<rule name="Application Support Forwarding" comments="Application Support Forwarding">
                <fork>
                                <recipient address=application.support@exchange.local />
                </fork>
                <condition>
                                <and>
                                                <true />
                                </and>
                </condition>
                <action name="AddEnvelopeRecipient">
                                <argument value=om.k@exchange.local />
                </action>
                <action name="AddEnvelopeRecipient">
                                <argument value=ra.rai@exchange.local />
                </action>
                <action name="AddEnvelopeRecipient">
                                <argument value=
u.garnder@exchange.local />
                </action>
                <action name="AddEnvelopeRecipient">
                                <argument value=Ven.C@exchange.local />
                </action>
</rule>

If you look at the XML carefully, you will observe that the deleted user email address still lies there in the XML. This deleted mailbox causes a problem and would not let you edit the rule by any known method.

Now, to fix this problem you just have to locate the below part in the Transport Rule XML and delete it from the attribute value.

                <action name="AddEnvelopeRecipient">
                                <argument value=
u.garnder@exchange.local />
                </action>

Once you have deleted this portion of XML and made sure that AD replication has completed, disable the rule in question and enable it back.

Bingo! Problem resolved!!

Advertisements

Posted in Exchange 2007, Transport | Comments Off on You cannot edit a transport rule if one or more of the recipient addresses are disabled or removed in an Exchange Server 2007 server

MX Records: Are they really needed?

Posted by Milind Naphade on 18/05/2011

Sound a weird question? Yes, it shocked me too. One of my customers run Symantech BrightMail Gateway for their inbound email handling. This appliance has multiple accepted domain names configured. We were amazed to see some domain names not having an associated MX records yet they were receiving emails from internet. I though of digging down more into this just because it was interesting 🙂

For most of us the equation is extremely simple, No MX no email. But I learned something extremely interesting today. RFC 2821 says you can receive emails even if you do not have a MX record for your domain name.

Below text comes from  RFC 2821

5. Address Resolution and Mail Handling Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in sections 3.6 and 3.7), a DNS lookup MUST be performed to resolve the domain name [22]. The names are expected to be fully-qualified domain names (FQDNs): mechanisms for inferring FQDNs from partial names or local aliases are outside of this specification and, due to a history of problems, are generally discouraged. The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name. If no MX records are found, but an A RR is found, the A RR is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error.

This clearly means if the IP address associated with your exchange server is the same that resolves to  your domain name’s IP address and you do not have any MX records configured in your DNS, you can still receive emails from the sending server compliant to RFC 2821.

Exchange Server 2007 and Exchange Server 2010 both applications are compliant to the mentioned RFC. Although I did not test this scenario yet this information might help you resolving your questions if you faced similar issue like I did.

Posted in Exchange 2007, Exchange 2010, Transport | 5 Comments »

#5.2.1 when sending emails from Exchange 2010 to Exchange 2003

Posted by Milind Naphade on 18/11/2010

You will find a lot of posts related to this issue. I read a bunch of them on internet too. What interested me more is a cause behind this problem. Although this problem is very generic and doesn’t occur in every organization after upgrading to Exchange 2010 there are many people I see who reported the same problem in various forums. In all cases I saw on internet, users on a specific store experienced this problem.

Typical symptoms are:

A user with mailbox on an Exchange 2010 store sends an email to another user with mailbox on Exchange 2003 store and receives an unexpected NDR even though the recipient user account exists and the message is well within configured size limits.

Delivery has failed to these recipients or groups:
Naphade, Milind
There’s a problem with the recipient’s mailbox. Please try resending this message. If the problem continues, please contact your helpdesk.
Diagnostic information for administrators:
Generating server: exchange2003.exchange.local
milind.naphade@exchange.local
#< #5.2.1> #SMTP#

You also see the application log full of Event IDs 9666, 9667

Microsoft Exchange SMTP 5.2.1 is generated when the message is too big or the recipient is missing SID on it. This can not be a cause for sure because the same recipient can receive other emails without any problem. So, I decided to drill down a little more  and figure out what happens when these NDRs are generated by Exchange 2003.

Event IDs 9666 and 9667 are logged to indicate that the exceeded named properties quota in a particular information store database. Above mentioned NDR is very closely related to the event IDs 9666 and 9667. Microsoft Exchange team has a very good post on their blog explaining the named properties (so called named props). I strongly recommend you reading it first here –> Confused About Named Properties Quotas in Exchange 2003 and Exchange 2007? Join the Club!

So, here is what happens when an email sent from Exchange 2010 to a recipient on an Exchange 2003 information store:

According the post linked above, Microsoft Exchange Server 2003 allows 16,384 named props creation for authenticated users by default however, insertion of new named props is stopped once the rows in the table exceed the number 16,384 for authenticated users and 8,192 for non-authenticated users. Unless the row limit is hit the server will continue accepting creation of new named props in the named props table. These named props are typically created by an application that connects to the exchange information store using MAPI. This can be an enterprise application which can read/write into database using MAPI connection or an outlook plug-in which uses exchange information store database for reading or writing information in mailbox. Also, custom properties/headers attached to the emails coming from internet are also inserted into the named props table. For example: if you have a spam filtering mechanism that stamps an additional header called x-spamScore-linux in the inbound message, this header is automatically added in named props table by Microsoft Exchange information store service. This is definitely required to display the message and its properties in outlook correctly. This behavior causes the named properties table to fill with new named properties.

Coming back to the original topic of NDRs: for an instance just imagine a scenario where you exchange 2003 store database named props quota has reached and there is no room in the table to add new named props and a user from Exchange 2010 using outlook 2010 sends an email to another user on the exchange 2003 store. As described earlier named props table reached to the maximum limit will not be able to add new named props attached with the message coming from Exchange 2010 server and hence store will generate an intermittent NDR.

Are you saying this happens to every message sent from Exchange 2010? Answer is NO. It does not happen to every message. This would happen only if the message contains additional named properties attached to it which are absent in the Exchange 2003 information store named props table and need insertion in the table. In most of the cases a plain text email sent using Outlook would get delivered but an HTML email or a meeting request may bounce back to the sender.

How should I fix it? Microsoft already has an official support article that talks about the named props limit handling which is linked in the above linked article from MS Exchange Team. Following that article would be enough.

At the end, I tried explaining the stuff to the best of my understanding. If you think that this post could have some more detailed information please do feel free to comment or write to me directly using the contact form. I will update the post accordingly.

Posted in Exchange 2003, Exchange 2010, Transport | Comments Off on #5.2.1 when sending emails from Exchange 2010 to Exchange 2003

Exchange Server 2010 Shadow Redundancy

Posted by Milind Naphade on 07/06/2010

Exchange 2007 was launched with a completely new design and product architecture and showed up with a whole new concept of bifurcated server roles which were a part of a single server installation in Exchange Server 2003. These server roles were wiz. Mailbox Server Role, Hub Transport Server Role, Client Access Server Role, Edge Transport Server Role and Unified Messaging Server role (this was a completely new feature that exchange 2007 supported. Earlier version of exchange did not have any native support to unified messaging and relied on third party products).

With these bifurcation of functionality in terms of server roles; exchange server 2007 also introduced new concepts of high availability for mailbox databases very well known as CCR, LCR, SCR. These HA features made sure that once an email is delivered to a mailbox on the database, it remains safeguarded against any data loss even in case of a complete database or server failure.

Transport Dumpster:

With highly available mailbox servers, email messages are safe once they are delivered to the database; protecting email messages in transit was another challenge. As a safety measure against any data loss for the message in transit, exchange 2007 hub transport server introduced another new feature called transport dumpster which is nothing more than a queue of messages that is maintained by the hub transport server. This queue contains the email messages which were recently delivered to the mailboxes protected by mailbox HA solution like CCR. These messages are retained in the database until they reach the age limit configured by the administrator. In case of a failover the clustered mailbox servers request all hub transport servers in the site to resubmit emails messages from transport dumpster. This mechanism prevents the loss of emails during the failover but it didn’t have the capability to handle the emails in transit between transport servers.

Shadow Redundancy uses notifications:

To make sure that least amount of data is lost in the form of in transit email messages; Exchange 2010 adds a new feature of the transport component called Shadow Redundancy. This is just like transport dumpster but except the deletion of messages from transport database is not completed until the transport server verifies that all of the database copies in DAG are successfully updated. Shadow Redundancy keeps tack of messages which have been delivered and replicated to all database copies in a DAG. This is achieved by maintaining a copy of messages being sent to database copies in a DAG and requesting a notification that it has been replicated to all database copies in DAG. The copy of messages is held in the mail.que database until the HT server receives a notification that the transaction log representing that particular message has been replicated to the primary target database and has also been successfully replicated to other copies. Once the notification is received the transaction log representing the message is truncated to make sure that the mail.que database contains only those messages which have not yet been replicated.

Shadow Redundancy Manager (SRM) and Heartbeat:

The initiating transport server issues and XQUERYDISCARD message to the target server and in response the target server returns a discard notification. This is known as the heartbeat. Once the heartbeat is received from the target; the Shadow Redundancy Manager uses this heartbeat to determine the availability of the primary target server for which the shadow messages are queued. Heartbeat time out is 300 seconds by default which is subject to 3 consecutive retries to the destination server. If the initiating server cant establish a connection to primary target within the heartbeat timeout the initiating server determines that the destination is not functional then resubmits the shadowed messages to next available server. If there is any chance of message duplication due to this approach then Exchange 2010 message de-duplication features takes the charge and removes them so that users don’t see duplicate messages in their mailboxes.

In short, Shadow redundancy is not the transport dumpster but an extension to SMTP service which works tightly with the transport dumpster. Shadow Redundancy is enabled by default and is used as far as both servers in a SMTP session support it. You can use Set-TransportConfig –ShadowRedundancyEnabled:$False. It uses discard notifications to remove only those messages from dumpster which has been delivered and successfully replicated across all database copies in a DAG.

Shadow Redundancy is the transport component and can only be managed using EMS, there is no GUI to administer it.

Microsoft Technet has a detailed article which discusses the various scenarios and the ways Shadow Redundancy works: You can read it here

Posted in Exchange 2010, Transport | Comments Off on Exchange Server 2010 Shadow Redundancy