Vergleichen der lokalen Exchange Online- und Exchange-Clientprogrammierung
Erfahren Sie mehr über die Entwurfsüberlegungen zum Erstellen einer verwalteten EWS-API- oder EWS-Clientanwendung, die für Exchange Online und exchange lokal funktioniert.
Clients und Webdienste in Exchange, auf die sie abzielen, funktionieren größtenteils auf die gleiche Weise, unabhängig davon, ob es sich bei dem Ziel um ein Exchange Online, Exchange Online als Teil von Office 365 oder um einen lokalen Exchange-Server handelt. Es gibt jedoch einige Ausnahmen, und Sie sollten sicherstellen, dass Ihre Anwendung sie verarbeiten kann. Verwenden Sie die Informationen in diesem Artikel, um Ihren Client so zu entwerfen, dass er sowohl Exchange Online als auch exchange lokal als Ziel verwendet.
Überlegungen zur Programmierung des AutoErmittlung-Clients
AutoErmittlung stellt Konfigurationsinformationen für Exchange-Clients bereit. Eine Clientanwendung kann ihre Konfigurationsinformationen auf eine von drei Arten ermitteln, je nachdem, ob der Client auf Exchange Online oder exchange lokal ausgerichtet ist.
Tabelle 1. AutoErmittlungsdiensttypen und Exchange-Anwendbarkeit
| AutoErmittlungsdiensttyp | Gilt für |
|---|---|
| SOAP-AutoErmittlung |
Exchange Online und Lokale Exchange-Versionen ab Exchange 2010 |
| POX-AutoErmittlung |
Exchange Online und lokale Exchange-Versionen ab Exchange 2007 |
| Dienstverbindungspunktsuche (Service Connection Point, SCP) |
Lokale Versionen von Exchange ab Exchange 2007 |
Zusätzlich zu den Clientkonfigurationsinformationen geben SOAP- und POX-AutoErmittlung auch die Exchange-Dienstversion zurück und geben an, ob der Dienst von Exchange Online gehostet wird. Diese Informationen werden in verschiedenen Elementen zurückgegeben, je nachdem, welche AutoErmittlung Sie verwenden.
Tabelle 2. AutoErmittlungselemente, die Dienstversion und Exchange Online Hostinginformationen zurückgeben
| AutoErmittlungsdiensttyp | XML-Element, das die Dienstversion enthält | XML-Element, das angibt, ob der Benutzer über ein Exchange Online-Konto verfügt |
|---|---|---|
| SOAP-AutoErmittlung |
Setting-Element (SOAP) mit dem CasVersion-Textwert . |
Setting-Element (SOAP) mit dem UserMSOnline-Textwert . |
| POX-AutoErmittlung |
ServerVersion (POX) |
MicrosoftOnline |
Stellen Sie sicher, dass Ihr Client diese Informationen erfasst, damit er auf den Featuresatz ausgerichtet werden kann, der auf dem Exchange-Server verfügbar ist. Dies kann hilfreich sein, um zu bestimmen, ob Ihr Client ein anderes Verhalten erwarten kann, je nachdem, ob sich das Postfach des Benutzers in einer Exchange Online oder einer lokalen Exchange-Organisation befindet.
Testen und Protokolldateien in Anwendungen, die auf Exchange Online abzielen
Exchange Online bietet keinen Zugriff auf die EWS-Protokolldateien, EWS-Leistungsindikatoren und EWS-bezogenen Dienstereignisse, die auf lokalen Exchange-Servern verfügbar sind. Der Zugriff auf diese ist jedoch nützlich, um die Leistung Ihrer Anwendung bei der Interaktion mit EWS zu ermitteln. Stellen Sie sicher, dass Sie Ihre Anwendung mit einem lokalen Exchange-Testserver testen, damit Sie die Leistung optimieren können. Wenn möglich, können Sie die Drosselungseinstellungen auf Dem Testserver so ändern, dass sie den Drosselungseinstellungen für Exchange Online entsprechen, damit Sie bewerten können, wie sich Ihre Anwendung verhält, wenn sie eine Verbindung mit Exchange Online herstellt.
Tipp
Sie können das EWSRelentless-Tool verwenden, um einen EWS-Auslastungstest durchzuführen. Sie können dieses Tool mit einem Testserver, den EWS-Protokollprotokollen, EWS-Leistungsindikatoren, Dienstereignissen und den EWS-Drosselungseinstellungen verwenden, um die Leistung von EWS unter Last besser zu verstehen.
Drosselungseinstellungen und Exchange Online
Die Standardwerte für die EWS-Drosselungseinstellungen unterscheiden sich für Exchange Online von denen für lokale Exchange-Instanzen. Außerdem können Sie Exchange Online Drosselungseinstellungen nicht ändern. Sie können Exchange-Verwaltungsshell-Cmdlets verwenden, um die Drosselungseinstellungen für exchange lokal zu ermitteln. Diese Cmdlets sind jedoch nicht für Exchange Online aktiviert.
Cmdlets und Konfigurationseinstellungen der Exchange-Verwaltungsshell
Eine Reihe von Cmdlets kann sich direkt oder indirekt auf die Webdienst-APIs in Exchange Online und Exchange lokal auswirken. Cmdlets sind für Folgendes in Exchange Online nicht verfügbar:
Drosselungseinstellungen
Einstellungen für virtuelles Verzeichnis
Authentifizierungseinstellungen
Ausführliche Informationen zu den Cmdlets, die für Exchange Online verfügbar sind, finden Sie unter PowerShell-Cmdlets in Exchange Online. Weitere Informationen zu Cmdlets, die für lokale Exchange-Instanzen verfügbar sind, finden Sie unter Exchange 2013-Cmdlets.
Clientaffinität und Netzwerklastenausgleich
Die meiste EWS-Kommunikation erfordert nicht, dass der Client an der Aufrechterhaltung der Affinität zu Exchange beteiligt ist. Die Abonnements für Postfachereignisse erfordern, dass der Client Cookies und andere Informationen bereitstellt, um die Affinität mit dem Exchange-Server aufrechtzuerhalten, der die Warteschlange der Postfachereignisse für einen Benutzer verwaltet. Exchange Server 2010 verwendet exchangecookie, um die Clientaffinität in den Netzwerklastenausgleichsmodulen aufrechtzuerhalten. Exchange Online und Versionen von Exchange lokal ab Exchange 2013 verwenden den X-AnchorMailbox-Header, den X-PreferServerAffinity-Header und das X-BackEndOverrideCookie-Cookie, um die Affinität für Postfachbenachrichtigungen aufrechtzuerhalten.
Authentifizierung
Clients können sich mit Exchange Online mithilfe von Basic oder OAuth authentifizieren. Lokale Versionen von Exchange ab Exchange 2013 verwenden standardmäßig NTLM. Es ist jedoch möglich, Exchange lokal für die Verwendung der Standardauthentifizierung zu konfigurieren.
Diagnose der Clientlatenz
Exchange Online erfasst die Clientlatenzdiagnose, wenn sie gemeldet werden. Dies hilft Microsoft bei der Behandlung von Konnektivitätsproblemen mit Exchange Online. Exchange lokal erfasst keine Clientlatenzdiagnosen. Wenn Ihr Client auf exchange lokal ausgerichtet ist, kann der Client keine Latenzdiagnose an den Server melden.
Funktionalität in der verwalteten EWS-API
Die verwaltete EWS-API macht einige Funktionen verfügbar, die für lokale Exchange-Instanzen spezifisch sind, z. B. die Suche nach Dienstpunktverbindungen, und einige Funktionen, die spezifisch für Exchange Online sind, z. B. clientlatenzberichte. Beachten Sie, dass einige Funktionen in Exchange Online implementiert werden können, bevor sie in der verwalteten EWS-API implementiert werden.
Die folgenden EWS Managed API-Funktionen gelten nur für Exchange Online:
Clientlatenzberichte
Standardvorauthentifizierung
Die Möglichkeit, die Rückgabe der RequestId in Antworten anzufordern
API-Features in Exchange Online-Plänen und Exchange Server-Editionen
Verschiedene Featuregruppen sind möglicherweise in verschiedenen Office 365- und Exchange Online-Plänen oder in den Standard- und Unternehmensversionen von Exchange Server verfügbar. Beachten Sie, dass einige API-Funktionen für Ihre Clientanwendung je nach Exchange Online Plan oder Exchange Server Edition, die das Postfach eines Benutzers hostet, möglicherweise nicht verfügbar sind.
Da sich die Featureverfügbarkeit ändern kann, empfehlen wir Ihnen, die Exchange Online Pläne und Exchange Server Editionen zu überprüfen, um zu bewerten, wie sich die Featureverfügbarkeit auf Ihren Client auswirken kann. Sie können Ihren Client auch so entwerfen, dass er die Featureverfügbarkeit überprüft, indem Sie den GetServiceConfiguration-Vorgang verwenden oder Testanforderungen für die Vorgänge senden, die die Features implementieren. Wenn das Feature nicht verfügbar ist, wird die Antwort vom Server als solche angegeben.
Andere Überlegungen
Sie können die folgenden Aktionen ausführen, wenn Sie exchange lokal als Ziel verwenden, aber nicht Exchange Online:
Erstellen Sie einen Client, der auf dem Exchange-Server installiert ist.
Installieren Sie benutzerdefinierte Transport-Agents , die sich auf die Übermittlung und den Inhalt von Nachrichten auswirken können, die Sie mit EWS und anderen Clients erstellen und senden.
Siehe auch
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für