PATCH /beta/admin/appsAndServices returns 204 No Content but never applies the settings

PATCH https://graph.microsoft.com/beta/admin/appsAndServices returns 204 No Content and the settings are never applied. A subsequent GET returns the old values indefinitely. The same two settings can be changed successfully by hand in the Microsoft 365 admin center on the same tenant, and that manual change is immediately visible through the Graph GET ; so the read path works and only the write is inert.

Request (copied verbatim from the Update adminAppsAndServices example)

PATCH https://graph.microsoft.com/beta/admin/appsAndServices
Content-Type: application/json
{
  "@odata.type": "#microsoft.graph.adminAppsAndServices",
  "settings": {
    "@odata.type": "microsoft.graph.appsAndServicesSettings",
    "isOfficeStoreEnabled": false,
    "isAppAndServicesTrialEnabled": false
  }
}

Response

HTTP/1.1 204 No Content
(empty body)

Verification issued 3s later, and again minutes later:

GET https://graph.microsoft.com/beta/admin/appsAndServices/settings
{
  "isOfficeStoreEnabled": true,
  "isAppAndServicesTrialEnabled": true
}

`The values never change. No error is returned at any point.

Token: delegated (scp contains OrgSettings-AppsAndServices.ReadWrite.All, the least-privileged permission the docs list for this operation). The signed-in user is a Global Administrator in the target tenant.

What we ruled out

Working control case

PATCH https://graph.microsoft.com/beta/admin/forms — same /admin/* beta org-settings family, same nested settings + @odata.type body shape, same delegated token, same HTTP client, same tenant, same app registration — applies correctly (confirmed in the M365 admin center). Only the resource path differs. This is why we believe the problem is specific to adminAppsAndServices rather than to our auth or request construction.

Not yet tested: application (app-only) permissions, because OrgSettings-AppsAndServices.ReadWrite.All is not currently consented as an application permission on our registration. If app-only is known to behave differently here, that would be useful to know.

Docs issue observed alongside this

The Response section states the operation "returns a 200 OK response code and an updated adminAppsAndServices object in the response body", while the example on the same page shows 204 No Content. We only ever observe 204 with an empty body, so the API never echoes back what it claims to have stored.

Questions

1. Is this a known defect in PATCH /beta/admin/appsAndServices?
2. Is there a supported programmatic alternative for these two settings? We found no PowerShell equivalent — Set-OrganizationConfig -AppsForOfficeEnabled governs Outlook add-in activation, which is a different setting.
3. Is adminAppsAndServices planned for v1.0? It is currently beta-only and is not listed under the v1.0 admin resource, so there is no GA endpoint to migrate to.