Freigeben über

EWS-Einschränkung in Exchange

  • Artikel

Lernen Sie die Einschränkungsrichtlinien kennen, die sich bei Verwendung von Exchange auf EWS auswirken.

Bereitgestellt von: Glen Scales; Michael Mainer, Microsoft Corporation

Dieser Artikel enthält Informationen über EWS-Einschränkungen in Exchange Online, Exchange Online als Teil von Office 365 und lokale Versionen von Exchange ab Exchange 2010. Einschränkungen in Exchange dienen zur Sicherstellung von Serverzuverlässigkeit und -betriebszeit durch Begrenzung der Menge an Serverressourcen, die ein einzelner Benutzer oder eine einzelne Anwendung verbrauchen kann. Einschränkungen sind eine reaktive Antwort auf die übermäßige Nutzung von Systemressourcen, die die Zuverlässigkeit und die Funktionalität von Diensten beeinflussen kann. Exchange überwacht kontinuierlich die Integrität kritischer Infrastrukturressourcen, z. B. von Postfachdatenbanken. Wenn hohe Lastfaktoren entdeckt werden, die die Leistung dieser Ressourcen beeinträchtigen, werden EWS-Verbindungen proportional basierend auf dem Anteil eingeschränkt, den jede aufrufende Person oder Anwendung zu dieser hohen Lastbedingung beigetragen hat. Dies kann dazu führen, dass ein Benutzer, der die Einschränkungsgrenzwerte nicht überschreitet, möglicherweise trotzdem Verzögerungen hinnehmen muss, bis die Integrität der Ressource wieder das Betriebniveau erreicht.

Jedes Clientzugriffsprotokoll in Exchange, einschließlich EWS, verfügt über eine Einschränkungsrichtlinie. Beim Entwerfen von Anwendungen, die EWS verwenden, müssen Einschränkungsrichtlinien berücksichtigt werden, um die Anwendungszuverlässigkeit und die Integrität des Exchange-Servers sicherzustellen. In diesem Artikel werden die verschiedenen Einschränkungsrichtlinien und Dienstgrenzwerte für EWS für Exchange Online oder Versionen von Exchange lokal ab Exchange Server 2010 vorgestellt. Gegebenenfalls werden in diesem Artikel außerdem Unterschiede bei den Einschränkungsrichtlinien in verschiedenen Exchange-Versionen aufgezeigt.

Wichtig

[!WICHTIG] Die standardmäßige Einschränkungsrichtlinie, der Zugriff auf Einschränkungsrichtlinien und die Konfiguration von Einschränkungsrichtlinien unterscheiden sich zwischen Exchange Online und Exchange lokal. Bestimmte Werte von Einschränkungseinstellungen sind nur für eine bestimmte Version von Exchange zutreffend. Da Einstellungswerte nach Version variieren und Exchange-Administratoren die standardmäßigen Richtlinien für lokale Bereitstellungen ändern können, werden die standardmäßigen Einstellungswerte in diesem Artikel nicht angegeben. Es ist wichtiger, dass Ihnen die Überlegungen bekannt sind, die Sie zum Entwerfen einer Anwendung berücksichtigen müssen, die innerhalb von Einschränkungsgrenzwerten funktioniert und angemessen auf Einschränkungsszenarien reagiert.

Als Anwendungsentwickler müssen Sie in Ihrem Anwendungsentwurf Einschränkungen berücksichtigen. Unterschiedliche Exchange-Versionen haben unterschiedliche Standardwerte für die EWS-Einschränkungsparameter. Client- und Dienstanwendungen, die für den Zugriff auf verschiedene Exchange-Versionen konzipiert sind, müssen diese Einstellungen berücksichtigen, egal ob es sich um Standardwerte, von einem Exchange-Administrator festgelegte benutzerdefinierte Werte oder - wie im Fall von Exchange Online - standardmäßig festgelegte und nicht auffindbare Werte handelt. Da Werte für Einschränkungsparameter nicht programmgesteuert ermittelt werden können, sollten die Cliententwurfsspezifikationen einen Plan enthalten, wie sich die Anwendung an verschiedene mögliche Einschränkungsgrenzwerte anpasst. Wenn Sie Multithreadanwendungen entwerfen, die auf eine große Anzahl von Postfächern zugreifen, oder wenn viele Clients auf dasselbe Postfach zugreifen, sollten Sie die Einschränkungen der Parallelität berücksichtigen, die die Standardrichtlinie für Exchange betrifft.

Einschränkungsrichtlinien mit Auswirkung auf EWS

Die Einschränkungsrichtlinien in Exchange wirken sich nicht nur auf EWS, sondern auch auf alle Clientverbindungen mit dem Exchange-Server aus, einschließlich der von Office Outlook, Outlook Web App und Exchange ActiveSync verwendeten Protokolle.

Die CPUStartPercent -Einschränkungsrichtlinie kann sich auf die EWS-Leistung auswirken, wenn Sie Exchange 2010 ausführen. Wenn die durchschnittliche CPU-Auslastung von Exchange-Prozessen, die auf dem Clientzugriffsserver ausgeführt werden (einschließlich, aber nicht beschränkt auf den EWS-Prozess), den von dieser Richtlinie angegebenen Wert überschreitet, werden eingehende Anfragen verzögert, um die CPU-Auslastung zu verringern. Sie können den Wert dieser Richtlinie nicht ändern, ihn zu kennen, kann jedoch bei der Behebung von Leistungsproblemen helfen. Die Samplinglogik, die der Clientzugriffsserver für diesen Wert ausführt, ist ein Mittelwert über ein 10-Sekunden-Gleitfenster. Dadurch kann der Prozess angemessen auf schnelle Spitzen in der CPU-Auslastung reagieren. Wenn dieser Schwellenwert überschritten wird, werden eingehende Verbindungen mit EWS verzögert. Diese Verzögerung ist auf 500 Millisekunden (ms) bei einer theoretischen 100-prozentigen CPU-Auslastung pro EWS-Anforderung begrenzt. Wenn eine EWS-Batchanforderung zum Abrufen von 100 Elementen übergeben wird, überprüft der Server die CPU-Auslastung 100 Mal (ein Mal pro Element), und es kann eine maximale Verzögerung von 50 Sekunden entstehen. Die Verzögerungsdauer ist linear proportional zur CPU-Auslastung. Bei CPUStartPercent beträgt die Verzögerung 0 (ein Threadergebnis) und erhöht sich linear auf bis zu 500 ms bei 100-prozentiger CPU-Auslastung. Da Einschränkungsrichtlinien für alle Exchange-Benutzer gelten, ist es unwahrscheinlich, dass die CPU-Auslastung den CPUStartPercent -Grenzwert auf einem Exchange-Clientzugriffsserver überschreitet, da einzelne Benutzer oder Anwendungen nicht genügend CPU-Auslastung erzeugen können, um den Serverbetrieb zu beeinflussen.

