Problèmes connus avec Microsoft Graph

Cet article décrit les problèmes connus avec Microsoft Graph.

Pour signaler un problème rencontré, consultez la page Prise en charge de Microsoft Graph .

Pour plus d’informations sur les dernières mises à jour de l’API Microsoft Graph, consultez le journal des modifications de Microsoft Graph.

Applications

Certaines limitations s’appliquent aux ressources application et servicePrincipal

Des modifications sont en cours pour les entités application et servicePrincipal. Voici un résumé des restrictions en cours et des fonctionnalités de l’API en cours de développement.

Restrictions en cours :

  • Certaines propriétés de l’application (par exemple, appRoles et addIns) ne seront disponibles que lorsque toutes les modifications auront été effectuées.
  • Seules les applications mutualisées peuvent être enregistrées.
  • La mise à jour des applications est limitée aux applications enregistrées après la mise à jour bêta initiale.
  • Les utilisateurs d’Azure Active Directory peuvent enregistrer des applications et ajouter des propriétaires supplémentaires.
  • Prise en charge des protocoles OpenID Connect et OAuth.
  • Échec des affectations de stratégie à une application.
  • Échec des opérations sur ownedObjects nécessitant un identificateur d’application (Par exemple, users/{id|userPrincipalName}/ownedObjects/{id}/...).

En cours de développement :

  • Possibilité d’enregistrer des applications de client unique.
  • Mises à jour de servicePrincipal.
  • Migration des applications Azure Active Directory existantes vers un modèle mis à jour.
  • Prise en charge d’appRoles, des clients préalablement autorisés, des revendications facultatives, des revendications d’appartenance de groupe et de la personnalisation
  • Les utilisateurs du compte Microsoft (MSA) peuvent enregistrer des applications.

Azure AD point de terminaison v2.0 n’est pas pris en charge pour les applications CSP

Les applications de fournisseur de solutions de cloud doivent acquérir des jetons des points de terminaison Azure AD (v1) pour appeler correctement Microsoft Graph dans leurs clients gérés par des partenaires. Actuellement, l’acquisition d’un jeton via le point de terminaison Azure AD v2.0 plus récent n’est pas prise en charge.

Dans certains cas, le pré-consentement pour les applications de fournisseur de solutions cloud (CSP) peut ne pas fonctionner pour certains de vos locataires clients.

  • Pour les applications utilisant des autorisations déléguées, lors de l’utilisation de l’application pour la première fois avec un nouveau locataire de client, l’erreur suivante peut être générée après la connexion : AADSTS50000: There was an error issuing a token.
  • Pour les applications utilisant des autorisations de l’application, votre application peut obtenir un jeton, mais inopinément recevoir un message d’accès refusé lors de l’appel de Microsoft Graph.

Nous travaillons sur ce problème pour qu’il soit résolu le plus vite possible afin que le consentement préalable fonctionne pour tous vos locataires de clients.

En attendant, pour débloquer le développement et les tests, vous pouvez utiliser la solution de contournement suivante.

NOTW: Il ne s’agit pas d’une solution permanente, elle vise uniquement à débloquer le développement. Cette solution de contournement ne sera plus nécessaire une fois le problème résolu. Cette solution de contournement n’a pas besoin d’être annulée une fois le correctif mis en place.

  1. Ouvrez une session Azure AD v2 PowerShell et connectez-vous à votre locataire customer en saisissant vos informations d’identification d’administrateur dans la fenêtre de connexion. Vous pouvez télécharger et installer Azure AD PowerShell V2 en cliquant ici.

    Connect-AzureAd -TenantId {customerTenantIdOrDomainName}
    
  2. Créer le principal de service de Microsoft Graph.

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

Réservations

Erreur lors de l’interrogation de bookingBusinesses

L’obtention de la liste de bookingBusinesses échoue avec le code d’erreur suivant lorsqu’une organisation a plusieurs entreprises de réservation et que le compte de la demande ne correspond pas à un administrateur :

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

Pour contourner le problème, vous pouvez limiter l’ensemble des entreprises renvoyé par la demande en incluant un paramètre query, par exemple :

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

Calendrier

Une erreur est survenue lors de l’accès à un calendrier partagé

Lorsque vous tentez d’accéder aux événements d’un calendrier qui a été partagé par un autre utilisateur à l’aide de l’opération suivante :

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

