Drosselungen und Sperren in SharePoint Online vermeiden

  • Artikel

In diesem Artikel erfahren Sie mehr über das Thema Drosselung (Einschränkungen) in SharePoint Online. Außerdem erläutern wir Ihnen, wie Sie eine Drosselung oder Sperre vermeiden können.

Kommt diese bekannt? Sie führen eine Anwendung aus, beispielsweise zum Überprüfen von Dateien in SharePoint Online, aber Sie werden gedrosselt. Oder sogar noch schlimmer, Sie werden gesperrt. Was geschieht, und was können Sie tun, sodass sie beenden?

Was ist Drosselung bzw. Einschränkung?

SharePoint Online verwendet Einschränkung, um eine optimale Leistung und Zuverlässigkeit des Diensts SharePoint Online verwalten. Drosselung beschränkt die Anzahl von API-Aufrufen oder -Vorgängen innerhalb eines Zeitfensters, um eine Überlastung von Ressourcen zu verhindern.

Was geschieht, wenn Sie in SharePoint Online gedrosselt abrufen?

Wenn Nutzungslimits überschritten werden, drosselt SharePoint Online alle weiteren Anforderungen von diesem Client für einen kurzen Zeitraum.

Bei Anforderungen, die ein Benutzer direkt im Browser ausführt, wird er von SharePoint Online zu einer Seite mit Informationen zur Einschränkung weitergeleitet. Die Anforderungen schlagen fehl.

Für Anforderungen, die eine Anwendung durchführt, einschließlich Microsoft Graph-, CSOM- oder REST-Aufrufen, gibt SharePoint Online HTTP-status Code 429 ("Zu viele Anforderungen") oder 503 ("Server zu ausgelastet") zurück, und die Anforderungen schlagen fehl.

  • HTTP 429 zeigt an, dass die aufrufende Anwendung zu viele Anforderungen innerhalb eines Zeitfensters gesendet und so einen vordefinierten Grenzwert überschritten hat.
  • HTTP 503 zeigt an, dass der Dienst nicht bereit ist, die Anforderung zu verarbeiten. Die häufige Ursache ist, dass der Dienst mehr temporäre Lastspitzen als erwartet aufweist.

In beiden Fällen enthält die Antwort einen Retry-After-Header, der anzeigt, wie lange die aufrufende Anwendung warten sollte, bevor sie es erneut versucht oder eine neue Anforderung sendet. Gedrosselte Anforderungen werden auf die Nutzungslimits angerechnet. Wenn Sie also Retry-After nicht respektierten, kann dies zu einer höheren Drosselung führen.

Wenn die problematische Anwendung weiterhin Nutzungslimits überschreitet, sperrt SharePoint Online die Anwendung oder bestimmte Anforderungsmuster der Anwendung möglicherweise vollständig. In diesem Fall erhält die Anwendung weiterhin den HTTP-Statuscode 503, und Microsoft benachrichtigt den Mandanten über die Sperre im Office 365-Nachrichtencenter.

Benutzereinschränkung

Drosselung schränkt die Anzahl der Anrufe und Vorgänge ein, die von Anwendungen im Auftrag eines Benutzers insgesamt getätigt werden, um eine Überlastung von Ressourcen zu verhindern.

Trotzdem kommt es selten vor, dass ein Benutzer in Microsoft Office SharePoint Online eingeschränkt wird. Der Dienst ist sehr stabil und für große Datenvolumen ausgelegt. Wenn Sie eingeschränkt werden, liegt dies zu 99 % an benutzerdefiniertem Code, z. B. benutzerdefinierten Webparts, komplexen Listenansichten und Abfragen oder benutzerdefinierten Apps, die Benutzer ausführen. Das bedeutet nicht, dass es keine anderen Gründe gibt, eingeschränkt zu werden, nur dass sie weniger häufig sind. Beispielsweise kann ein Benutzer, der eine große Datenmenge auf 10 Computern gleichzeitig synchronisiert, eine Einschränkung auslösen.

