Bekannte Probleme in Microsoft Graph

Artikel
07/07/2022
20 Minuten Lesedauer

Dieser Artikel beschreibt bekannte Probleme in Microsoft Graph.

Zum Melden eines bekannten Problems siehe die Seite Microsoft Graph-Support.

Informationen zu den neuesten Updates für die Microsoft Graph-API finden Sie im Microsoft Graph-Änderungsprotokoll.

Anwendungen

Einige Beschränkungen gelten für die „application-“ und „servicePrincipal“-Ressourcen

Die Änderungen an den application- und servicePrincipal--Ressourcen werden derzeit entwickelt. Nachfolgend finden Sie eine Zusammenfassung aktueller Einschränkungen und API-Features, die derzeit entwickelt werden.

Aktuelle Einschränkungen:

Einige Anwendungseigenschaften (z. B. appRoles und addIns) sind erst verfügbar, wenn alle Änderungen abgeschlossen sind.
Es können nur Apps mit mehreren Mandanten registriert werden.
Das Aktualisieren von Apps ist auf Apps beschränkt, die nach dem anfänglichen Beta-Update registriert wurden.
Azure Active Directory-Benutzer können Apps registrieren und weitere Besitzer hinzufügen.
Unterstützung für OpenID Connect und OAuth-Protokolle.
Richtlinienzuweisungen zu einer App schlagen fehl.
Vorgänge mit ownedObjects, die die appId erfordern, schlagen fehl (z. B. users/{id|userPrincipalName}/ownedObjects/{id}/...).

In der Entwicklung:

Die Möglichkeit, Apps mit nur einem Mandanten zu registrieren.
Updates für servicePrincipal.
Migration von vorhandenen Azure AD-Apps zum aktualisierten Modell.
Unterstützung für appRoles, vorab autorisierte Clients, optionale Ansprüche, Gruppenmitgliedschaftsansprüche und Branding
Benutzer eines Microsoft-Kontos (MSA-Benutzer) können Apps registrieren.

Azure AD v2.0-Endpunkt wird für CSP-Apps nicht unterstützt

CSP-Apps (Cloud-Lösungsanbieter) müssen Token von den Azure AD (v1)-Endpunkten erwerben, um Microsoft Graph erfolgreich in ihren partnerverwalteten Kunden aufrufen zu können. Derzeit wird der Erwerb eines Tokens über den neueren Azure AD v2.0-Endpunkt nicht unterstützt.

Unter bestimmten Umständen funktioniert die Vorabgenehmigung für Apps vom Cloudlösungsanbieter (Cloud Solution Provider – CSP) bei einigen Kundenmandanten möglicherweise nicht.

Für Apps, die delegierte Berechtigungen verwenden, wird bei der ersten Verwendung der App mit einem neuen Kundenmandanten möglicherweise der folgende Fehler nach der Anmeldung angezeigt: AADSTS50000: There was an error issuing a token.
Für Apps, die Anwendungsberechtigungen verwenden, kann Ihre App ein Token erfassen, beim Aufrufen von Microsoft Graph wird jedoch unerwartet die Meldung angezeigt, dass der Zugriff verweigert wurde.

Wir arbeiten daran, dieses Problem so schnell wie möglich zu lösen, damit die Vorabgenehmigung für alle Kundenmandanten funktioniert.

In der Zwischenzeit können Sie die folgende Problemumgehung verwenden, um die Entwicklung und das Testen nicht zu blockieren.

Hinweis

Dies ist keine dauerhafte Lösung und soll nur dazu dienen, die Entwicklung nicht zu blockieren. Diese Problemumgehung wird nicht mehr benötigt, wenn das Problem behoben ist. Diese Problemumgehung muss nicht rückgängig gemacht werden, nachdem die Anforderung behoben wurde.

Öffnen Sie eine Azure AD v2-PowerShell-Sitzung, und stellen Sie eine Verbindung mit Ihrem customer-Mandanten her, indem Sie Ihre Administrator-Anmeldeinformationen in das Anmeldefenster eingeben. Sie können Azure AD PowerShell V2 hier herunterladen und installieren.
```
Connect-AzureAd -TenantId {customerTenantIdOrDomainName}
```

Erstellen Sie den Microsoft Graph-Dienstprinzipal.

New-AzureADServicePrincipal -AppId 00000003-0000-0000-c000-000000000000

Bookings

Fehler beim Abfragen von bookingBusinesses

Beim Abrufen der Liste mit bookingBusinesses tritt ein Fehler mit dem folgenden Fehlercode auf, wenn eine Organisation über mehrere Buchungsunternehmen verfügt und das Konto, das die Anforderung stellt, kein Administratorkonto ist:

{
  "error": {
    "code": "ErrorExceededFindCountLimit",
    "message":
      "The GetBookingMailboxes request returned too many results. Please specify a query to limit the results.",
  }
}

