In un sito SharePoint Online la ricerca smette di funzionare soltanto per una persona e mostra “Something went wrong, please refresh to try again”. Qui trovi diagnosi mirata e una soluzione definitiva basata sulla rimozione di identità duplicate nella lista All People.
Panoramica del problema
Scenario tipico: in un sito SharePoint Online la ricerca funziona per tutti, tranne che per una dipendente. Qualsiasi query produce l’errore generico “Something went wrong, please refresh to try again” e non vengono restituiti documenti. Le autorizzazioni sul sito sono corrette, e i colleghi vedono risultati regolarmente.
Questo comportamento è fuorviante perché fa pensare a un problema di browser o di cache. In realtà, nella maggior parte dei casi la causa è legata alla identità dell’utente così come memorizzata nella raccolta siti: per esempio una duplicazione dell’oggetto utente nella “User Information List” (la vista “All People”) oppure una traccia di un vecchio account personale/guest rimasto come “fantasma”.
Sintomi e contesto
- Errore immediato all’esecuzione di una ricerca nel sito: “Something went wrong, please refresh to try again”.
- Il problema si manifesta per un solo utente (o pochissimi); gli altri vedono risultati corretti.
- La persona colpita può comunque aprire documenti se raggiunge le pagine in altro modo (navigazione, link diretti, librerie).
- Le autorizzazioni su sito, librerie e cartelle risultano corrette e in linea con gli altri colleghi.
Tentativi locali che non risolvono
Le azioni lato client qui sotto sono utili come esclusione, ma non risolvono quando la radice è identitaria:
- Cancellazione di cache, cookie e dati di navigazione.
- Reinstallazione o cambio browser (es. Edge, Chrome) anche in modalità InPrivate.
- Accesso da un altro PC con profilo Windows nuovo o privo di estensioni.
- Verifica delle autorizzazioni nei gruppi SharePoint/di sicurezza (l’utente risulta correttamente presente).
Cause probabili
Identità duplicate o incoerenti
SharePoint Online mantiene una propria cache di utenti e gruppi nella User Information List (vista All People). Nel tempo si possono accumulare:
- Omonimie o duplicazioni dovute a cambi UPN, migrazioni, rinominazioni.
- Vecchi account Microsoft personali (MSA) importati accidentalmente quando l’utente visitava il sito prima del consolidamento in Azure AD.
- Account guest (#EXT#) residuali rispetto all’identità aziendale corrente.
Queste situazioni generano un disallineamento tra controllo accessi (ACL) e identità effettiva con cui l’utente interroga l’indice, causando filtri di security trimming imprevisti o errori applicativi lato Search.
Incidenti lato servizio
Occasionalmente Microsoft segnala incidenti globali che impattano la propagazione delle proprietà di controllo accessi nell’indice (esempio: SP709902, in cui un disallineamento dell’indice propagava in modo errato le ACL). In presenza di messaggi analoghi nella bacheca di amministrazione di Microsoft 365, è opportuno aprire un ticket tramite Help & support per una verifica del tenant e, se necessario, una rigenerazione dell’indice o una re-crawl mirata.
Checklist di diagnosi rapida
Prima di intervenire, usa questa sequenza “da campo” (5–10 minuti):
| Verifica | Cosa guardare | Esito | Azione successiva |
|---|---|---|---|
| Riproducibilità | Il problema accade su altri PC/reti/privato? Con Edge InPrivate? | Sì | Escludi client → probabile causa server/identità. |
| Confronto pari livello | Collega con stessi gruppi/permessi vede risultati? | Sì | Le ACL sono sane → focus sull’utente affetto. |
| Autorizzazioni | L’utente è presente nei gruppi SharePoint corretti? | Sì | Passa alla verifica “All People”. |
| All People | Ci sono due o più voci per lo stesso individuo (AAD, guest, personale)? | Sì | Pulizia delle voci duplicate (vedi sotto). |
| Bacheca messaggi | Esiste un incident ID correlato a Ricerca/ACL? | Sì | Apri ticket M365 e allega dettagli (UPN, sito, orario). |
Soluzione definitiva applicata
Nel caso reale che ha ispirato questo articolo, nella vista All People del sito erano presenti due occorrenze della stessa persona:
- l’account aziendale corrente (Azure AD)
- un vecchio account Microsoft personale (MSA) rimasto come “fantasma”.
La rimozione di entrambe le voci seguita dalla ri-aggiunta del solo account aziendale ha ripristinato immediatamente la ricerca per l’utente.
Procedura passo‑passo da interfaccia
- Accedi come Owner del sito interessato.
- Vai su Impostazioni sito → Utenti e autorizzazioni → Utenti e gruppi.
- Apri la vista All People (tutte le persone).
- Nella casella di ricerca, cerca il nome/UPN della persona interessata.
- Se vedi più voci che rappresentano la stessa persona (es. una con suffisso
#EXT#o un MSA), selezionale e scegli Rimuovi dal sito. - Verifica che l’utente non compaia più nella vista.
- Reinserisci l’utente corretto solo con l’account aziendale:
- aggiungilo al gruppo del sito (es. Members) o a quello previsto dalla governance;
- in alternativa, fai visitare il sito all’utente: SharePoint ricreerà automaticamente la sua voce coerente.
- Invita l’utente a rieseguire la ricerca: l’errore deve scomparire e i risultati tornare visibili.
Nota: la rimozione dalla vista All People (User Information List) non elimina documenti né rompe permessi a livello di contenuto; rimuove solo l’oggetto utente “cache” del sito. All’accesso successivo l’oggetto viene rigenerato con gli attributi corretti.
Procedura PowerShell – SharePoint Online Management Shell
Se preferisci operare da PowerShell (utile quando la UI non mostra chiaramente i duplicati):
# Connessione all'Admin Center
Connect-SPOService -Url https://<tenant>-admin.sharepoint.com
Elenco degli utenti noti alla raccolta siti
Get-SPOUser -Site https://<tenant>.sharepoint.com/sites/<sito> ` | Where-Object { $_.LoginName -match 'utente@dominio\.com|#EXT#|outlook\.com|live\.com' }`
| Select LoginName, DisplayName, IsSiteAdmin, GroupUser
Rimozione dell'identità "fantasma" (adatta il LoginName esatto)
Remove-SPOUser -Site https://<tenant>.sharepoint.com/sites/<sito> `
-LoginName 'i:0#.f|membership|utente_outlook.com#EXT#@tenant.onmicrosoft.com'
Eventuale reinserimento nel gruppo corretto via People Picker / UI
Procedura PowerShell – PnP PowerShell
Con PnP PowerShell puoi analizzare e ripulire più siti in modo consistente:
# Connessione interattiva al sito
Connect-PnPOnline -Url https://<tenant>.sharepoint.com/sites/<sito> -Interactive
Utenti noti al sito (User Information List)
Get-PnPUser | Select LoginName, Email, Title
Eliminazione voce specifica (login "fantasma")
Remove-PnPUser -LoginName 'i:0#.f|membership|[utente@outlook.com](mailto:utente@outlook.com)' Permessi necessari: devi essere Sito Amministratore/Owner della raccolta siti; in alternativa, esegui con privilegi adeguati o fatti delegare temporaneamente.
Verifica post‑fix
- L’utente riesegue la query: nessun errore e risultati coerenti.
- Controlla che la nuova voce in All People corrisponda all’UPN aziendale corrente.
- Facoltativo: svuota cache del browser e verifica anche da una finestra InPrivate per sicurezza.
Approfondimento tecnico: perché colpisce un solo utente
La Ricerca in SharePoint Online applica il security trimming: l’indice contiene metadati e ACL, e restituisce risultati solo se l’utente chiamante è autorizzato. Se a livello di sito o di indice l’utente è “visto” con un’identità non allineata (es. residuo #EXT# o MSA), le ACL non combaciano con i gruppi reali dell’utente in Azure AD. L’esito può essere duplice:
- Zero risultati (documenti “nascosti” per quell’identità);
- Errore applicativo perché la pipeline di query non riesce a risolvere correttamente i token di sicurezza.
Da qui la peculiarità del caso: un singolo utente colpito mentre gli altri, con identità integre, non incontrano problemi.
Ulteriori verifiche consigliate
- Oggetti utente duplicati o disabilitati in Azure AD: verifica se esistono utenze dismesse con lo stesso indirizzo o alias.
- Gruppi SharePoint “classici”: membership ereditate da siti storici possono contenere voci obsolete.
- Azure AD Connect: per ambienti ibridi, controlla che non siano rimasti account on‑prem “orfani”.
- Guest (#EXT#): elimina o riconcilia inviti guest non più necessari o duplicati rispetto all’utente interno.
Buone pratiche e prevenzione
- Governance delle identità: evita rinominazioni massive di UPN senza piano di bonifica nei siti.
- Manutenzione periodica: ogni 3–6 mesi controlla in siti critici la vista All People e rimuovi voci orfane.
- Automazione: usa PowerShell per scansionare le raccolte siti in cerca di duplicati palesi.
- Onboarding/Offboarding: prevedi checklist per aggiunta/rimozione da gruppi M365 e SharePoint.
- Segnalazione rapida: se compare un incident ID relativo alla ricerca, apri subito ticket dal portale di amministrazione.
Playbook operativo (pronto all’uso)
- Conferma che il problema è isolato a uno o pochi utenti.
- Escludi il client (InPrivate + altro PC/rete).
- Confronta le autorizzazioni con un collega “gemello”.
- Ispeziona All People e rimuovi eventuali identità duplicate o “fantasma”.
- Riaggiungi solo l’account aziendale attuale.
- Riprova la ricerca; se persiste, verifica la bacheca messaggi e apri ticket M365 con dettagli.
Albero decisionale sintetico
| Domanda | Sì | No |
|---|---|---|
| Succede a un solo utente? | Controlla All People e identità. | Possibile incidente servizio: consulta bacheca, verifica stato. |
| All People mostra duplicati? | Rimuovi voci e riaggiungi account AAD. | Conferma gruppi/ACL e indaga eventuali guest/EXT. |
| Dopo la pulizia la ricerca funziona? | Chiudi il caso, documenta. | Apri ticket M365 con informazioni tecniche. |
Template di ticket per il supporto Microsoft
Quando apri un caso, fornisci fin da subito informazioni utili a ridurre i tempi di analisi:
- UPN dell’utente affetto, URL del sito, orario (con fuso) dell’ultima riproduzione.
- Testo completo del messaggio di errore visualizzato dall’utente.
- Se disponibile, ID di correlazione/richiesta ricavato dalla pagina o dagli strumenti sviluppatore del browser.
- Elenco dei passaggi già eseguiti (cache, altro browser/PC, controllo autorizzazioni, pulizia All People).
- Riferimento a eventuali incident ID visualizzati nella bacheca messaggi.
Script di audit (modello) per individuare identità duplicate
Lo script seguente produce un CSV con possibili duplicati per Email/DisplayName in una raccolta siti. Adattalo e ripeti sui siti critici o in batch.
# Requisiti: PnP PowerShell
Obiettivo: elenco potenziali duplicati nella User Information List (All People)
$SiteUrl = "https://.sharepoint.com/sites/"
$OutCsv = "AllPeople-Duplicati.csv"
Connect-PnPOnline -Url $SiteUrl -Interactive
$users = Get-PnPUser | Select LoginName, Email, Title, PrincipalType
$grouped = $users | Group-Object Email
$result = foreach ($g in $grouped) {
if ($g.Count -gt 1 -and $g.Name) {
foreach ($u in $g.Group) {
[PSCustomObject]@{
Email = $g.Name
DisplayName = $u.Title
LoginName = $u.LoginName
PrincipalType = $u.PrincipalType
}
}
}
}
$result | Export-Csv -NoTypeInformation -Path $OutCsv
Write-Host "Analisi completata. File: $OutCsv" FAQ
Perché cancellare e riaggiungere l’utente risolve?
Perché costringe il sito a ricreare l’oggetto utente locale allineandolo all’identità AAD attuale, eliminando riferimenti errati a vecchi SID/UPN o a identità guest/personali.
È rischioso rimuovere una voce da All People?
No, l’operazione non cancella file né gruppi; elimina solo la cache locale dell’utente. L’oggetto si ricostruisce al login successivo o quando lo aggiungi a un gruppo del sito.
Quando sospettare un incidente globale?
Se il problema è diffuso su più utenti o siti, o compare anche in ricerche su siti diversi senza pattern di identità duplicata. In questo caso, usa la bacheca messaggi di Microsoft 365 e apri un ticket fornendo i dettagli.
Come distinguo utenti “interni”, “guest” e “personali” a colpo d’occhio?
- Interni: UPN del dominio aziendale.
- Guest: login con
#EXT#@tenant.onmicrosoft.com. - Personali (MSA): indirizzi
@outlook.com,@live.com, ecc.
Errori comuni da evitare
- Limitarsi al client: continuare a reinstallare browser e svuotare cache senza guardare All People.
- Aggiungere l’utente a nuovi gruppi “a caso” per “far comparire” risultati: si snatura la governance e non si rimuove la causa.
- Ignorare i guest: voci #EXT# spesso restano a residuo e creano ambiguità.
- Dimenticare Azure AD: account disabilitati o duplicati possono riflettersi sui siti.
Lezioni apprese
- Identità duplicate (legacy, guest, personali) possono interferire con indicizzazione e permessi in SharePoint Online; conviene controllare periodicamente la lista All People o usare PowerShell (
Get-SPOUser) per individuare SID/UPN obsoleti. - In presenza di errori di ricerca isolati, oltre a cache/browser, verificare:
- oggetti utente duplicati o disabilitati in Azure AD;
- membership di gruppi ereditati dal classico SharePoint (SharePoint Groups);
- sincronizzazione di Azure AD Connect per account on‑prem abbandonati.
- Se Microsoft segnala un incident ID correlato alla ricerca, aprire subito un ticket: il supporto può rigenerare l’indice o forzare una re‑crawl del tenant.
Conclusioni
Quando la ricerca di SharePoint Online non restituisce risultati a un singolo utente, pensa prima di tutto all’identità. La pulizia delle voci duplicate in All People, seguita dalla ri-aggiunta del solo account aziendale, è un fix semplice e potente che nella pratica risolve all’istante la maggior parte dei casi. Accompagna l’azione con un minimo di audit su gruppi e AAD, e attiva il supporto Microsoft se noti segnali di incidente lato servizio. Documenta la procedura e inseriscila nel tuo playbook: la prossima volta risparmierai tempo prezioso.