Exchange 2013: Foreign Connectors vs. Delivery Agent connectors
Over the period of time, these foreign connectors have been playing a major role in handling the non-SMTP messages from the applications and FAX machines.
These foreign connectors manage a file transfer system process to route inbound/outbound messages from NON-SMTP systems.
For outbound systems, it uses the drop directory where applications must create and submit their own messages to this drop directory.
These foreign connectors check if the messages are properly formatted (MIME) and then move them to the drop directory. From here Exchange has done its job and its the responsibility of the NON-SMTP system to pick these messages and deliver them.
For the inbound flow the message should be submitted to to the replay directory from the non-SMTP system. We need to make sure that the submitted messages are properly formatted in MIME or TIFF (usually used format) so that exchange picks them up, processes these messages and delivers them to the directory.
Usually these directories are not scoped to these connectors and we need to run the below command an example below:
Set-ForeignConnector -identity Test -DropDirectory \exchange2010\share
Running the above command will create a shared directory for the outbound so that after exchange drops the email the non-SMTP system will pick these messages for delivery.
From Exchange 2013 these foreign connectors have been depreciated. Since it uses file transfer systems to route the messages through drop (outbound) and replay (inbound) the sender will not be aware if the message has been delivered to the recipients.
But still this foreign connectors can be configured in Exchange 2013.
From Exchange 2013 Microsoft recommends to have the delivery agent connectors which is having a simpler configuration compared to the foreign connectors.
Below are the advantages of having the delivery agent connectors:
- There is no need to manage file transfer to a Drop directory and check the drop directory quota, permissions, etc.
- We can use the queue management for messages that are routed to non-SMTP systems through this method.
- We can verify and acknowledge the message delivery to which is a major benefit when compared to foreign connectors.
Each delivery agent is associated with a Delivery Agent connector, which queues messages routed to the delivery agent for processing and delivery to the non-SMTP device or system.
A delivery agent is a component installed in the Transport service of a Mailbox server.
Example there is a Citrix Virtual Delivery Agent which is used for one of the Citrix application to route the non-SMTP messages.
If there is a agent required for your non-SMTP system then we need to install that agent on Mailbox servers of Exchange 2013 and 2016
By Default there is a text messaging Delivery Agent connector.
This is an agent which is installed by default in the Mailbox Servers of Exchange 2013 and 2016.
These delivery agent connectors are available from Exchange 2010 where they are present in hub roles.
By default it will have only the default mobile delivery agent connector. You can see the delivery protocol is mentioned as MOBILE.
So for other delivery agent connectors, we need to specify the protocol types.
https://exchangequery.files.wordpress.com/2016/01/d1.png?w=891
Example if we need a delivery protocol as x400 which most of the fax applications and non-SMTP application uses we need to run the below command.
New-DeliveryAgentConnector -Name “Contoso X.400 Connector” -AddressSpaces “X400:c=US;a=Fabrikam;p=Contoso;1” -DeliveryP
rotocol “X.400” -SourceTransportServers Mailboxserver
https://exchangequery.files.wordpress.com/2016/01/d2.png?w=891
After performing the above the message is routed to a Delivery Agent connector, the associated delivery agent performs the content conversion and message delivery.