Le code d’erreur HTTP 500 ErrorInternalServerTransientError peut s’afficher. Voici les raisons pour lesquelles une erreur est générée :

  • Historiquement, il existe deux manières d’implémenter le partage de calendrier, qui seront appelées respectivement « ancienne » et « nouvelle » approche, par souci de commodité.
  • La nouvelle approche est actuellement disponible pour le partage de calendriers avec des autorisations d’affichage ou de modification, mais pas avec des autorisations déléguées.
  • Vous pouvez utiliser l’API REST du calendrier pour afficher ou modifier des calendriers partagés, uniquement si ceux-ci ont été partagés avec la nouvelle approche.
  • Par contre, vous ne pouvez pas l’utiliser pour afficher ou modifier ce type de calendriers (ou leurs événements) si les calendriers ont été partagés au moyen de l’ancienne approche.

Si un calendrier a été partagé avec des autorisations d’affichage ou de modification, mais avec l’ancienne approche, vous pouvez désormais contourner l’erreur et mettre à niveau manuellement le partage de calendrier de façon à utiliser la nouvelle approche. Au fil du temps, Outlook mettra automatiquement à niveau tous les calendriers partagés pour qu’ils utilisent la nouvelle approche, y compris ceux partagés avec des autorisations déléguées.

Pour mettre à niveau manuellement un calendrier partagé de sorte à utiliser la nouvelle approche, procédez comme suit :

  1. Le destinataire supprime le calendrier qui a été partagé avec lui précédemment.
  2. Le propriétaire du calendrier partage à nouveau le calendrier dans Outlook sur le web, Outlook sur iOS ou Outlook sur Android.
  3. Le destinataire accepte à nouveau le calendrier partagé à l’aide d’Outlook sur le web. (Les autres clients Outlook pourront bientôt être utilisés.)
  4. Pour vérifier que le calendrier a bien été partagé à l’aide de la nouvelle approche, le destinataire s’assure qu’il peut l’afficher dans Outlook sur iOS ou Outlook sur Android.

Un calendrier partagé avec vous à l’aide de la nouvelle approche a la même apparence que les autres calendriers figurant dans votre boîte aux lettres. Vous pouvez utiliser l’APi REST du calendrier pour afficher ou modifier des événements dans le calendrier partagé, comme s’il s’agissait de votre propre calendrier. Par exemple :

GET /me/calendars/{id}/events

Prise en charge partielle de l’ajout et de l’accès aux calendriers ICS dans la boîte aux lettres de l’utilisateur

Actuellement, les calendriers basés sur un abonnement ICS (Internet Calendar Subscription) ne sont que partiellement pris en charge :

  • Vous pouvez ajouter un calendrier ICS à la boîte aux lettres d’un utilisateur via l’interface utilisateur, mais pas via l’API Microsoft Graph.
  • La liste des calendriers de l’utilisateur vous permet d’obtenir les propriétés name, color et id de chaque calendrier dans le groupe des calendriers par défaut de l’utilisateur, ou un groupe de calendriers spécifié, y compris les calendriers ICS. Vous ne pouvez pas stocker ou accéder à l’URL ICS dans la ressource de calendrier.
  • Vous pouvez également répertorier les événements d’un calendrier ICS.

Une erreur est survenue lors de l’attachement de fichiers volumineux à des évènements

Une application dotée d’autorisations déléguées renvoie HTTP 403 Forbidden lorsque vous essayez de joindre des fichiers volumineux à un message Outlook ou un évènement figurant dans une boîte aux lettres partagée ou déléguée. Avec les autorisations déléguées, createUploadSession réussit uniquement si le message ou l'évènement se trouve dans la boîte aux lettres de l’utilisateur connecté.

la propriété onlineMeetingUrl n’est pas prise en charge pour Microsoft Teams

Pour l’instant, la propriété onlineMeetingUrl d’un événement de réunion Skype doit indiquer l’URL de la réunion en ligne. Toutefois, cette propriété est définie sur la valeur null pour les événements de réunion Microsoft Teams.

La version bêta offre une solution de contournement, dans laquelle vous pouvez utiliser la propriété onlineMeetingProvider d’un événement pour vérifier si le fournisseur est Microsoft Teams. Par le biais de la propriété onlineMeeting de l’événement, vous pouvez accéder à joinUrl.

Notifications de modification

Des notifications de mise à jour se produisent lors de la création et de la suppression réversible d’utilisateurs

Les abonnements aux modifications pour utilisateur avec changeType définis sur mise à jour reçoivent également les notifications de changeType: mis à jour sur la création et la suppression réversible d’utilisateurs.

Des notifications de mise à jour se produisent lors de la création et de la suppression réversible de groupes

Les abonnements aux modifications pour groupe avec changeType définis sur mis à jour reçoivent également les notifications de changeType: mis à jour sur la création et la suppression réversible de groupes.

Communications dans le cloud

Le menu Afficher les détails de la réunion n’est pas disponible sur le client Microsoft Teams

Le client Microsoft Teams n’affiche pas le menu Afficher les détails de la réunion pour les réunions de canal créées via l’API de communications cloud.

Contacts

L’opération GET ne retourne pas le dossier des contacts par défaut

Dans la version /v1.0, GET /me/contactFolders n’inclut pas de dossier des contacts par défaut de l’utilisateur.

Un correctif sera disponible. En attendant, vous pouvez utiliser la requête de liste de contacts suivante et la propriété parentFolderId pour contourner le problème et obtenir l’ID du dossier des contacts par défaut :

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

Dans cette demande :

  1. /me/contacts?$top=1 obtient les propriétés d’un contact dans le dossier de contacts par défaut.
  2. L’ajout de &$select=parentFolderId renvoie uniquement la propriété parentFolderId du contact, qui est l’ID du dossier de contacts par défaut.

L’accès aux contacts via un dossier de contacts ne fonctionne pas dans la version bêta

Dans la version/beta, il existe actuellement un problème qui empêche d’accéder à un contact en spécifiant son dossier parent dans l’URL de requête REST, comme indiqué dans les deux scénarios ci-dessous.

Accès à un contact de l’élément contactFolderde niveau supérieur d’un utilisateur :

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

Accès à un contact contenu dans un dossier enfant d’un élément contactFolder :

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

L’exemple précédent montre un seul niveau d’imbrication, mais un contact peut se trouver dans un enfant d’un enfant, et ainsi de suite.

Vous pouvez aussi obtenirle contact en spécifiant son ID comme indiqué ci-dessous, car GET /contacts dans la version/beta s’applique à tous les contacts de la boîte aux lettres de l’utilisateur :

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

Requête delta

Le contexte OData est retourné de manière incorrecte

Le contexte OData est parfois renvoyé incorrectement lors du suivi des modifications apportées aux relations.

Les extensions de schéma ne sont pas retournées avec select

Les extensions de schéma (héritées) ne sont pas renvoyées avec $selectinstruction mais sans $select.

Les clients ne peuvent pas suivre les modifications apportées aux extensions ouvertes

Les clients ne peuvent pas suivre les modifications apportées aux extensions d’ouverture ou aux extensions de schéma enregistrées.

Appareils et applications | Mises à jour d’appareil (mises à jour Windows)

L’accès et la mise à jour des audiences de déploiement ne sont pas pris en charge

L’accès et la mise à jour des audiences de déploiement sur déploiement ressources créées via Intune n’est pas pris en charge actuellement.

Extensions

Le suivi des modifications n’est pas pris en charge

Le suivi des modifications (requête delta) n’est pas pris en charge pour les propriétés des extensions de schéma ou d’ouverture.

Impossible de créer une ressource et d’ouvrir l’extension en même temps

Vous ne pouvez pas spécifier une extension d’ouverture quand vous créez une instance de ressource administrativeUnit, device, group, organization ou user. Vous devez d’abord créer l’instance, puis spécifier les données de l’extension d’ouverture dans une demande POST ultérieure sur cette instance.

Impossible de créer une instance de ressource et d’ajouter des données d’extension de schéma en même temps

Vous ne pouvez pas spécifier d’extension de schéma dans la même opération que la création d’une instance de contact, event, message ou post. Vous devez d’abord créer l’instance de ressource, puis effectuez une opération PATCH sur cette instance pour ajouter une extension de schéma et des données personnalisées.

Limite de 100 valeurs de propriété d’extension de schéma autorisées par instance de ressource

Les ressources du répertoire, telles que device, groupe, et user, limitent actuellement le nombre total de propriétés d’extension de schéma pouvant être définies sur une instance de ressource à 100.

Le propriétaire doit être spécifié lors de la mise à jour d’une définition schemaExtension à l’aide de Microsoft Graph Explorer

Lorsque vous utilisez PATCH pour mettre à jour un schemaExtension à l’aide de l’afficheur Graph, vous devez spécifier la propriété propriétaire et la définir sur sa valeur appId actuelle (il doit s’agir d’une appId d’une application dont vous êtes propriétaire). C’est également le cas pour toute applicationncliente dont appIdn’est pas le même que le propriétaire.

Le filtrage sur les propriétés d’extension.de schéma n’est pas pris en charge sur tous les types d’entité

Le filtrage sur les propriétés d’extension de schéma (à l’aide de l’expression $filter) n’est pas pris en charge pour les types d’entité Outlook : contact, événement, message ou publication.

Fichiers (OneDrive)

L’accès au lecteur d’un utilisateur avant qu’il n’y accède génère une erreur

L'accès initial au lecteur personnel d’un utilisateur via Microsoft Graph, avant que l’utilisateur accède à son site personnel par l'intermédiaire d'un navigateur, entraîne une 401 réponse.

Groupes

Microsoft Graph expose deux permissions (Group.Read.All et Group.ReadWrite.All) pour l'accès aux API pour les groupes et Microsoft Teams. Ces autorisations doivent être accordées par un administrateur. À l'avenir, nous prévoyons d'ajouter de nouvelles autorisations pour les groupes et les équipes auxquelles les utilisateurs pourront consentir.

Certaines API de groupe ne prennent pas en charge les autorisations déléguées ou d’application uniquement

Seule l’API pour l’administration et la gestion de groupes principaux prend en charge l’accès à l’aide des autorisations déléguées ou d’application uniquement. Toutes les autres fonctionnalités de l’API de groupe prennent uniquement en charge les autorisations déléguées.

Exemples de fonctionnalités de groupe qui prennent en charge les autorisations déléguées et d’application uniquement :

  • Création et suppression de groupes
  • Obtention et mise à jour des propriétés de groupe se rapportant à l’administration ou à la gestion de groupe
  • Paramètres d’annuaire, type et synchronisation de groupe
  • Appartenance et propriétaires de groupe
  • Récupérer des conversations et des threads de groupe

Exemples de fonctionnalités de groupe qui prennent en charge les autorisations déléguées uniquement :

  • Événements de groupe, photo
  • Expéditeurs externes, expéditeurs acceptés ou refusés, abonnement de groupe
  • Favoris de l’utilisateur et compte non consulté

Microsoft Graph contourne les stratégies de groupe configurées via Outlook sur le web

Utilisation de Microsoft Graph pour créer et nommer un groupe Microsoft 365 qui ignore les stratégies de groupe Microsoft 365 qui sont configurées via Outlook sur le web.

La propriété allowExternalSenders est uniquement accessible sur les groupes unifiés

Il existe actuellement un problème qui empêche de définir la propriété allowExternalSenders d’un groupe dans une opération POST ou PATCH, dans /v1.0 et /beta.

La propriété allowExternalSenders est uniquement accessible sur les groupes unifiés. L’accès à cette propriété sur les groupes de sécurité, y compris via les opérations GET, entraîne une erreur.

La suppression d’un propriétaire de groupe supprime également l’utilisateur en tant que membre du groupe

Lorsque DELETE /groups/{id}/owners est appelé pour un groupe associé à une équipe, l’utilisateur est également supprimé de la liste /groups/{id}/members. Pour contourner ce problème, supprimez l’utilisateur des propriétaires et des membres, puis patientez 10 secondes, puis rajoutez-le aux membres.

Identité et accès

L’API conditionalAccessPolicy nécessite actuellement l’autorisation de Policy.Read.All pour appeler les méthodes POST et PATCH. À l'avenir, l'autorisation Policy.ReadWrite.ConditionalAccess vous permettra de lire les stratégies à partir de l’annuaire.

L’API claimsMappingPolicy peut nécessiter le consentement des autorisations Policy.Read.All et Policy.ReadWrite.ConditionalAccess pour les méthodes LIST /policies/claimsMappingPolicies et GET /policies/claimsMappingPolicies/{id} comme suit :

  • Si aucun objet claimsMappingPolicy n’est disponible pour la récupération dans une opération LIST, l’une ou l’autre autorisation est suffisante pour appeler cette méthode.
  • S’il existe des objets claimsMappingPolicy à récupérer, votre application doit consentir aux deux autorisations. Si ce n’est pas le cas, une erreur403 Forbidden est retournée.

