Kommunikation

Exchange-Edge-Transport-Server bei Microsoft

Kay Unkroth

Kurz zusammengefasst:

• Die Edge-Transport-Serverfunktion in Exchange
• Einrichten einer Testumgebung
• Transport-Agents und -Ereignisse
• Agent-Interna

Laden Sie den Code für diesen Artikel herunter: ExchangeEdge2007_10.exe (354KB)

Microsoft erhält an einem durchschnittlichen Arbeitstag ungefähr 13 Millionen Nachrichtenübermittlungsversuche aus dem Internet. Von diesen werden etwa 10,5 Millionen als nicht legitim blockiert. In kritischen

Situationen, z. B. bei Spamangriffen oder Virenangriffen im Internet, kann das Volumen auf mehr als 90 Millionen Nachrichten ansteigen. Natürlich bezieht sich dieses Ergebnis speziell auf Microsoft. Probleme wie Betrügereien, unerwünschte E-Mails, Phishing, durch E-Mails übertragene Viren, Directory-Harvesting-Angriffe, verteilte Denial-of-Service-Angriffe und ähnliche Themen sind jedoch nicht nur für Microsoft aktuell. Wie ist es angesichts dieser Probleme möglich, die Zustellung aller legitimen Nachrichten an die Benutzer sicherzustellen und gleichzeitig die Überflutung mit unzulässigem, schädlichem Inhalt aus der Messagingumgebung fernzuhalten?

Eine Möglichkeit, einen zuverlässigen Messagingschutz zu erreichen, besteht darin, Edge-Transport-Server für Exchange Server 2007 und Forefront Security für Exchange Server in einem Umkreisnetzwerk zwischen dem Internet und der Produktionsumgebung bereitzustellen. Dadurch wird ein organisiertes Team von mehr als 10 Edge-Transport-Agents in Ihrem Umkreis platziert, um Produktionssysteme und Benutzer zu schützen. Die Gründe dafür, unerwünschten Inhalt zum frühestmöglichen Zeitpunkt zu blockieren, liegen auf der Hand. In Anbetracht der Last, die Ihre Messagingumgebung in einer kritischen Situation bewältigen müsste, findet dies idealerweise bereits statt, bevor der Inhalt Ihre Server erreicht. Die Aufgabe des Messagingschutzes umfasst jedoch viel mehr als nur das Blockieren von Nachrichten.

Dies ist der erste Teil einer zweiteiligen Reihe, in der die in Exchange Server 2007 und Forefront Security für Exchange Server verfügbare Architektur und die Hauptfeatures der entsprechenden Antispam- und Antivirus-Agents erörtert werden. In diesem ersten Artikel soll auf realistische und praktische Art und Weise aufgezeigt werden, wie eine Testumgebung erstellt werden kann, die den Messagingschutzentwurf reflektiert, den Microsoft in seiner eigenen Unternehmensproduktionsumgebung verwendet. Anschließend wird die Edge-Transport-Architektur von Exchange Server 2007 detaillierter besprochen.

Im gesamten Artikel werden Skripts und Batchdateien häufig verwendet, um die wichtigsten Konfigurationsaufgaben zu automatisieren. Diese Dateien enthalten Kommentare, in denen die einzelnen Schritte erklärt werden. Die Skripts stehen zum Download auf der TechNet Magazin-Website unter technetmagazine.com/code07.aspx zur Verfügung

Edge-Transport-Topologie

In Abbildung 1 wird der von Microsoft IT in der Unternehmensproduktionsumgebung implementierte Edge-Transport-Entwurf illustriert. Bevor näher auf die Edge-Transport-Architektur eingegangen wird, sollen ein paar interessante Entwurfsfeatures vorgestellt werden. Die vollständigen Implementierungsdaten finden Sie im IT Showcase-Whitepaper, auf das in der Randleiste „Exchange-Ressourcen“ verwiesen wird.

