Hide attendee names / anonymizeIdentityForRoles is silently failing to apply

Question

Hide attendee names / anonymizeIdentityForRoles is silently failing to apply

Conrad Fleming 20

anonymizeIdentityForRoles cannot be written through Microsoft Graph in this tenant. Graph accepts the request, returns success, and silently discards the property — on both POST and PATCH, for both a Teams Premium licensed organizer and an unlicensed one.

Every client-side explanation was tested and eliminated. The request is schema-valid, correctly typed, correctly serialised, correctly headered, and made with sufficient permissions by an organizer whose entitlement is proven working on other premium-gated properties in the same request path.

Meetings created by the script did not hide attendee names, despite anonymizeIdentityForRoles = @("attendee") being present in the creation payload. The script reported success, because its only verification read the property back off the create response - which is also empty - so the failure passed silently.

Environment / Test Notes

Item	Value
Endpoint	`https://graph.microsoft.com/beta/users/{id}/onlineMeetings`

Endpoint	`https://graph.microsoft.com/beta/users/{id}/onlineMeetings`
Auth	Client credentials (app-only), no user context
Token roles	`OnlineMeetings.ReadWrite.All`, `User.Read.All`, `Calendars.ReadWrite`
Organizer A	Teams Premium — SKUs include `Teams_Premium_for_Faculty`, `M365EDU_A5_FACULTY`
Organizer B	No Premium — SKUs `FLOW_FREE`, `M365EDU_A5_FACULTY`
PowerShell	Tested on 5.1 and 7

Both organizers show the "Hide attendee names" toggle in the Teams client, confirming the feature is surfaced to them in the UI regardless of Premium licensing.

Final Comparison:

Graph refuses loudly when it means to refuse. Organizer B's watermark attempt returned an explicit 403 with a specific error code and a human-readable message. The service does not silently drop features it is denying. It has never once returned an error for anonymizeIdentityForRoles — not on either account, not on either verb.

A fully entitled organizer fails identically. Organizer A holds Teams_Premium_for_Faculty. In the same PATCH sequence, against the same meeting, on the same endpoint, watermarkProtection and recordAutomatically both applied successfully. anonymizeIdentityForRoles still vanished.

A property that is schema-valid, correctly typed, licence-satisfied, permission-satisfied, and discarded without an error is being accepted by request validation and dropped by the service implementation.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Dear @Conrad Fleming,

I hope you’re having a good day.

Thank you for the detailed analysis and for documenting the testing so thoroughly.

Based on what you've described, you've already ruled out many of the common explanations, including payload structure, permissions, licensing, serialization issues, and organizer entitlement. The comparison with watermarkProtection and recordAutomatically is particularly helpful, as it demonstrates that other meeting properties are being applied successfully through the same workflow.

One remaining detail that stands out is that all of the tests appear to have been performed using client credentials (app-only) authentication. Have you had an opportunity to reproduce the same behavior using a delegated organizer context (for example, signing in as Organizer A and issuing the request with delegated permissions rather than app-only permissions)?

If anonymizeIdentityForRoles is also silently discarded when using a delegated organizer context, then based on the evidence you've provided, this starts to look less like a permissions, licensing, or payload issue and more like a potential service-side implementation issue or a limitation/inconsistency in the current Graph beta implementation.

In that scenario, I would recommend opening a Microsoft support case. The value of a support case at that point would not be additional client-side troubleshooting, but rather enabling Microsoft to:

Review backend behavior for the specific Graph requests.
Verify whether anonymizeIdentityForRoles is currently expected to be supported in the exact authentication and meeting-creation scenario being used.
Check for any known issues, feature flags, service-side restrictions, or documentation gaps related to the property.
Correlate the requests with internal service logs using request IDs and timestamps.
Engage the Microsoft Graph and/or Teams engineering teams if the behavior is determined to be a product issue.

If you decide to open a case, I would suggest including:

Request IDs
Correlation IDs
UTC timestamps
Sample request and response payloads
Organizer licensing details
Confirmation of whether delegated authentication produces the same result

You can raise support ticket from Microsoft 365 Admin Center>Support>Help & Support.

For reference:  Get support | Microsoft Docs  

User's image

That information should give Support the best chance of reproducing the behavior and determining whether this is an implementation issue rather than an entitlement or configuration problem.

I hope this information helps point you in the right direction.

Warm regards,

If the answer is helpful, please select "Yes, accept answer". If you have any questions or new updates, please feel free to comment below.

Note: Please follow the steps in the forum documentation to enable email notifications if you want to receive the related email notification for this thread.