À l’avenir, ces autorisations seront suffisantes pour appeler les deux méthodes.

Traitement par lots JSON

Les lots imbriqués ne sont pas pris en charge

Les requêtes de lots JSON ne doivent pas contenir des requêtes de lots imbriquées.

Toutes les requêtes individuelles doivent être synchrones

Toutes les requêtes contenues dans une requête de lots doivent être exécutées simultanément. Si elle est présente, la préférence respond-async sera ignorée.

Le traitement transactionnel des demandes n’est pas pris en charge

Microsoft Graph ne prend pas en charge le traitement transactionnel des requêtes individuelles. La propriété atomicityGroupsur des requêtes individuelles sera ignorée.

Les URI doivent être relatifs

Spécifiez toujours des URI relatifs dans les requêtes de lots. Microsoft Graph rend ensuite ces URL absolues à l’aide du point de terminaison de version inclus dans l’URL par lots.

La taille du lot est limitée

Les requêtes de lots JSON sont actuellement limitées à 20 requêtes individuelles.

  • Selon la partie API de la demande de lot, les services sous-jacents imposent leurs propres limites de limitation qui affectent les applications qui utilisent Microsoft Graph pour y accéder.
  • Les demandes d’un lot sont évaluées individuellement par rapport aux limites de limitation et, si une demande dépasse les limites, elle échoue avec un statut de 429.

Pour plus de détails, consultez Limitation et traitement par lot.

Les dépendances de demande sont limitées

Les requêtes individuelles peuvent dépendre d’autres requêtes individuelles. Actuellement, les requêtes peuvent dépendre uniquement d’une seule autre requête et doivent respecter l’un de ces trois modèles :

  • Parallel : aucune demande individuelle n’indique une dépendance dans la propriété dependsOn .
  • Série - toutes les requêtes individuelles dépendent de la requête individuelle précédente.
  • Identique : toutes les demandes individuelles qui indiquent une dépendance dans la propriété dependsOn, indiquent la même dépendance. Remarque: les demandes effectuées à l’aide de ce modèle s’exécutent séquentiellement.

À mesure que le traitement par lots JSON évolue, ces limitations seront supprimées.

Courrier (Outlook)

L’attachement de fichiers volumineux à des messages avec des autorisations déléguées peut échouer

Une application dotée d’autorisations déléguées renvoie HTTP 403 Forbidden lorsque vous essayez de joindre des fichiers volumineux à un message Outlook ou un évènement figurant dans une boîte aux lettres partagée ou déléguée. Avec les autorisations déléguées, createUploadSession réussit uniquement si le message ou l'évènement se trouve dans la boîte aux lettres de l’utilisateur connecté.

Le paramètre de commentaire pour la création d’un brouillon ne fait pas partie du corps du message

Le paramètre comment pour la création d’un brouillon de réponse ou de transfert (createReply, createReplyAll, createForward) ne fait pas partie du corps du brouillon du message résultant.

Les messages GET renvoient des conversations dans Microsoft Teams

Dans les points de terminaison v1.0 et bêta, la réponse à GET /users/id/messagesinclut les conversations Microsoft Teams de l’utilisateur qui se sont produites en dehors de l’étendue d’une équipe ou d’un canal. Ces messages de conversation ont « IM » en tant qu’objet.

Rapports

Erreurs de vérification de licence pour les rapports d’activité Azure AD

Lorsque vous avez une licence Azure AD Premium valide et appelez les API de rapports d’activité Azure AD directoryAudit, signInou approvisionnement, vous pouvez encore rencontrer un message d’erreur semblable au suivant :

{
    "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"
        }
    }
}

Cette erreur peut également se produire lors de la récupération de la propriété signInActivity de la ressource utilisateur ; par exemple, https://graph.microsoft.com/beta/users?$select=signInActivity .

Cette erreur est due à des échecs intermittents de vérification de licence que nous nous efforçons de corriger. Comme solution de contournement temporaire, ajoutez l’autorisation Directory.Read.All. Cette solution de contournement temporaire n’est pas nécessaire lorsque le problème est résolu.