Abbildung 1** Edge-Transport-Topologie bei Microsoft **(Klicken Sie zum Vergrößern auf das Bild)

Wenn Sie Abbildung 1 analysieren, stellen Sie fest, dass die Edge-Transport-Topologie bei Microsoft vollständig redundant ist. Es gibt an keinem Ort eine einzelne Fehlerquelle. Für den Lastenausgleich verwendet Microsoft IT extern DNS-Roundrobin sowie intern Messagingconnectors mit mehreren Bridgeheads. Beachten Sie auch, dass alle Transportserver (Hub-Transport und Edge-Transport) für die Virenüberprüfung Forefront Security für Exchange Server ausführen. Dies ermöglicht Microsoft IT, alle eingehenden, ausgehenden und internen Nachrichten zu scannen, sobald die Nachrichten einen Transportserver in der Nachrichtenroutingtopologie erreichen.

Ein anderes wichtiges sicherheitsbezogenes Entwurfsfeature besteht darin, dass die Edge-Transport-Server nicht Teil der Unternehmensumgebung von Active Directory® sind. Es ist nicht erforderlich, Edge-Transport-Server in Active Directory-Gesamtstrukturen bereitzustellen. Um jedoch ein konsistentes Verwaltungsframework beizubehalten, einen gemeinsamen Satz an Richtlinien anzuwenden und die einmalige Anmeldung zu unterstützen, stellt Microsoft IT alle Edge-Transport-Server in einer Extranetgesamtstruktur bereit, die von der Produktionsumgebung getrennt ist.

Schließlich können Sie deutlich erkennen, dass alle Nachrichten aus dem Internet Microsoft über Edge-Transport-Server erreichen, die sich in Nordamerika befinden. Die Edge-Transport-Server in Dublin und Singapur verarbeiten nur ausgehende Nachrichten. Der Vorteil, den gesamten eingehenden Datenverkehr über die Edge-Transport-Server in Nordamerika abzuwickeln, besteht darin, Sicherheits- und Antispamkontrollen zu zentralisieren und gleichzeitig die Übertragung ausgehender Nachrichten von großen regionalen Datenzentren über den internen Messagingbackbone zu vermeiden.

Microsoft IT-Systemingenieur Omesh Desai hat die Edge-Transport-Topologie bei Microsoft entworfen. Als ich ihn zu den wichtigsten Entwurfsfeatures befragte, antwortete er: „In diesem Edge-Transport-Entwurf werden systemeigene Antispam- und Antivirusfunktionen in Exchange genutzt, um einen Messagingschutz auf mehreren Ebenen des Messagingbackbones zu erzielen. Die Messagingumkreissicherheit hat höchste Priorität. Sehr wichtig ist für uns jedoch auch ein unkompliziertes Verwaltungsmodell. Mithilfe von Edge-Transport-Servern können Sie die Sicherheit über strengere Firewallkonfigurationen erhöhen und gleichzeitig die Genauigkeit der Spamfilterung über IP-Zuverlässigkeitsdienste, automatische Inhaltsfilterupdates, die Aggregation von Listen sicherer Adressen und die E-Mail-Poststempelprüfung verbessern. Die gesamte interne Server-zu-Server-Kommunikation wird standardmäßig verschlüsselt. Nach Möglichkeit wird zudem die Kommunikation mit externen Zielen verschlüsselt.

In den Edge-Transport-Servern werden 64-Bit-Prozessoren mit zwei Kernspeichern und acht Gigabyte an Speicher verwendet. Sechs dieser Server mit Lastenausgleich über zwei Datenzentren stellen genügend Kapazitäten zur Verfügung, um sogar Spitzen der Nachrichtenübermittlung, z. B. bei Virenangriffen im Internet, zu bewältigen.“

Edge-Transport-Testumgebung

Einrichten der Testumgebung

