Beiträge von CSchmidt

    Oh no no no. Stimmt, habe ich blöd formuliert.


    Wir benutzen den Dummy-Adressraum zum Finden der Config. ExSBR weist der Nachricht beim Routing explizit den Connector zu. Wir übertragen keine Mail oder so. Das macht Exchange besser als wir es je programmieren könnten. Unsere Aufgabe ist die ENTSCHEIDUNG, welcher Connector benutzt wird. Die Eigenschaften des Connectors (Smarthostname, Zeitplan oder was auch immer) werden von Exchange dann schon ganz normal genutzt.


    Exchange nutzt den Connector also schon, aber nur unter unserem Zwang.

    Hallo, lustig, wenn man in einem Thread einen Link aufs eigene Blog findet. ;) Natürlich darf man über office 2010 bloggen und reden. NDA ist für Fat Client Applikationen nicht mehr aktuell. Sonst hätte ich das Thema Multiple Accounts in Outlook 2010 nie gepostet. Ich musste ja schon Monate vorher schweigen, da ich das Glück hatte, schon mit einer sehr frühen Alpha arbeiten zu können.


    Zum Thema:


    Das Problemchen wird m.E. nicht durch Exchange sondern durch den CLient gelöst werden. Outlook 2010 adressiert das Thema definitiv.


    Alternativ empfehle ich meinen Kunden seit Jahr und Tag die Nutzung von OWA für Info-Accounts usw. Wenn es massiv von x usern genutzt wird, haben wir den Usern auch schon automatisiert die OWA-URLs in die Favoriten gespielt.


    LG, Chrischmi

    Die Sache ist viel einfacher, als ich nachts schreibe. Ein Beispielszenario:


    1000 User in der Exchange Org:


    50 eigene User vom Provider exhosting.de (A)
    350 User vom Kunden contoso.com (B)
    200 User vom Kunden tailspin-toys.com (C)
    400 User vom Kunden bike-adventure.de (D)


    A ist Hoster und nutzt seine Exchange Produktionsumgebung auch für sein Adminteam. Er nutzt für ausgehende Mails einfach den Default SMTP-Send-Connector mit dem SMTP-*-Adressraum.


    B ist die Tochter eines amerikanischen Konzerns. Die deutschen Benutzer arbeiten mit derselben SMTP-Domäne contoso.com wie die Mutter. Amerika nimmmt eingehende Mails an (MX) und leitet an die Routingdomain exchange.exhosting.de des deutschen Provider weiter, die den Usern als Secondary Proxy hinterlegt ist. Das macht Exchaneg noch alles selbst.


    Die Amerikaner von B haben eine Security Policy, dass alle augehenden Nachrichten von Ihnen gescannt werden müssen. Hier kommen wir zu einem Problem: Exchange routet im wesentlichen ausschließlich basierend auf den Eigenschaftem des Empfängers. Hier müssen wir aber die ausgehenden Nachrichten umleiten Richtung USA basierend auf den Absendern. Wir legen dazu einen weiteren SMTP-Send-Connector mit einem Adressraum contoso.com.smarthost und dem namen contoso.com_ExSBR an. Dank ".smarthost" ignoriert Exchange diesen Connector mehr oder minder, denn niemals werden Nachrichten an diese TLD versendet. Exchange findet den Default-SMTP-Connector mit SMTP:* und versucht die Mail über diesen Connector zu versenden. Allerdings schaltet sich hier nun unser Transport Agent ein bevor die Mail den Connector erreicht. ExSBR erkennt Absenderdomain contoso.com = Connector für contoso.com und erzwingt den Send-Connnector contoso.com_ExSBR für diese Nachricht.


    C ist komplett mit allen Usern bei dem Hoster. Er hat den Premium Service gebucht und lässt seine externen Nachrichten vom Hoster archivieren. Eingehende Mails gehen direkt auf den MX des Hosters, dann ins SMTP-basierte Archiv, dann ins Exchange. Ausgehende Nachrichten werden von ExSBR über das Matching Senderdomänenname = Connectorname wie oben umgeroutet auf einen Connector, der auf das Archiv zeigt. Mailweg ist dann Exchange - Archiv - Internet.


    D ist komplett beim Hoster und nutzt den Standardtarif. Eingehende Nachrichten gehen über den MX des Hosters direkt auf Exchange. Ausgehende Nachrichten gehen über den Default Send Connector raus. ExSBR ignoriert diese Nachrichten und überlässt sie dem Default Routing von Exchange.


    [Blockierte Grafik: http://chrischmi.de/blog/images/ExSBR%20Routing.gif]


    Oben noch eine kleine Grafik. Hoffe, Licht ins Dunkel gebracht zu haben.


    Beste Grüße, Christoph Schmidt

    Hallo André, Hallo alle Mitleser,


    als Mitarbeiter des Hersteller von ExSBR / Sender Based Routing for Exchange Server habe ich grad zufällig diesen Thread entdeckt.


    ptecs ExSBR benutzt zum Routen Standard-Microsoft-SMTP-Connectoren. Allerdings ist es die Aufgabe von ExSBR, in das Exchange-Routing einzugreifen, um automatisiert ABSENDERabhängig einen alternativen Connector zuzuweisen, der dann z.B. einen alternativen Smarthost verwendet. Dies wird beispielsweise von Managed Service Providern genutzt, um bestimmte Kundendomänen über den Smarthost des Internet Providers zu schicken, der für die DNS-Domäne verantwortlich ist.


    Zur Auswahl des Connectors wird von ExSBR wie in der André vorliegenden Doku beschrieben, eine Art Dummy-Adressraum verwendet. Diese Sondersituation, die eine Administration des Transport Agent mit der Microsoft GUI und der Powershell erlaubt, kann selbstverständlich niemand in einem öffentlichen Forum rechnen.


    André hat von uns kostenfrei eine voll funktionsfähige Demolizenz für seinen Heimserver bekommen. Sein Ziel war es, die beiden Postfächer auf seinem Server mit zwei verschiedenen Smarthosts (GMX und HTP) zu versorgen. Letzter Status war am 05.05.: "Hallo Herr Schmidt, Am Wochenende hatte ich Zeit um Ihre Software zu installieren und ich muss sagen ich bin sehr begeistert:-) Anleitung hat vollkommen ausgereicht und die Software funktioniert wunderbar:-)"


    Dies nur soweit hier der Eindruck entstanden ist, dass unser Produkt, welches normalerweise in Umgebungen zwischen 500 und mehreren 1000 Postfächern im Einsatz ist, nicht funktioniert.


    Zum eigentlichen Problem: Ein für ExSBR konfigurierter Connector verfügt nur über einen auf .smarthost endenden Adressruam. Im vorliegenden Fall also gmx.de.smarthost bzw. htp-tel.de.smarthost. Klingt für einen Exchange-Spezialisten komisch, passt aber trotzdem. ;) Zur Analyse des Problems wäre es am einfachsten den Debug-Mode einzuschalten und die Eventlogs dann zu kontrollieren. ExSBR wird dann sehr gesprächig. Aber ich denke, das Exchange-Konfigurationsproblem habe ich schon erkannt.


    Für Exchange muss natürlich immer ein Ausgang ins Internet (Adressraum SMTP:*)gelassen werden. Wenn man *nur* zwei Connectoren mit Dummy-Adressräumen erstellt, dann kann Exchange nicht routen. D.h. Exchange findet keinen Weg und schickt dann einen NDR zurück. Als Konsequenz kommt die Mail niemals auf dem Hub Transport Service und damit auch nicht in unserem Produkt an.


    Die Lösung ist, einen beliebigen Send Connector mit einem Adressraum SMTP:* zu erstellen. Dies kann in diesem Sonderfall eines Heimservers mit 2 (!) Postfächern gerne auch einer der beiden ExSBR-Connectoren sein (wie hier im Forum vorgeschlagen). In Unternehmensumgebungen wäre das eher der Standardweg zum nächsten Smarthost (Virenscanner etc.) oder ein Verweis zum direkten Versenden ins Internet.


    Gerne schicken wir auch das aktuelle Manual nochmal zu, Andre hat ja meine Kontaktdaten.


    Puuh, garnicht so einfach das Produkt zu erläutern, wenn die Leser das Problem garnicht haben, das vom Produkt gelöst wird. ;) Daher lege ich unseren erläuternden Flyer zum Thema einfach mal bei. Ich hoffe, damit nicht gegen Forumsregeln (Werbung etc.) zu verstoßen.


    http://www.nobbysweb.de/commun…bb/6764_4a8dfc552d7b0.pdf


    Mit besten Grüßen,


    Christoph Schmidt