In der folgenden Tabelle sind die Einschränkungsrichtlinienparameter aufgeführt, die sich auf Anwendungen mit EWS-Nutzung auswirken.

Tabelle 1: Einschränkungsrichtlinienparameter mit Auswirkung auf EWS

Name des Einschränkungsrichtlinienparameters Gilt für Beschreibung
DiscoveryMaxConcurrency Exchange 2013 Exchange Online Gibt die Anzahl der gleichzeitigen Discoverysuchverbindungen an, die ein Benutzer zur gleichen Zeit geöffnet haben kann.
DiscoveryMaxKeywords Exchange 2013 Exchange Online Gibt die maximale Anzahl an Schlüsselwörtern an, die ein Benutzer in eine Discoverysuche einschließen kann.
DiscoveryMaxKeywordsPerPage Exchange 2013 Exchange Online Gibt die Anzahl an Schlüsselwörtern an, für die Statistiken angezeigt werden sollen.
DiscoveryMaxMailboxes Exchange 2013 Exchange Online Gibt die maximale Anzahl an Quellpostfächern an, die ein Benutzer in eine Discoverysuche einschließen kann.
DiscoveryMaxMailboxesResultsOnly Exchange 2013 Exchange Online Gibt die maximale Anzahl an Postfächern an, die Sie in einer In-Situ-eDiscovery-Suche durchsuchen können, ohne die Statistik anzeigen zu können.
DiscoveryPreviewSearchResultsPageSize Exchange 2013 Exchange Online Gibt die Anzahl an Nachrichten an, die in der Vorschauantwort einer eDiscovery-Suche zurückgegeben werden.
EwsCutoffBalance Exchange 2013 Exchange Online Definiert die Grenzwerte für die Ressourcennutzung für EWS-Benutzer, bevor der Benutzer vollständig an der Ausführung von Vorgängen für eine bestimmte Komponente gehindert wird.
EwsMaxBurst Exchange 2013 Exchange Online Definiert den Zeitraum, für den ein EWS-Benutzer eine erhöhte Menge von Ressourcen verbrauchen darf, bevor er eingeschränkt wird. Dieser Zeitraum wird in Millisekunden gemessen. Dieser Wert wird für jede Komponente einzeln festgelegt.
EwsRechargeRate Exchange 2013 Exchange Online Definiert die Rate, mit der das Budget eines EWS-Benutzers während der Budgetzeit aufgeladen wird (um die das Budget wächst).
EWSMaxSubscriptions Exchange 2010 Exchange 2013 Exchange Online Definiert die maximale Anzahl an aktiven Push-, Pull- und Streamingbenachrichtigungsabonnements, über die ein Benutzer auf einem bestimmten Clientzugriffsserver gleichzeitig verfügen kann. Dies wird je nach Exchange-Version anders budgetiert.
EWSFastSearchTimeoutInSeconds Exchange 2010 Definiert die Zeitspanne in Sekunden, die mit der Exchange-Suche in EWS durchgeführte schnelle Suchläufe fortgesetzt werden, bevor ein Timeout eintritt. Schnelle Suchläufe sind Suchvorgänge, die mithilfe einer AQS-Abfragezeichenfolge (Advanced Query Syntax, erweiterte Abfragesyntax) in einem FindItem-Vorgang ausgeführt werden.
EWSFindCountLimit Exchange 2010 Exchange 2013 Exchange Online Definiert die maximale Anzahl an Elementen aus einem FindItem-Vorgang oder einem FindFolder Operation, die gleichzeitig für einen bestimmten Benutzer im Arbeitsspeicher auf dem Clientzugriffsserver vorhanden sein können. Der Standardwert für diese Eigenschaft ist 1000. Der Ausweichwert für diesen Wert ist 1000. In Exchange Online und lokalen Versionen von Exchange ab Exchange 2013 kann diese Einschränkungsrichtlinie nicht abgefragt oder von einem Cmdlet konfiguriert werden. In Exchange Online und lokalen Versionen von Exchange ab Exchange 2013 beträgt der EWSFindCountLimit für die AQS-Suche und alle Exchange-Suchvorgänge mit einer Beschränkung 250 Ergebnisse. Eine Exchange-Suche ohne Beschränkung gibt bis zu 1000 Ergebnisse zurück.
EWSPercentTimeInAD Exchange 2010 Definiert die Zeit pro Minute in Prozent, für die ein bestimmter Benutzer Active Directory-Anforderungen ausführen kann.
EWSPercentTimeInCAS Exchange 2010 Definiert die Zeit pro Minute in Prozent, für die ein bestimmter Benutzer Clientzugriffsserver-Code ausführen kann.
EWSPercentTimeInMailboxRPC Exchange 2010 Definiert die Zeit pro Minute in Prozent, für die ein bestimmter Benutzer Postfach-RPC-Anforderungen ausführen kann.
EWSMaxConcurrency Exchange 2010 Exchange 2013 Exchange Online Definiert die Anzahl der Verbindungen, die ein bestimmter Benutzer gleichzeitig auf einem Exchange-Server geöffnet haben kann, auf dem EWS ausgeführt wird. Der Standardwert für Exchange 2010 ist 10. Der Standardwert für Exchange 2013 und Exchange Online ist 27. Diese Richtlinie gilt für alle Vorgänge mit Ausnahme von Streamingbenachrichtigungen. Streamingbenachrichtigungen verwenden den HangingConnectionLimit, um die Anzahl der verfügbaren geöffneten Streamingereignisverbindungen anzugeben. Weitere Informationen finden Sie unter Welche Drosselung Werte muss ich berücksichtigen?.
MessageRateLimit Exchange 2010 Exchange 2013 Exchange Online Definiert die Anzahl an Nachrichten pro Minute, die gesendet werden können.
RecipientRateLimit Exchange 2010 Exchange 2013 Exchange Online Definiert den Grenzwert für die Anzahl an Empfängern, die ein Benutzer in einem Zeitraum von 24 Stunden adressieren kann.
ForwardeeLimit Exchange 2010 Exchange 2013 Exchange Online Definiert den Grenzwert für die Anzahl an Empfängern für Weiterleitungs-/Umleitungsaktionen im Posteingang in einem Zeitraum von 24 Stunden.
ConcurrentSyncCalls Exchange 2019 Exchange 2016 Exchange Online Definiert den Grenzwert für die Anzahl gleichzeitiger Synchronisierungsaufrufe (SyncFolderHierarchy, SyncFolderItems) für einen Benutzer.

