Pourquoi les utilisateurs désactivent Always On et pourquoi le profil le maintient désactivé

Un utilisateur décoche Connexion automatique, et le profil cesse de se connecter. Des mois plus tard, l’équipe de déploiement livre un profil mis à jour portant le même nom, s’attend à voir le déclencheur revenir, et il ne revient pas. La raison est que le choix n’a jamais été uniquement dans le profil : Windows a enregistré la décision de l’utilisateur associée à ce nom de profil dans son propre état, et une réinstallation ne l’efface pas. Le fichier de profil n’est que la moitié de la configuration.

Ce que la case à cocher écrit réellement

Décocher l’option de connexion automatique est une décision par appareil stockée hors du XML du profil. Microsoft la documente comme une liste de noms de profils dont le déclencheur automatique est désactivé, ce qui explique pourquoi le réglage survit à la suppression puis au rajout du profil.

Cette conception a du sens du point de vue de l’utilisateur. Quelqu’un sur une connexion à forfait limité qui désactive la connexion automatique ne s’attend pas à ce que la prochaine actualisation de la stratégie la réactive en silence.

Cela signifie aussi que le nom du profil est une identité, pas une étiquette. Deux profils portant le même nom sont la même entrée pour cette liste, et un renommage crée une nouvelle identité sans aucune préférence stockée.

Pourquoi réinstaller le profil ne le réinitialise pas

Supprimer une connexion VPN et la rajouter depuis un fichier mis à jour supprime et recrée l’objet profil. Cela ne supprime pas l’enregistrement de la décision de l’utilisateur, car cet enregistrement est indexé par le nom et non par l’identifiant interne du profil.

La mise à jour arrive donc, le profil est présent et correctement configuré, et le déclencheur ne se déclenche toujours pas. Rien dans le profil ne l’explique, et c’est pourquoi cela est escaladé comme un déploiement cassé.

Le même comportement peut être utilisé délibérément : gardez le nom du profil stable lorsque la mise à jour doit conserver la même connexion, et ne le changez que lorsque vous voulez repartir de zéro. Renommer pour échapper à une préférence stockée fonctionne, et laisse aussi l’ancienne entrée derrière, si bien que l’appareil accumule des noms qui ne correspondent plus à rien.

Décidez lequel des deux vous voulez avant de toucher au XML, car le nom est l’interrupteur.

Un profil actif, plusieurs éligibles

Windows applique les déclencheurs automatiques à un ensemble limité de profils, et le fait d’avoir plusieurs profils éligibles ne les fait pas tous se connecter comme des valeurs par défaut concurrentes. Un seul est actif, et les autres attendent.

Cela compte lorsqu’un appareil reçoit à la fois un profil de portée utilisateur et un profil de portée appareil aux noms similaires. Ce ne sont pas la même connexion, et celui qui se connecte automatiquement est celui qu’ont choisi les règles de sélection, pas nécessairement celui que vous avez testé. Un test réussi sur l’autre profil ne prouve rien sur le déclencheur. Notez quel profil a répondu avant de changer quoi que ce soit.

Lisez l’état stocké avant une mise à jour

Avant de livrer un quelconque changement de profil, regardez ce que l’appareil détient actuellement : l’objet de connexion, son état et la liste stockée des déclencheurs automatiques désactivés.

Ces commandes listent les connexions VPN et recherchent dans le registre la valeur documentée :

Get-VpnConnection | Select-Object Name,ConnectionStatus,SplitTunneling
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Network /s /f AutoTriggerDisabledProfilesList

Une entrée correspondant au profil que vous êtes sur le point de déployer vous indique que le choix de l’utilisateur est déjà enregistré. Ce n’est pas un défaut à corriger en silence ; c’est l’état dont votre stratégie doit tenir compte.

Décidez de la stratégie que vous voulez

Il existe deux stratégies défendables et une mauvaise habitude. La première respecte le refus d’un utilisateur tant que l’utilisateur ne le change pas, et documente que le déclencheur est indicatif sur les appareils gérés. La seconde traite la connexion automatique comme une exigence de conformité, et alors le refus ne devrait pas être proposé du tout.

La mauvaise habitude consiste à réécrire un état sans rapport pour forcer le déclencheur à revenir, ce qui fonctionne jusqu’à la prochaine actualisation et laisse l’appareil avec des réglages que personne ne peut expliquer.

Consignez le choix là où le profil est maintenu, avec les quatre transitions qu’il vaut la peine d’examiner : le premier provisionnement, un déclencheur normal, un changement autorisé de l’utilisateur et une mise à jour vers le même nom. L’automatisation, la portée de routage et l’application de l’état déconnecté sont des contrôles distincts, et le libellé Always On ne garantit aucun d’entre eux.