Only Powerpoint templates in Create in Office.com

I was clearly on the wrong track; what I described earlier isn't entirely accurate, and I apologize. My previous explanation of the "overwriting" behavior was flawed (I'm a bit older than I'd like to admit).

If you are seeing Organization Templates + The Default Microsoft Gallery in the web app, but the Default Gallery is missing specific apps (Word/Excel) while PowerPoint works, we need to look at a very specific technical nuance: The "App-First" vs. "Library-First" rendering logic.

Here is my revised answer to the question of why PowerPoint works in your create.office.com scenario, but Word/Excel doesn't, even though the settings are correct.

The Core Issue: The "CDN Fallback" Failure

When you set OrganizationAssetsLibraryType OfficeTemplateLibrary, the web client (WOPI) performs a handshake:

1. It checks the SharePoint library for your templates.
2. It attempts to fetch the Microsoft commercial templates from the public CDN.
3. It merges them.

The Bug/Behavior: If the WOPI client detects a "configuration anomaly" in your SharePoint library (even if permissions are 99% correct), it triggers a fail-safe mode.

• PowerPoint is often resilient enough to ignore the anomaly and show something (your custom PPTs).
• Word and Excel are stricter. If they detect the anomaly, they suppress the entire Microsoft Gallery to prevent a broken user experience, leaving the user with only the local org templates (if they can read them) or nothing at all.

Since you confirmed permissions are "Everyone except external users," the issue is likely one of the following three "Silent Failures":

 1. The "Site Collection" vs. "Subsite" Scope

The OrganizationAssetsLibrary must be on a Communication Site or the Root Site Collection of a modern team site.

• The Issue: If https://tenant.sharepoint.com/sites/sjablonen is a subsite (e.g., .../sites/sjablonen/subfolder), the discovery service sometimes fails to enumerate Word/Excel templates correctly, even if PPT works.
• The Check: Run Get-SPOSite on the URL. Ensure it is a root site. If it is a subsite, move the library to the root or create a new library at the root level. Microsoft's backend is hard-coded to scan root sites more aggressively for Word/Excel than for PowerPoint.

  2. The "NoExternals" Permission Block

You mentioned: "Everyone except external users have read permissions."

• The Trap: The create.office.com service acts as an anonymous/guest context initially to probe the library before signing the user in.
• The Conflict: If "Everyone except external users" is a specific AD group, and "Limited Access" is not granted to the guest/service principal, the probe fails for Word/Excel. PowerPoint's probe is less strict.
• The Fix: Ensure that SharePoint: AllowAccessForGuestUsers is enabled at the tenant level, OR ensure the specific "Everyone except external users" group includes the NT AUTHORITY\authenticated users claim explicitly.
• Quick Test: Temporarily add Read access for "Everyone" (All authenticated users) to the specific library only (not the whole site). If Word/Excel templates suddenly appear in the web app alongside the MS Gallery, the issue is strictly the exclusion of external/guest contexts in the permission resolution.

 3. Content Type Hub Propagation (The "Ghost" Content Type)

Word and Excel web apps rely heavily on the Content Type Hub.

• The Issue: If the .dotx or .xltx files were uploaded before the Set-SPOTenant command was run, or if they were uploaded via OneDrive sync rather than the browser, the "Word Template" content type might not be properly registered in the hub for the web app to recognize it as a "Template" rather than a "Document".
• Why PPT works: PowerPoint is more lenient with file headers.
• The Fix:

1. Download one of your Word org templates.
2. Delete it from the library.
3. Upload via Browser (Drag and drop into the library view).
4. Crucial Step: Before opening, click the file -> Info -> Convert to Content Type (if available) OR ensure that in Library Settings > Advanced, "Manage Content Types" is ON, and the file is explicitly assigned 0x010100... (Word Template).
5. Wait 4-6 hours for the Search/Index to pick up the new content type.

The "Nuclear" Verification Step

To prove definitively if this is a Service Health issue vs. a Config issue, perform this test:

1. Create a brand new modern SharePoint site (e.g., sjablonen-test).
2. Create a document library.
3. Upload one valid .dotx and one .potx.
4. Run the PowerShell again pointing to this new URL:

Set-SPOTenant -OrganizationAssetsLibraryUrl https://tenant.sharepoint.com/sites/sjablonen-test -OrganizationAssetsLibraryType OfficeTemplateLibrary

     5. Wait 2 hours.

      6. Check create.office.com.

If Word/Excel appear here but not in the old library: The old library has a "corrupted" state (permission inheritance or content type issue).
If Word/Excel still fail to show the MS Gallery: It is a tenant-wide service bug (Region specific or GCC/Commercial difference) and requires a support ticket.

Summary of Correction

Yepp: The command does not disable the MS gallery.
The likely reality is that Word/Excel web apps are failing the "handshake" with your library due to a Content Type or "External User" permission nuance. Because the handshake fails, the web app suppresses the MS Gallery to avoid errors, leaving you with only the local templates (which PPT can see, but Word/Excel cannot validate fully).

Try the "Allow Everyone (authenticated)" read permission on the library specifically for 10 minutes as a test. If the MS Gallery pops up for Word, you've found the permission bottleneck.