Anwendungseinschränkung

Zusätzlich zur Drosselung nach Benutzerkonto werden Grenzwerte auch auf Anwendungen in einem Mandanten angewendet.

Jede Anwendung besitzt ihre eigenen Grenzwerte in einem Mandanten, die auf der Anzahl der pro Organisation erworbenen Lizenzen basieren (enthaltene Lizenzen finden Sie in den unter SharePoint-Grenzwerte aufgeführten Plänen). Jede Anforderung, die eine Anwendung über alle API-Endpunkte hinweg sendet, einschließlich Microsoft Graph, CSOM und REST, zählt für die Nutzung der Anwendung.

SharePoint stellt verschiedene APIs bereit. Verschiedene APIs gehen je nach Komplexität der API mit unterschiedlichen Kosten einher. Die Kosten für APIs werden von SharePoint normalisiert und durch Ressourceneinheiten ausgedrückt. Die Grenzwerte einer Anwendung werden auch mithilfe von Ressourceneinheiten definiert.

In der folgenden Tabelle sind die Grenzwerte für Ressourceneinheiten für eine Anwendung in einem Mandanten definiert:

Lizenzanzahl 0–1k 1k–5k 5k–15k 15k–50k 50k+
App 1 Minute 1.200 2.400 3.600 4.800 6.000
App täglich 1.200.000 2.400.000 3.600.000 4.800.000 6.000.000

Hinweis

Wir behalten uns das Recht vor, die Grenzwerte für Ressourceneinheiten zu ändern.

In Bezug auf die API-Kosten weisen Microsoft Graph-APIs eine vordefinierte Ressourceneinheit pro Anforderung auf:

Ressourceneinheiten pro Anforderung Aktivitäten
1
  • Einzelelementabfrage, z. B. Element abrufen.
  • Delta mit einem Token.
    		•
    2
  • Abfrage mehrerer Elemente, z. B. untergeordnete Elemente auflisten, außer Delta mit einem Token.
  • Erstellen, Aktualisieren, Löschen und Hochladen.
    		•
    5
  • Alle Berechtigungsressourcenvorgänge, einschließlich $expand=permissions.
    		•

    Hinweis

    Wir behalten uns das Recht vor, die API-Ressourceneinheitskosten zu ändern.

    Delta mit einem Token ist die effizienteste Methode zum Scannen von Inhalten in SharePoint, und wir gehen unter Bewährte Methoden zum Überprüfen von Anwendungen ausführlicher darauf ein. Um Anwendungen zu unterstützen, die die Anleitungen befolgen, senken wir die Ressourceneinheitskosten von Deltaanforderungen mit einem Token auf 1 Ressourceneinheit, auch wenn es sich um eine Abfrage mit mehreren Elementen handelt. Die Deltaanforderung ohne ein Token wird als Abfrage mit mehreren Elementen betrachtet und kostet 2 Ressourceneinheiten pro Anforderung.

    Bei der Batchverarbeitung werden Anforderungen in einem Batch einzeln nach Ressourceneinheiten ausgewertet.

    CSOM und REST haben keine vordefinierten Kosten für Ressourceneinheiten und verbrauchen in der Regel mehr Ressourceneinheiten als Microsoft Graph-APIs , um die gleiche Funktionalität zu erreichen. Außerdem unterliegen CSOM und REST zusätzlich zu den Grenzwerten für Ressourceneinheiten noch weiteren internen Ressourcengrenzwerten. Wenn also Anwendungen CSOM und REST aufrufen, kann es zu einer Drosselung kommen, die die in diesem Dokument beschriebenen Grenzwerte übersteigt. Es wird dringend empfohlen, nach Möglichkeit Microsoft Graph-APIs gegenüber CSOM- und REST-APIs zu wählen.

    Da Anwendungsgrenzwerte in Ressourceneinheiten angegeben werden, hängt die tatsächliche Anforderungsrate, z. B. Anforderungen pro Minute, von der API-Auswahl der Anwendung und den entsprechenden API-Ressourceneinheitskosten ab. Im Allgemeinen können Sie die Anforderungsrate mit durchschnittlich 2 Ressourceneinheiten pro Anforderung abschätzen und die Grenzwerte für Ressourceneinheiten durch 2 dividieren, um die geschätzte Anforderungsrate zu erhalten.

    Obwohl jede Anwendung innerhalb eines Mandanten eigene Grenzwerte aufweist und wir Mandanten das Ausführen mehrerer Anwendungen gestatten, teilen sich mehrere Anwendungen, die auf demselben Mandanten ausgeführt werden, denselben Ressourcenbucket, was in seltenen Fällen zu Ratenbegrenzungen führen kann, wenn zu viele Anwendungen zu diesem Zeitpunkt Anforderungen senden.

    Wie behandelt man Drosselung?

    Nachfolgend finden Sie eine kurze Zusammenfassung der bewährten Methoden für die Behandlung von Drosselung:

    • Verringern der Anzahl gleichzeitiger Anforderungen
    • Vermeiden von Anforderungsspitzen
    • Auswählen von Microsoft Graph-APIs über CSOM- und REST-APIs nach Möglichkeit
    • Verwenden der HTTP-Header Retry-After und RateLimit
    • Gestalten Sie Ihren Datenverkehr so aus, dass Ihre Identität ersichtlich ist (siehe Abschnitt mit den bewährten Methoden zur Datenverkehrsausgestaltung weiter unten).

    Wie bereits erwähnt, handelt es sich bei Microsoft Graph um cloudbasierte APIs mit den neuesten Verbesserungen und Optimierungen. Im Allgemeinen verbraucht Microsoft Graph weniger Ressourcen als CSOM und REST, um die gleiche Funktionalität zu erreichen. Daher kann die Einführung von Microsoft Graph die Leistung der Anwendung verbessern und die Drosselung reduzieren.

    Wenn es bei Ihnen zu einer Drosselung kommt, setzen wir die Nutzung des HTTP-Headers Retry-After durch, um eine Mindestverzögerung zu gewährleisten, bis die Drosselung beseitigt wurde. Die RateLimit-HTTP-Header senden Ihnen frühzeitig Signale, wenn Sie sich Grenzwerten nähern, und Sie können Anforderungen präventiv reduzieren, um eine eventuelle Drosselung zu vermeiden.

    „Retry-After“-Header

    Wenn es bei Anwendungen zu einer Drosselung kommt, gibt SharePoint Online einen Retry-After-HTTP-Header in der Anforderung zurück, der in Sekunden anzeigt, wie lange die aufrufende Anwendung warten sollte, bevor sie es erneut versucht oder eine neue Anforderung sendet.

    Den HTTP-Header Retry-After zu respektieren, ist der schnellste Weg, mit einer Drosselung umzugehen, da SharePoint Online dynamisch den richtigen Zeitpunkt für einen erneuten Versuch bestimmt.

    Gedrosselte Anforderungen werden auf die Nutzungslimits angerechnet. Wenn Sie also Retry-After nicht respektierten, kann dies zu einer höheren Drosselung führen. Mit anderen Worten, aggressive Wiederholungsversuche sind für die aufrufenden Anwendungen kontraproduktiv, da trotz Fehlschlagen der Aufrufe diese weiterhin auf die Nutzungslimits angerechnet werden. Das Respektieren des Retry-After HTTP-Headers stellt die kürzeste Verzögerung sicher und reduziert die Verschwendung von Kontingenten bei gedrosselten Anforderungen.

    RateLimit-Header (Vorschau)

    Zusätzlich zum Retry-After-Header in der Antwort gedrosselter Anforderungen gibt SharePoint Online auch die RateLimit-IETF-Header für ausgewählte Grenzwerte unter bestimmten Bedingungen zurück, um Anwendungen bei der Verwaltung der Ratenbegrenzung zu unterstützen. Wir empfehlen, Anwendungen diese Header nutzen zu lassen, um Drosselungen zu vermeiden.

    • RateLimit-Limit enthält den Grenzwert im aktuellen Zeitfenster.
    • RateLimit-Remaining zeigt das verbleibende Kontingent im aktuellen Fenster an.
    • RateLimit-Reset zeigt die Anzahl der verbleibenden Sekunden an, bis das Kontingent nachgefüllt wird.

    Hinweis

    Diese Header befinden sich derzeit in der Betaversion und können sich jederzeit ändern. Zum Zeitpunkt der Einführung der Header befand sich die IETF-Spezifikation noch im Entwurfsstadium. Die aktuelle Implementierung basiert auf draft-03 der IETF-Spezifikation. Es besteht die Möglichkeit von Änderungen, wenn die Spezifikation abgeschlossen ist, und wir werden diese Änderungen in Zukunft übernehmen.

    Die RateLimit-Header werden nach dem Best Effort-Prinzip zurückgegeben, sodass Anwendungen die Kopfzeilen möglicherweise nicht unter allen Umständen erhalten. Darüber hinaus gibt es weitere Grenzwerte, die nicht in den RateLimit-Headern angezeigt werden, weshalb Anwendungen sogar gedrosselt werden können, bevor sie den in den RateLimit-Headern beschriebenen Grenzwert erreicht haben. Nachfolgend finden Sie eine Liste der Grenzwerte, für die wird die RateLimit-Header unterstützen. Die Richtlinien und Werte können sich jederzeit ändern:

    Begrenzung Bedingung Grenzwert Beschreibung
    App 1 Minute Ressourceneinheit Nutzung >= 80 % des Grenzwerts Ressourceneinheit Wenn eine Anwendung 80 % oder mehr ihres „App 1 Minute“-Grenzwerts verbraucht, werden der Grenzwert, der verbleibende Wert und der Reset-Wert (Zurücksetzen) zurückgegeben.

    Im Folgenden finden Sie einige Beispiele, die Ihnen helfen, die RateLimit-Header zu verstehen:

    • Eine Anwendung hat 90 % ihres Ressourceneinheitskontingents (1.080 von 1.200) verbraucht, und ihr Verbrauch liegt innerhalb aller für sie geltenden Grenzwerte. Die Anforderung ist erfolgreich, und die RateLimit-Header werden zurückgegeben.
    HTTP/1.1 200 Ok