Vorsicht

[!VORSICHT] Legen Sie Einschränkungsrichtlinien nicht auf null fest. Hierdurch wird die Richtlinie auf "unbegrenzt" festgelegt, was bedeutet, dass eine Einschränkungsrichtlinie nicht festgelegt ist.

Anzeigen der für Exchange-Postfächer geltenden Richtlinien

Exchange lokal stellt Exchange-Verwaltungsshell-Cmdlets zur Verfügung, mit denen Sie Einschränkungsrichtlinien festlegen und abrufen können. Exchange Online bietet keinen Zugriff auf die Einschränkungsrichtlinien-Cmdlets.

Verwenden Sie die folgenden Cmdlets, um Einschränkungsrichtlinien für eine lokale Bereitstellung von Exchange Server anzuzeigen:

  • Get-ThrottlingPolicy - Ruft die Clienteinschränkungseinstellungen für eine oder mehrere Einschränkungsrichtlinien ab. Weitere Informationen finden Sie unter Get-ThrottlingPolicy auf TechNet.

  • Get-ThrottlingPolicyAssociation - Ermöglicht es Ihnen, die Beziehung zwischen einem Objekt und den zugeordneten Einschränkungsrichtlinien anzuzeigen. Bei dem Objekt kann es sich um einen Benutzer mit einem Postfach, einen Benutzer ohne Postfach oder einen Kontakt handeln. Weitere Informationen finden Sie unter Get-ThrottlingPolicyAssociation in TechNet.

Verwenden Sie den folgenden Befehl, um die standardmäßige Einschränkungsrichtlinie für Exchange 2010 anzuzeigen.

  • Get-ThrottlingPolicy | Where-Object {$_.IsDefault -eq "True"} | format-list

Verwenden Sie den folgenden Befehl, um die globale Einschränkungsrichtlinie in Exchange 2013 anzuzeigen (die der standardmäßigen Einschränkungsrichtlinie in Exchange 2010 entspricht).

  • Get-ThrottlingPolicy | Where-Object {$_.ThrottlingPolicyScope -eq "Global"} | format-list

Verwenden Sie den folgenden Befehl, um die einem Benutzer in Exchange 2010 oder Exchange 2013 zugeordnete Einschränkungsrichtlinie anzuzeigen. Ersetzen Sie den Benutzernamen john@contoso.com durch den Benutzernamen des Zielbenutzers, für den Sie Drosselungsrichtlinieninformationen erhalten möchten.

  • Get-ThrottlingPolicyAssociation john@contoso.com | format-list

Bei Ausführung dieses Befehls in der Exchange-Verwaltungsshell wird eine Ausgabe ähnlich der folgenden generiert.

PS C:\>Get-ThrottlingPolicyAssociation john@contoso.com
RunspaceId               : 72153d6-9dce-2fae-8dbd-5ca5f760g2df
ObjectId                 : john
ThrottlingPolicyId       :
Name                     : john
Identity                 : FHXB-28178dom.contoso.com/Users/john
IsValid                  : True
NeedsToSuppressPii       : False
ExchangeVersion          : 0.10 (15.0.0.0)
DistinguishedName        : CN=john,CN=Users,DC=FHXB-28178dom,DC=contoso,DC=com
Guid                     : 2c10dab6-de28-1937-ad8g-535832613a08

Hinweis

[!HINWEIS] Wenn die ThrottlingPolicyId -Eigenschaft leer ist, wird die Standardrichtlinie auf das Postfach angewendet.

Sie können Einschränkungsrichtlinien auf einem Exchange-Server mithilfe der Cmdlets Set-ThrottlingPolicy und Set-ThrottlingPolicyAssociation festlegen. Sie können nicht standardmäßige Einschränkungsrichtlinien erstellen und entfernen, indem Sie die Cmdlets New-ThrottlingPolicy und Remove-ThrottlingPolicy verwenden.

Tipp

[!TIPP] Es wird empfohlen, Anwendungen so zu entwerfen, dass sie die standardmäßige Einschränkungsrichtlinie einhalten. Nehmen Sie nur dann Änderungen an standardmäßigen Einschränkungsrichtlinien vor, wenn der Clientanwendungsentwurf die Standardrichtlinie nicht berücksichtigen kann. Beachten Sie, dass weniger restriktive Einschränkungsrichtlinien die Dienstzuverlässigkeit beeinträchtigen können.

Überlegungen zu Einschränkungen für Anwendungen, die den EWS-Identitätswechsel verwenden

Identitätswechsel ist eine Autorisierungsmethode, die einem einzelnen Konto den Zugriff auf viele Konten ermöglicht. Wenn ein Dienstkonto die Identität von Benutzern annimmt, agiert es als diese Benutzer und übernimmt daher die Rechte, die diesen Benutzern zugewiesen sind. Protokolldateien zeichnen den Zugriff als den Benutzer auf, dessen Identität angenommen wird. Administratoren verwenden die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC), um den Identitätswechsel über die Exchange-Verwaltungsshell zu konfigurieren.

