We receive NDR 550 5.6.0." smtpsendrdstnottransmittable" when sending e-mail to mail-enabled Public Folder on Exchange 2003

You just installed Exchange 2007 or 2010 in coexistence with Exchange 2003 in order to proceed to migration. When performing tests you realise that you are unable to send any e-mail to the Public folders that are not yet replicated on the new server(s), or worse, you try to replicate the public folders to the new server and you observe that the queue gets full and nothing gets to the post 2003 servers. For both case you receive an NDR 550 5.6.0." smtpsendrdstnottransmittable" in message tracking or Outlook client.

 

What does " smtpsendrdstnottransmittable" mean?

It means that the sending server is unable to Transmit the Routing destination of the message.

You observe in the application log of the newly installed HUB transport server(s) an intresting event is logged:

ID:       2021
Level:    Error
Source: MSExchangeTransport
Machine:  computer fqdn
Message:  Unable to transmit RDST (Routing Destination) to remote server 'legacyserver.contoso.com' over send connector 'Intra org SMTP Send connector '. Message '<InternalMessageID@postlegacyservername.contoso.com>' will not be delivered to recipient <'PFalias@ccontoso.com'>.

 

xRDST:

This parameter is new for Exchange 2007. This protocol extension is used to communicate a routing destination that is associated with a message to the remote server. If a remote server does not advertise XRDST and if the message to be sent requires XRDST support, MSExchangeTransport event ID 2021 is logged in the event log. The symbolic name of this event is tuple_SmtpSendUnableToTransmitRDst. This event indicates that the message cannot be sent.

XRDST is a parameter included in XEXCH50 is, among other things, used by Exchange for public folder replication, and a proprietary SMTP verb of Microsoft Exchange, therefore, the functionality is provided in a file that is installed and registered by Exchange Setup. In our situation this means that there is something wrong with the SMTP send connector using the XEXCH50 verb or the module (peexch50.dll) involved in its use.

 

How can we check about XEXCH50 ?

There are 2 possibilities to do that:

1- set a telnet connection to the legacy server on port 25 (SMTP):

c:\>telnet 2003server 25

220 Lab01-dc01.LAB01.LOCAL Microsoft ESMTP MAIL Service, Version:
6.0.3790.3959 ready at  Tue, 22 Nov 2011 19:12:23 +0100

EHLO

250-Lab01-dc01.LAB01.LOCAL Hello [127.0.0.1]

250-TURN

250-SIZE

250-ETRN

250-PIPELINING

250-DSN

250-ENHANCEDSTATUSCODES

250-8bitmime

250-BINARYMIME

250-CHUNKING

250-VRFY

250-X-EXPS GSSAPI NTLM

250-AUTH GSSAPI NTLM

250-X-LINK2STATE

250 OK

QUIT

221 2.0.0 Lab01-dc01.LAB01.LOCAL Service closing transmission channel

We can observe in the list of verbs that 250-XEXCH50 is missing. This means that it is not handled

 

2- The Exchange Server Analyzer (Exchange Best Practice Analyzer) may return this warning like following in the report tree.

" The SMTP instance "Default SMTP Virtual Server" on server 2003server does not take in charge of the verb XEXCH50. This can lead to Public Folders replication issue.

What could cause the deletion or disactivation of XEXCH50?

The ExBPA report warning point to:

"The antivirus software installed on the server uses its own SMTP stack to intercept and scan messages before they reach the Exchange SMTP stack. In this case, the SMTP stack in the antivirus software is not using the XEXCH50 verb. It is recommended that you run the antivirus software in a mode that does not require it to install its own SMTP stack on the Exchange server or run such software at the incoming perimeter of your SMTP network. If you have disabled the SMTP stack for the antivirus software, and you still get this warning, reinstall Exchange to install"

 

How can we resolve this issue?

ExBPA point to the following KB for the resolution of the issue: https://support.microsoft.com/?kbid=822939, It suggests to re-install the Exchange server or the smtp server.

In big production environnements, we cannot accept this solution as there are risks in doing that and offers a considerable outtage for the users.

I would suggest a better alternative that is instantaneous: register the implicated module peexch50.dll properly using the folowing command in comand-prompt:

C:\Program files\Exchsrvr\bin>regsvr32 peexch50.dll

Now, if you set a a telnet connection to the SMTP server you will find in the list 250-XEXCH50 after issuing the command EHLO