Microsoft Graph 已知问题

本文介绍了 Microsoft Graph 已知问题。

若要报告已知问题,请参阅 Microsoft Graph 支持 页面。

若要了解 Microsoft Graph API 的最新更新,请参阅 Microsoft Graph 更改日志

应用程序

应用程序和 servicePrincipal 资源存在一些限制

应用程序servicePrincipal 资源的更改当前处于开发阶段。下面总结了当前的限制和处于开发阶段的 API 功能。

当前限制:

  • 只有在所有更改完成后,一些应用属性(如 appRoles 和 addIns)才可用。
  • 只能注册多租户应用。
  • 更新应用仅限于在首次 beta更新后注册的应用。
  • Azure Active Directory 用户可以注册应用并添加其他所有者。
  • 支持 OpenID Connect 和 OAuth 协议。
  • 无法向应用分配策略。
  • 无法对需要 appId 的 ownedObjects 执行操作(例如,users/{id|userPrincipalName}/ownedObjects/{id}/...)

处于开发阶段的功能:

  • 可以注册单租户应用。
  • 更新 servicePrincipal。
  • 将现有 Azure AD 应用迁移到更新后的模型中。
  • 支持 appRoles、预授权客户端、可选声明、组成员身份声明和品牌塑造
  • Microsoft 帐户 (MSA) 用户可以注册应用。

CSP 应用不支持使用 Azure AD v2.0 终结点

云解决方案提供商 (CSP) 应用必须从 Azure AD (v1) 终结点中获取令牌,才能在其合作伙伴托管的客户中成功调用 Microsoft Graph。目前,不支持通过较新的 Azure AD v2.0 终结点获取令牌。

在某些情况下,对云解决方案提供商 (CSP) 应用的预授权可能不适用于一些客户租户。

  • 对于使用委派权限的应用,首次将此应用用于新客户租户时,登录后可能会看到以下错误:AADSTS50000: There was an error issuing a token
  • 对于使用应用权限的应用,应用可以获取令牌,但在调用 Microsoft Graph 时会意外看到“拒绝访问”消息。

我们正在努力工作,以尽快解决此问题,让预授权适用于所有客户租户。

同时,若要取消阻止开发和测试,可使用以下解决方法。

备注

这不是永久性解决方案,且仅用于取消阻止开发。 解决问题后,将不需要使用此解决方法。 在问题得到解决后,无需撤消此解决方法。

  1. 打开 Azure AD v2 PowerShell 会话,然后在登录窗口中输入管理员凭据,以连接 customer 租户。可以单击此处,下载并安装 Azure AD PowerShell V2。

    Connect-AzureAd -TenantId {customerTenantIdOrDomainName}
    
  2. 创建 Microsoft Graph 服务主体。

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

Bookings

查询 bookingBusinesses 时出错

当组织拥有多个预订业务且提出请求的帐户不是管理员时,获取 bookingBusinesses 列表会失败,并显示以下错误代码:

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

解决方法是,可以通过加入 query 参数来限制请求返回的业务集,例如:

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

日历

访问共享日历时出错

使用以下操作尝试访问其他用户共享的日历中的事件时:

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

可能会看到错误代码为 ErrorInternalServerTransientError 的 HTTP 500。导致错误发生的原因是:

  • 过去,日历共享的实现方法有两种。为了加以区分,将它们称为“旧”方法和“新”方法。
  • 新方法当前可用于通过查看或编辑权限共享日历,但无法通过委派权限进行共享。
  • 只有使用 方法共享日历后,才能使用日历 REST API 查看或编辑共享日历。
  • 如果使用 方法共享日历,则无法使用日历 REST API 查看或编辑此类日历(或其事件)。

如果日历是通过查看或编辑权限共享,但使用的是旧方法,现在可以修复错误,手动将日历共享升级为使用新方法。 随着时间的推移,Outlook 将把所有共享日历(包括通过委托权限共享的日历)自动升级为使用新方法。

若要手动将共享日历升级为使用新方法,请按照以下步骤操作:

  1. 收件人删除以前与他们共享的日历。
  2. 日历所有者在 Outlook 网页版、iOS 版或 Android 版中重新共享日历。
  3. 收件人使用 Outlook 网页版重新接受共享日历。(很快就可以使用其他 Outlook 客户端了。)
  4. 收件人可以在 Outlook iOS 版或 Android 版中查看共享日历,从而验证是否已成功使用新方法重新共享日历。

使用新方法共享的日历看起来与邮箱中的其他日历一样。可以使用日历 REST API 查看或编辑共享日历中的事件,就像查看或编辑自己日历中的事件一样。示例:

GET /me/calendars/{id}/events

在用户邮箱中添加和访问基于 ICS 的日历的部分支持

目前,仅部分支持基于 Internet 日历订阅 (ICS) 的日历:

  • 你可以通过用户界面,而不是通过 Microsoft Graph API 为用户邮箱添加基于 ICS 的日历。
  • 列出用户的日历允许你获取用户默认日历组中或指定日历组中的每个 日历名称颜色id 属性,包括所有基于 ICS 的日历。你无法存储或访问日历资源中的 ICS URL。
  • 还可以列出基于 ICS 的日历事件

将大文件附加到事件时出错

尝试将大型文件附加到共享或委派的邮箱中的 Outlook 邮件或事件时,具有委派权限的应用将返回 HTTP 403 Forbidden。 使用委派权限,仅当邮件或事件在已登录用户的邮箱中时,createUploadSession 才会成功。

Microsoft Teams 不支持 onlineMeetingUrl 属性

目前,Skype 会议 事件onlineMeetingUrl 属性指明联机会议 URL。 不过,对于 Microsoft Teams 会议事件,此属性设置为 NULL。

Beta 版本提供了一种解决方法,可以使用 事件onlineMeetingProvider 属性来验证提供商是否为 Microsoft Teams。 通过 事件 的 属性,可以访问 joinUrl

更改通知

更新通知在创建和软删除用户时发生

对于“changeType”设置为“updated” 的“user”,订阅以上更改还将收到“changeType”的通知:在创建和软删除用户时 已更新

更新通知在创建和软删除组时发生

对于“changeType”设置为“updated” 的“group”,订阅以上更改还将收到“changeType”通知:在创建和软删除组时 已更新

云通信

Microsoft Teams 客户端上不提供“查看会议详细信息”菜单

对于通过云通信 API 创建的频道会议,Microsoft Teams 客户端不会显示“查看会议详细信息”菜单。

无法将演示者角色分配给非 Azure AD 参与者

当前不支持将 presentercoorganizer 角色分配给未在 Azure Active Directory 中注册的用户。 create onlineMeeting 方法将接受此类请求,但当参与者加入联机会议时,将不会应用该角色。 create onlineMeeting 方法将拒绝请求并返回 400 Bad Request 错误。

联系人

GET 操作不会返回默认联系人文件夹

/v1.0 版本中,GET /me/contactFolders 不包括用户的默认联系人文件夹。

将会提供修复程序。同时,您还可以使用以下 列出联系人查询和 parentFolderId 属性作为一种解决方法,来获取默认联系人文件夹的文件夹 ID:

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

在此请求中:

  1. /me/contacts?$top=1 获取默认联系人文件夹中 联系人 的属性。
  2. 附加 &$select=parentFolderId 仅返回联系人的 parentFolderId 属性,即默认联系人文件夹的 ID。

通过联系人文件夹访问联系人在 beta 版中不起作用

目前,/beta 版中存在一个问题,即会在 REST 请求 URL 中指定父文件夹,从而阻止访问联系人,如以下两种情况所示。

访问用户的顶级 contactFolder 中的联系人:

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

访问 contactFolder 的子文件夹中的联系人:

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

上面的示例展示了一级嵌套,但也可以访问子文件夹的子文件夹中的联系人,并以此类推。

或者也可以按照示例仅通过指定联系人 ID 来获取此联系人,因为 /beta 版本中的 GET /contacts 适用于用户邮箱中的所有联系人:

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

Delta 查询

OData 上下文返回不正确

跟踪关系更改时,OData 上下文有时无法正确返回。

架构扩展未使用 select 返回

架构扩展(旧版)未使用 $select 语句返回,而是在不带有 $select 的情况下返回。

客户端无法跟踪开放扩展的更改。

客户端无法跟踪开放扩展或已注册的架构扩展的更改。

设备和应用|设备更新(Windows 更新)

不支持访问和更新部署访问群体。

当前不支持访问和更新通过 Intune 创建的 部署 资源上的部署访问群体。

扩展

不支持更改跟踪

开放扩展或架构扩展属性不支持更改跟踪(Delta 查询)。

无法同时创建资源和开放扩展

无法在创建 管理单元设备组织用户 的实例的同时指定开放扩展。必须首先创建实例,然后在该实例的后续 POST 请求中指定开放扩展数据。

无法同时创建资源实例和添加架构扩展数据