Schränken Sie zur Umgehung dieses Problems den Satz von Unternehmen ein, der von der Anforderung zurückgegeben wird, indem Sie einen query-Parameter einbeziehen. Beispiel:

GET https://graph.microsoft.com/beta/bookingBusinesses?query=Fabrikam

Kalender

Fehler beim Zugreifen auf einen freigegebenen Kalender

Beim Versuch, auf Ereignisse in einem Kalender zuzugreifen, der von einem anderen Benutzer mithilfe des folgenden Vorgangs freigegeben wurde:

GET /users/{id}/calendars/{id}/events

Möglicherweise wird HTTP 500 mit dem Fehlercode ErrorInternalServerTransientError angezeigt. Der Fehler tritt aus folgendem Grund auf:

Bisher gibt es zwei Methoden zur Implementierung der Kalenderfreigabe, die zur Unterscheidung einmal als der „alte“ Implementierungsansatz und einmal als der „neue“ Implementierungsansatz bezeichnet werden.
Der neue Ansatz ist derzeit für die Kalenderfreigabe mit Berechtigungen zum Anzeigen oder Bearbeiten verfügbar, jedoch nicht mit aber nicht mit Berechtigungen der Stellvertretung.
Sie können die Kalender-REST-API verwenden, um freigegebene Kalender anzuzeigen oder freizugeben, aber nur, wenn die Kalender auf die neue Weise freigegebenen wurden.
Sie können die Kalender-REST-API nicht verwenden, um freigegebene Kalender (oder deren Ereignisse) anzuzeigen oder freizugeben, wenn die Kalender auf die alte Weise freigegebenen wurden.

Wenn ein Kalender mit Berechtigungen zum Anzeigen oder Bearbeiten auf die alte Weise freigegeben wurde, können Sie dieses Problem umgehen und die Kalenderfreigabe für die Verwendung des neuen Ansatzes aktualisieren. Im Laufe der Zeit werden alle freigegebenen Kalender für die Verwendung des neuen Ansatzes automatisch in Outlook aktualisiert, einschließlich mit Berechtigungen der Stellvertretung freigegebener Kalender.

Gehen Sie folgendermaßen vor, um einen freigegebenen Kalender für die Verwendung des neuen Ansatzes manuell zu aktualisieren:

Der Empfänger entfernt den Kalender, der zuvor für diesen freigegeben wurde.
Der Besitzer des Kalenders gibt den Kalender erneut in Outlook im Web, Outlook für iOS oder Outlook für Android frei.
Der Empfänger akzeptiert den freigegebenen Kalender mithilfe von Outlook im Web erneut. (Zukünftig können auch andere Outlook-Clients verwendet werden.)
Der Empfänger überprüft, ob der Kalender auf die neue Weise erfolgreich erneut freigegeben wurde und in Outlook für iOS oder in Outlook für Android angezeigt werden kann.

Ein für Sie mit dem neuen Ansatz freigegebener Kalender wird genau wie jeder andere Kalender in Ihrem Postfach angezeigt. Sie können die Kalender-REST-API verwenden, um Ereignisse im freigegebenen Kalender so anzuzeigen oder zu bearbeiten, als wäre es Ihr eigener Kalender. Beispiel:

GET /me/calendars/{id}/events

Partielle Unterstützung für das Hinzufügen von und Zugreifen auf ICS-basierte Kalender im Postfach des Benutzers

Derzeit werden Kalender, die auf einem Internet-Kalenderabonnement (ICS) basieren, nur teilweise Unterstützt:

Sie können einen ICS-basierten Kalender einem Benutzerpostfach über die Benutzeroberfläche, jedoch nicht über die Microsoft Graph-API hinzufügen.
Das Auflisten der Kalender des Benutzers ermöglicht Ihnen, die Eigenschaften name, color und id jedes Kalenders in der Standardkalendergruppe des Benutzers oder einer bestimmten Kalendergruppe abzurufen, einschließlich ICS-basierte Kalender. Sie können die ICS-URL in der Kalenderressource nicht speichern und nicht darauf zugreifen.
Sie haben auch die Möglichkeit zum Auflisten der Ereignisse eines ICS-basierten Kalenders.

Fehler beim Anfügen von großen Dateien an Ereignisse

Eine App mit delegierten Berechtigungen gibt HTTP 403 Forbidden zurück, wenn Sie versuchen, große Dateien an eine Outlook-Nachricht oder ein Ereignis anzufügen, die bzw. das sich in einem freigegebenen oder delegierten Postfach befindet. Bei delegierten Berechtigungen ist createUploadSession nur dann erfolgreich, wenn sich die Nachricht oder das Ereignis im Postfach des signierten Benutzers befindet.

onlineMeetingUrl-Eigenschaft wird für Microsoft Teams nicht unterstützt

Derzeit gibt die onlineMeetingUrl-Eigenschaft einer Skype-Besprechung event die URL der Online-Besprechung angeben. Allerdings wird diese Eigenschaft für eine Microsoft Teams-Besprechung auf Null festgelegt.

Die Beta-Version bietet eine Problemumgehung, bei der Sie die Eigenschaft onlineMeetingProvider eines Ereignisses verwenden können, um zu überprüfen, dass es sich bei dem Anbieter um Microsoft Teams handelt. Über die Eigenschaft onlineMeeting des Ereignisses können Sie auf die joinUrl zugreifen.

Ändern von Benachrichtigungen

Updatebenachrichtigungen treten beim Erstellen und vorläufigen Löschen von Benutzern auf

Abonnements von Änderungen für Benutzer, deren changeType auf updated (aktualisiert) festgelegt ist, erhalten auch Benachrichtigungen zu changeType: updated beim Erstellen und vorläufigen Löschen von Benutzern.

Updatebenachrichtigungen treten beim Erstellen und vorläufigen Löschen von Gruppen auf

Abonnements von Änderungen für Gruppe, deren changeType auf updated (aktualisiert) festgelegt ist, erhalten auch Benachrichtigungen zu changeType: updated beim Erstellen und vorläufigen Löschen von Gruppen.

Cloud-Kommunikation

Der Microsoft Teams-Client zeigt das Menü Besprechungsdetails anzeigen nicht für Kanalbesprechungen an, die über die Cloud-Kommunikations-API erstellt wurden.

Die Moderatorenrolle kann Nicht-Azure AD-Teilnehmern nicht zugewiesen werden

Das Zuweisen der presenter Oder-Rolle coorganizer zu Benutzern, die nicht in Azure Active Directory registriert sind, wird derzeit nicht unterstützt. Solche Anforderungen werden von der Create onlineMeeting-Methode akzeptiert, aber die Rolle wird nicht angewendet, wenn der Teilnehmer an der Onlinebesprechung teilnimmt. Die create onlineMeeting-Methode lehnt die Anforderung ab und gibt einen 400 Bad Request Fehler zurück.

Kontakte

Der GET-Vorgang gibt keinen Standardordner für Kontakte zurück

In der /v1.0-Version enthält GET /me/contactFolders keinen Standardordner für Kontakte des Benutzers.

Es wird ein Update zur Verfügung gestellt. In der Zwischenzeit können Sie die folgende list contacts-Abfrage und die parentFolderId-Eigenschaft als Problemumgehung verwenden, um die ID des Standardordners für Kontakte abzurufen:

GET https://graph.microsoft.com/v1.0/me/contacts?$top=1&$select=parentFolderId

In dieser Anforderung:

/me/contacts?$top=1 ruft die Eigenschaften eines Kontakts im Standardordner für Kontakte ab.
Das Anfügen von &$select=parentFolderId gibt nur die parentFolderId-Eigenschaft des Kontakts zurück, also die ID des Standardordners für Kontakte.

Das Zugreifen auf Kontakte über einen Kontakteordner funktioniert in der Betaversion nicht

In der Version /beta liegt aktuell ein Problem vor, aufgrund dessen der Zugriff auf einen Kontakt über die Angabe seines übergeordneten Ordners in der REST-Anforderungs-URL in den folgenden zwei Szenarien nicht möglich ist.

Zugreifen auf einen Kontakt über ein contactFolder-Objekt höchster Ebene eines Benutzers:

GET /me/contactfolders/{id}/contacts/{id}
GET /users/{id | userPrincipalName}/contactfolders/{id}/contacts/{id}

Zugreifen auf einen Kontakt in einem untergeordneten Ordner eines contactFolder:

GET /me/contactFolders/{id}/childFolders/{id}/.../contacts/{id}
GET /users/{id | userPrincipalName}/contactFolders/{id}/childFolders/{id}/contacts/{id}

Das vorherige Beispiel zeigt eine einzige Schachtelungsebene, aber ein Kontakt kann sich auch in einem untergeordneten Element eines untergeordneten Elements usw. befinden.

Alternativ können Sie den Kontakt ganz einfach per GET-Befehl abrufen, indem Sie seine ID wie gezeigt angeben. Das funktioniert, weil der Befehl „GET /contacts“ in der Version /beta auf alle Kontakte im Postfach des Benutzers angewendet wird:

GET /me/contacts/{id}
GET /users/{id | userPrincipalName}/contacts/{id}

Delta-Abfrage

OData-Kontext wird falsch zurückgegeben

OData-Kontext wird beim Nachverfolgen von Änderungen an Beziehungen manchmal falsch zurückgegeben.

Schemaerweiterungen werden nicht mit `select` zurückgegeben

Schemaerweiterungen (Legacy) werden nicht mit $select-Anweisung, sondern ohne $select zurückgegeben.

