Can't reset FQDN for ELHO/HELO banner using set-sendconnector
Hi all, I've got a problem with email not being delivered to just a few domains. The outgoing email sits in the Queue, is re-sent a few times, until it times out and this message is sent to the originating email box in Outlook. Delivery has failed to these recipients or distribution lists: example@domain.comMicrosoft Exchange has been trying to deliver this message without success and has stopped trying. Please try sending this message again, or provide the following diagnostic text to your system administrator. _____ Sent by Microsoft Exchange Server 2007 I've ran into this problem before, and found that the domain in the banner returned to outside email servers didn't match the domain in the MX Record. So, the (outside) recepients email server rejects the connection to my Exchange 2007 Server and the email isn't sent, and ends up in the Queue. So, no problem I think, I just change it on the Send Connectors Tab: FQDN for EHLO/HELO in the EMC. So, I made the change, restarted the services, and sent some test messages to the domains that rejected email from my Exchange 2007 Server before. I expected it to have resolved the problem, as the EMC let me make the change without issue. However, the email still failed for the same reason. After further investigation I find this: That when you have both the Transport Server Role and the Mailbox Server Role installed on the same Server the entry in the Send Connectors Tab for FQDN for EHLO/HELO will be ignored and to set it using Exchange PowerShells set-sendconnector -Fqdn command. Which I tried, and got this: WARNING: The command completed successfully but no settings of 'OutBound from Mail1' have been modified. After more investigation I find this: (Read the NOTE: section below) Specify the FQDN this connector will provide in response to HELO or EHLO This field specifies the fully qualified domain name (FQDN) that is used as the source server for connected messaging servers that use the Send connector to receive outgoing messages. The value of this field is displayed to connected messaging servers whenever a source server name is required, as in the following examples: In the EHLO/HELO command when the Send connector communicates with the next hop messaging server In the most recent Received: header field of the message that is added to the message by the next hop messaging server after the message leaves the Hub Transport server or Edge Transport server During Transport Layer Security (TLS) authentication Note: If the Send connector is configured on a Hub Transport server that also has the Mailbox server role installed, any value that you specify for the FQDN field is not used. Instead, the FQDN of the server that is displayed by using the Get-ExchangeServer cmdlet is always used.For servers that have both the Hub Transport server role and the Mailbox server role installed, the only way to remove the server name from the Received: headers of the outgoing message is to use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Routing permission from the security principals that use the connector. This action will remove all the Received: headers from the message as the message leaves the Hub Transport server. We recommend that you don't remove the Received: headers for internal messages, because the Received: headers are used for maximum hop count calculations. For more information about the Remove-ADPermission cmdlet and the Get-ExchangeServer cmdlet, see the following topics: At this point I've searched all over the Internet for a clearexample of how to use the Remove-ADPremission to resolve my outgoing banner issue. But, can't find anything quickly usable. Has anyone else run into this, and found a way to resolve it. Thanks very much, = Rod Neff =
February 8th, 2008 10:30pm

Rod - did you get a resolution for this? Am stuck with the same issue.
Free Windows Admin Tool Kit Click here and download it now
May 16th, 2008 11:06pm

Hello, I have the same problem. Any ideas someone? Thanks, Heiko
May 21st, 2008 4:59pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics