MENU
  1. Accueil
  2. Windows
  3. Edge
  4. Edge 121 bloque les liens file:// en intranet : « about\:blank#blocked », IntranetFileLinksEnabled et correctif 121.0.2277.106

Edge 121 bloque les liens file:// en intranet : « about\:blank#blocked », IntranetFileLinksEnabled et correctif 121.0.2277.106

Edge

Après la mise à jour vers Microsoft Edge 121.0.2277.83, les liens file:// cliqués depuis des pages intranet n’ouvrent plus l’Explorateur et mènent à about:blank#blocked, même avec IntranetFileLinksEnabled. Voici pourquoi, comment corriger et quoi faire en entreprise.

Sommaire

Vue d’ensemble du problème

De nombreuses organisations ont observé qu’à partir d’Edge 121.0.2277.83, les liens locaux de type file:// ajoutés dans des portails intranet (wiki interne, SharePoint on‑prem, applications line of business, etc.) ne déclenchent plus l’ouverture de l’Explorateur Windows. À la place, l’onglet affiche about:blank#blocked. Cette réaction signale un blocage volontaire du navigateur pour un schéma considéré sensible.

Le paramètre attendu pour autoriser ce scénario, la stratégie IntranetFileLinksEnabled (GPO/ADMX), est pourtant correctement activé chez les entreprises concernées. Le comportement normal est rétabli par la version 121.0.2277.106, ce qui confirme une régression introduite dans le build 121.0.2277.83.

Résumé exécutif (TL;DR)

  • Cause : régression du canal Stable 121.0.2277.83 impactant l’ouverture des liens file:// depuis des origines intranet, malgré la politique IntranetFileLinksEnabled.
  • Correctif : mise à jour vers 121.0.2277.106 (ou version ultérieure).
  • Contournement entreprise si MAJ immédiate impossible : geler la diffusion du build 121 affecté, et rétrograder temporairement vers 120.0.2210.144 via MSI avec ALLOWDOWNGRADE=1.
  • À vérifier : stratégie IntranetFileLinksEnabled appliquée, page d’origine réellement intranet, syntaxe des URL file:// correcte, et (si utilisé) IE Mode avec InternetExplorerIntegrationLocalFileAllowed.

Tableau de synthèse

ÉlémentDétail
SymptômeCliquer un lien file:// depuis un site intranet ouvre about:blank#blocked au lieu de lancer l’Explorateur.
Canal/version impactéeStable 121.0.2277.83
Comportement attenduAvec IntranetFileLinksEnabled=Enabled et une page source intranet, l’OS doit ouvrir le chemin local ou UNC ciblé.
CorrectionStable 121.0.2277.106 (et suivantes)
Population affectéeUtilisateurs Windows dans des environnements intranet s’appuyant sur des liens file:// (wiki interne, SharePoint on‑prem, applis LOB).
RisqueRupture d’usage, perte de productivité, tickets Helpdesk massifs.

Pourquoi about:blank#blocked ?

Quand Edge affiche about:blank#blocked, cela signifie qu’il a empêché une navigation jugée risquée (ici, vers un schéma non‑web : file://). Les navigateurs modernes bloquent par défaut les tentatives d’ouverture de fichiers locaux depuis des pages web afin de réduire l’exposition aux attaques. Edge propose une exception contrôlée pour les origines intranet via IntranetFileLinksEnabled. Dans le build concerné, cette exception n’est pas honorée correctement.

Stratégie de résolution

Option 1 : Mettre à jour Edge (recommandé)

La solution la plus fiable consiste à mettre à jour Edge vers 121.0.2277.106 (ou ultérieur). Ceci rétablit l’ouverture des liens file:// depuis des pages intranet lorsque IntranetFileLinksEnabled est activé.

