使用Microsoft Graph findMeetingTimes接口查询会议室可用时段异常问题

一、问题原因分析 #

1. locationConstraint参数的局限性
   locationConstraint的核心作用是筛选满足属性条件的会议室（比如指定会议室邮箱、场地类型等），但它不会校验该会议室的日程可用性。也就是说，只要你指定的会议室存在且符合属性要求，接口就会将其纳入时段建议，哪怕该时段会议室已经被预订。

2. 会议室加入attendees后显示始终忙碌的原因
   直接将会议室邮箱加入普通参会者列表时，会触发以下问题：

   • 会议室邮箱的默认忙闲设置为“始终显示忙碌”，导致接口无法获取实际日程状态；
   • 应用权限不足，无法读取会议室邮箱的详细日程数据；
   • 接口对资源邮箱（如会议室）的处理逻辑与普通用户不同，未明确标记其类型为Resource时，无法正确解析其日程。

二、正确的查询方法 #

要同时校验组织者、与会者和会议室的可用性，需将会议室作为资源类型的参与者加入attendees列表，具体请求参数示例如下：

{
  "attendees": [
    {
      "emailAddress": {
        "address": "madreww@mycompany.com"
      },
      "type": "Required"
    },
    {
      "emailAddress": {
        "address": "room-accueil@mycompany.com"
      },
      "type": "Resource"
    }
  ],
  "timeConstraint": {
    "timeslots": [
      {
        "start": {
          "dateTime": "2023-01-11T12:00:00.000Z",
          "timeZone": "Pacific Standard Time"
        },
        "end": {
          "dateTime": "2023-01-11T15:00:00.000Z",
          "timeZone": "Pacific Standard Time"
        }
      }
    ]
  },
  "meetingDuration": "PT1H"
}

关键说明： #

• 将会议室的type设置为Resource，明确告知Graph接口需要校验该资源邮箱的实际日程可用性；
• 移除locationConstraint参数，因为已通过attendees指定了需要校验的会议室；
• 确保应用拥有Calendars.Read权限（应用权限或委托权限），以读取组织者、与会者及会议室的日程数据；
• 检查会议室邮箱的忙闲设置，确保其允许外部应用读取实际日程状态（可通过Exchange管理中心调整）。

额外验证步骤 #

如果问题仍存在，可先调用GET /users/room-accueil@mycompany.com/calendarview接口并指定时间范围，手动确认该会议室在目标时段的实际日程，排查是否是日程数据本身的问题。

内容的提问来源于stack exchange，提问作者Adrien Ruffie