Da es als Best Practice empfohlen wird, nicht existierende Domänennamen und private IP-Adressen zu verwenden, verwende ich AdventureWorks.com und IP-Adressen aus den Bereichen 192.168.xxx.0-24. Es gibt keine redundanten Systeme oder Firewallarrays, weil der Lastenausgleich oder die Fehlertoleranz nicht getestet werden. (Außerdem können natürlich echte Firewallsysteme, die Microsoft IT verwendet, aus Sicherheitsgründen nicht besprochen werden.) Solche Details sind für diese Testumgebung nicht relevant.

In dieser Testumgebung wird ISA Server 2006 verwendet, weil dies wahrscheinlich eines der am häufigsten verwendeten Firewallsysteme in Verbindung mit Exchange Server 2007 ist. Wenn ISA Server 2006 sowohl auf der äußeren als auch auf der inneren Firewall ausgeführt wird, kann die Komplexität der Testumgebung auf einen überschaubaren Grad beschränkt werden. Für Produktionsumgebungen ist jedoch zur Erhöhung der Sicherheit die Verwendung unterschiedlicher äußerer und innerer Firewallsysteme empfehlenswert. Es würde den Umfang dieses Artikels überschreiten, auch Richtlinien für die Bereitstellung von IP-Sicherheit (IPSec) oder die Vorbereitung der Umgebung auf Transport Layer Security (TLS) zu erörtern.

Es wurden jedoch virtuelle Computer und 32-Bit-Evaluierungssoftware verwendet, die Sie von der Microsoft-Website herunterladen können. Microsoft unterstützt nicht die sich in der Produktion befindende 32-Bit-Version von Exchange Server 2007, dies ist jedoch in einer Testumgebung nicht relevant.

Diese Testumgebung basiert nach Möglichkeit auf Standardeinstellungen. Nur die IP-Konfiguration, Firewalls und DNS-Zonen müssen vor dem Ausführen von Exchange Server 2007-Setup und dem Abonnieren des Edge-Transport-Servers zur Produktionsumgebung zusätzlich konfiguriert werden. Weitere Einzelheiten zur IP-Konfiguration finden Sie in der IP-Configuration.xls-Datei zur Testumgebung im Download zu diesem Artikel. Wenn Sie die gleichen IP-Adresszuweisungen verwenden, können Sie schnell die äußere Firewall mit der Bezeichnung ISA01 konfigurieren, indem Sie das ISA01_Firewall_Policies.vbs-Skript direkt auf dem ISA01-Computer ausführen und die ISA02_Firewall_Policies.vbs für die innere Firewall (ISA02) verwenden. Im Download zu diesem Artikel sind auch Batchdateien für die Konfiguration der DNS-Server (INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat und AD02_DNS_Config.bat) enthalten. Da diese Batchdateien das DNS-Befehlszeilentool (dnscmd.exe) verwenden, müssen Sie die Windows-Supporttools installieren. Andernfalls müssen die DNS-Einträge über die DNS-Konsole manuell erstellt werden.

Um Störungen von vorhandenen Umgebungen zu vermeiden, ist die Testumgebung nicht mit dem Internet verbunden. Diese Isolierung ist eine gute Vorsichtsmaßnahme. Sie verursacht zwar beim Herunterladen aller Signaturupdates, IP-Zuverlässigkeitsdienste und Inhaltsfilterupdates Fehler, dies ist jedoch für die Testzwecke nicht von Bedeutung. Um Fehlermeldungen zu vermeiden, wechseln Sie in der Forefront Server Security Administrator-Konsole zu „Scanner-Updates“. Setzen Sie dann die Aktualisierungsrate für alle Scanmodule auf „Einmal“, und geben Sie ein Datum in der Vergangenheit an.