Clients können keine Änderungen an offenen Erweiterungen nachverfolgen

Clients können keine Änderungen an offenen Erweiterungen oder registrierten Schemaerweiterungen nachverfolgen.

Geräte und Apps | Geräteupdates (Windows Updates)

Zugreifen auf und Aktualisieren von Bereitstellungszielgruppen wird nicht unterstützt

Das Zugreifen auf und Aktualisieren von Bereitstellungszielgruppen auf Bereitstellungs-Ressourcen, die über Intune erstellt wurden, wird derzeit nicht unterstützt.

Das Auflisten von Bereitstellungszielgruppenmitgliedern und Auflisten von Ausschlüssen von Bereitstellungszielgruppen gibt 404 Not Found zurück.
Das Aktualisieren von Mitgliedern und Ausschlüssen der Bereitstellungszielgruppe oder die Aktualisierung nach ID gibt 202 Accepted zurück, aber die Zielgruppe wird nicht aktualisiert.

Erweiterungen

Die Änderungsnachverfolgung wird nicht unterstützt.

Die Änderungsnachverfolgung (Delta-Abfrage) wird für Eigenschaften von offenen Erweiterungen oder Schemaerweiterungen nicht unterstützt.

Das Erstellen einer Ressource und das Öffnen einer Erweiterung zur gleichen Zeit ist nicht möglich

Wenn Sie eine Instanz von Ressourcen des Typs administrativeUnit, device, group, organization oder user erstellen, können Sie nicht gleichzeitig eine offene Erweiterung angeben. Sie müssen zuerst die Instanz erstellen und dann eine POST-Anforderung auf diese Instanz anwenden, in der Sie die Daten der offenen Erweiterung angeben.

Erstellen einer Ressourceninstanz und Hinzufügen von Schemaerweiterungsdaten zur gleichen Zeit ist nicht möglich

Sie können während des Vorgangs zum Erstellen einer contact-, event-, message- oder post-Instanz nicht gleichzeitig eine Schemaerweiterung festlegen. Sie müssen zuerst die Ressourceninstanz erstellen und dann einen PATCH für die betreffende Instanz durchführen, um eine Schemaerweiterung und benutzerdefinierte Daten hinzuzufügen.

Grenzwert von 100 zulässigen Werten für Schemaerweiterungseigenschaften pro Ressourceninstanz.

Für Verzeichnisressourcen wie device, group und user gilt aktuell: Für eine Ressourceninstanz dürfen maximal 100 Eigenschaftswerte von Schemaerweiterungen festgelegt werden.

Ein Besitzer muss während des Aktualisieren einer schemaExtension-Definition mittels Microsoft Graph Explorer angegeben sein.

Wenn PATCH zum Aktualisieren einer schemaExtension verwendet wird, indem Graph Explorer verwendet wird, müssen Sie die Besitzer-Eigenschaft spezifizieren und sie auf ihren aktuellen appId Wert (welcher ein appId einer Anwendung, die Sie besitzen, sein muss) einstellen. Dies ist auch bei Clientanwendungen der Fall, das appId für welches nicht mit dem Besitzer identisch ist.

Filtern von Schemaerweiterungseigenschaften wird nicht für alle Entitätstypen unterstützt

Das Filtern von Schemaerweiterungseigenschaften (mit dem Ausdruck $filter) wird für Outlook-Entitätstypen – contact, event, message oder post, nicht unterstützt.

Dateien (OneDrive)

Der Zugriff auf das Laufwerk eines Benutzers, bevor der Benutzer darauf zugreift, führt zu einem Fehler

Beim ersten Zugriff auf ein persönliches Benutzerlaufwerk über Microsoft Graph tritt ein 401-Fehler auf, wenn der Benutzer seine persönliche Website noch nicht in einem Browser aufgerufen hat.

Gruppen

Microsoft Graph stellt zwei Berechtigungen (Group.Read.All und Group.ReadWrite.All) für den Zugriff auf die APIs für Gruppen und Microsoft Teams zur Verfügung. Diesen Berechtigungen muss ein Administrator seine Zustimmung erteilen. Zukünftig sollen neue Berechtigungen für Gruppen und Teams hinzugefügt werden, für die Benutzer ihre Zustimmung erteilen können.

Einige Gruppen-APIs unterstützen keine delegierten oder Nur-App-Berechtigungen

Ausschließlich die API für die Hauptgruppenadministration und -verwaltung unterstützt den Zugriff mithilfe delegierter oder Nur-App-Berechtigungen. Alle anderen Features der Gruppen-API unterstützen nur delegierte Berechtigungen.

Beispiele für Gruppenfeatures, die delegierte und Nur-App-Berechtigungen unterstützen:

