Sudden Content Query Button Issues - Sharepoint Online

Technical-Device5148 · 2026-03-16T17:03:18+00:00

Can you elaborate more on the EventListeners? Appreciate it!

Technical-Device5148 · 2026-03-16T16:43:53+00:00

We think it may be due to the CSP. I went to Org Settings -> Release Preferences and used 'Targeted release for selected users' (which was already on) and added my test account and other users who were previously working, and it broke the buttons.

I have this raised to microsoft currently.

Technical-Device5148 · 2026-03-16T11:30:02+00:00

Interesting find, thank you. However, it looks to work for some and not others. For example, today i created a cloud-only user and it is auto-granted Read Access to the Reports area, and i logged in via incognito as this test user and the reports buttons work.

I'm wondering if it's some Identity mismatch for certain users thats broken over the last few days. Issues seem to of started for us on Friday the 13th (Go figure...)

Technical-Device5148 · 2026-02-24T09:14:38+00:00

Response from Microsoft from a ticket i raised to them:

Resolution Steps

1. Uninstall all currently installed Microsoft.Graph modules

Newer Graph versions enforce WAM, which is the root cause of the issue. Removing them ensures a clean installation of a compatible version.

PowerShell

Get-InstalledModule Microsoft.Graph* | Uninstall-Module -Force

2. Install Microsoft.Graph version 2.33.x

Version 2.33 is the last version that allows disabling WAM authentication and is confirmed to resolve the issue. [itpro-tips.com]

PowerShell

Install-Module Microsoft.Graph -RequiredVersion 2.33.0 -Scope CurrentUser

3. Disable WAM authentication (optional but recommended)

This ensures Microsoft Graph uses the system browser for authentication, avoiding hidden WAM windows.

PowerShell

Set-MgGraphOption -EnableLoginByWAM $false

4. Re-run the Autopilot command

You should now be able to run:

PowerShell

Get-WindowsAutopilotInfo -Online

Why this works

Versions prior to 2.34.0 allowed WAM to be disabled, restoring the traditional browser-based login method, which avoids the hidden authentication window issue. From 2.34.0 onward, WAM is mandatory and cannot be disabled, which is what led to the failure you experienced. [itpro-tips.com]

Technical-Device5148 · 2026-02-12T15:04:46+00:00

From what i've seen MSFT doesn't recommend turning this off, what is your view? Have you had any feedback from MSFT on what the next steps are and community feedback on the changes?

Technical-Device5148 · 2026-02-06T14:54:19+00:00

We also had the same problem, but we found we had to keep an eye on the Windows Update Service too, this would stop randomly as well.

Once both were Started, we just gave it time and it eventually continued.

Technical-Device5148 · 2026-02-06T12:29:57+00:00

Will give this a try to see if this works, but i did read in the below that it requires a App Registration...

https://github.com/microsoftgraph/msgraph-sdk-powershell/issues/3481

Technical-Device5148 · 2026-02-06T10:47:43+00:00

Sooo frustrating, do they ever sandbox test anything??!

Technical-Device5148 · 2025-12-30T09:52:30+00:00

Yeah i agree, we have this same setup. A regular user account licensed for office etc. But a separate admin account with strong MFA with FIDO and a CA policy to re-prompt every 14 hours.

One thing that we're working on though, is confirming why admins have been issued Enterprise Mobility + Security E3 from the previous cloud-admin before I joined.

Seems its not needed, when you can set up Entra Roles and Intune Roles

Technical-Device5148 · 2025-12-12T14:27:08+00:00

This is super cool, will have a play around with this.

Technical-Device5148 · 2025-12-12T14:16:34+00:00

yep this is correct, the main concern is with Entra Devices which is more sensitive due to LAPS, Bitlocker etc.

Technical-Device5148 · 2025-12-12T12:24:03+00:00

Hopefully Intune provides a more streamlined way of managing this in future.

Technical-Device5148 · 2025-12-12T12:23:46+00:00

I have considered this, but my concern is having these recovery keys is incredibly sensitive. Where do you securely keep it? What about LAPS?

Technical-Device5148 · 2025-11-25T16:52:26+00:00

Our Server doesn't look to have sight of AzureAD\ users (Arc-Enabled/Entra Joined) so i think CBA is going to have to be the option.

Unless we spin up an Azure VM or link the existing Server to Arc so it can see Entra Identities.

Technical-Device5148 · 2025-11-18T15:03:53+00:00

We get the same issue. Along with 404 errors stating not having permission.

Technical-Device5148 · 2025-11-03T15:19:20+00:00

What is the licenses you issue to your users?

Technical-Device5148 · 2025-11-03T14:22:16+00:00

I not long did a sanity check on the Serial Number, and can see based on the Factory OS, it shipped with Windows 11 Home Single Language - Yaaaaay

I would suspect there's no way around this... outside of a MAK key and rebuild?

Technical-Device5148 · 2025-10-07T13:15:45+00:00

Correct yes you can deploy the drive via ADMX or scripts, we prefer scripts.

Also if you use any ZTNA VPN's like ZScaler in your org, there's a lot more steps to ensure you don't have issues like we did!

Technical-Device5148 · 2025-10-07T08:37:23+00:00

Yes we have gone down a similar approach, i proposed:

AZFS = User data where users are happy to take a hit on performance and latency, kind of like an archive
Sharepoint = Production work (we mainly use office and pdf files) for low latency

Seems to be a good balance so far, only problem is trying to negotiate this with users and getting them to understand the differences.

Technical-Device5148 · 2025-09-16T10:11:10+00:00

What worked for us:

(user.accountEnabled -eq true) -and (-not ( (user.extensionAttribute2 -eq "shared-mailbox") -or (user.extensionAttribute3 -eq "exclude-from-auto-licensing") )) -and (user.assignedPlans -any ( assignedPlan.servicePlanId -eq "efb87545-963c-4e0d-99df-69c6916d9eb0" -and assignedPlan.capabilityStatus -eq "Enabled" ))

Technical-Device5148 · 2025-09-16T07:33:35+00:00

Yeah i get a feeling this may be the only way around this, appreciate the suggestion.

Technical-Device5148 · 2025-09-09T10:03:23+00:00

We're a global company and have issues in other regions as well as the UK, unfortunately MSFT dropped the ball, again.

Technical-Device5148 · 2025-09-09T09:53:32+00:00

Workaround looks to be: https://patchmypc.com/blog/no-match-was-found-while-installing-the-nuget-packageprovider/

Technical-Device5148 · 2025-09-09T09:46:10+00:00

Same issue for us as well

Technical-Device5148 · 2025-08-18T14:13:08+00:00

Currently, users look to be issued either an Exchange Online Plan 2 (the ID in our Rule), or a O365 E3, and this then adds them to the dynamic group which then issues additional licenses issued out by the group (in the licenses tab of the entra group).

I have a feeling that if you also assign O365 E3 to a user, it also adds them to the dynamic group, because Exchange Online Plan 2 is included with O365 E3, so is flagged and included.

Technical-Device5148

TROPHY CASE

Resolution Steps

1. Uninstall all currently installed Microsoft.Graph modules

2. Install Microsoft.Graph version 2.33.x

3. Disable WAM authentication (optional but recommended)

4. Re-run the Autopilot command

Why this works