Linked Connector
Diese Funktion steht nur in Exchange 2010 zur Verfügung. Ist also nicht wirklich zukunftssicher.
Die Funktion ist mit Exchange 2016 nicht mehr nutzbar
Die meisten Administratoren werden den Linked Connector noch nie gehört haben. Er ist ja auch mit Exchange 2010 raus gekommen und soll den ForeignConnector ersetzen, welcher ein Stück weit glücklos agiert. Als Dateischnittstelle ist er nicht "aktiv" genug und kann schlecht überwacht werden, da sich das Queueing außerhalb von Exchange dann befindet.
Der Linked Connector ist dabei gar nicht mal ein echter Connector, sondern mehr eine Konfigurationseinstellung, um einen Receiveconnector und einen SendConnector geschickt so zu verbinden, dass die Nachrichten über einen Umweg geleitet werden können. Mit der Verknüpfung kann eine Mail, welche über einen Receive Connector empfangen wird, direkt über einen bestimmten Send-Connector wieder verteilt werden. So eröffnen sich nette Möglichkeiten, aktive Komponenten beim Versand per SMTP zwischen Exchange und dem Zielsystem zu schalten.
Klassischer Ansatz
Normalerweise müssen sich Zusatzprodukte wie Antivirengateways, Signaturprogramme etc. immer zwischen Internet und Exchange konfigurieren.
Letztlich kann das bei mehreren Gateways dann zu einer richtigen Kette von Produkten ausarten, bei denen Sie eigentlich jedes einzelne Produkt und deren Warteschlangen überwachen müssen. Im Exchange 2010 Messagetracking sehen Sie dann nur noch den ersten Punkt: "Mail wurde zum upstream Gateway zu gestellt". Alles was danach kommt, ist nicht mehr sichtbar.
Die gleiche Einschränkung gilt aber auch für den ForeignConnector, welcher ebenfalls für Exchange nur ein dummer Connector ist, in den Mails in eine Verzeichnisstruktur abgelegt aber nicht weiter verfolgt werden können. Der Linked Connector möchte diese Einschränkung umgehen, indem weiter konsequent auf SMTP und "Zustellung" gesetzt wird statt auf "abholen" und trotzdem soll Exchange weiter die zentrale Drehscheibe bleiben. Die Schnittstelle ist weiterhin SMTP.
Einschränkungen
Wenn Sie nun alles gleich parallel in ihrer TestUmgebung nachstellen wollten, dann sollten Sie kurz innehalten, denn so einfach ist es nicht. Spätestens bei der Einrichtung des Links zum Internet wird die PowerShell Sie auf einige Voraussetzungen hinweisen:
Oder in einem Suchmaschinen-freundlichen Format als Text:;
[PS] C:\>Set-SendConnector outAdd-on2 -LinkedReceiveConnector W2K8R2E2010\FromAdd-on2 You can't set the LinkedReceiveConnector parameter if any one of the following conditions is true: the AddressSpaces at tribute is already configured; DNS is used to route mail; the MaxMessageSize attribute isn't set to unlimited + CategoryInfo : NotSpecified: (OutAdd-on2:ADObjectId) [Set-SendConnector], DataValidationException + FullyQualifiedErrorId : 99AE5D85,Microsoft.Exchange.Management.SystemConfigurationTasks.SetSendConnector
Die Bedeutung im Einzelnen
- Addressspace
Der Send-Connector, welcher an den Receive Connector gebunden wird, darf keinen Adressraum zugewiesen bekommen. Das macht auch Sinn, da ansonsten Mails von Intern vielleicht auch diesen Connector nutzen würden und das Routing für andere Administratoren nicht mehr so einfach zu durchschauen wäre. Fatalerweise kann man den Adressraum zumindest in der GUI eines Send-Connectors gar nicht leer lassen:
- kein DNS Routing
Auch das ist logisch, da alle Mails ja an einen Smarthost gehen sollen, der eine Verarbeitung vornimmt. - MessageSize
Auch hier gilt: Wenn sie eine bestimmte Mailgröße nicht überschreiten wollen, dann sollten Sie schon auf dem Receive Connector die Größe beschränken und die Mail gar nicht erst annehmen anstelle nach der Annahme bei der Weiterverarbeitung diese zu blockieren und damit einen NDR erstellen zu müssen (Siehe auch NDR Spamming)
Mit diesen Einschränkungen ist auch der Einsatzbereich von Linked Connctoren schon stark eingeschränkt.
Linked Connector eingehend
Der klassische Fall ist die Konfiguration für eingehende Mails. Hierzu wird der Receive-Connector, welcher die Mails aus dem Internet annimmt direkt mit einem Send-Connector verknüpft, der die Mails dann an ein Zusatzprodukt weiter sendet.
Auch dieses Produkt kann sich nun hier "intern" einfach um die Nachrichten kümmern und diese nach der Verarbeitung wieder an Exchange zurück senden. Exchange empfängt diese Nachricht nun über einen Receive Connector, der nicht mehr mit einem "Link" versehen ist. Es ist damit eine ganz normale eingehende Mail, die durch die Hub/Transport-Rolle läuft und entsprechend zugestellt wird.
Die Mail wird direkt beim Empfang aus dem Internet schon im Messagetracking protokolliert und die in Exchange enthaltenen Filter (z.B. Ungültige Mailadresse, Postfach voll etc.) können angewendet werden. für einen echten Spamfilter sollten Sie aber nicht diesen Umweg durch den Linked-Connector wählen, da die Mail dann schon als "angenommen" gilt und das Add-on nur mit einer Quarantäne arbeiten kann.
Linked Connector ausgehend
Kniffliger wird es natürlich, auch ausgehende Mails über solch eine Schnittstelle zu verarbeiten. Gegen einen direkten Einsatz wirkt hier das Verbot einer DNS-Zustellung auf dem Send -Connector. Zwar kann ein ganz normaler Send-Connector mit dem Adressraum "SMTP:*" die Mails an einen Zusatzdienst weiterleiten, der diese dann wieder an Exchange zustellen kann, aber der zweite erforderliche Send-Connector, welcher mit dem Receive-Conector verbunden ist, darf nicht per DNS zustellen und auch keinen Adressraum haben.
Insofern muss ein externer Smarthost für "ausgehend" mit eingeschaltet werden. Ob da dann noch Sinn macht und nachvollzogen werden kann, bezweifle ich. Vor allem habe ich als Administrator dann doch keine weitere Kontrolle mehr über ausgehende Mails und diese auch nicht mehr im Messagetrackinglog von Exchange.
Konfiguration eingehend
Die Einrichtung der Verbindung zwischen Send-Connector und Receive-Connector ist sehr einfach, muss aber über PowerShell durchgeführt werden. Der Eintrag ist beim Send-Connector durchzuführen. Hier am Beispiel zur Einbindung eines Add-ons beim Empfang aus dem Internet
Set-SendConnector "ZumAdd-on"
-LinkedReceiveConnector "server\FromInternet"
-SmartHosts Add-on.firma.de
-SmartHostAuthMechanism ExternalAuthoritative
-AddressSpaces $Null
-DNSRoutingEnabled $False
-MaxMessageSize unlimited
Jede Mail die nun auf dem Receive Connector "FromInternet" auf dem "Server" ankommt, wird über den Send-Connector "Zum Add-on" versendet. ein Adressraum ist hierfür nicht erforderlich.
Weitere Links
- ForeignConnector
- SendConnector
- Receiveconnector
- Create Linked Connectors
http://technet.microsoft.com/en-us/library/bb201724.aspx - Routing: Tell Those Messages
Where to Go By using Exchange
2007 SP1 Transport Agents
http://msdn.microsoft.com/en-us/library/bb897564%28v=exchg.80%29.aspx