Wenn Identitätswechsel verwendet wird, gelten die Budgets für alle Einschränkungsschwellenwerte je nach Exchange-Version unterschiedlich. Das Budget wird entweder für das Konto, dessen Identität angenommen wird, oder für das Dienstkonto verrechnet. Wenn Ihre Anwendung multithreaded ist und gleichzeitig Anforderungen für mehrere Postfächer sendet, sollten Sie überlegen, wie sich der Drosselungsschwellenwert auf die Leistung Ihrer Anwendung auswirkt. Im Allgemeinen sollten Sie die folgenden Grenzwerte für Dienstkonten berücksichtigen, wenn Sie eine dienstbasierte Anwendung erstellen, die Identitätswechsel für den Zugriff auf alle Postfächer verwendet:

  • Bei Verwendung von Identitätswechsel hat das Dienstkonto ein getrenntes Budget für die folgenden Richtlinienparameter:

    • EWSMaxConcurrency
    • EWSPercentTimeInAD
    • EWSPercentTimeInCAS
    • EWSPercentTimeInMailboxRPC
    • EWSMaxSubscriptions
    • EWSFastSearchTimeoutInSeconds
    • EWSFindCountLimit

  • Das EWSMaxConcurrency -Budget wird vom Dienstkonto und von dem Konto, dessen Identität angenommen wird, gemeinsam verwendet, und zwar für alle Verbindungen mit Exchange-Versionen vor Exchange 2010 Service Pack 2 (SP2) Update Rollup 4 (RU4). Ab Exchange 2010 SP2 RU4 und einschließlich Exchange Online verwendet der Dienstkontozugriff ein vom EWSMaxConcurrency -Budget des Benutzers getrenntes Budget. Weitere Informationen zum Update auf die Exchange-Einschränkungsrichtlinie für gleichzeitige Verbindungen für EWS finden Sie unter Hinweise zum Updaterollup 4 für Exchange Server 2010 Servicepack 2.

    EWS-Streamingbenachrichtigungen in Versionen von Exchange ab Exchange 2010 und einschließlich Exchange Online verfügen über ein zusätzliches geklontes EWSMaxConcurrency-Budget von allen anderen EWS-Clientverbindungen. Streamingbenachrichtigungsverbindungen werden für ein separates Budget als alle anderen EWS-Vorgänge gezählt. Das maximale Parallelitätsbudget für Streamingbenachrichtigungen umfasst tatsächlich zwei verschiedene Budgets: ein Budget gilt für alle Dienstkonten und ein Budget für das Konto, das die Identität angenommen wird. Streamingbenachrichtigungen in Exchange Online und Versionen von Exchange ab Exchange 2013 verwenden hangingConnectionLimit, um die Anzahl der Verbindungen zu begrenzen.

    Nehmen wir beispielsweise einen EWSMaxConcurrency -Wert von fünf an. Ein Benutzer kann fünf geöffnete Pullbenachrichtigungsverbindungen haben, während ein Dienstkonto zeitgleich mit dem Benutzer fünf gleichzeitige Pullbenachrichtigungsverbindungen für das Postfach des Benutzers haben kann.

  • Die folgende Tabelle zeigt, wie EWSMaxSubscriptions -Einschränkungsbudgets für das Dienstkonto und das Konto, dessen Identität angenommen werden soll, verrechnet werden.

    Tabelle 2: EWSMaxSubscriptions-Budgetberechnung

    Exchange-Version EWSMaxSubscriptions-Einschränkungsbudgetberechnung
    Exchange Online Mit Zielpostfach verrechnet
    Exchange 2013 Mit Zielpostfach verrechnet
    Exchange 2010 SP3 Mit Zielpostfach verrechnet
    Exchange 2010 SP2 Mit aufrufendem Konto verrechnet Ab Exchange 2010 SP2 RU4 wird das Budget dem Zielpostfach in Rechnung gestellt.
    Exchange 2010 SP1 Mit aufrufendem Konto verrechnet
    Exchange 2010 Mit aufrufendem Konto verrechnet

  • Da das EWSMaxSubscriptions -Einschränkungsbudget mit dem Konto verrechnet wird, dessen Identität angenommen wird, ist die Anzahl der Postfächer, die ein Dienstkonto abonnieren und für die es Streamingbenachrichtigungen erhalten kann, unbegrenzt, solange der Identitätswechsel verwendet wird. Das Konto, dessen Identität angenommen wird, kann maximal n gleichzeitige Anforderungen pro Zielpostfach ausführen, wobei n der EWSMaxSubscriptions-Wert ist. Wenn kein Identitätswechsel verwendet wird, sind für das gleiche Dienstkonto insgesamt maximal n gleichzeitige Anforderungen zulässig. Die Schlussfolgerung ist daher, dass sich mithilfe eines Identitätswechsels auf einem Dienstkonto die Anzahl von Postfächern, die Sie bedienen können, exponentiell erhöht. Weitere Informationen finden Sie unter Verwalten von Affinität zwischen einer Gruppe von Abonnements und Postfachserver in Exchange.

  • Die Richtlinienparameter EWSPercentTimeInMailboxRPC, EWSPercentTimeInCAS und EWSPercentTimeInAD beziehen sich auf Aktionen, die von einem einzigen Thread durchgeführt werden. Wenn eine Anwendung mehrere gleichzeitige Vorgänge ausführt, müssen Sie den kumulativen Effekt dieser Vorgänge auf das Benutzerressourcenbudget berücksichtigen.

Auswirkungen von Einschränkungen für EWS-Batchanforderungen

