getSchedule returns ErrorInternalServerError for specific mailbox while user exists and was previously schedulable

The behavior matches a mailbox/calendar issue for that specific user rather than a general Graph or permission problem. getSchedule depends on the target having a valid mailbox and calendar; if the mailbox is missing, corrupted, or in a transient state, calls like GET /users/{id}/calendar returning 404 and getSchedule returning ErrorInternalServerError for that user are expected.

Key points from the APIs involved:

• getSchedule returns free/busy data for users, DLs, or resources only when their calendars are available and within service limits. It returns a collection of scheduleInformation objects, one per requested schedule.
• Each scheduleInformation includes an error property of type freeBusyError that indicates problems retrieving availability for that specific schedule (for example, if the user cannot be resolved or their calendar cannot be accessed).
• There are limits and error conditions for getSchedule (max 20 entities per call, max 62-day window, and a 1000-entry limit per time slot), but these would affect all users in the call, not just a single mailbox, and typically return a specific error code like 5006 when the result set is too large.

Given the observations:

• GET /users/{id} succeeds → the directory object exists in Microsoft Entra ID.
• GET /users/{id}/calendar returns 404 → the mailbox or default calendar is not accessible or not provisioned correctly for that user.
• getSchedule works for other users → tenant-wide configuration, permissions, and Graph endpoint are generally correct.
• The user was previously schedulable → suggests a change in mailbox state (deletion/recreation, move, or corruption) rather than a coding or permission regression.

Recommended checks and actions:

1. Inspect the scheduleInformation.error for that user
   • In the getSchedule response, locate the scheduleInformation object whose scheduleId is that user’s SMTP address.
   • Check the error property (type freeBusyError) for a more specific error code/message about why availability cannot be retrieved.
2. Verify mailbox existence and health in Exchange Online (GCC High)
   • Confirm that the user has an active mailbox and that it is not soft-deleted, recently restored, or in a migration/hold state.
   • If the user or mailbox was deleted and re-created with the same SMTP address, ensure the old object is permanently deleted and any caching has cleared before re-testing, as stale references can cause mailbox-related errors.
3. Confirm calendar availability limits are not being hit for that user
   • If the user has extremely dense calendar data, getSchedule can fail with a 5006 error when a time slot contains more than 1000 entries.
   • Narrow the requested time window and/or reduce availabilityViewInterval to see if the error changes or the call succeeds.
4. Re-test with a direct /users/{id}/calendar and getSchedule after mailbox remediation
   • Once Exchange confirms the mailbox is present and healthy, GET /users/{id}/calendar should return the default calendar instead of 404.
   • At that point, getSchedule should start returning valid scheduleInformation for that user again.

If the mailbox is confirmed healthy and the error persists only for this user, the next step is to open a support case for the GCC High tenant so Microsoft can inspect backend mailbox and free/busy configuration for that specific object.

References:

• calendar: getSchedule
• Get free/busy schedule of Outlook calendar users and resources
• scheduleInformation resource type