Option 2 : Contournement entreprise si la MAJ est momentanément impossible

  • Geler la diffusion du build 121 impacté via vos canaux (GPO, MDM, outil de gestion logicielle).
  • Rétrograder temporairement vers la 120.0.2210.144 avec MSI : msiexec /I FileName.msi /qn ALLOWDOWNGRADE=1
  • Réactiver les mises à jour dès qu’un build correctif est validé au sein de votre environnement pilote.

Procédure détaillée pas à pas

1) Identifier précisément la version installée

Sur un poste affecté :

  • Ouvrez edge://settings/help et relevez la version exacte (ex. 121.0.2277.83 ou 121.0.2277.106).
  • En entreprise, vous pouvez auditer à grande échelle avec PowerShell :
# Afficher la version du binaire msedge.exe local
$edgeExe = "${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe"
if (-not (Test-Path $edgeExe)) { $edgeExe = "${env:ProgramFiles}\Microsoft\Edge\Application\msedge.exe" }
(Get-Item $edgeExe).VersionInfo.ProductVersion

Intégrez ce contrôle à vos scripts d’inventaire pour dresser la cartographie des postes en 121.0.2277.83 et prioriser le déploiement du correctif.

2) Mettre à jour vers 121.0.2277.106 ou ultérieur

Déployez le correctif via vos mécanismes habituels (Edge Update, MEM/Intune, Configuration Manager, outil logiciel tiers, image VDI). Prévoyez :

  • Un anneau pilote (quelques % des postes) pour valider rapidement le bon rétablissement des liens file://.
  • Un anneau large une fois la validation obtenue.
  • La surveillance post‑déploiement (tickets Helpdesk, sondes applicatives, logs).

3) Contournement : bloquer et rétrograder (temporaire)

Si vous ne pouvez pas mettre à jour immédiatement :

  1. Bloquez la diffusion du build 121.0.2277.83 dans votre canal Stable.
  2. Rétrogradez vers 120.0.2210.144 à l’aide de l’installateur MSI (off‑line) avec l’option ALLOWDOWNGRADE=1 : msiexec /I FileName.msi /qn ALLOWDOWNGRADE=1 Cette opération ne supprime pas le profil utilisateur Edge ni ses données de navigation.
  3. Planifiez la remontée dès que possible vers un build corrigé (121.0.2277.106+).

4) Vérifications indispensables (même après correctif)

  • Stratégie : dans edge://policy, vérifiez que IntranetFileLinksEnabled = Enabled.
  • Origine intranet : confirmez que la page d’où provient le lien est bien un site intranet de votre organisation (non Internet).
  • Syntaxes valides des URL file:// :
    • Partage réseau : file://serveur/partage/chemin/fichier.ext (variante acceptée : file://///serveur/partage/chemin/fichier.ext)
    • Disque local : file:///C:/chemin/fichier.ext
    • Remplacez les espaces par %20 et encodez les caractères spéciaux en UTF‑8 percent‑encoding.

Bonnes pratiques pour les liens file://

Un lien mal formé est une cause fréquente d’échec, indépendamment de la version. Respectez strictement la grammaire des URL.

Cas d’usageExemple correctExemple incorrectRemarques
Partage réseau (UNC)file://srv-fichiers/Compta/Bilan%202024.xlsxfile://\\srv-fichiers\Compta\Bilan 2024.xlsxUtilisez des slashes (/), pas de backslashes (\), et encodez les espaces.
Variante réseaufile://///srv-fichiers/Compta/Bilan%202024.xlsxfile:///\\srv-fichiers\Compta\Bilan 2024.xlsxLa variante à 5 slashes est aussi acceptée pour un chemin UNC.
Disque localfile:///D:/Projets/Outils/outil.exefile://D:\Projets\Outils\outil.exeTrois slashes après file:, puis la lettre de lecteur et des slashes.
Chemin avec accentsfile:///C:/Données/Réunions/Résumé%20janvier.docxfile:///C:/Données/Réunions/Résumé janvier.docxEncodez les espaces et caractères non ASCII (é → %C3%A9 si nécessaire).

IE Mode : quand l’utiliser et comment le configurer

Si votre intranet utilise déjà le mode Internet Explorer (IE Mode), vous pouvez autoriser l’accès aux fichiers locaux directement dans ce contexte, indépendamment du correctif, à l’aide des politiques suivantes :

  • InternetExplorerIntegrationSiteList : URL du fichier XML de votre Enterprise Mode Site List.
  • InternetExplorerIntegrationLocalFileAllowed : autorise les liens file:// en IE Mode.

Exemple minimal de déclaration dans la liste de sites (XML) :

<site-list version="1">
  <site url="http://intranet.contoso.local" open-in="IE11">
    <path url="/apps/dossiers" />
  </site>
</site-list>

Ajoutez ensuite la politique InternetExplorerIntegrationLocalFileAllowed et redémarrez Edge.

Points à écarter

La suppression de politiques HSTS pour localhost ou des manipulations similaires n’ont aucun lien avec le blocage des liens file:// en intranet et ne corrigent pas ce problème. Évitez aussi les modifications hasardeuses de drapeaux (edge://flags) en production.

Checklist opérationnelle (entreprise)

  1. Qualifier l’incident : confirmer le symptôme sur un poste témoin et documenter les URLs file:// en cause.
  2. Auditer les versions : identifier les machines en 121.0.2277.83.
  3. Choisir la voie : mise à jour vers 121.0.2277.106 (préféré) ou contournement (freeze + rétrograde en 120).
  4. Valider sur un périmètre pilote (portail intranet principal + applications LOB critiques).
  5. Déployer à large échelle, puis surveiller (tickets, sondes, métriques d’usage).
  6. Hygiène : contrôler IntranetFileLinksEnabled, l’origination intranet des pages, et la qualité des URL.

Modèles GPO et Registre (pour vérification rapide)

ObjetChemin/CléValeur attendueCommentaire
Autoriser les liens file:// depuis l’intranetHKLM\SOFTWARE\Policies\Microsoft\Edge\IntranetFileLinksEnabled (REG_DWORD)1 (Enabled)Contrôlable aussi côté utilisateur (HKCU) si vos modèles l’autorisent.
IE Mode : autoriser file://HKLM\SOFTWARE\Policies\Microsoft\Edge\InternetExplorerIntegrationLocalFileAllowed (REG_DWORD)1Nécessite aussi une liste de sites IE Mode.
IE Mode : liste de sitesHKLM\SOFTWARE\Policies\Microsoft\Edge\InternetExplorerIntegrationSiteList (REG_SZ)URL/chemin vers la XMLChemin réseau ou HTTP(S) interne accessible à tous.

Scénario de test minimal

Pour valider la correction (en pilote ou après déploiement), utilisez une page intranet avec un lien de test et vérifiez l’ouverture de l’Explorateur :

<!-- Page intranet de test -->
<p>Test lien vers un dossier partagé :</p>
<a href="file://srv-fichiers/Compta/Bilan%202024.xlsx">Ouvrir le bilan 2024</a>

Le clic doit ouvrir le dossier/fichier dans l’Explorateur. En cas d’échec, vérifiez le chemin (droits d’accès, disponibilité du partage), la syntaxe et la classification intranet de la page source.

FAQ

Est-ce que ce problème touche macOS ou Linux ?

Le cas décrit concerne Windows (avec ouverture de l’Explorateur et politiques GPO/ADMX associées). Les plateformes non Windows ont des comportements et politiques différents et ne sont généralement pas concernées par IntranetFileLinksEnabled.

Pourquoi faut‑il une exception spécifique pour l’intranet ?

Permettre à un site Internet d’ouvrir des fichiers locaux exposerait la machine à des risques majeurs. L’exception intranet part du principe que le contenu est contrôlé par l’organisation et que l’exposition est maîtrisée.