Mithilfe von EWS können Sie mehrere Elementanforderungen zu einer einzigen Batchanforderung zusammenfassen, die vom Clientzugriffsserver ausgeführt wird. Dies sorgt für mehr Effizienz und Leistung. Wenn ein Exchange-Server eine Batchanforderung ausführt, wird nach Ausführung jedes einzelnen Elements im Batch das Budget des Benutzers überprüft. Wenn die Anwendung das Budget überschreitet, wird die Verarbeitung des nächsten Elements im Batch verzögert, bis das Budget für den betreffenden Benutzer wiederaufgeladen wurde. Um die erfolgreiche Ausführung von Anwendungen sicherzustellen, die Batchvorgänge nutzen, begrenzen Sie die Anzahl der Elementanforderungen in einem einzelnen Batch, und teilen Sie große Batches in mehrere kleinere Batches auf, um die Zuverlässigkeit der Ergebnisse zu erhöhen. Die Auswirkung eines Batchvorgangs auf bestimmte Einschränkungsschwellenwerte hängt von dem Typ der Anforderung, der Größe der zu verarbeitenden Elemente (z. B. in UploadItems- oder ExportItems-Vorgängen) und dem Postfachinhalt ab. Einschränkungsrichtlinien wirken sich insofern auf Batchvorgänge aus, als sie die Verarbeitung der Anforderung verlangsamen. Die aufrufende Person oder Anwendung muss daher länger auf die Antwort warten, und es kann zu einem Aufruftimeout kommen, da EWS die Ausführungszeit einer Batchanforderung auf eine Minute beschränkt.

Um die optimale Batchgröße für eine Anwendung zu bestimmen, führen Sie Komponententests mit verschiedenen Eingabesätzen durch, um sicherzustellen, dass in einer Produktionsumgebung keine Fehler in der Anwendung auftreten.

Einschränkungsrichtlinienparameter mit Auswirkung auf EWS-Suchvorgänge

Suchvorgänge in EWS können sehr viel Zeit und Ressourcen beanspruchen, je nachdem, wie die Suche ausgeführt wird und welche Informationen angefordert werden. Zum Steuern des Ressourceneinsatzes bei Suchvorgängen können zwei Richtlinienparameter verwendet werden: EWSFastSearchTimeoutInSeconds und EWSFindCountLimit.

Der EWSFastSearchTimeoutInSeconds -Richtlinienparameter gibt die Zeitspanne in Sekunden an, die schnelle EWS-Suchläufe (auch als Inhaltsindizierungssuche bezeichnet) ausgeführt werden, bevor ein Timeout eintritt. Schnelle Suchläufe sind Suchvorgänge, die mithilfe einer AQS-Abfragezeichenfolge (Advanced Query Syntax, erweiterte Abfragesyntax) in einem FindItem-Vorgang ausgeführt werden.

Sie können einen Exchange-Postfachordner auf zwei Arten durchsuchen:

  • Mithilfe einer Exchange-Informationsspeichersuche, die einen sequenziellen Scan aller Nachrichten im Zielsuchbereich durchführt

  • Mithilfe des Exchange-Suchdiensts (Inhaltsindizierung)

Bei beiden Suchvorgangstypen können Timeouts auftreten. Verwenden Sie nach Möglichkeit den Exchange-Suchdienst, da diese Suchvorgänge häufig für Postfachindizes ausgeführt werden und AQS-Abfragen verwenden. Das folgende Beispiel zeigt, wie eine AQS-Suche im Posteingang mithilfe von EWS und des Exchange-Suchdiensts ausgeführt wird.

ItemView iv = new ItemView(1000);
FindItemsResults<Item> fiitems = service.FindItems(WellKnownFolderName.Inbox, "subject:football", iv);

Wenn Sie keine AQS-Suche verwenden können, vermeiden Sie übermäßig komplexe Suchfilter. Vermeiden Sie nach Möglichkeit außerdem, Suchfilter auf der Grundlage berechneter Werte zu erstellen, wenn die Abfrage erweiterte MAPI-Eigenschaften enthält. Die AQS-Suche wurde in Exchange 2010 eingeführt.

Hinweis

Wenn Sie eine komplexe Exchange-Speichersuchabfrage zum ersten Mal ausführen, wird sie sehr langsam ausgeführt und kann zu einem Timeout führen. Danach reagiert die Abfrage schneller. Weitere Informationen zu den Exchange-Back-End-Serverprozessen, die während Exchange-Speichersuchabfragen auftreten, finden Sie unter Grundlegendes zu den Auswirkungen auf die Leistung von hohen Elementanzahlen und eingeschränkten Ansichten auf TechNet. Die Verwendung eines Suchfilters erstellt eine dynamische Einschränkung, die ähnliche Abfragen in Der Zukunft unterstützt, aber da diese Einschränkungen dynamischer Natur sind, sind sie nicht dauerhaft oder zuverlässig und werden nach maximal drei Tagen gelöscht.

Der EWSFindCountLimit-Richtlinienparameter gibt die maximale Anzahl von Elementen aus den Ergebnissen eines FindItem- oder FindFolder-Vorgangs an, die gleichzeitig für einen Benutzer im Arbeitsspeicher auf einem Clientzugriffsserver vorhanden sein können. Jedes Element oder jeder Ordner, das EWS in einer FindItem- oder FindFolder-Anforderung verarbeitet, wird mit dem im EWSFindCountLimit-Element angegebenen Budget gezählt. Wenn die Antwort an den anfordernden Benutzer zurückgesendet wird, wird die Find-Count-Gebühr für den aktuellen Anruf freigegeben. Die Antwort, die der Server an einen Anfordernden zurückgibt, wenn das Budget überschritten wird, basiert auf dem Wert des RequestServerVersion-Elements und darauf, ob der Anfordernde paging angegeben hat. Wenn der Wert des RequestServerVersion-Elements Exchange 2010 oder eine frühere Version von Exchange angibt, sendet der Server eine Fehlerantwort mit dem Fehlercode ErrorServerBusy. Wenn der Wert des RequestServerVersion-Elements eine Version von Exchange angibt, die mit Exchange 2010 SP1 oder Exchange Online beginnt und der Client Paging verwendet, gibt EWS möglicherweise anstelle eines Fehlers ein Partielles Resultset zurück. Ihre Anwendung sollte erwarten, dass EWS möglicherweise nicht alle Elemente zurückgibt. Wenn der Wert des IncludesLastItemInRange-Elements false ist, sollte die Anwendung eine weitere FindItem- oder FindFolder-Anforderung mit dem neuen Offset ausführen und fortfahren, bis das IncludesLastItemInRange-Element true zurückgibt.