Um diese Features in aktivem Zustand zu erforschen, empfiehlt es sich, eine Testumgebung zu erstellen – ein Produktionssystem sollte aus verständlichen Gründen niemals für Testzwecke verwendet werden. Es wird mindestens ein Server benötigt, um Exchange Server 2007 für die Mailbox-, ClientAccess- und Hub-Transport-Serverfunktionen auszuführen. Sie benötigen einen zweiten Exchange Server für die Edge-Transport-Serverfunktion. Sie können die Edge-Transport-Serverinstallation auslassen, wenn Sie alle Transport-Agents auf dem Server mit mehreren Rollen bereitstellen, indem Sie das Install-AntispamAgents.ps1-Skript ausführen. (Dies befindet sich auf Hub-Transportservern im Ordner %ProgramFiles%\Microsoft\Exchange Server\Skript.) Diese Methode entspricht jedoch nicht der Microsoft IT-Bereitstellung. Für eine realistische Testumgebung müssen Sie weitere Server integrieren. Abbildung 2 zeigt die Testumgebung, die für die Recherche dieses Artikels verwendet wurde. Eine ausführlichere Illustration ist im Download zu diesem Artikel verfügbar. Weitere Informationen zum Einrichten der Testumgebung finden Sie in der Randleiste „Einrichten der Testumgebung“.

Abbildung 2** Edge-Transport-Testumgebung **(Klicken Sie zum Vergrößern auf das Bild)

Während des Abonnements des Edge-Transport-Servers und der Konfiguration zugeordneter Connectors entfernt Microsoft IT alle Standardconnectors und erstellt anschließend vier Sendeconnectors, um eine effiziente Kommunikation mit unterschiedlichen Arten von SMTP-Hosts (Simple Mail Transfer Protocol) und internen Hub-Transportservern zu ermöglichen. Der erste Sendeconnector ist ein allgemeiner Internetconnector für alle Ziele, die bestimmten Adressraumdefinitionen nicht entsprechen

Die zweite Sendeconnector ist ein Internetconnector mit ausführlichen Adressraumdefinitionen für bekannte Ziele, die ESMTP (HELO-Domänen) nicht unterstützen. Durch Setzen des ForceHELO-Parameters für diesen Connector auf „$true“ vermeidet Microsoft IT beim Einrichten von SMTP-Verbindungen eine unnötige Sequenz von EHLO, Fehlerantwort 500, HELO.

Der dritte Sendeconnector ist ein Internetconnector mit ausführlichen Adressraumdefinitionen für Partner und andere Remotedomänen, die TLS für eine sichere Kommunikation über verschlüsselte Verbindungen (TLS-Domänen) unterstützen. Bei diesem Connector wird der RequireTLS-Parameter auf „$true“ gesetzt.

Der vierte Sendeconnector ist ein eingehender Connector für die Übertragung von empfangenen Internetnachrichten an Hub-Transportserver in der Unternehmensumgebung. Weitere Einzelheiten zur Konfiguration des Edge-Transport-Servers finden Sie im IT-Showcase-Whitepaper, auf das in der Randleiste „Exchange-Ressourcen“ am Endes dieses Artikels verwiesen wird.

Um eine Connector-Topologie im Microsoft IT-Stil auf die Testumgebung anzuwenden, wurde ein skriptbasiertes Verfahren eingesetzt, das Omesh Desai für die interne Microsoft IT-Verwendung erstellt hat. Aus Sicherheitsgründen wurden die einzelnen Befehle geändert und drastisch verkürzt. Die entstandene Connectortopologie entspricht jedoch trotzdem der Microsoft IT-Topologie. Dies sind die Schritte:

1. Entfernen Sie die Standardconnectors auf dem Exchange-Server mit mehreren Rollen (HUB-MBX-01) und auf dem Edge-Transport-Server (EDGE01).
2. Erstellen Sie auf HUB-MBX-01 einen neuen Empfangsconnector, indem Sie das HUB-MBX-01_recv_connector.ps1-Skript ausführen, das Sie im Download für diesen Artikel finden.
3. Erstellen Sie auf EDGE01 zwei neue Empfangsconnectors für die interne und externe Messagingkonnektivität, indem Sie das EDGE01_recv_connector.ps1-Skript ausführen.
4. Erstellen Sie durch Ausführen des folgenden Befehls eine Abonnementdatei auf EDGE01:

    New-EdgeSubscription -FileName 
    "c:\subscriptionfile.xml" 