不能在创建 contacteventmessagepost 实例的同一个操作中指定架构扩展。 必须先创建资源实例,然后再对此实例执行 PATCH,从而添加架构扩展和自定义数据。

每资源实例最多可以添加 100 个架构扩展属性值

目录资源(如 设备用户)目前将可在资源实例上设置的架构扩展属性值的总数限制为 100。

使用 Microsoft Graph 浏览器更新 schemaExtension 定义时,必须指定所有者

当使用PATCH 使用 Graph 浏览器更新 schemaExtension 时,必须指定 所有者 属性并将其设置为其当前appId值(该值必须是您所拥有的应用程序的 appId)。 对于 appId所有者 不同的任何客户端应用程序,也是如此。

并非所有实体类型都支持对架构扩展属性进行筛选

Outlook 实体类型不支持对架构扩展属性进行筛选(使用 $filter 表达式)- 联系人事件消息帖子

文件 (OneDrive)

在用户访问用户驱动器之前访问它会导致错误

在通过浏览器访问个人网站之前,用户首次通过 Microsoft Graph 访问个人驱动器会生成 401 响应。

Microsoft Graph 访问组和 Microsoft Teams 的 API 公开了两个权限 (Group.Read.AllGroup.ReadWrite.All)。管理员必须同意这些权限。将来,我们计划为用户可以同意的组和 Teams 添加新权限。

某些组 API 不支持委派权限或仅应用权限

只有与核心组管理相关的 API 才支持使用委派权限或仅限应用权限进行访问。其他所有的组 API 功能仅支持委派权限。

同时支持委派权限和仅限应用权限的组功能示例:

  • 创建和删除组
  • 获取和更新与组管理或管理相关的组属性
  • 目录设置、类型和同步
  • 组所有者和成员
  • 正在获取组对话和线程

仅支持委派权限的组功能示例:

  • 将事件、照片分组
  • 外部发件人、被接受或拒绝的发件人、组订阅
  • 用户收藏夹和未看计数

Microsoft Graph 会绕过通过 Outlook 网页版配置的组策略

使用 Microsoft Graph 创建并命名 Microsoft 365 组时,会忽略通过 Outlook 网页版配置的所有 Microsoft 365 组策略。

只能在统一组上访问 allowExternalSenders 属性

目前,/v1.0/beta 中均存在一个问题,即会阻止在 POST 或 PATCH 操作中设置组的属性 allowExternalSenders

只能在统一组上访问 allowExternalSenders 属性。 访问安全组上的此属性(包括通过 GET 操作)将导致错误。

删除组所有者还将删除作为组成员的用户

在为与 团队 关联的组调用 DELETE /groups/{id}/owners 时,还会从 /groups/{id}/members 列表中删除用户。 要解决此问题,请从所有者和成员中移除用户,然后等待 10 秒,再将其添加回成员。

身份和访问

conditionalAccessPolicy API 当前需要同意 Policy.Read.All 权限才能调用 POST 和 PATCH 方法。 将来可以通过 Policy.ReadWrite.ConditionalAccess 权限读取目录中的策略。

claimsMappingPolicy API 可能需要得到 LIST /policies/claimsMappingPoliciesGET /policies/claimsMappingPolicies/{id} 方法的 Policy.Read.AllPolicy.ReadWrite.ConditionalAccess 授权,如下所示:

  • 如果没有 claimsMappingPolicy 对象可用于在 LIST 操作中检索,则任一权限都足以调用此方法。
  • 如果存在要检索的 claimsMappingPolicy 对象,则应用必须同意这两项授权。否则,将返回错误 403 Forbidden

将来,任一权限都足以调用这两种方法。

具有应用程序权限的应用无法更新基于 Linux 的设备

当具有应用程序权限的应用程序尝试更新 operationSystem 属性为 linux 的设备对象的任何属性时,除了 extensionAttributes 属性外,“更新设备”API 将返回 400 Bad request 错误代码和错误消息“ExtendedAttribute1..15 以外的属性只能在 Windows 设备上修改”。 使用委派权限更新基于 Linux 的设备的属性。

JSON 批处理

不支持嵌套批处理

JSON 批处理请求中不得包含任何嵌套批处理请求。

所有单个请求必须同步

批处理请求中包含的所有请求都必须同步执行。如果存在,将忽略 respond-async 首选项。

不支持请求的事务处理

Microsoft Graph 当前不支持单个请求的事务处理。将忽略单个请求的 atomicityGroup 属性。

URI 必须相对

始终在批处理请求中指定相对的 URI。Microsoft Graph 将使用批处理 URL 中包含的版本终结点使这些 URL 绝对。

