Remote-Zeitgeberaufträge im SharePoint-Add-In-Modell

Wichtig

SharePoint-Add-Ins haben am 2. April 2026 das Ende der Lebensdauer in SharePoint Online erreicht. Sowohl von SharePoint als auch vom Anbieter gehostete Add-Ins werden eingestellt und funktionieren nicht mehr in SharePoint Online, einschließlich Government-Clouds. Die Hinweise zu Add-Ins-Entwicklung, -Bereitstellung und -Verwendung werden als historische Referenz und für anwendbare SharePoint Server-Szenarien beibehalten, nicht für neue SharePoint Online-Lösungen.

SharePoint Server-Add-Ins, die über einen lokalen App-Katalog bereitgestellt werden, werden durch diese Änderung nicht zurückgezogen. Der Erwerb von SharePoint-Add-Ins aus dem öffentlichen Marketplace endete am 2. April 2026 für SharePoint Server.

Mit dieser Einstellung werden SharePoint-REST-APIs, CSOM, JSOM oder SharePoint-Framework (SPFx) nicht außer Betrieb genommen. Verwenden Sie für SharePoint Online SPFx für Benutzeroberflächenerweiterungen und Microsoft Entra ID für die Authentifizierung bei externen Anwendungen. Weitere Informationen finden Sie in der Ankündigung der Einstellung und in der Anleitung zur Add-In-Migration.

Der Ansatz zum Implementieren von Zeitgeberaufträgen unterscheidet sich im neuen SharePoint-Add-In-Modell von der Vorgehensweise bei voll vertrauenswürdigem Code. In einem typischen Szenario mit Full Trust Code (FTC)/Farmlösung wurden SharePoint-Zeitgeberaufträge mit dem SharePoint-Server-Side-Objektmodellcode erstellt, über Farmlösungen bereitgestellt und auf der Website für die SharePoint-Zentraladministration verwaltet. SharePoint behandelt die Planung und Ausführung des Zeitgeberauftrags in diesem Szenario.

Im SharePoint-Add-In-Modellszenario werden Zeitgeberaufträge außerhalb von SharePoint erstellt und geplant. SharePoint ist in diesem Szenario nicht für die Planung oder die Ausführung des Zeitgeberauftrags verantwortlich.

Richtlinien auf hoher Ebene

Als Faustregel werden die folgenden allgemeinen Richtlinien für die Erstellung von Zeitgeberaufträgen bereitgestellt.

  • Zeitgeberaufträge sollten außerhalb von SharePoint implementiert werden.
  • Die Planung von Zeitgeberaufträgen sollte außerhalb von SharePoint implementiert werden.
  • Zeitgeberaufträge sollten über ein Dienstkonto oder OAuth authentifiziert werden.

Herausforderungen beim Erstellen von Zeitgeberaufträgen

Die größte Herausforderung beim Erstellen von Zeitgeberaufträgen in Office 365-Mandanten besteht darin, dass Sie keine Lösungen auf Farmebene für einen Office 365-Mandanten bereitstellen können. Ohne eine Lösung mit Farmumfang können Sie keinen SharePoint-Zeitgeberauftrag bereitstellen.

Die neue Möglichkeit zum Erstellen eines Zeitgeberauftrags ist, ihn außerhalb von SharePoint zu erstellen und die Planung ebenfalls außerhalb von SharePoint zu verarbeiten. Berücksichtigen Sie die folgenden Faktoren für SharePoint-Zeitgeberaufträge für eine lokale SharePoint-Umgebung.

  • SharePoint wird mit Hunderten von standardmäßigen Zeitgeberaufträgen bereitgestellt, mit denen der SharePoint-Planer Schritt halten muss.
  • Sie können die Menge an Arbeitsspeicher und Prozessorleistung, die auf Ihrem SharePoint-Server benötigt wird, reduzieren, indem Sie den Implementierungscode nach Azure oder in eine andere Umgebung verschieben.
  • Das Verschieben des Planungs- und Implementierungscodes für Zeitgeberaufträge auf einen anderen Server macht Ihren SharePoint-Server skalierbarer und stabiler.