Travail d’équipe (Microsoft Teams)

Désolé... Nous n’avons pas pu filtrer les membres de l’équipe par rôles

Les filtres de requête de rôle et d’autres filtres GET /teams/team-id/members?$filter=roles/any(r:r eq 'owner') and displayName eq 'dummy' peuvent ne pas fonctionner. Le serveur peut répondre par BAD REQUEST.

Les demandes de filtrage des membres d’équipe par rôle nécessitent un paramètre

Toutes les demandes de filtrage par rôle des membres d’équipe attendent un paramètre skipToken ou un paramètre Top dans la demande, mais pas les deux. Si les deux paramètres sont passés dans la demande, le paramètre Top est ignoré.

Certaines propriétés des membres de la conversation peuvent être manquantes dans la réponse à une demande GET

Dans certains cas, il est possible que la propriété tenantId / email / displayName pour les membres individuels d’une conversation ne soit pas remplie sur une demande GET /chats/chat-id/members ou GET /chats/chat-id/members/membership-id .

Les propriétés sont manquantes dans la liste des équipes qu’un utilisateur a rejointes

L’appel d’API pour me/joinedTeams renvoie uniquement les propriétés ID, le displayName et description d’une équipe. Pour obtenir toutes les propriétés, utilisez l’opération Obtenir l’équipe.

Les appels d’API suivants ne permettent pas d’installer des applications qui nécessitent des autorisations de consentement spécifiques à la ressource.

Impossible d’accéder à un canal partagé inter-locataire lorsque l’URL de la demande contient des locataires/{cross-tenant-id}

L’API appelle teams/{team-id}/incomingChannels et teams/{team-id}/allChannels renvoie la propriété @odata.id que vous pouvez utiliser pour accéder au canal et exécuter d’autres opérations sur l’objet de canal . Si vous appelez l’URL retournée par la propriété @odata.id, la demande échoue avec l’erreur suivante lorsqu’elle tente d’accéder au canal partagé interlocataire :

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"
        }
    }
}

Pour résoudre ce problème, supprimez la partie /tenants/{tenant-id} de l’URL avant d’appeler l’API pour accéder au canal partagé inter-locataire.

Utilisateurs