Bei Ausführung eines FindItem- oder FindFolder-Vorgangs ist die Verwendung von Auslagerung wichtig. Die verwaltete EWS-API erzwingt die Verwendung von Auslagerung, wenn Sie jedoch andere Methoden wie z. B. EWS-Proxyobjekte oder Raw-SOAP verwenden, muss die Auslagerung explizit festgelegt werden. Das folgende Beispiel zeigt die Verwendung von Auslagerung in der verwalteten EWS-API.

ItemView iv = new ItemView(1000);
FindItemsResults<Item> fiFindItemResults = service.FindItems(WellKnownFolderName.Inbox, iv);

Hinweis

[!HINWEIS] Die Standardrichtlinie in Exchange beschränkt die Seitengröße auf 1000 Elemente. Die Festlegung der Seitengröße auf einen größeren Wert hat keine praktischen Auswirkungen.

Anwendungen sollten auch die Tatsache berücksichtigen, dass der Wert des EWSFindCountLimit-Einschränkungsparameters dazu führen kann, dass ein partielles Resultset für Anwendungen zurückgegeben wird, die gleichzeitige Anforderungen stellen. Das folgende Beispiel zeigt, wie die MoreAvailable -Eigenschaft in der verwalteten EWS-API verwendet wird, um die Aufnahme aller Ergebnisse in eine Abfrage sicherzustellen.

ItemView iv = new ItemView(1000);
service.TraceEnabled = false;
FindItemsResults<Item> fiResults = null;
Do
{
    fiResults = service.FindItems(WellKnownFolderName.Inbox, iv);
    PropertySet itItemPropSet = new PropertySet(BasePropertySet.IdOnly) { EmailMessageSchema.Body };
    //Process Items in Result Set
    iv.Offset += fiResults.Items.Count;
}
while (fiResults.MoreAvailable == true);

Einschränkungsrichtlinien und Parallelität

Parallelität bezeichnet die Anzahl der Verbindungen von einem bestimmten Benutzer. Eine Verbindung wird ab dem Moment gehalten, an dem eine Anforderung empfangen wird, bis eine Antwort an die anfordernde Person gesendet wird. Wenn Benutzer versuchen, mehr gleichzeitige Anforderungen zu stellen, als ihre Richtlinie zulässt, tritt beim erneuten Verbindungsversuch ein Fehler auf. Die bestehenden Verbindungen bleiben jedoch gültig. Einschränkungsrichtlinien können sich auf verschiedene Weise auf Parallelität auswirken.

Der EWSMaxConcurrency -Einschränkungsrichtlinienparameter legt die Anzahl der gleichzeitigen Verbindungen fest, die ein bestimmter Benutzer zur gleichen Zeit mit einem Exchange-Server haben kann. Um die maximal zuzulassende Anzahl gleichzeitiger Verbindungen zu bestimmen, betrachten Sie die Verbindungen, die von Outlook-Clients verwendet werden. Outlook 2007 und Outlook 2010 verwenden EWS zum Zugreifen auf Verfügbarkeits- und Abwesenheitsinformationen. Mac Outlook 2011 verwendet EWS für alle Clientzugriffsfunktionen. Abhängig von der Anzahl der Outlook-Clients, die aktiv eine Verbindung mit Postfach eines Benutzers herstellen, kann die Anzahl der für einen Benutzer verfügbaren gleichzeitigen Verbindungen beschränkt sein. Wenn Ihre Anwendung in einem einzigen Sicherheitskontext eine Verbindung mit mehreren Postfächern gleichzeitig herstellen muss, muss außerdem der Wert der EWSMaxConcurrency -Richtlinie berücksichtigt werden. Weitere Informationen über die Verwendung eines einzigen Sicherheitskontexts mit gleichzeitigen Verbindungen finden Sie unter Einschränkungsüberlegungen für Anwendungen, die EWS-Identitätswechsel verwenden weiter vorne in diesem Artikel.

Anwendungen, die gleichzeitig Verbindungen mit mehreren Postfächer herstellen, müssen den Ressourceneinsatz auf Clientseite verfolgen können. Da EWS-Vorgänge anforderungs-/antwortbasiert sind, können Sie die ordnungsgemäße Funktion Ihrer Anwendungen innerhalb des EWSMaxConcurrency -Schwellenwerts sicherstellen, indem Sie die Anzahl der Verbindungen verfolgen, die zwischen dem Start einer Anforderung und dem Erhalt der Antwort stattfinden, und sicherstellen, dass höchstens zehn offene Anforderungen gleichzeitig vorliegen.

Der EWSFindCountLimit -Richtlinienparameter gibt die maximale Ergebnisgröße an, die ein FindItem - oder FindFolder -Vorgang auf einem Clientzugriffsserver für einen Benutzer gleichzeitig verwenden kann. Wenn eine Anwendung (oder auch mehrere Anwendungen) zwei gleichzeitige EWS- FindItem -Anforderungen ausführt, die jeweils 100 Elemente für einen bestimmten Benutzer zurückgeben, wird für EWSFindCountLimit ein Wert von 200 auf das Budget des betreffenden Benutzers angerechnet. Wenn die Rückgabe der ersten Anforderung erfolgt, sinkt das Budget auf 100, und bei Rückgabe der zweiten Anforderung sinkt das Budget auf 0 (null). Wenn dieselbe Anwendung zwei gleichzeitige Anforderungen für 1000 Elemente ausführt, beträgt der Budgetwert 2000 Elemente, was den EWSFindCountLimit -Wert überschreitet. Wenn das Budget des Benutzers für Elemente unter null fällt, resultiert die nächste Anforderung in einem Fehler, bis das Budget des Benutzer wieder auf eins oder mehr aufgeladen wurde.

Überlegungen zu Einschränkungen für EWS-Benachrichtigungsanwendungen

Wenn Sie EWS-Benachrichtigungsanwendungen erstellen, die Push-, Pull- oder Streamingbenachrichtigungen verwenden, müssen Sie die Auswirkungen der Einschränkungsrichtlinien EWSMaxSubscriptions und EWSMaxConcurrency sowie des HangingConnectionLimit berücksichtigen.