Erstellen und Löschen von Gruppen
Abrufen und Aktualisieren von Gruppeneigenschaften, die zur Gruppenadministration oder -verwaltung gehören
Verzeichniseinstellungen für Gruppen, Typ und Synchronisierung
Gruppenbesitzer und Mitgliedschaft
Gruppenunterhaltungen und -Threads aufrufen

Beispiele für Gruppenfeatures, die nur delegierte Berechtigungen unterstützen:

Gruppenereignisse, Fotos
Externe Absender, akzeptierte oder abgelehnte Absender, Gruppenabonnement
Benutzerfavoriten und Anzahl ungesehener Elemente

Microsoft Graph umgeht Gruppenrichtlinien, die über Outlook im Web konfiguriert werden

Das Erstellen und Benennen einer Microsoft 365-Gruppe mit Microsoft Graph umgeht Microsoft 365-Gruppenrichtlinien, die über Outlook im Web konfiguriert werden.

Auf die Eigenschaft „allowExternalSenders“ kann nur über einheitlichen Gruppen zugegriffen werden.

Aktuell liegt ein Problem vor, aufgrund dessen sich die Eigenschaft allowExternalSenders einer Gruppe in POST- oder PATCH-Operationen nicht festlegen lässt. Das Problem tritt sowohl in /v1.0 als auch in /beta auf.

Auf die Eigenschaft AllowExternalSenders kann nur über einheitlichen Gruppen zugegriffen werden. Der Zugriff auf diese Eigenschaft auf Sicherheitsgruppen, einschließlich GET-Vorgänge, führt zu einem Fehler.

Durch das Entfernen eines Gruppenbesitzers wird der Benutzer auch als Gruppenmitglied entfernt

Wenn DELETE /groups/{id}/owners für eine Gruppe aufgerufen wird, die einem Team zugeordnet ist, wird der Benutzer auch aus der Liste „/groups/{id}/members“ entfernt. Um dies zu umgehen, sollten Sie den Benutzer sowohl aus Besitzern als auch aus Mitgliedern entfernen, dann 10 Sekunden warten, und sie dann den Mitgliedern wieder hinzufügen.

Identität und Zugriff

Die conditionalAccessPolicy API erfordert derzeit die Zustimmung zur Policy.Read.All Berechtigung zum Aufrufen der POST- und PATCH-Methoden. In Zukunft können Sie mit der Berechtigung Policy.ReadWrite.ConditionalAccess Richtlinien aus dem Verzeichnis lesen.

Die claimsMappingPolicy-API erfordert möglicherweise die Zustimmung sowohl der Policy.Read.All- als auch der Policy.ReadWrite.ConditionalAccess-Berechtigung für die LIST /policies/claimsMappingPolicies- und GET /policies/claimsMappingPolicies/{id}-Methoden wie folgt:

Wenn keine ClaimsMappingPolicy-Objekte zum Abrufen in einem LIST-Vorgang verfügbar sind, reicht eine der beiden Berechtigungen aus, um diese Methode aufzurufen.
Wenn ClaimsMappingPolicy-Objekte abgerufen werden müssen, muss Ihre App beiden Berechtigungen zustimmen. Wenn dies nicht der Fall ist, wird ein 403 Forbidden-Fehler zurückgegeben.

In Zukunft wird jede Berechtigung ausreichen, um beide Methoden aufzurufen.

Linux-basierte Geräte können von einer App mit Anwendungsberechtigungen nicht aktualisiert werden

Wenn eine App mit Anwendungsberechtigungen versucht, Eigenschaften des Geräteobjekts zu aktualisieren, bei dem die operationSystem-Eigenschaft linux ist, mit Ausnahme der extensionAttributes-Eigenschaft, gibt die Gerät aktualisieren-API den Fehlercode 400 Bad request mit der Fehlermeldung "Properties other than ExtendedAttribute1..15 can be modified only on windows devices." (Andere Eigenschaften als ExtendedAttribute1..15 können nur auf Windows-Geräten geändert werden). Verwenden Sie delegierte Berechtigungen, um die Eigenschaften von Linux-basierten Geräten zu aktualisieren.

JSON-Batchverarbeitung

Geschachtelte Batches werden nicht unterstützt

JSON-Batchanforderungen dürfen keine geschachtelten Batchanforderungen enthalten.

Alle einzelnen Anforderungen müssen synchron sein.

Alle in einer Batchanforderung enthaltenen Anforderungen müssen synchron ausgeführt werden. Falls vorhanden, wird die respond-async-Präferenz ignoriert.

Transaktionsverarbeitung von Anforderungen wird nicht unterstützt

Microsoft Graph unterstützt derzeit keine Transaktionsverarbeitung von einzelnen Anforderungen. Die atomicityGroup-Eigenschaft von einzelnen Anforderungen wird ignoriert.

URIs müssen relativ sein

Geben Sie in Batchanforderungen immer relative URIs an. Microsoft Graph macht daraus dann mithilfe des in der Batch-URL enthaltenen Versionsendpunkts absolute URLs.

