Corriger l'erreur AnyConnect « échec d'initialisation du sous-système de connexion »

Vous cliquez sur Connexion et la boîte de dialogue répond presque instantanément : échec d'initialisation du sous-système de connexion. Rien n'a atteint la passerelle, donc pas d'échange de certificat, pas d'identifiant et pas de sélection de groupe de tunnel à l'autre bout. Cela signifie que les journaux du concentrateur afficheront une session vide et que l'assistance demandera une capture d'écran d'une boîte qui n'a jamais rien contenu d'utile. Travaillez plutôt le poste, dans un ordre fixe, et arrêtez-vous à la première étape qui change le résultat.

Le moment est la preuve la plus précieuse dont vous disposez, et le noter ne coûte rien. Notez si l'erreur est apparue avant ou après l'invite d'identification, et si elle a commencé après une mise à niveau, une mise à jour Windows ou un nouvel agent de sécurité. Ces trois réponses réduisent généralement la liste des candidats de moitié avant que vous ne touchiez à un réglage.

Lisez le moment avant de changer quoi que ce soit

Trois points de défaillance se ressemblent et ne sont pas identiques. Si la boîte apparaît à l'instant où vous pressez Connexion, le client n'a pas pu démarrer sa propre infrastructure, et c'est ce qu'indique ce message. Si elle apparaît après la saisie des identifiants, le groupe de tunnel a été atteint et le problème est plus loin. Si le tunnel monte puis tombe, le sous-système s'est bien initialisé et vous courez après un tout autre défaut. Confondre les trois fait perdre un après-midi en réinstallations qui ne peuvent pas aider.

Seul le premier cas appartient ici. Le message est généré avant toute décision réseau, donc une mauvaise adresse de passerelle, un certificat expiré ou un mot de passe erroné ne le produiront pas.

Étape 1 : vérifier que le service de l'agent est en cours d'exécution

La fenêtre sur laquelle vous cliquez n'est qu'une façade ; le travail se fait dans le service Cisco AnyConnect Secure Mobility Agent, enregistré sous le nom vpnagent. Si ce service est arrêté ou désactivé, l'interface graphique n'a rien à qui parler et signale exactement cet échec d'initialisation. Vérifiez l'état et le type de démarrage depuis une invite PowerShell élevée :

Get-Service vpnagent | Select-Object Name, Status, StartType
sc.exe qc vpnagent
net start vpnagent

Un programme d'installation qui a respecté un type de démarrage précédemment manuel est la raison habituelle de cette désactivation, vérifiez donc StartType plutôt que de simplement appuyer sur Démarrer. Si le service démarre et s'arrête en quelques secondes, lisez le journal Système pour les entrées du Service Control Manager avant de cliquer sur Réparer :

Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"} -MaxEvents 40

Un pilote bloqué, un fichier mis en quarantaine ou un pilote de filtre d'un produit de sécurité tiers se nommera dans ces événements. Réparer réinstalle par-dessus le même fichier bloqué et ne change rien, c'est pourquoi le journal des événements vient en premier.

Étape 2 : effacer l'état hors connexion signalé par la pile HTTP

Le client télécharge son profil et évalue la stratégie via les composants HTTP de Windows, donc un indicateur hors connexion défini dans les paramètres Internet de l'utilisateur peut casser l'initialisation alors que tous les navigateurs continuent de charger des pages. Vérifiez la valeur directement :

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name GlobalUserOffline

Une valeur de 1 signifie que la pile WinINet indique aux appelants que la machine n'a aucune connexion ; cet état est normalement défini par l'entrée de menu Travailler hors connexion d'Internet Explorer ou par un script d'automatisation. Remettez-la à 0, déconnectez-vous et reconnectez-vous, puis réessayez la connexion avant de changer quoi que ce soit d'autre.

Si vous avez hérité de cette machine et ne pouvez pas dire pourquoi l'indicateur a été défini, notez-le dans le ticket. Autre chose sur la machine a pu le définir volontairement, et il reviendra à la prochaine ouverture de session.

Étape 3 : libérer l'adaptateur virtuel d'Hyper-V ou d'ICS

Deux rôles Windows peuvent retenir les pièces dont le client a besoin pour créer son adaptateur. Hyper-V est le premier : lorsque les services du commutateur virtuel tournent, la création de l'adaptateur peut échouer de façon à se manifester par cette erreur. Arrêter les services est un diagnostic, pas un correctif :

Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"

Si le client se connecte avec ces services arrêtés, le conflit est confirmé et vous savez maintenant quoi négocier avec le propriétaire de l'hôte Hyper-V. Redémarrez-les ensuite, sauf si la machine n'a plus besoin de virtualisation.

Le partage de connexion Internet est le second propriétaire. Si une connexion est partagée, le client peut échouer avant même de créer un tunnel. Confirmez avec Get-Service SharedAccess et, s'il est en cours d'exécution et réglé sur automatique, parcourez les adaptateurs à la recherche d'une connexion partagée et désactivez le partage sur cet adaptateur uniquement.

Il existe aussi une explication moins coûteuse à écarter d'abord. Une machine sans aucun accès Internet fonctionnel affiche souvent ce message au lieu d'une erreur de joignabilité, alors confirmez que Test-NetConnection vers l'adresse de la passerelle et vers un hôte public réussissent tous deux avant d'accuser le client.

Vérifiez, puis annulez ce qui n'était pas nécessaire

La vérification n'est pas le bouclier vert de la barre d'état. Confirmez que l'adaptateur existe, porte une adresse et fait passer le trafic : Get-NetAdapter -Name "Cisco AnyConnect*" devrait le montrer actif, ipconfig /all devrait afficher l'adresse attribuée et les serveurs DNS, et une vraie requête vers un nom interne devrait se résoudre par le tunnel plutôt que par le résolveur local.

Tenez une courte liste de chaque modification, avec la valeur trouvée et la valeur définie. Si la connexion fonctionne après la troisième étape, restaurez les services Hyper-V et retestez avant de fermer le ticket, car un contournement qui désactive discrètement la virtualisation sera annulé par le prochain administrateur qui le remarquera.

Si aucune des trois étapes ne déplace l'erreur, cessez de modifier le poste. Rassemblez la version du client, l'état du service, le moment indiqué en haut de cette page et le paquet de diagnostic que le client peut produire, puis transmettez-les avec l'ordre exact que vous avez essayé. Ce paquet vaut plus pour l'ingénieur suivant qu'une capture de la boîte de dialogue, et c'est le seul artefact qui montre si le sous-système a échoué avant ou après avoir touché le réseau.