Optionen zum Planen von Zeitgeberaufträgen

Es gibt eine Reihe von Optionen, um die Planung für einen Zeitgeberauftrag zu implementieren.

  • Windows-Planer
    • Windows-Dienst
  • Azure WebJob
    • Azure-Arbeitsprozess

Windows-Planer

In diesem Muster übernimmt der Windows Scheduler die Planungsaspekte eines Zeitgeberauftrags. Der Implementierungscode kann eine Konsolenanwendung oder ein PowerShell-Skript oder ein beliebiger anderer Code sein, den der Windows Scheduler aufrufen kann.

Windows-Dienst-Unteroption

Ein Windows-Dienst weist die gleichen Eigenschaften wie der Windows-Scheduler auf. Dieses Muster wird von Microsoft nicht empfohlen, ist aber erwähnenswert, da es häufig verwendet wird.

Wann ist der Windows-Planer geeignet?

Wenn Sie keinen Zugriff auf ein Azure-Abonnement haben, um Zeitgeberaufträge mit Azure WebJobs zu planen, ist die Verwendung eines Windows-Schedulers eine gute Option, da diese Option auf jedem Computer mit dem Windows-Betriebssystem implementiert werden kann.

  • Erfordert zusätzliche Hardware, um den Windows-Planer auszuführen.
  • Erfordert zusätzliche Hardware, um den Zeitgeberauftragscode auszuführen.

Erste Schritte

Die folgenden Artikel verwenden das Muster für den Windows-Planer und stellen Codebeispiele bereit, um Ihnen den Einstieg zu erleichtern.

Azure WebJob

In diesem Muster übernimmt der Azure-WebJob die Planungsaspekte im Zusammenhang mit einem Zeitgeberauftrag enthält den Implementierungscode.

  • Erfordert keine zusätzliche Hardware, um den Azure WebJob auszuführen (Planungs- und Implementierungscode).
  • Vorteilhaft, da der Azure-WebJob sowohl für Planung als auch für den Implementierungscode verwendet wird, was die Verwaltung an einem zentralen Ort vereinfacht.

Unteroption der Azure-Workerrolle

Eine Azure-Workerrolle hat die gleichen Merkmale wie ein Azure-WebJob. Dieses Muster wird von Microsoft nicht empfohlen, ist aber erwähnenswert, da es häufig verwendet wird.

Wann ist Azure WebJob geeignet?

Wenn Sie Zugriff auf ein Azure-Abonnement haben, um Zeitgeberaufträge mit Azure WebJobs zu planen.

Erste Schritte

Die folgenden Artikel beschreiben das Muster für den Azure WebJob und stellen Codebeispiele bereit, um Ihnen den Einstieg zu erleichtern.

Authentifizierungsoptionen

Damit Ihre Zeitgeberaufträge mit SharePoint interagieren können, müssen sie authentifiziert werden. Derzeit gibt es zwei Muster, die Sie zur Authentifizierung von Zeitgeberaufträgen verwenden können.

  • Verwenden eines Dienstkontos
  • Verwenden von OAuth

Verwenden eines Dienstkontos

In diesem Muster definieren Sie eines oder mehrere Dienstkonten, die zur Authentifizierung von Zeitgeberaufträgen verwendet werden.

  • Dienstkonten werden in SharePoint definiert.

    • In einem Office 365-Mandaten benötigen die Dienstkonten, abhängig von den Funktionen der Zeitgeberaufträge, eine Office 365-Lizenz.
    • Sie können Dienstkonten pro Zeitgeberauftrag erstellen oder ein einziges Konto für alle Zeitgeberaufträge verwenden.
    • Erstellen Sie eindeutige und aussagekräftige Namen für die Dienstkonten, damit Sie die Operationen einfacher nachverfolgen können, die sie ausführen.

    Beispiel: Wenn Ihr Zeitgeberauftrag Listenelemente ändert, zeigt die Spalte „Geändert von“ für die Listenelemente den Namen des Dienstkontos für den Zeitgeberauftrag an.

  • Bei der Authentifizierung für Dienstkonten müssen Sie einen Benutzernamen und ein Kennwort für das Dienstkonto abrufen.

    • Der folgende Codeausschnitt veranschaulicht die Verwendung eines Benutzernamens und Kennworts zur Authentifizierung.

    • Setzen Sie beim Speichern und Abrufen des Benutzernamens und Kennworts auf Sicherheit.

      using (ClientContext context = new ClientContext("https://tenancy.sharepoint.com"))
{
  // Use default authentication mode
  context.AuthenticationMode = ClientAuthenticationMode.Default;
  // Specify the credentials for the account that will execute the request
  context.Credentials = new SharePointOnlineCredentials("User Name", "Password");
}