RateLimit-Limit: 1200
RateLimit-Remaining: 120
RateLimit-Reset: 5
    • Eine Anwendung hat 100 % ihres Ressourceneinheitskontingents verbraucht, weshalb sie durch diese Richtlinie gedrosselt wird. Die Anforderung wird gedrosselt, und die RateLimit-Header werden zurückgegeben. Retry-After stimmt mit RateLimit-Reset überein.
    HTTP/1.1 429 Too Many Requests
Retry-After: 31
RateLimit-Limit: 1200
RateLimit-Remaining: 0
RateLimit-Reset: 31
    • Eine Anwendung hat 90 % ihres Ressourceneinheitskontingents verbraucht, aber ihr Verbrauch hat bereits andere Grenzwerte erreicht, die von den RateLimit-Headern nicht unterstützt werden. In diesem Fall wird die Anforderung gedrosselt, und die RateLimit-Header werden nicht zurückgegeben, um Verwirrung zu vermeiden, obwohl die Bedingung für das Zurückgeben der Header erfüllt ist.
    HTTP/1.1 429 Too Many Requests
Retry-After: 9

    Weitere Informationen finden Sie unter Verhindern der Drosselung in Ihrer Anwendung mithilfe von RateLimit-Headern in SharePoint Online.

    Ausgestalten Ihres HTTP-Datenverkehrs

    Korrekt ausgestalteter Datenverkehr hat Vorrang vor nicht korrekt ausgestaltetem Datenverkehr.

    Wann gilt Datenverkehr als nicht ausgestaltet?

    • Datenverkehr gilt als nicht ausgestaltet, wenn API-Aufrufe an SharePoint Online die Zeichenfolgen „AppID“/„AppTitle“ und „UserAgent“ nicht enthalten. Die Zeichenfolge des Benutzer-Agenten sollte in einem bestimmten Format, wie nachstehend beschrieben, vorliegen.
    • Wenn Sie eine Webanwendung entwickeln, die im Browser ausgeführt wird, gestatten die meisten modernen Browser kein Überschreiben der UserAgent-Zeichenfolge, weshalb Sie sie nicht implementieren müssen.

    Nach welchen Empfehlungen sollte ich mich richten?

    • Wenn Sie eine Anwendung erstellt haben, empfiehlt es sich, „AppID“ und „AppTitle“ zu registrieren und zu verwenden. Dies gewährleistet die beste Gesamterfahrung und den besten Weg für jede zukünftige Problemlösung. Sie sollten zudem die Zeichenfolge des Benutzer-Agents einfügen, wie im nachfolgenden Beispiel beschrieben.

      Hinweis

      Informationen zum Erstellen einer Azure AD-Anwendung finden Sie in der Microsoft Identity-Dokumentation, z. B. auf der Seite Schnellstart: Registrieren einer Anwendung bei der Microsoft Identity Platform.

    • Verwenden Sie für die Zeichenfolge des Benutzer-Agenten im API-Aufruf auf jeden Fall die folgende Namenskonvention:

    Typ Benutzer-Agent Beschreibung
    ISV-Anwendung ISV|CompanyName|AppName/Version Diese Zeichenfolge identifiziert Sie als „ISV“ und enthält den Namen Ihres Unternehmens sowie den Namen der App, alles jeweils getrennt durch einen senkrechten Strich und gefolgt von einem Schrägstrich und der Versionsnummer.
    Unternehmensanwendung NONISV|CompanyName|AppName/Version Diese Zeichenfolge identifiziert Sie als „NONISV“ und enthält den Namen Ihres Unternehmens sowie den Namen der App, alles jeweils getrennt durch einen senkrechten Strich und gefolgt von einem Schrägstrich und der Versionsnummer.
    • Wenn Sie Ihre eigenen JavaScript-Bibliotheken erstellen, die zum Aufrufen von SharePoint-Online-APIs verwendet werden, stellen Sie sicher, dass Sie die Benutzer-Agent-Informationen in Ihre HTTP-Anforderung aufnehmen und Ihre Webanwendung gegebenenfalls auch als Anwendung registrieren.

    Hinweis

    Es wird erwartet, dass das Format der Zeichenfolge des Benutzer-Agents RFC2616 folgt. Befolgen Sie daher die obige Anleitung zu den rechten Trennzeichen. Sie können die erforderlichen Informationen auch an bereits vorhandene Benutzer-Agent-Zeichenfolgen anfügen.

    Allgemeine Einschränkungsszenarien in SharePoint Online

    Die häufigsten Ursachen für Drosselungen in SharePoint Online pro Benutzer werden mithilfe der clientseitigen Objektmodell (CSOM) oder Representational State Transfer (REST) Code, der zu häufig zu viele Aktionen ausführt.

    • Gelegentlicher Datenverkehr

      Eine konstante Auslastung oder sich wiederholenden komplexe Abfragen in SharePoint Online müssen für geringe Auswirkungen optimiert werden. Wenn Sie nicht die bewährten Methoden zum Überprüfen von Anwendungen befolgen, die Dateien massenverarbeiten, führt dies mit großer Wahrscheinlichkeit zu Einschränkungen. Zu diesen Apps gehören Synchronisierungsmodule, Sicherungsanbieter, Indexerstellungen für die Suche, Klassifizierungsmodule, Tools zur Verhinderung von Datenverlust sowie andere Tools, die versuchen, die gesamten Daten und Änderungen daran zu verarbeiten.

    • Overwhelming Datenverkehr

      Ein einzelner Prozess überschreitet erheblich Drosselung Grenzwerte ständig, über einen längeren Zeitraum Zeitraum.

      • Sie verwendet Webdienste zum Erstellen eines Tools zum Synchronisieren von Benutzerprofileigenschaften haben. Das Tool aktualisiert Benutzerprofileigenschaften basierend auf Informationen aus der Line-of-Business (LOB) Personalabteilung (HR)-System. Das Tool führt Aufrufe Zeitabständen zu hoch.
      • Sie führen ein Lasttest-Skript auf Microsoft Office SharePoint Online aus und werden gedrosselt. Auslastungstests sind auf Microsoft Office SharePoint Online nicht zugelassen.
      • Sie haben Ihre Teamwebsite auf SharePoint Online, beispielsweise durch Hinzufügen einer Statusanzeige auf der Homepage angepasst. Dieser Statusindikator aktualisiert häufig, die bewirkt, dass der Seite zu viele Aufrufe an den Dienst SharePoint Online - dieser Einschränkung ausgelöst.
      • Das Ausführen des OneDrive-Synchronisierungsclients beim gleichzeitigen Ausführen von Migrationsanwendungen oder Anwendungen, die Websites durchforsten und Daten zurückschreiben, kann zu hohen Anforderungsvolumen führen, die möglicherweise eine Drosselung auslösen.

    • Nicht unterstützte Anwendungsfälle

      Bei einer nicht unterstützten Verwendung von SharePoint Online kann es zu Einschränkungen kommen. Die Verwendung von SharePoint und OneDrive als Zwischendienst zwischen Microsoft 365 und einem anderen Repository ist ein Beispiel für einen nicht unterstützten Anwendungsfall.

    • Mehrere AppIDs für dieselbe Anwendung erstellen

      Erstellen Sie keine separaten AppIDs, wenn die Anwendungen im Wesentlichen dieselben Vorgänge ausführen, z. B. Sicherung oder Verhinderung von Datenverlust. Anwendungen, die für denselben Mandanten ausgeführt werden, verwenden letztendlich dieselbe Ressource des Mandanten. In der Vergangenheit hatten einige Anwendungen diesen Ansatz, um die Anwendungsdrosselung zu umgehen. Dies führte jedoch dazu, dass die Ressourcen des Mandanten erschöpft waren und mehrere Anwendungen im Mandanten gedrosselt wurden.

    Szenariospezifische Grenzwerte

    Bei Verwendung der reinen App-Authentifizierung mit der Berechtigung „Sites.Read.All“.

    Wenn Sie SharePoint Online-Such-APIs mit nur app-Authentifizierung verwenden und die App über die Berechtigung Sites.Read.All (oder stärker) verfügt, wird die App mit vollständigen Berechtigungen registriert und kann alle SharePoint Online-Inhalte (einschließlich der privaten OneDrive for Business Inhalte des Benutzers) abfragen.

    Um sicherzustellen, dass der Dienst schnell und zuverlässig bleibt, werden Abfragen mit einer solchen Berechtigung auf 25 Anforderungen pro Sekunde gedrosselt. Die Suchabfrage wird mit einer HTTP 429-Antwort zurückgegeben. Während des Wartens auf die Wiederherstellung von einer Drosselung sollten Sie alle Suchabfrageanforderungen anhalten, die Sie möglicherweise mittels ähnlicher reiner App-Genehmigungen an den Dienst senden. Das Ausführen weiterer Aufrufe, während Sie Drosselungsantworten erhalten, verlängert den Zeitraum, den es benötigt, bis die Drosselung Ihrer Anwendung aufgehoben wird.

    Bei der Suche nach Suchergebnissen für Personen

    Bei der Suche mithilfe einer Ergebnisquelle, die Personenergebnisse anfordert, können wir alle Anforderungen drosseln, die einen organization-weiten Grenzwert von 25 Anforderungen pro Sekunde überschreiten. Dieser Grenzwert gilt für alle SharePoint-Such-CSOM- und REST-Anforderungen, die entweder die vordefinierte Ergebnisquelle "Local Personen Results" oder eine benutzerdefinierte Ergebnisquelle für die Personensuche verwenden.

    Wenn Sie Anwendungen oder Komponenten besitzen, die dazu führen, dass Ihre Personensuchanforderungen gedrosselt werden, empfehlen wir Ihnen Folgendes:

    1. Überlegen Sie, ob die Anforderungen für Ihre Anwendung notwendig sind. Wenn Sie beispielsweise eine benutzerdefinierte Suchwebsite verwenden, die viele gleichzeitige Abfragen durchführt, überprüfen Sie, ob einige dieser Anforderungen entfernt werden können, ohne dass die Sucherfahrung Ihrer Organisation erheblich beeinträchtigt wird. Alternativ können Sie unsere moderne Personensuche in Microsoft Search ausprobieren, indem Sie auf der SharePoint-Startseite suchen. Die Personensuche in Microsoft Search wurde für bessere Leistung und relevantere Ergebnisse optimiert.
    2. Vermeiden Sie gleichzeitige Anfragen. Anstatt beispielsweise 10 Anfragen auf einmal zu stellen, geben Sie sie nacheinander aus – geben Sie die nächste Anfrage erst aus, nachdem die vorherige abgeschlossen ist. Möglicherweise müssen Sie erwägen, diese Ergebnisse zwischenzuspeichern, wenn Sie sie schnell benötigen, beispielsweise beim Laden einer Seite.
    3. Versuchen Sie, die Anforderungen in einer einzigen Abfrage zu konsolidieren. Führen Sie stattdessen beispielsweise 10 gleichzeitige Abfragen für WorkEmail:user1@constoso.com,..., WorkEmail:user2@constoso.comWorkEmail:user10@contoso.comaus, und versuchen Sie es mit der einzelnen AbfrageWorkEmail:user1@constoso.com WorkEmail:user2@constoso.com ... WorkEmail:user10@contoso.com.
    4. Erwägen Sie die Verwendung der Microsoft Graph-API, wenn ein Szenario mit hohem Anforderungsvolumen (über 25 Anforderungen pro Sekunde) wirklich erforderlich ist.

    Was sollten Sie tun, wenn Sie in SharePoint Online blockiert werden?

    Sperren stellen die äußerste Form von Einschränkung dar. Mandanten werden nur sehr selten gesperrt, es sei denn, es wird ein langfristiger, übermäßig hoher Datenverkehr festgestellt, der die Gesamtintegrität des SharePoint Online-Diensts beeinträchtigt. Sperren werden angewendet, um zu verhindern, dass dieser Datenverkehr die Leistung und Zuverlässigkeit von SharePoint Online beeinträchtigt. Eine Sperre, die in der Regel auf App- oder Benutzerebene verhängt wird, verhindert, dass der fehlerhafte Prozess ausgeführt wird – bis das Problem behoben ist. Wenn Ihr Abonnement gesperrt wird, müssen Sie aktiv werden, um die problematischen Prozesse zu ändern. Erst dann kann die Sperre entfernt werden.

    Wenn wir Ihr Abonnement sperren, werden wir Sie im Nachrichtenzentrum von Office 365 über die Sperrung informieren. In der Nachricht wird beschrieben, was die Sperre verursacht. Die Nachricht enthält außerdem Anleitungen zum Beheben des Problems und teilt Ihnen mit, an wen Sie sich wenden können, um die Sperre zu entfernen.

    Siehe auch