批处理大小受限

JSON 批处理请求目前限定为 20 个单独请求。

  • 根据批处理请求的 API 部分,基础服务会施加自己的限制,从而影响使用 Microsoft Graph 访问它们的应用程序。
  • 批处理中的请求将根据限制单独进行评估,如果任何请求超过限制,则请求会失败,状态为 429。

有关更多详细信息,请访问 限制和批处理

请求依赖项受限

单独请求可以依赖其他单独请求。目前,请求只能依赖于单个其他请求,并且必须遵循下面的三种模式之一:

  • 并行 - 没有单个请求在 dependsOn 属性中声明依赖项。
  • 串行 - 所有单独请求都依赖于之前的单独请求。
  • 相同 - 在 dependsOn 属性中声明依赖项的所有单个请求都声明相同的依赖项。 Note: 使用此模式发出的请求将按顺序运行。

随着 JSON 批处理技术日臻成熟,这些限制将会被取消。

邮件 (Outlook)

将大文件附加到具有委派权限的邮件可能会失败

尝试将大型文件附加到共享或委派的邮箱中的 Outlook 邮件或事件时,具有委派权限的应用将返回 HTTP 403 Forbidden。 使用委派权限,仅当邮件或事件在已登录用户的邮箱中时,createUploadSession 才会成功。

用于创建草稿的注释参数不会成为邮件正文的一部分

用于创建答复或转发草稿的 注释 参数(createReplycreateReplyAllcreateForward)不会成为最终的邮件草稿正文的一部分。

GET 消息返回 Microsoft Teams 中的聊天

在 v1.0 和 beta 终结点中,GET /users/id/messages 的响应包含出现在团队或频道范围外的用户的 Microsoft Teams 聊天。这些聊天消息的主体为“IM”。

报告

Azure AD 活动报告的许可证检查错误

当你拥有有效的 Azure AD Premium 许可证并调用 directoryAuditsignIn预配 Azure AD 活动报告 API 时,你可能仍会遇到类似于以下内容的错误消息:

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

在检索 用户资源的 signInActivity 属性时,也可能发生此错误;例如,https://graph.microsoft.com/beta/users?$select=signInActivity

此错误是由于间歇性许可证检查失败造成的,我们正在努力解决此问题。 作为临时解决方法,请添加 Directory.Read.All 权限。 问题解决后,将不需要此临时解决方法。

团队合作 (Microsoft Teams)

无法按角色筛选团队成员

角色查询筛选器以及其他筛选器 GET /teams/team-id/members?$filter=roles/any(r:r eq 'owner') and displayName eq 'dummy' 可能不起作用。 服务可能使用 BAD REQUEST 响应。

按角色筛选团队成员的请求需要参数

所有按角色筛选团队成员的请求都要求在请求中使用 skipToken 参数或 top 参数,但不能同时使用两者。 如果两个参数都在请求中传递,则将忽略 top 参数。

GET 请求的响应中可能缺少聊天成员的某些属性

在某些情况下,聊天中tenantId / email / displayName成员的个人属性可能不会填充到请求GET /chats/chat-id/members``GET /chats/chat-id/members/membership-id中。

用户已加入的团队列表中缺少属性

目前,我/joinedTeams API 调用仅返回 团队iddisplayName说明 属性。 若要获取所有属性,请使用获取团队操作。

以下 API 调用不支持安装需要 资源特定的同意 权限的应用。

当请求 URL 包含租户/{cross-tenant-id} 时,无法访问跨租户共享通道

针对 teams/{team-id}/incomingChannelsteams/{team-id}/allChannels 的 API 调用返回 @odata.id 属性,可将此属性用于访问信道和在 信道 对象上运行其他操作。 如果调用从 @odata.id 属性返回的 URL,则请求将在尝试访问跨租户共享 信道 时失败,并出现以下错误:

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

要解决此问题,请先从 URL 中删除 /tenants/{tenant-id} 部分,然后调用 API 以访问跨租户共享 信道

TeamworkAppSettings 权限在 Azure 门户中不可见

权限 TeamworkAppSettings.Read.All 和 TeamworkAppSettings.ReadWrite.All 当前正在推出,可能尚未在 Azure 门户中显示。 若要同意这些权限,请使用授权请求,如下所示:

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

用户