Kopieren Sie dann die entstandene Abonnementdatei in den Stammordner des Hub-Transportservers (c:\subscriptionfile.xml).

5. Stellen Sie sicher, dass der Pfad zur Abonnementdatei auf HUB-MBX-01 c:\subscriptionfile.xml ist, und führen Sie anschließend das HUB-MBX-01_complete_subscription.ps1-Skript aus. Dieses Skript importiert die Abonnementdatei für die Edge-Synchronisierung, ohne automatisch einen Sendeconnector zu erstellen. Es erstellt die Sendeconnectors für die Internetkonnektivität sowie die interne Konnektivität und repliziert die entstehende Konfiguration auf dem Edge-Transport-Server über Edge-Synchronisierung.

6. Überprüfen Sie die Konfiguration, indem Sie vom Internethost Testnachrichten als Contoso.User@contoso.com und Fabrikam.User@fabrikam.com an Administrator@adventureworks.com senden. Antworten Sie auf die empfangenen Nachrichten, um sicherzustellen, dass die eingehende und ausgehende Nachrichtenübermittlung funktioniert.

Es empfiehlt sich, die einzelnen Skriptdateien in Editor zu öffnen und die Cmdlets und Parameter, die diese Skripts für die Konfiguration verwenden, zu analysieren. Ausführliche Informationen zu diesen Cmdlets und Parametern finden Sie online in der Produktdokumentation für Exchange Server 2007.

Edge-Transport-Architektur

In diesem Abschnitt wird auf die Edge-Transport-Agents eingegangen, die seit der Installation der Edge-Transport-Serverfunktion darauf gewartet haben, dass sie jemand mit HELO oder EHLO begrüßt. Wenn Sie das Get-Transport-Agent-Cmdlet auf dem Edge-Transport-Server ausführen, werden die 11 Einträge angezeigt, die in Abbildung 3 aufgelistet sind. Alle Agents sind standardmäßig aktiviert, um mit den entsprechenden Einstellungen Messagingschutz zur Verfügung zu stellen.

Figure 3 Transport-Agents

Im Get-Transport-Agent-Cmdlet und in Abbildung 3 werden die Agents in der Reihenfolge ihrer Priorität aufgelistet. Dabei handelt es sich jedoch nicht um die Reihenfolge, in der die Agents ihre Arbeit durchführen. Die Arbeitsreihenfolge hängt hauptsächlich von der Sequenz der SMTP-Empfangsereignisse und Routingereignisse ab, für die die Agents registriert sind. Um zu sehen, wie Agents und Ereignisse zusammenarbeiten, sehen Sie sich das Diagramm in Abbildung 4 an. Es zeigt, wie Transport-Agents in die Edge-Transport-Architektur integriert sind.

Abbildung 4** Transport-Agents innerhalb der Edge-Transport-Architektur **(Klicken Sie zum Vergrößern auf das Bild)

Transportereignisse finden in verschiedenen Phasen während der Nachrichtenverarbeitung statt, um zusätzlichen Code für die Spamfilterung, die Virenüberprüfung und andere Aufgaben aufzurufen. In diesem locker verbundenen und erweiterbaren Entwurf übernimmt der Edge-Transport-Prozess (Edge-Transport.exe) die Rolle der Ereignisquelle. Bei den Ereignishandlern bzw. den Transport-Agents handelt es sich um verwaltete Delegatobjekte, die auf Microsoft® .NET Framework 2.0 basieren und bei der Ereignisquelle registriert sind, um Rückrufbenachrichtigungen zu empfangen.