Batchgröße ist begrenzt

JSON-Batchanforderungen sind derzeit auf 20 einzelne Anforderungen beschränkt.

Abhängig von den APIs, die Teil der Batchanforderung sind, legen die zugrunde liegenden Dienste eigene Grenzwerte für Einschränkungen fest, die sich auf Anwendungen auswirken, die Microsoft Graph verwenden, um darauf zuzugreifen.
Anforderungen in einem Batch werden einzeln anhand von Drosselungsgrenzwerten ausgewertet. Wenn eine Anforderung die Grenzwerte überschreitet, tritt der Statusfehler 429 auf.

Weitere Informationen finden Sie unter Drosselung und Batchverarbeitung.

Anforderungsabhängigkeiten sind begrenzt

Einzelne Anforderungen können von anderen einzelnen Anforderungen abhängen. Derzeit können Anforderungen nur von einer einzigen anderen Anforderung abhängen und müssen einem der folgenden drei Muster entsprechen:

Parallel: keine einzelne Anforderung gibt eine Abhängigkeit in der dependsOn-Eigenschaft an.
Seriell: Alle einzelnen Anforderungen hängen von der vorherigen einzelnen Anforderung ab.
Gleich – Alle einzelnen Anforderungen, die eine Abhängigkeit in der dependsOn-Eigenschaft angeben, geben die gleiche Abhängigkeit an. Note: Anforderungen, die mit diesem Muster vorgenommen werden, werden sequenziell ausgeführt.

In der weiteren Entwicklung der JSON-Batchverarbeitung werden diese Einschränkungen entfernt.

E-Mail (Outlook)

Das Anfügen großer Dateien an Nachrichten mit delegierten Berechtigungen kann fehlschlagen

Der comment-Parameter für das Erstellen eines Entwurfs wird nicht Teil des Textkörpers

Der comment-Parameter für das Erstellen eines Antwort- oder Weiterleitungsentwurfs (createReply, createReplyAll, createForward) wird nicht Teil des Textkörpers des resultierenden Nachrichtenentwurfs.

Nachrichten abrufen gibt Chats in Microsoft Teams zurück

In den v1.0- und Beta-Endpunkten beinhaltet die Antwort von GET /users/id/messages die Chats des Benutzers aus Microsoft Teams, die außerhalb des Bereichs eines Teams oder Kanal erfolgt sind. Diese Chatnachrichten haben „Chat“ als Betreff.

Berichte

Lizenzprüfungsfehler für Azure AD-Aktivitätsberichte

Wenn Sie über eine gültige Azure AD Premium-Lizenz verfügen und die directoryAudit, signIn, oder provisioning Azure AD-Aktivitätsbericht-APIs aufrufen, wird möglicherweise weiterhin eine Fehlermeldung angezeigt:

{
    "error": {
        "code": "Authentication_RequestFromNonPremiumTenantOrB2CTenant",
        "message": "Neither tenant is B2C or tenant doesn't have premium license",
        "innerError": {
            "date": "2021-09-02T17:15:30",
            "request-id": "73badd94-c0ca-4b09-a3e6-20c1f5f9a307",
            "client-request-id": "73badd94-c0ca-4b09-a3e6-20c1f5f9a307"
        }
    }
}

Dieser Fehler kann auch beim Abrufen der signInActivity Eigenschaft der Benutzer Ressource auftreten; zum Beispiel, https://graph.microsoft.com/beta/users?$select=signInActivity.

Dieser Fehler ist auf zeitweilige Fehler bei der Lizenzprüfung zurückzuführen, an deren Behebung wir arbeiten. Fügen Sie als vorübergehende Problemumgehung die Berechtigung Directory.Read.All hinzu. Diese vorübergehende Problemumgehung ist nicht erforderlich, wenn das Problem behoben ist.

Teamwork (Microsoft Teams)

Teammitglieder können nicht nach Rollen gefiltert werden

Rollenabfragefilter und andere Filter GET /teams/team-id/members?$filter=roles/any(r:r eq 'owner') and displayName eq 'dummy' funktionieren möglicherweise nicht. Der Server reagiert möglicherweise mit einem BAD REQUEST.

Anforderungen zum Filtern von Teammitgliedern nach Rolle erfordern einen Parameter

Alle Anforderungen zum Filtern von Teammitgliedern nach Rollen erwarten entweder einen skipToken-Parameter oder einen top-Paramater in der Anforderung, aber nicht beides. Wenn beide Parameter in der Anforderung übergeben werden, wird der top-Parameter ignoriert.

Einige Eigenschaften für Chatmitglieder können möglicherweise in der Antwort auf eine GET-Anforderung fehlen

