Edge 121 blocca i link file://? Come risolvere l’errore “about\:blank#blocked” e ripristinare i collegamenti locali

Dopo l’aggiornamento a Microsoft Edge 121.0.2277.83, molti ambienti aziendali hanno segnalato che i link locali file:// non si aprono più: il click genera una scheda con about:blank#blocked. In questa guida trovi cause, impatti, soluzioni verificate e procedure operative per ripristinare il comportamento atteso.

Indice

Panoramica del problema

Con la build Edge 121.0.2277.83 il browser ha iniziato a bloccare i link verso percorsi locali e UNC (es. file:///C:/cartella/report.xlsx o file://///server/condivisa/report.xlsx) pubblicati su pagine Intranet o portali aziendali. Al click, invece di aprire Esplora File o l’app associata, viene creata una nuova scheda con l’URL about:blank#blocked. Il criterio IntranetFileLinksEnabled — che in precedenza consentiva l’accesso a file:// dai siti considerati Intranet — appare impostato correttamente ma non ha più effetto.

Il comportamento ha impatti diretti su processi di back‑office, portali documentali, pagine di reparto con scorciatoie a file su share di rete e, più in generale, su qualsiasi applicazione web interna che delega l’apertura di file locali al sistema operativo.

Segnali e riproduzione dell’errore

Clic su un link file:// → apertura di una scheda con about:blank#blocked.
Il link file:// funziona in alcuni PC (build diverse) e non in altri, a parità di pagina Intranet.
In edge://policy il criterio IntranetFileLinksEnabled è “Enabled”, ma il click resta bloccato.
In Strumenti di sviluppo (F12), Console: messaggi generici tipo “Not allowed to load local resource” o “navigation was blocked”.

Perché accade

L’apertura di risorse locali da un contesto web è un’area storicamente delicata dal punto di vista della sicurezza: attraversa confini tra content sandbox del browser e file system/gestori di protocollo del sistema operativo. Cambiamenti in ambito hardening possono temporaneamente interrompere queste transizioni, anche quando è presente un criterio esplicito (come IntranetFileLinksEnabled) per permetterle nelle reti fidate. La build 121.0.2277.83 ha introdotto un comportamento più restrittivo che ha impedito la navigazione verso file:// dai siti intranet, generando il sintomo about:blank#blocked.

Soluzioni e workaround confermati

Le opzioni qui sotto sono in ordine di preferenza e di efficacia. Dove possibile, privilegia l’aggiornamento correttivo: è l’unica soluzione che non richiede cambiamenti strutturali o regressioni di versione.

Approccio	Descrizione	Quando usarlo
Aggiornamento correttivo	Installare Edge 121.0.2277.106 o versione superiore. Gli utenti hanno confermato che il bug risulta risolto in questa build e nelle successive.	Opzione consigliata: ripristina la funzionalità senza altre modifiche.
Rollback alla 120.x	Disinstallare la 121 e tornare a Edge 120.0.2210.144 (o altra 120.x stabile). Esempio MSI: `msiexec /i FileName.msi /qn ALLOWDOWNGRADE=1`. Possibile bloccare temporaneamente l’upgrade via GPO con criteri di rollback/target version.	Utile se non puoi distribuire subito la 121.0.2277.106 o se serve una soluzione immediata e centralizzata.
Pulizia HSTS locale	Aprire `edge://net-internals/#hsts` → sezione Domain Security Policy → nel campo Delete Domain Security Policies inserire `localhost` → Delete → riavviare Edge.	In alcuni casi ha sbloccato i link, ma non è garantito; da provare solo se le altre opzioni non sono percorribili.

Guida passo‑passo: aggiornamento correttivo

La strada maestra è portare tutti i client almeno a 121.0.2277.106 o superiore. Di seguito una traccia operativa per diversi scenari di distribuzione.

Verifica versione attuale

Digitare edge://settings/help e annotare il numero di versione (oppure leggere la versione dall’installer in uso nel tuo sistema di gestione pacchetti).
In CMD/PowerShell amministrativo: powershell -NoProfile -Command "$v = (Get-Command msedge -ErrorAction SilentlyContinue).FileVersionInfo.FileVersion; Write-Output $v"
In ambienti gestiti, si può interrogare il registro: reg query "HKLM\SOFTWARE\WOW6432Node\Microsoft\Edge\BLBeacon" /v version

Distribuzione manuale (singolo device o pilot)

Chiudi tutte le istanze di Edge.
Installa il pacchetto Stable corrispondente alla build ≥ 121.0.2277.106.
Riapri Edge e verifica su edge://settings/help che la versione sia aggiornata.
Apri la pagina intranet di test e prova un link file://.

Distribuzione con strumenti aziendali (MECM/ConfigMgr, Intune, WSUS, altri)

Pacchetto: usa l’MSI offline della versione desiderata. Imposta REBOOT=ReallySuppress se vuoi evitare riavvii automatici e demanda la chiusura di Edge con uno script pre‑installazione.
Rilevazione: regola di detection su versione ≥ 121.0.2277.106.
Ring: crea un anello pilota (5‑10%), monitora gli esiti, poi estendi a ondata successiva (30‑40%) e infine a 100%.
Monitoraggio: verifica percentuale di successo, rollback rate e segnalazioni help desk sul tema “link locali bloccati”.

Guida passo‑passo: rollback controllato a 120.x

Se l’aggiornamento correttivo non è immediatamente distribuibile, un rollback temporaneo può ridurre il fermo operativo.

Prerequisiti

Disponi dell’MSI della versione 120.x approvata (es. 120.0.2210.144).
Hai definito in GPO/MDM la destinazione di versione per impedire che i client tornino subito alla 121.

Esecuzione del downgrade

Chiudi tutte le istanze di Edge (termina eventuali processi residui).
Installa la versione 120.x con il flag di downgrade: msiexec /i "MicrosoftEdgeEnterpriseX64.msi" /qn ALLOWDOWNGRADE=1
Facoltativo: imposta criteri di aggiornamento per bloccare temporaneamente l’upgrade automatico. In ambito GPO (percorso tipico Criteri Computer → Modelli Amministrativi → Microsoft Edge → Aggiornamenti):
- TargetVersionPrefix: 120
- RollbackToTargetVersion: Enabled
- UpdateDefault: Enabled (con vincolo alla versione target) oppure Disabled per una finestra limitata.
Verifica su edge://policy che i criteri siano applicati.

Nota: rimuovi il vincolo di versione appena completi la distribuzione della build correttiva ≥ 121.0.2277.106.

Opzione “di fortuna”: pulizia HSTS locale

In alcuni ambienti, soprattutto dopo molteplici migrazioni e test, lo store HSTS locale può introdurre effetti collaterali. Per una prova rapida:

Apri edge://net-internals/#hsts.
Nella sezione Domain Security Policy, campo Delete Domain Security Policies, inserisci localhost e premi Delete.
Riavvia Edge e riprova il link file://.

Questa azione non è garantita e non sostituisce l’aggiornamento correttivo, ma in diversi casi ha rimosso il blocco.

Controlli post‑fix e validazione

Dopo l’aggiornamento o il rollback, esegui i seguenti check:

Policy: in edge://policy verifica:
- IntranetFileLinksEnabled = Enabled.
- Eventuali criteri di aggiornamento coerenti con la tua strategia (se hai usato rollback).
Zona Intranet: se usi mapping di zona, controlla in Assegnazione siti a zone che il portale con i link file:// sia effettivamente in Intranet locale.
Test funzionale: esegui 3‑5 link rappresentativi:
- Percorso UNC lungo (>260 caratteri) e corto (<=260).
- File aperti da app diverse (Excel, PDF, immagini, DWG).
- Cartelle e file: entrambi devono aprirsi.
Telemetria: monitora nel primo giorno i ticket con oggetto “link file bloccati” e “about:blank#blocked”.

Raccomandazioni operative

Distribuisci la build 121.0.2277.106 (o successiva) con i tuoi canali di aggiornamento aziendali: è la soluzione ufficiale e definitiva.
Mantieni un piano di rollback 120.x in GPO finché il deployment non è completato, per evitare interruzioni lato utente.
Verifica le policy: dopo l’aggiornamento, assicurati che IntranetFileLinksEnabled resti Enabled per consentire i link locali.
Test di regressione: aggiungi casi sui link file:// nella validazione dei futuri aggiornamenti di Edge, così da intercettare eventuali ricadute.

Approfondimento: sicurezza e vincoli dei link `file://`

Permettere a un sito web di aprire file locali comporta rischi: un attore malevolo potrebbe indurre l’utente a cliccare link a file sensibili o ad eseguire protocol handler non desiderati. Per questo, i browser limitano l’uso di file:// in contesti Internet e lo consentono solo in scenari ben delimitati (es. Intranet con policy dedicate). Il criterio IntranetFileLinksEnabled ha proprio lo scopo di “sbloccare” file:// per i siti ritenuti fidati dalla tua organizzazione, ma rimane soggetto a modifiche di sicurezza introdotte nelle release.

Best practice di progettazione per ridurre la dipendenza da `file://`

Preferisci percorsi documentali moderni (SharePoint/OneDrive) quando possibile, con link HTTP(S) “intelligenti”.
Protocol Handler applicativi: per file Office valuta link del tipo ms-excel:ofe|u|<URL> o ms-word:ofe|u|<URL> (richiedono URL http/https raggiungibili; non sostituiscono i link file:// a share SMB).
Unità di rete mappate: per gli utenti che usano spesso share UNC, una lettera di unità riduce path lunghi e migliora compatibilità.
IE Mode: se la tua Intranet usa IE Mode, verifica che la configurazione non sovrascriva il comportamento dei link locali e che il sito sia realmente in Intranet.
Validazioni per release: inserisci nel piano di test una checklist automatizzata (vedi sotto) eseguibile a ogni nuovo rilascio di Edge.

Checklist rapida per l’IT

Identifica i siti che espongono link file:// e i reparti che li usano quotidianamente.
Allinea un pilot con la build ≥ 121.0.2277.106 e valida l’apertura di file e cartelle.
Se serve rollback, imposta TargetVersionPrefix a 120 e abilita RollbackToTargetVersion prima di distribuire l’MSI 120.x.
Comunica agli utenti lo stato dell’intervento e la finestra temporale del fix.
Rimuovi i vincoli di versione appena la nuova build è stabilizzata su ampia scala.

Esempi pronti all’uso

HTML di esempio per un link locale

<a href="file://///fs01/Contabilita/2024/Report.xlsx">Apri il report mensile</a>

Nota: su siti non classificati come Intranet, il link verrà bloccato a prescindere dalla versione.

PowerShell: inventario rapido versioni Edge

# Elenco versioni Edge dai PC di un OU tramite WinRM (esempio semplificato)
$computers = @("PC-001","PC-002","PC-003")
$results = foreach ($c in $computers) {
  try {
    $v = Invoke-Command -ComputerName $c -ScriptBlock {
      (Get-Item "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe").VersionInfo.ProductVersion
    } -ErrorAction Stop
    [pscustomobject]@{ Computer = $c; Version = $v }
  } catch {
    [pscustomobject]@{ Computer = $c; Version = "N/D" }
  }
}
$results | Format-Table -AutoSize

PowerShell: regola di detection (Intune/MECM) ≥ 121.0.2277.106

$min = [version]"121.0.2277.106"
$cur = [version]((Get-Item "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe").VersionInfo.ProductVersion)
if ($cur -ge $min) { exit 0 } else { exit 1 }

Esempio di criteri (GPO) per bloccare temporaneamente l’upgrade

# Percorso indicativo: Criteri Computer → Modelli Amministrativi → Microsoft Edge → Aggiornamenti
Impostazioni consigliate durante il rollback
TargetVersionPrefix = 120
RollbackToTargetVersion = Enabled
Rimuovere/aggiornare questi valori appena distribuita la build correttiva

Procedura guidata per pulizia HSTS

Apri edge://net-internals/#hsts.
Sezione Domain Security Policy.
Nel riquadro Delete Domain Security Policies digita localhost.
Clic su Delete e riavvia Edge.

Domande frequenti

I link file:// funzionano solo su Intranet?
Sì, per design i browser moderni bloccano file:// in siti Internet/Esterno. Su siti Intranet la policy IntranetFileLinksEnabled abilita l’eccezione — quando supportata dalla build.

Serve per forza un rollback?
No, se puoi portare i client a 121.0.2277.106 (o superiore). Il rollback a 120.x è una misura ponte per chi non può aggiornare subito.

Perché la cancellazione HSTS aiuta?
In alcuni ambienti rimuove entry locali che interferiscono con navigazioni speciali; non è una cura strutturale, solo un tentativo a basso rischio.

IE Mode risolve automaticamente?
Non necessariamente. IE Mode può cambiare il motore di rendering ma i vincoli di sicurezza sui link locali restano. Verifica sempre con test espliciti.

Possiamo forzare l’apertura con script lato client?
Tecniche come componenti helper o estensioni possono aggirare il problema, ma aggiungono superficie di rischio e manutenzione. Preferisci l’aggiornamento correttivo.

Strategia di rilascio consigliata

Analisi d’impatto: mappa i siti interni con file:// e i team che li usano.
Pilot: aggiorna un gruppo campione alla build ≥ 121.0.2277.106; raccogli feedback.
Comunicazione: invia una nota agli utenti spiegando che i link locali torneranno operativi dopo l’aggiornamento.
Rollout a scaglioni: amplia progressivamente fino a copertura completa.
Rimozione rollback: se applicato, elimina i vincoli GPO/MDM alla versione 120.x.
Hardening continuo: inserisci test file:// nella pipeline di validazione per ogni nuova release.

Diagnostica avanzata (per team IT)

Edge Policies: esporta JSON da edge://policy prima e dopo l’aggiornamento per confrontare effettive policy applicate.
Site to Zone Assignment: verifica che il dominio della tua Intranet sia effettivamente in zona 1 (Intranet locale) se usi mapping di zona.
DevTools: controlla la Console per messaggi “Not allowed to load local resource” e annota eventuali intestazioni CSP della pagina (anche queste possono impedire la navigazione verso file://).
Path lunghi/nomi: prova percorsi con spazi, caratteri non ASCII e oltre 260 caratteri per assicurarti che non ci siano limiti del file system o dell’app associata.

Cosa evitare

Non disabilitare indiscriminatamente gli aggiornamenti di Edge: usa il rollback solo come ponte, con finestra temporale definita.
Non modificare criteri di sicurezza non correlati (es. SmartScreen, site isolation) nella speranza di sbloccare file://: non è efficace e introduce rischi.
Non distribuire estensioni di terze parti per “forzare” l’apertura dei file se non strettamente necessario e previo security review.

Riepilogo esecutivo

Il blocco dei link locali file:// in Edge 121.0.2277.83 è un effetto collaterale di un cambiamento restrittivo. La build 121.0.2277.106 (e successive) ripristina il comportamento atteso in presenza di IntranetFileLinksEnabled. Se non puoi aggiornare subito, esegui un rollback temporaneo a 120.x con controllo di versione via GPO. Mantieni test di regressione per anticipare anomalie simili in futuro.

Appendice: modello di comunicazione agli utenti

Oggetto: Ripristino apertura link a cartelle e file di rete dal portale interno
Testo breve: “Abbiamo completato l’aggiornamento di Microsoft Edge alla versione correttiva. I link a cartelle e file locali (file://) tornano a funzionare. Se visualizzi ancora about:blank#blocked, riavvia Edge o contatta l’help desk.”

Appendice: tabella decisionale

Situazione	Azione consigliata	Note
Piccolo gruppo utenti bloccati	Aggiornamento manuale a ≥ 121.0.2277.106	Tempo di ripristino minimo, impatto limitato
Organizzazione ampia con change freeze	Rollback a 120.x con GPO; pianifica aggiornamento	Controlla TargetVersionPrefix e rimuovilo appena possibile
Vincoli IT temporanei	Prova pulizia HSTS	Non garantita, nessun impatto strutturale

Appendice: domande di audit che potresti ricevere

Qual è la versione minima di Edge che risolve il problema? 121.0.2277.106.
Qual è la policy necessaria per i link locali? IntranetFileLinksEnabled abilitata.
Qual è il piano di prevenzione? Test di regressione su file:// e monitoraggio note di rilascio.

Conclusioni
Se i tuoi utenti vedono about:blank#blocked cliccando link a cartelle o file interni, applica come prima scelta l’aggiornamento a Edge 121.0.2277.106 o superiore. Mantieni in tasca un piano di rollback controllato a 120.x per ridurre i tempi di fermo, valida le policy su edge://policy e aggiungi test file:// al tuo processo di qualificazione. In questo modo ti garantisci continuità operativa oggi e resilienza contro eventuali regressioni domani.