Abbildung 5 zeigt die Ereignisregistrierungen für alle Agents, die auf einem Edge-Transport-Server mit Forefront Security installiert sind. Diese Registrierungen sind zunächst vielleicht aufgrund der großen Anzahl an Agent-Registrierungen etwas schwierig zu sortieren. Wenn Sie den Get-TransportPipeline | Format-List-Befehl auf einem Edge-Transport-Server ausführen, können Sie die Registrierungen für jedes einzelne Transportereignis einfacher analysieren. Stellen Sie nur sicher, dass der Microsoft Exchange-Transportdienst (MSExchangeTransport.exe) ausgeführt wird und seit dem letzten Dienstneustart mindestens eine Nachricht über den Edge-Transport-Server gesendet wurde. Wie die Ausgabe zeigt, können sich mehrere Agents für den gleichen Ereignistyp registrieren, und jeder einzelne Agent kann sich für mehrere Ereignisse registrieren. Die Ereignisregistrierungen hängen lediglich von den Verarbeitungsanforderungen des entsprechenden Agents ab.

Abbildung 5** Ereignisregistrierungen für Transport-Agents **(Klicken Sie zum Vergrößern auf das Bild)

Eines der wichtigsten Ereignisse ist das OnSubmittedMessage-Routingereignis, das ausgelöst wird, wenn eine Nachricht die Übermittlungswarteschlange erreicht. Alle Nachrichten müssen diese Warteschlange durchlaufen, sei es, dass Sie über SMTP, das Dateisystem oder eine andere Methode empfangen wurden. Das Kategorisierungsmodul ist eine zentrale Komponente der Transportarchitektur von Exchange Server. Es ist für die Empfängerauflösung, die Nachrichtengabelung und das Routing sowie die Generierung der Benachrichtigung über den Zustellungsstatus (Delivery Status Notification, DSN) verantwortlich. Das OnSubmittedMessage-Ereignis ist deshalb eine perfekte Registrierungsmöglichkeit für Agents, die alle empfangenen Nachrichten verarbeiten müssen. Der FSE-Routing-Agent ist eine Forefront Security-Komponente, die für das OnSubmittedMessage-Ereignis registriert ist, um alle empfangenen Nachrichten an die Virenüberprüfungsmodule zu übergeben. Da der FSE-Routing-Agent für das OnSubmittedMessage-Ereignis registriert ist, kann keine Nachricht die Antiviruslösung umgehen.

Warum registrieren sich dann nicht alle Agents für das OnSubmittedMessage-Ereignis? Der Grund liegt darin, dass unerwünschte Nachrichten zum frühestmöglichen Zeitpunkt blockiert werden sollen, und zwar bevor der Server eine erfolgreiche Lieferung bestätigt. Andernfalls müssen Ihre Server möglicherweise 90 Millionen unerwünschte Nachrichten während eines Spam- oder Virusangriffs verarbeiten, die vielleicht 90 Millionen Unzustellbarkeitsberichte (Non-Delivery Reports, NDRs) generieren, was wiederum eine ernsthafte Bedrohung für Unbeteiligte darstellen könnte. Spam- und Virusangriffe verwenden fast immer gefälschte Absenderinformationen. Das Senden von Millionen von NDRs an Empfänger, von denen die ursprünglichen Nachrichten nicht erstellt wurden, ist nicht nur eine Verschwendung Ihrer Ressourcen und der Ressourcen der Zielorganisationen, sondern gibt böswilligen Benutzern auch die Gelegenheit, Mailüberflutungen und verteilte Denial-of-Service-Angriffe zu starten. Es ist zu Ihrem eigenen Schutz und dem anderer wichtig, schädliche Nachrichten frühzeitig aufzuhalten.