Der EWSMaxSubscriptions-Richtlinienparameter gibt die maximale Anzahl aktiver Push-, Pull- und Streamingabonnements an, die ein Benutzer gleichzeitig auf einem bestimmten Clientzugriffsserver haben kann. Verschiedene Versionen von Exchange verfügen über unterschiedliche Standardwerte für diesen Parameter. Ein Benutzer kann alle Ordner in einem Postfach abonnieren, indem er die SubscribeToAllFolders-Eigenschaft verwendet. Dabei wird ein einzelnes Abonnement für das EWSMaxSubscriptions-Budget verwendet. Benutzer können einzelne Ordner abonnieren, wobei jedes Ordnerabonnement auf das EWSMaxSubscriptions-Budget angerechnet wird, bis zu dem Grenzwert, der durch den Wert des EWSMaxSubscriptions-Parameters festgelegt ist (z. B. können Benutzer 20 Kalenderordner in verschiedenen Postfächern abonnieren, wenn EWSMaxSubscriptions auf 20 festgelegt ist).

Informationen zum Identitätswechsel und zum EWSMaxSubscriptions -Parameter finden Sie unter Einschränkungsüberlegungen für Anwendungen, die EWS-Identitätswechsel verwenden weiter vorne in diesem Artikel.

Auch der EWSMaxConcurrency -Richtlinienparameter kann ein Problem für EWS-Benachrichtigungen darstellen. Beispiel:

  • Wenn EWS die Anzahl der Verbindungen für den Besitzer des Abonnements erhöht, während ein Pushabonnement eine Benachrichtigung generiert.

  • Wenn eine Anwendung dafür entwickelt wurde, mehrere Benutzerpostfächer zu überwachen, und Benutzer gleichzeitige Benachrichtigungen für eine Instanz einer Nachricht erhalten, die an eine Verteilerliste gesendet wird.

Wenn die Benachrichtigungsanwendung multithreaded ist und gleichzeitig Verbindungsanforderungen sendet, um weitere Informationen zu einer bestimmten Nachricht zu erhalten, die von einem Benutzerkonto empfangen wurde, kann der Grenzwert der EWSMaxConcurrency-Richtlinie überschritten werden. Um dies zu berücksichtigen, können Sie die gleichzeitigen Verbindungen in Ihrer Anwendung überwachen, einschließlich derjenigen, die möglicherweise vom Server verwendet werden, und Sie können Anforderungswarteschlangen auf dem Client implementieren.

Der HangingConnectionLimit gilt nur für Streamingbenachrichtigungen. Dieser Grenzwert wird in der Datei „web.config“ festgelegt. Dies bedeutet, dass ein Exchange-Administrator diesen Wert auf einem lokalen Exchange-Server festlegen kann. Exchange Online-Postfächer müssen jedoch den Standardwert für diesen Grenzwert verwenden, d. h. 10 für Exchange Online, Exchange 2019, Exchange 2016 und 3 für Exchange 2013. Weitere Informationen finden Sie unter Welche Einschränkungswerte muss ich berücksichtigen?

Einschränkungsrichtlinie und Anwendungsleistung

Die folgenden drei Parameter der PercentTimeIn -Einschränkungsrichtlinie wirken sich auf die Zeitspanne aus, die eine ESW-Anwendung auf einem Clientzugriffsserver nutzen kann:

  • EWSPercentTimeInAD
  • EWSPercentTimeInCAS
  • EWSPercentTimeInMailboxRPC

Die in den PercentTimeIn-Richtlinienparametern angegebenen Werte geben an, wie lange ein Thread, der eine Anforderung sendet, zugeordnet wird. Angenommen, ein EWSPercentTimeInCAS-Wert von 90, wenn ein Prozess zwei gleichzeitige Anforderungen sendet, die jeweils 54 Sekunden lang Code auf dem Clientzugriffsserver ausführen, verwendet der Prozess 108 Sekunden in einem 60-Sekunden-Fenster. Dies stellt einen EWSPercentTimeInCAS-Parameterwert von 180 Prozent dar.

Hinweis

[!HINWEIS] Der EWSPercentTimeInCAS -Parameterwert ist eine überlappende Obermenge der Parameterwerte EWSPercentTimeInAD und EWSPercentTimeInMailboxRPC. Dies bedeutet, dass die Ausgaben für Verarbeitungszeit auf dem Clientzugriffsserver immer höher sein werden als die Ausgaben für EWSPercentTimeInAD und EWSPercentTimeInMailboxRPC. Dies liegt daran, dass die Exchange-Komponente nur dann einen Active Directory- oder RPC-Aufruf durchführen kann, wenn sie bereits Clientzugriffsserver-Code ausführt. Darüber hinaus laufen die Ausgaben für Verarbeitungszeit für EWSPercentTimeInCAS während der Ausführung von LDAP- oder RPC-Aufrufen weiter. Obwohl die Anforderung möglicherweise synchron auf eine Antwort von Active Directory Domain Services (AD DS) oder dem Exchange-Informationsspeicher wartet, verbraucht der Prozess trotzdem einen Thread auf dem Server, daher sollte dem Thread diese Nutzung in Rechnung gestellt werden.

Die von einer Anwendung innerhalb eines 60-Sekunden-Zeitraums genutzte CPU-Zeit überschreitet diese Einschränkungsgrenzwerte möglicherweise; daher ist es wichtig, den Umfang und die Art der gestellten Anforderungen zu berücksichtigen. Beispielsweise kann ein großer Batch gleichzeitig ausgeführter ResolveNames -Vorgänge den Wert des EWSPercentTimeInAD -Richtlinienparameters überschreiten. Die Richtlinienwerte, die in der Standarddrosselungsrichtlinie enthalten sind, sind so konzipiert, dass die meisten EWS-Anwendungen problemlos funktionieren. Wenn jedoch Multithreadanwendungen mit hohem Volumen eine große Anzahl von Anforderungen auf einem bestimmten Clientzugriffsserver platzieren, kann dies Zu Problemen führen. Um dies zu vermeiden, können Sie die Größe der auf dem Server ausgeführten Batches beschränken.

Einschränkungsrichtlinien und Anwendungen mit hohem E-Mail-Versandvolumen