Est‑ce lié à HSTS (localhost, etc.) ?

Non. Les politiques HSTS, qu’elles ciblent localhost ou toute autre origine, n’ont aucun impact sur l’ouverture des liens file:// et ne résolvent pas le blocage observé.

Le correctif 121.0.2277.106 suffit‑il ?

Oui, il rétablit le comportement attendu des liens file:// en intranet. Il reste toutefois utile de valider vos GPO et la syntaxe de vos liens, et d’exécuter des tests de non‑régression sur les pages clés de votre intranet.

Peut‑on pousser un contournement côté application web ?

À défaut, fournissez aux utilisateurs le chemin UNC (\\serveur\partage\...) à copier/coller dans l’Explorateur. C’est moins ergonomique mais indépendant du navigateur.

Quid des environnements VDI/RDS ?

Le symptôme et la correction sont identiques. Vérifiez néanmoins que la résolution des partages (DNS/NetBIOS), les droits et la redirection de lecteurs sont en place côté session.

Bonnes pratiques d’ingénierie (prévenir les régressions)

  • Tests de fumée après chaque mise à jour Edge : scénarios critiques (ouverture de file://, SSO, formulaires, modules ActiveX via IE Mode).
  • Anneaux de déploiement : pilote → large → généralisation.
  • Télémétrie : scripts qui vérifient la version d’Edge et remontent les écarts.
  • Documentation : page interne référençant les syntaxes file:// validées, exemples et anti‑patrons.

Plan d’action recommandé

  1. Vérifier la version dans edge://settings/help.
  2. Si vous êtes en 121.0.2277.83, mettre à jour vers 121.0.2277.106 (ou plus).
  3. Si la MAJ est bloquée, geler les updates et rétrograder en 120 via MSI + ALLOWDOWNGRADE=1.
  4. Confirmer la stratégie et la syntaxe des liens, puis retester.

Annexe A — Scripts utiles

Inventaire des versions Edge sur un parc (exemple)

# Exemple: lister la version Edge pour une liste de machines (WinRM/PSRemoting requis)
$computers = Get-Content .\parc.txt
$results = foreach ($c in $computers) {
  try {
    Invoke-Command -ComputerName $c -ScriptBlock {
      $path = "${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe"
      if (-not (Test-Path $path)) { $path = "${env:ProgramFiles}\Microsoft\Edge\Application\msedge.exe" }
      if (Test-Path $path) {
        [PSCustomObject]@{
          ComputerName = $env:COMPUTERNAME
          EdgeVersion  = (Get-Item $path).VersionInfo.ProductVersion
        }
      } else {
        [PSCustomObject]@{ ComputerName = $env:COMPUTERNAME; EdgeVersion = "Non installé" }
      }
    }
  } catch {
    [PSCustomObject]@{ ComputerName = $c; EdgeVersion = "Injoignable" }
  }
}
$results | Sort-Object EdgeVersion, ComputerName | Format-Table -AutoSize

Annexe B — Anti‑patrons à éviter

  • Insérer des backslashes (\) dans les URL : utilisez des slashes (/).
  • Laisser des espaces non encodés dans l’URL : remplacez par %20.
  • Compter sur des hacks (suppression HSTS, flags expérimentaux) au lieu d’un correctif.
  • Oublier de vérifier que la page source est bien intranet (l’exception ne s’applique pas sur Internet).

Conclusion

Le blocage des liens file:// en intranet après Edge 121.0.2277.83 est bien une régression côté navigateur. La mise à jour vers 121.0.2277.106 rétablit le fonctionnement normal pour les organisations s’appuyant sur IntranetFileLinksEnabled. En parallèle, maintenez de bonnes pratiques : contrôlez vos GPO, vérifiez la classification intranet des pages et durcissez la qualité des URL file://. Ce triptyque (correctif + gouvernance + hygiène) garantit la continuité d’usage et la sécurité de vos postes.

Edge
Sommaire