In bestimmten Fällen kann es vorkommen, dass die tenantId / email / displayName Eigenschaft für die einzelnen Mitglieder eines Chats bei einer GET /chats/chat-id/members- oder GET /chats/chat-id/members/membership-id-Anfrage nicht ausgefüllt wird.

Eigenschaften fehlen in der Liste der Teams, denen ein Benutzer beigetreten ist

Der API-Aufruf für me/joinedTeams gibt nur die Eigenschaften id, displayName und description eines Teams zurück. Um alle Eigenschaften abzurufen, verwenden Sie die Operation Team abrufen.

Die folgenden API-Aufrufe unterstützen nicht die Installation von Apps, die ressourcenspezifische Zustimmungsberechtigungen erfordern.

Auf einen mandantenübergreifenden freigegebenen Kanal kann nicht zugegriffen werden, wenn die Anforderungs-URL „tenants/{cross-tenant-id}“ enthält.

Die API-Aufrufe für teams/{team-id}/incomingChannels und teams/{team-id}/allChannels geben die Eigenschaft @odata.id zurück, mit der Sie auf den Kanal zugreifen und andere Vorgänge für das Kanalobjekt ausführen können. Wenn Sie die von der Eigenschaft @odata.id zurückgegebene URL aufrufen, schlägt die Anforderung mit dem folgenden Fehler fehl, wenn sie versucht, auf den mandantenübergreifenden freigegebenen Kanal zuzugreifen:

GET /tenants/{tenant-id}/teams/{team-id}/channels/{channel-id}
{
    "error": {
        "code": "BadRequest",
        "message": "TenantId in the optional tenants/{tenantId} segment should match the tenantId(tid) in the token used to call Graph.",
        "innerError": {
            "date": "2022-03-08T07:33:50",
            "request-id": "dff19596-b5b2-421d-97d3-8d4b023263f3",
            "client-request-id": "32ee2cbd-27f8-2441-e3be-477dbe0cedfa"
        }
    }
}

Um dieses Problem zu beheben, entfernen Sie den Teil /tenants/{tenant-id} aus der URL, bevor Sie die API aufrufen, um auf den mandantenübergreifenden freigegebenen Kanal zuzugreifen.

TeamworkAppSettings-Berechtigungen sind im Azure-Portal nicht sichtbar

Die Berechtigungen TeamworkAppSettings.Read.All und TeamworkAppSettings.ReadWrite.All werden derzeit eingeführt und sind möglicherweise im Azure-Portal noch nicht sichtbar. Um diesen Berechtigungen zuzustimmen, verwenden Sie bitte eine Autorisierungsanforderung wie folgt:

GET https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize?client_id={client-app-id}&response_type=code&scope=https://graph.microsoft.com/TeamworkAppSettings.ReadWrite.All

Benutzer