Erste Schritte

Die folgenden Artikel beschreiben die Verwendung eines Musters für die Dienstkonto-Authentifizierung und stellen Codebeispiele bereit, um Ihnen den Einstieg zu erleichtern.

Verwenden von OAuth

In diesem Muster definieren Sie eine Anwendung in SharePoint oder Azure Active Directory und verwenden die Authentifizierungstoken der Anwendung zur Authentifizierung.

  • Wenn Sie eine SharePoint-Anwendung zur Authentifizierung verwenden, erstellen Sie einen App-Prinzipal und weisen diesem Berechtigungen zu.

    • In diesem Muster werden möglicherweise über ein vom Anbieter gehostetes SharePoint-Add-in oder eine Konsolenanwendung Zeitgeberaufträge implementiert.
    • Um einen App-Hauptbenutzer für das vom Anbieter gehostete SharePoint-Add-In oder die Konsolenanwendung zu registrieren, verwenden Sie die Seite „AppRegNew“ in SharePoint.

    Der Zugriff auf diese Seite erfolgt unter der folgenden URL http://<tenancy>/<site>/_layouts/AppRegNew.aspx

    • Zum Erteilen von Berechtigungen zu einem App-Hauptbenutzer können Sie die Seite „AppInv“ in SharePoint verwenden.

    Der Zugriff auf diese Seite erfolgt unter der folgenden URL http://<tenancy>/<site>/_layouts/AppInv.aspx

  • Zeitgeberaufträge verwenden Nur-App-Berechtigungen, da ihnen kein interaktiver Benutzer zugeordnet ist.

    • Der folgende Codeausschnitt veranschaulicht das Abrufen eines Zugriffstokens und die Verwendung von Nur-App-Berechtigungen für die Authentifizierung bei SharePoint.

      string accessToken = TokenHelper.GetAppOnlyAccessToken(TokenHelper.SharePointPrincipal, siteUri.Authority, realm).AccessToken;

using(var clientContext = TokenHelper.GetClientContextWithAccessToken(siteUri.ToString(),accessToken))
{
  //Implement timer job code
}

  • Wenn Sie eine Azure Active Directory-Anwendung zur Authentifizierung verwenden, erstellen Sie eine Azure Active Directory-Anwendung im Azure-Portal und weisen Sie ihr Berechtigungen zu.

    • In diesem Muster werden möglicherweise über ein vom Anbieter gehostetes SharePoint-Add-in oder eine Konsolenanwendung Zeitgeberaufträge implementiert.
    • In diesem Muster interagieren Sie mit der Active Directory-Authentifizierungsbibliothek oder der Microsoft Graph-API, um ein Zugriffstoken abzurufen.
    • Das Zugriffstoken wird verwendet, um SharePoint (und möglicherweise andere Office 365-Dienste in einem Office 365-Mandanten) zu authentifizieren.

Erste Schritte

Die folgenden Artikel beschreiben das OAuth-Authentifizierungsmuster und stellen Codebeispiele für die ersten Schritte bereit.

PnP-Beispiele

Gilt für

  • Office 365 mehrinstanzenfähig (Office 365 Multi-Tenant, MT)
  • Office 365 dediziert (D) teilweise
  • SharePoint 2013 lokal – teilweise

Muster für dedizierte und lokale Umgebungen sind identisch mit SharePoint-Add-In-Modelltechniken, aber es gibt Unterschiede bezüglich der verwendbaren Technologien.

  • Zuletzt aktualisiert um