对 userPrincipalName 中的数字符号 (#) 进行编码

通过 Azure AD B2B 添加的来宾用户的 userPrincipalName 通常包含数字字符 (#)。 如果对包含 # 符号的 userPrincipalName 使用 $filter,例如 GET /users?$filter=userPrincipalName eq 'AdeleV_contoso.com#EXT#@fabrikam.com',将会返回 400 Bad request HTTP 错误响应。 若要按 userPrincipalName 进行筛选,请用其 UTF-8 等效字符 (%23) 对 # 字符进行编码,例如 GET /users?$filter=userPrincipalName eq 'AdeleV_contoso.com%23EXT%23@fabrikam.com'

用户资源访问权限将在创建后延迟

可通过在用户实体上使用 POST 来即时创建用户。必须先向用户分配 Microsoft 365 许可证,然后用户才能访问 Microsoft 365 服务。尽管如此,由于服务具有分散特性,因此用户可能需要先等待 15 分钟,然后才能通过 Microsoft Graph API 使用文件、邮件和事件实体。在此期间,应用会收到一个 404 Not Found HTTP 错误响应。

对用户的个人资料照片的访问受限

  1. 只有当用户有邮箱时,才能读取和更新用户的个人资料照片。 在这种情况下,无法读取或更新照片会导致以下错误:

    {
      "error": {
        "code": "ErrorNonExistentMailbox",
        "message": "The SMTP address has no mailbox associated with it."
      }
    }
    
  2. 之前 可能 使用 thumbnailPhoto 属性(使用 Azure AD Graph API(已弃用),或通过 AD Connect 同步)存储的所有照片无法再通过 用户资源的 Microsoft Graph 照片 属性进行访问。

  3. 目前,Azure AD B2C 租户不支持通过 Microsoft Graph API 的profilePhoto 资源管理用户的照片。

调用登录会话返回了错误的 HTTP 代码

用户: revokeSignInSessions API 返回 204 No content 响应表示成功调用;如果请求出现任何错误,则返回 HTTP 错误代码(4xx 或 5xx)。 但是,由于服务问题,此 API 会返回 200 OK 和始终为 true 的布尔值参数。 在此问题得到修复之前,可以将所有 2xx 返回代码看作此 API 成功。

使用 getByIds 请求时返回不完整的对象

使用获取 ID 列表中的目录对象请求对象应返回完整对象。 但是,当前返回的 v1.0 端点上的用户对象具有一组有限的属性。 作为临时解决方法,当您将该操作与 $select 查询选项结合使用时, 将返回更完整的用户对象。 此行为不符合 OData 规范。 由于此行为可能在将来更新,因此仅在你提供 $select= 以及感兴趣的所有属性时,并且仅当此解决方法的未来重大更改可接受时,才使用此解决方法。

showInAddressList 属性与 Microsoft Exchange 不同步

通过 Microsoft Graph 查询用户时, showInAddressList 属性可能并不指示 Microsoft Exchange 中显示的相同状态。 建议通过 Microsoft 365 管理中心直接使用 Microsoft Exchange 管理此功能,而不是在 Microsoft Graph 中使用此属性。

查询参数

查询参数存在一些限制

以下限制适用于查询参数:

  • 不支持多个命名空间。
  • 在用户、组、设备、服务主体和应用程序上,不支持对 $ref 执行 GET 请求和强制转换。
  • @odata.bind 不受支持。这意味着无法在组上正确设置 acceptedSendersrejectedSenders 导航属性。
  • 使用极少的元数据时,非包容导航(如邮件)上不存在 @odata.id
  • $expand:
    • 最多返回 20 个对象。
    • 不支持 @odata.nextLink
    • 不支持一级以上的扩展。
    • 不支持其他参数($filter$select
  • $filter:
    • /attachments 终结点不支持筛选器。 如果存在,将忽略 $filter 参数。
    • 不支持跨工作负载筛选。
  • $search:
    • 全文搜索仅对实体子集(如邮件)可用。
    • 不支持跨工作负载搜索。
    • Azure AD B2C 租户不支持搜索。
  • $count:
    • Azure AD B2C 租户不支持。
    • 在针对目录资源进行查询时使用 $count=true 查询字符串时, @odata.count 属性将仅出现在分页数据的第一页中。
  • 请求中指定的查询参数可能会自行失败。 不支持的查询参数以及不支持的查询参数组合的情况就是如此。

功能仅在 Office 365 REST 或 Azure AD Graph API 中可用(已弃用)

某些功能尚未在 Microsoft Graph 中提供。如果找不到所需的功能,请使用特定于终结点的 Office 365 REST API。有关 Azure AD Graph,请参阅 将 Azure Active Directory (Azure AD) 应用迁移到 Microsoft Graph