Vermeiden nicht unterstützter Integrationsmethoden für Exchange

Ursprüngliche KB-Nummer: 3086992

Einführung

In diesem Artikel wird beschrieben, wie Microsoft Customer Service and Support Entwicklern dabei helfen kann, benutzerdefinierte Lösungen zu erstellen, die verschiedene offene Standards verwenden und auch in Microsoft Exchange Server integrieren.

Weitere Informationen

Es ist wichtig, unterstützte APIs und Methoden zu verwenden, wenn Sie Code für Exchange Server schreiben. Manchmal versuchen Entwickler, das Verhalten von Exchange zu verbessern oder Anwendungen auf andere Weise mit Exchange Server zu integrieren, indem sie eine nicht unterstützte Methodik verwenden. Dies kann dazu führen, dass Exchange instabil wird und sich unerwartet verhält.

Die folgenden Methoden werden von Microsoft nicht unterstützt:

• Verwenden des Threadidentitätswechsels für Exchange mithilfe von APIs, die den Threadidentitätswechsel nicht speziell unterstützen.
• Ändern der Outlook Web App (OWA), Exchange Web Services (EWS), Exchange ActiveSync (EAS) oder ähnlicher Streams auf dem Clientzugriffsserver (Client Access Server, CAS).
• Ausführen einer ISAPI-Erweiterung oder eines ISAPI-Moduls in einem Exchange-Anwendungspool.
• Ändern des Kontos, unter dem ein Exchange-Anwendungspool ausgeführt wird.
• Einfügen von DLLs in Exchange-Prozesse auf nicht unterstützte WeiseExchange Server verwendet bestimmte Schnittstellen und Methoden, für die er entworfen und getestet wurde. Da diese speziellen Methoden Features mithilfe einer nicht unterstützten Methodik einführen, betrachtet Microsoft diese Art der Entwicklung als nicht unterstützt.

Wenn Microsoft-Support Agents Anwendungen von Drittanbietern finden, die eine der aufgeführten Methoden zu verwenden scheinen, werden Sie höchstwahrscheinlich aufgefordert, die Anwendung zu entfernen, um zu überprüfen, ob sich das Problem reproduziert. Wenn sich das Problem nicht reproduziert, nachdem die Drittanbieteranwendung entfernt wurde, müssen Sie sich an die Supporttechniker für dieses Produkt wenden, um das Problem zu beheben.

Exchange verfügt über Überprüfungen, um zu verhindern, dass Code einen Threadidentitätswechsel ausführt. Beispielsweise kann Exchange seinen Prozess plötzlich herunterfahren (FastFail). In diesem Fall wird Ereignis 4999 im Exchange-Ereignisprotokoll protokolliert. Sie enthält den folgenden Text:

M.E.D.D.ConnectionPoolManager.BlockImpersonatedCallers

APIs wie EWS, die den Identitätswechsel durch andere Anwendungen zulassen, verfügen über die Mechanismen zum Annehmen der Identität von Konten selbst. Sicherheitssoftware und SSO-Software sind gängige Beispiele für Anwendungen, die den Threadidentitätswechsel verwenden, um Anmeldeinformationen für Aufrufe zu ändern, die an Exchange gesendet werden.

Code von Drittanbietern, der in einer Anwendung im Rahmen des Workerpoolprozesses einer anderen Anwendung ausgeführt wird, kann Probleme verursachen, es sei denn, die Anwendungen werden so erstellt, dass sie miteinander arbeiten. Exchange lässt nicht zu, dass andere Anwendungen unter seinen Arbeitsprozessen ausgeführt werden. Die Exchange-Anwendungspoolprozesse gehören ausschließlich zu Exchange, und Sie sollten keinen Drittanbietercode unter ihnen ausführen. Dies kann zu Konflikten mit Exchange führen und zu Fehlern bei Prozessen führen.

Einige Entwickler ändern das Konto, unter dem Teile von Exchange arbeiten, um funktionen zu erhalten, die sie andernfalls nicht hätten. Dies kann zu Serverabstürzen, Datenbeschädigungen und anderen unerwarteten Problemen führen. Diese Probleme können jederzeit im Prozess auftreten.

Es gibt unterstützte Möglichkeiten, benutzerdefinierte DLLs in Exchange zu integrieren, z. B. benutzerdefinierte Transport-Agents. Es wird nicht empfohlen, eine Methode zu verwenden, die von der Exchange-Entwicklung nicht unterstützt wird. Beispielsweise ist eine erzwungene Einschleusung einer DLL eine nicht unterstützte Methode zum Laden einer benutzerdefinierten DLL in Exchange.

Es ist wichtig, dass Sie Methoden vermeiden, die nicht unterstützt werden, wenn Sie die Option zur Integration von Drittanbieteranwendungen in Exchange in Betracht ziehen. Diese Art von Vorgehensweise kann später schwerwiegende Folgen haben, z. B. verlorene Funktionalität oder die Notwendigkeit, eine Anwendung neu zu schreiben. Am Ende kann es sein, dass Sie auf eine Straßensperre stoßen und keinen Weg haben, in dem Sie vorankommen können.