Um eine Nachricht effizient zu blockieren, muss ein Transport-Agent den SMTP-Nachrichtenaustausch mit dem Remotehost unterbrechen, bevor der Server den Empfang der Daten mit einem 250 OK-Statuscode bestätigt. Gemäß dem SMTP-Prinzip zur Speicherung und Weiterleitung kann Ihr Server alle empfangenen Daten sicher verwerfen, ohne NDRs zu generieren, wenn die Nachrichtenübermittlung nicht bestätigt wurde. Dies kann mit SMTP-Empfangs-Agents erreicht werden. Sie interagieren mit der SMTP-Sitzung, weil die Transportpipeline diese auf SMTP-Empfangsereignissen basierten Agents aufruft, während der Remotehost eine Verbindung zum Server herstellt, eine SMTP-Sitzung einrichtet, SMTP-Verben überträgt, Nachrichten sendet und die Verbindung beendet. (Die SMTP-Empfangsereignisse für jeden Schritt sind in Abbildung 6 aufgelistet.) Aufgrund der Möglichkeit, Nachrichten vor der Lieferung zurückzuweisen und die Verbindung zu Remote-SMTP-Hosts zu trennen, sind alle Antispam-Agents für Exchange Server 2007 als SMTP-Empfangs-Agents implementiert.

Figure 6 SMTP-Sitzungsereignisse

Sie sollten den Unterschied zwischen SMTP-Empfangs-Agents und Routing-Agents hinsichtlich ihres Verarbeitungskontexts kennen. Während Routing-Agents vollständigen Zugriff auf die Nachrichteneigenschaften haben, sind SMTP-Empfangs-Agents kontextbezogener, da diese Agents mit der SMTP-Sitzung interagieren. Zum Beispiel kann ein Spamfilter erst auf Nachrichteneigenschaften reagieren, wenn der Remotehost die Nachricht tatsächlich übertragen hat. Folglich ist es wichtig, den Agent für das richtige SMTP-Empfangsereignis zu registrieren. Weitere Informationen enthalten Sie in der Randleiste „Entwicklung von Transport-Agents“.

Exchange-Ressourcen

• Edge-Transport und Messagingschutz für Microsoft Exchange Server 2007 (Technisches Whitepaper in Microsoft IT Showcase)
• Windows PowerShell-Skriptcenter
• Exchange Server 2007-TechCenter
• Microsoft Exchange-Teamblog „You Had Me From EHLO“

Bleiben Sie dran

Im nächsten Artikel werden die Transportarchitektur und die Testszenarios eingehender beleuchtet. In diesem Artikel wurden viele Themen angesprochen, von der Bereitstellung von Edge-Transport-Servern im Microsoft IT-Stil bis zu den internen Ereignissen, die in der Transportpipeline während der Nachrichtenverarbeitung ausgelöst werden. Im nächsten Artikel dieser zweiteiligen Reihe wird das Verhalten von Edge-Transport-Agents in einigen interessanten Testszenarios analysiert.

Ich empfehle Ihnen, in der Zwischenzeit die 90 Tage gültige Testversion von Microsoft Visual Studio 2005 Professional Edition herunterzuladen (go.microsoft.com/fwlink/?LinkId=98043) und die Erklärungen des Autors zur Kompilierung und Installation von Beispiel-Agents in Ihrer Testumgebung zu befolgen. Selbst wenn Sie kein Entwickler sind, dürften Sie bei diesen Aufgaben keine Schwierigkeiten haben. Angesichts der Tatsache, wie unkompliziert die Entwicklung benutzerdefinierter Agents in Exchange Server 2007 mit Visual Studio 2005 ist, würde es mich nicht überraschen, wenn die Anzahl der auf diesen Komponenten basierten Geschäftsanwendungen in Zukunft weiter wächst.

Kay Unkroth ist Unternehmer und bereits seit mehr als 15 Jahren als Supporttechniker, Systementwickler, Berater, Schulungsleiter und Autor für Microsoft-Servertechnologien tätig. Außerdem ist er Gründungsmitglied und Vorsitzender der Biblioso Corporation. Dieses Unternehmen spezialisiert sich auf verwaltete Dokumentations- und Lokalisierungsdienste.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.