Die standardmäßigen Einschränkungsrichtlinien enthalten drei Richtlinienparameter zur Ratenbegrenzung, die Auswirkungen auf Anwendungen haben können, die EWS zum Senden einer großen Anzahl von Nachrichten oder zum Senden von Nachrichten in großen Batches innerhalb kurzer Zeit nutzen.

Hinweis

[!HINWEIS] Im Allgemeinen wird empfohlen, EWS nicht für den Massenversand von E-Mail-Nachrichten einzusetzen. Verwenden Sie einen SMTP-Host, der auf Massen-E-Mail-Dienste spezialisiert ist, wenn Sie häufig einen Massenversand großer E-Mail-Nachrichten durchführen.

Der MessageRateLimit-Richtlinienparameter gibt die Anzahl der Nachrichten pro Minute an, die von einem beliebigen Exchange-Client wie z. B. EWS gesendet werden können. Standardmäßig ist diese Richtlinie in Exchange Online auf 30 Nachrichten pro Minute festgelegt (in Exchange Server unbegrenzt). Für normale Benutzer in Exchange Online ist diese Ratenbegrenzung im Allgemeinen ausreichend. Bei Anwendungen, die große Batches mit E-Mail-Nachrichten senden, z. B. als Teil eines Fakturierungsprogramms, können jedoch Probleme auftreten. Wenn dieser Richtliniengrenzwert überschritten wird, wird die Nachrichtenübermittlung für das Postfach verzögert. Insbesondere kann es passieren, dass Nachrichten für einen längeren Zeitraum im Ordner "Postausgang" oder "Entwürfe" angezeigt werden, wenn ein Benutzer oder eine Anwendung eine größere Anzahl von Nachrichten sendet, als vom Wert des MessageRateLimit-Parameters angegeben. Achten Sie darauf, dass Sie diesen Aspekt bei der Entwicklung eines Übermittlungsverfolgungssystems berücksichtigen, insbesondere, wenn die Anwendung ein Postfach verwendet, mit dem sich Benutzer über Outlook verbinden. Wenn verzögerte Elemente im Ordner "Postausgang" oder "Entwürfe" gespeichert werden, können Benutzer dies als Fehler interpretieren.

Der RecipientRateLimit -Richtlinienparameter gibt den Grenzwert für die Anzahl von Empfängern an, die ein Benutzer in einem Zeitraum von 24 Stunden adressieren darf. Wenn dieser Wert auf 500 festgelegt ist, bedeutet dies beispielsweise, dass ein einzelnes Exchange-Postfachkonto Nachrichten an maximal 500 Empfänger pro Tag senden darf. Dieser Grenzwert gilt für Nachrichten an Empfänger innerhalb und außerhalb der Organisation. Dieser Standardgrenzwert verursacht möglicherweise Probleme bei einigen Branchenanwendungen, die Rechnungsläufe am Monatsende ausführen und Nachrichten an mehr als diese Anzahl von Empfängern senden müssen. Sie können externe Dienste verwenden, die die Batchverarbeitung von Nachrichten ermöglichen, oder separate lokale ausgehende Relaylösungen, um diese Einschränkung zu umgehen.

Der ForwardeeLimit -Richtlinienparameter gibt die maximale Anzahl von Empfängern an, an die Nachrichten mithilfe von Posteingangsregeln weitergeleitet oder umgeleitet werden können. Dieser Parameter beschränkt nicht die Anzahl der Nachrichten, die an die Empfänger weitergeleitet oder umgeleitet werden können.

Bei Überschreitung von Einschränkungsgrenzwerten generierte Fehler

Wenn Einschränkungsrichtlinien überschritten werden, generiert EWS einen der in der folgenden Tabelle aufgeführten Fehler.

Tabelle 3: Fehler bei Überschreitung von Einschränkungsgrenzwerten

Fehler Einschränkungsrichtlinienparameter Beschreibung
ErrorExceededConnectionCount EWSMaxConcurrency Gibt an, dass mehr gleichzeitige Anforderungen an den Server gestellt werden, als die Richtlinie des Benutzers zulässt.
ErrorExceededSubscriptionCount EWSMaxSubscriptions Gibt an, dass die maximale Abonnementanzahl für Richtlinieneinschränkungen eines Benutzers überschritten wurde.
ErrorExceededFindCountLimit EWSFindCountLimit Gibt an, dass ein Suchvorgangsaufruf die Gesamtzahl der Elemente überschritten hat, die zurückgegeben werden können.
ErrorServerBusy EWSPercentTimeInMailboxRPC
EWSPercentTimeInCAS
EWSPercentTimeInAD		 Tritt auf, wenn der Server ausgelastet ist. Der mit ErrorServerBusy-Fehlern zurückgegebene BackOffMilliseconds-Wert gibt an, wie lange der Client warten muss, bevor die Anforderung erneut gesendet werden kann, für deren Antwort dieser Fehlercode zurückgegeben wurde.

Die folgende Tabelle enthält die HTTP-Statuscodes, die von Einschränkungsfehlern zurückgegeben werden.

Tabelle 4: Von Einschränkungsfehlern zurückgegebene HTTP-Statuscodes

HTTP-Statuscode Beschreibung
HTTP 503 Gibt an, dass EWS-Anforderungen bei IIS in der Warteschlange stehen. Der Client sollte das Senden weiterer Anforderungen auf einen späteren Zeitpunkt verschieben.
HTTP 500 Zeigt einen internen Fehler mit dem ErrorServerBusy-Fehlercode an. Dies weist darauf hin, dass der Client das Senden weiterer Anforderungen auf einen späteren Zeitpunkt verschieben sollte. Die Antwort enthält möglicherweise einen Backoff-Hinweis namens BackOffMilliseconds. Falls vorhanden, verwenden Sie den Wert von BackOffMilliseconds als die Zeitspanne, die der Client bis zum erneuten Senden einer Anforderung wartet.
HTTP 200 Enthält eine auf dem EWS-Schema basierende Fehlerantwort mit einem ErrorInternalServerError-Fehlercode. Ein interner ErrorServerBusy-Fehlercode kann vorhanden sein. Dies weist darauf hin, dass der Client das Senden weiterer Anforderungen auf einen späteren Zeitpunkt verschieben sollte.

Siehe auch