Zahlensymbolen (#) in userPrincipalName codieren

Der userPrincipalName von Gastbenutzern, die über Azure AD B2B hinzugefügt wurden, enthält häufig das Zahlenzeichen (#). Die Verwendung von $filter für einen userPrincipalName, der das #-Symbol enthält, z. B. GET /users?$filter=userPrincipalName eq 'AdeleV_contoso.com#EXT#@fabrikam.com', gibt eine HTTP-Fehlerantwort „400 Bad request“ zurück. Um nach dem userPrincipalName zu filtern, codieren Sie das #-Zeichen mit seinem UTF-8-Äquivalent ( %23), z. B. GET /users?$filter=userPrincipalName eq 'AdeleV_contoso.com%23EXT%23@fabrikam.com'.

Der Zugriff auf Benutzerressourcen wird nach der Erstellung verzögert

Benutzer können direkt über POST in der Benutzerentität erstellt werden. Einem Benutzer muss zunächst eine Microsoft 365-Lizenz zugewiesen werden, damit dieser Zugriff auf Microsoft 365-Dienste erhält. Aufgrund der verteilten Art des Diensts kann es jedoch bis zu 15 Minuten dauern, bis Dateien-, Nachrichten- und Ereignisentitäten für diesen Benutzer über die Microsoft Graph-API zur Verfügung stehen. In dieser Zeit erhalten Apps als Antwort eine 404 Not Found HTTP-Fehlermeldung.

Der Zugriff auf das Profilfoto eines Benutzers ist eingeschränkt

Benutzerprofilfotos können nur gelesen und aktualisiert werden, wenn der Benutzer über ein Postfach verfügt. Beim Auftreten eines Fehlers beim Lesen oder Aktualisieren eines Fotos wird die folgende Meldung angezeigt:
```
{
  "error": {
    "code": "ErrorNonExistentMailbox",
    "message": "The SMTP address has no mailbox associated with it."
  }
}
```
Auf Fotos, die möglicherweise zuvor mithilfe der Eigenschaft thumbnailPhoto (unter Verwendung der Azure AD Graph-API (veraltet) oder über die AD Connect-Synchronisierung) gespeichert wurden, kann nicht mehr über die Microsoft Graph-Eigenschaft photo der Ressource user zugegriffen werden.
Das Verwalten von Benutzerfotos über die profilePhoto-Ressource der Microsoft Graph-API wird in Azure AD B2C-Mandanten derzeit nicht unterstützt.

Die Benutzer: revokeSignInSessions-API sollte eine 204 No content-Antwort auf erfolgreiche Sperrungen sowie einen HTTP-Fehlercode (4xx oder 5xx) zurückgeben, wenn bei der Anforderung etwas schief läuft. Aufgrund eines Dienstproblems gibt diese API jedoch 200 OK und einen booleschen Parameter zurück, der immer true ist. Solange dies nicht behoben ist, können Sie jeden 2xx-Rückgabecode als Erfolg für diese API behandeln.

Unvollständige Objekte werden bei Verwendung der getByIds-Anforderung zurückgegeben

Das Anfordern von Objekten mithilfe von Erhalten von Verzeichnisobjekten aus einer Liste von IDssollte vollständige Objekte zurückgeben. Allerdings werden derzeitBenutzer-Objekte am v 1.0-Endpunkt mit einem begrenzten Satz von Eigenschaften zurückgegeben. Als temporärer Problemumgehung werden, wenn Sie den Vorgang in Kombination mit der$selectAbfrageoption verwenden, vollständigere Benutzer -Objekte zurückgegeben. Dieses Verhalten entspricht nicht den OData-Spezifikationen. Da dieses Verhalten in Zukunft möglicherweise aktualisiert wird, verwenden Sie diese Problemumgehung nur, wenn Sie $select=mit allen Eigenschaften zur Verfügung stellen, die für Sie von Interesse sind, und nur dann, wenn zukünftige Änderungen an dieser Problemumgehung zulässig sind.

Die Eigenschaft showInAddressList ist nicht mit Microsoft Exchange synchron.

Beim Abfragen von Benutzern über Microsoft Graph gibt die Eigenschaft showInAddressList möglicherweise nicht denselben Status an, der in Microsoft Exchange angezeigt wird. Wir empfehlen, dass Sie diese Funktionalität direkt mit Microsoft Exchange über das Microsoft 365 Admin Center verwalten und diese Eigenschaft nicht in Microsoft Graph verwenden.

Abfrageparameter

Einige Beschränkungen gelten für Abfrageparameter

Die folgenden Beschränkungen gelten für Abfrageparameter:

Mehrere Namespaces werden nicht unterstützt.
GET-Anforderungen für $ref und Umwandlung werden für Benutzer, Gruppen, Geräte, Dienstprinzipale und Anwendungen nicht unterstützt.
@odata.bind wird nicht unterstützt. Dies bedeutet, dass Sie die Navigationseigenschaft acceptedSenders oder rejectedSenders für eine Gruppe nicht ordnungsgemäß festlegen können werden.
@odata.id ist bei Nicht-Aufnahmenavigationen (z. B. Nachrichten) nicht vorhanden, wenn minimale Metadaten verwendet werden.
$expand:
- Gibt maximal 20 Objekte zurück.
- Keine Unterstützung für @odata.nextLink.
- Keine Unterstützung für mehr als eine Erweiterungsebene.
- Keine Unterstützung mit zusätzlichen Parametern ($filter, $select).
$filter:
- Filter werden vom /attachments-Endpunkt nicht unterstützt. Falls vorhanden, wird der $filter-Parameter ignoriert.
- Arbeitsauslastungsübergreifende Filter werden nicht unterstützt.
$search:
- Volltextsuche ist nur für einige Entitäten wie Nachrichten verfügbar.
- Arbeitsauslastungsübergreifende Suche wird nicht unterstützt.
- Die Suche wird in Azure AD B2C-Mandanten nicht unterstützt.
$count:
- Wird in Azure AD B2C-Mandanten nicht unterstützt.
- Wenn Sie die $count=true-Abfragezeichenfolge beim Abfragen von Verzeichnisressourcen verwenden, ist die Eigenschaft @odata.count nur auf der ersten Seite der ausgelagerten Daten vorhanden.
Abfrageparameter, die in einer Anforderung angegeben sind, können im Hintergrund einen Fehler verursachen. Dies gilt für nicht unterstützte Abfrageparameter sowie für nicht unterstützte Kombinationen von Abfrageparametern.

Nur in Office 365-REST- oder Azure AD-Graph-APIs verfügbare Funktionen (veraltet)

Einige Funktionen sind in Microsoft Graph noch nicht verfügbar. Wenn die gesuchte Funktionalität nicht angezeigt wird, können Sie die endpunktspezifischen Office 365-REST-APIsverwenden. Informationen zu Azure AD Graph finden Sie unter Migrieren von Azure Active Directory (Azure AD) Graph-Apps zu Microsoft Graph.