Encoder les symboles numériques (#) dans userPrincipalName

L’userPrincipalName des utilisateurs invités ajouté par Azure AD B2B contient souvent le caractère numéro (#). $filterL’utilisation sur un userPrincipalName qui contient le symbole #, par exemple, renvoie une réponse d’erreur GET /users?$filter=userPrincipalName eq 'AdeleV_contoso.com#EXT#@fabrikam.com' 400 Bad request HTTP. Pour filtrer par userPrincipalName, encodez le caractère # à l’aide de son équivalent UTF-8 ( %23 ), par exemple, GET /users?$filter=userPrincipalName eq 'AdeleV_contoso.com%23EXT%23@fabrikam.com' .

L’accès aux ressources utilisateur est différé après la création

Les utilisateurs peuvent être créés immédiatement via un POST sur l’entité de l’utilisateur. Une licence Microsoft 365 doit d’abord être affectée à un utilisateur, afin d’obtenir un accès aux services Microsoft 365. Même ensuite, en raison de la nature distribuée du service, un délai de 15 minutes peut s’écouler avant que les entités de fichiers, messages et événements puissent être utilisées pour cet utilisateur, via l’API Microsoft Graph. Pendant ce temps, les applications reçoivent une réponse d’erreur HTTP404 Not Found.

L’accès à la photo de profil d’un utilisateur est limité

  1. La lecture et la mise à jour de la photo du profil d’un utilisateur ne sont possibles que si l’utilisateur dispose d’une boîte aux lettres. L’échec de lecture ou de mise à jour d’une photo, dans ce cas, entraîne l’erreur suivante :

    {
      "error": {
        "code": "ErrorNonExistentMailbox",
        "message": "The SMTP address has no mailbox associated with it."
      }
    }
    
  2. Toutes les photos qui ont été précédemment stockées à l’aide de la propriété thumbnailPhoto (à l’aide de l’API Azure AD Graph (supprimé) ou via la synchronisation AD Connecter) ne sont plus accessibles via la propriété de photo Microsoft Graph de la ressource utilisateur.

  3. La gestion des photos des utilisateurs via la ressource profilePhoto de l’API Microsoft Graph n’est actuellement pas prise en charge Azure AD clients B2C.

La révocation de sessions de connexion renvoie un code HTTP incorrect

L' API user: revokeSignInSessions doit renvoyer une 204 No content réponse en si les révocations sont réussies et un code d’erreur HTTP (4xx ou 5xx) en cas de problème avec la demande. Toutefois, en raison d’un problème de service, cette API renvoie un 200 OK et un paramètre booléen qui est toujours true. Tant que ce problème n’est pas résolu, vous pouvez traiter n’importe quel code de retour 2xx comme une réussite pour cette API.

Les objets incomplets sont retournés lors de l’utilisation de la demande getByIds

La demande d'objets via Obtenir des objets d’annuaire à partir d’une liste d’ID doit renvoyer des objets complets. Cependant, les objets utilisateur actuellement présents sur le point de terminaison v 1.0 sont renvoyés avec un groupe limité de propriétés. Dans le cadre d’une solution de contournement temporaire, lorsque vous utilisez l'opération conjointement avec l’option de requête$select, des objets utilisateur plus complets sont renvoyés. Ce comportement n’est pas conforme aux spécifications OData. Ce comportement pouvant être mis à jour ultérieurement, utilisez cette solution de contournement uniquement lorsque vous fournissez $select= toutes les propriétés qui vous intéressent, et uniquement si les prochaines modifications apportées à cette solution de contournement sont acceptables.

la propriété showInAddressList n’est pas synchronisée avec Microsoft Exchange

Lors de l’interrogation des utilisateurs via Microsoft Graph, la propriété showInAddressList peut ne pas indiquer le même état que celui indiqué dans Microsoft Exchange. Nous vous recommandons de gérer cette fonctionnalité directement avec Microsoft Exchange via le Centre d’administration Microsoft 365 et de ne pas utiliser cette propriété dans Microsoft Graph.

Paramètres de requête

Certaines limitations s’appliquent aux paramètres de requête

Les limitations suivantes s’appliquent aux paramètres de requête :

  • Les espaces de noms multiples ne sont pas pris en charge.
  • Les demandes GET sur $ref et la projection ne sont pas pris en charge sur les utilisateurs, groupes, appareils, principaux de service et applications.
  • @odata.bind n’est pas pris en charge. Cela signifie que vous ne pouvez pas définir correctement définir correctement la propriété de navigation acceptedSenders ou rejectedSenders sur un groupe.
  • @odata.id n’est pas présent sur les navigations autres que les navigations d’imbrication (comme les messages) lors de l’utilisation de métadonnées minimales.
  • $expand:
    • Renvoie un nombre maximal de 20 objets.
    • Aucune prise en charge pour @odata.nextLink.
    • Aucune prise en charge pour plus d’un niveau de développement.
    • Pas de prise en charge avec des paramètres supplémentaires ($filter, $select).
  • $filter:
    • Le point de terminaison /attachments ne prend pas en charge les filtres. Le cas échéant, le paramètre $filter est ignoré.
    • Le filtrage entre charges de travail n’est pas pris en charge.
  • $search:
    • La recherche de texte intégral est disponible uniquement pour un sous-ensemble d’entités, tout comme les messages.
    • La recherche entre charges de travail n’est pas prise en charge.
    • La recherche n’est pas prise Azure AD les locataires B2C.
  • $count:
    • Non pris en charge Azure AD client B2C
    • Lors de l’utilisation de la chaîne de requête $count=true pendant l’exécution d’une requête sur les ressources du répertoire, la propriété @odata.count est uniquement présente sur la première page des données paginées.
  • Les paramètres de requête spécifiés dans une requête peuvent échouer silencieusement. Ce peut être le cas de paramètres de requête non pris en charge, ainsi que d’associations de paramètres de requête non prises en charge.

Fonctionnalités disponibles uniquement dans Office 365 REST ou les API Azure AD Graph (déconseillé)

Certaines fonctionnalités ne sont pas encore disponibles dans Microsoft Graph. Si vous ne voyez pas la fonctionnalité que vous recherchez, vous pouvez utiliser les API REST d'Office 365 spécifiques au point de terminaison. Pour Azure AD Graph, voir Migrer les applications Azure Active Directory (Azure AD) Graph vers Microsoft Graph.