Extended properties not persisted on calendar events via Graph API (SDK and raw HTTP)

We are migrating from EWS to Microsoft Graph API due to the upcoming deprecation of EWS. Our legacy system relies on storing a custom identifier (VisitID) in calendar events using extended properties. In EWS, this was reliable and allowed us to track and manage appointments across consultants.

In Microsoft Graph (SDK v5 and raw HTTP), attempts to persist SingleValueLegacyExtendedProperty on Event resources consistently fail. We've tested:

• SDK-based PostAsync and PatchAsync calls
• Raw HTTP POST and PATCH requests with correctly formatted property IDs
• Verified access tokens, permissions, and payload structure

Despite this, the extended property is not saved or returned in subsequent queries, even when $expand=singleValueExtendedProperties and $select=singleValueExtendedProperties are used.

Expected Behavior: Extended properties should be persisted and retrievable on calendar events when correctly formatted and submitted via SDK or raw Graph API.

Actual Behavior: Extended properties are silently ignored or dropped. Even when the request succeeds and other fields (e.g., subject) are updated, the extended property is not present in the response or retrievable via Graph.

Impact: This limitation breaks a core part of our calendar sync logic. Without reliable extended property support, we are forced to fall back to encoding metadata in the subject line, which is error-prone and fragile.

Environment:

• Microsoft Graph SDK v5
• .NET Framework 4.8
• Application permissions via ClientSecretCredential
• Property ID used: "String {00020329-0000-0000-C000-000000000046} Name VisitID"

Request: Please clarify the current support status for extended properties on Event resources and provide guidance or fixes for reliably persisting and retrieving them. If this feature is deprecated or unsupported, we need clear alternatives for storing structured metadata on calendar events.We are migrating from EWS to Microsoft Graph API due to the upcoming deprecation of EWS. Our legacy system relies on storing a custom identifier (VisitID) in calendar events using extended properties. In EWS, this was reliable and allowed us to track and manage appointments across consultants.

In Microsoft Graph (SDK v5 and raw HTTP), attempts to persist SingleValueLegacyExtendedProperty on Event resources consistently fail. We've tested:

• SDK-based PostAsync and PatchAsync calls
• Raw HTTP POST and PATCH requests with correctly formatted property IDs
• Verified access tokens, permissions, and payload structure

Despite this, the extended property is not saved or returned in subsequent queries, even when $expand=singleValueExtendedProperties and $select=singleValueExtendedProperties are used.

Expected Behavior:
Extended properties should be persisted and retrievable on calendar events when correctly formatted and submitted via SDK or raw Graph API.

Actual Behavior:
Extended properties are silently ignored or dropped. Even when the request succeeds and other fields (e.g., subject) are updated, the extended property is not present in the response or retrievable via Graph.

Impact:
This limitation breaks a core part of our calendar sync logic. Without reliable extended property support, we are forced to fall back to encoding metadata in the subject line, which is error-prone and fragile.

Environment:

• Microsoft Graph SDK v5
• .NET Framework 4.8
• Application permissions via ClientSecretCredential
• Property ID used: "String {00020329-0000-0000-C000-000000000046} Name VisitID"

Request:
Please clarify the current support status for extended properties on Event resources and provide guidance or fixes for reliably persisting and retrieving them. If this feature is deprecated or unsupported, we need clear alternatives for storing structured metadata on calendar events.