AnyConnect-Fehler „Verbindungssubsystem konnte nicht initialisiert werden“ beheben

Sie klicken auf Verbinden, und der Dialog antwortet fast sofort: Verbindungssubsystem konnte nicht initialisiert werden. Nichts hat das Gateway erreicht, also gibt es keinen Zertifikatsaustausch, keine Anmeldedaten und keine Tunnelgruppenauswahl auf der Gegenseite. Das bedeutet, die Logs des Concentrators zeigen eine leere Sitzung, und der Helpdesk bittet um einen Screenshot eines Dialogs, der nie etwas Nützliches enthielt. Arbeiten Sie stattdessen den Endpunkt in fester Reihenfolge ab und halten Sie beim ersten Schritt an, der das Ergebnis ändert.

Der Zeitpunkt ist der wertvollste Beweis, den Sie haben, und es kostet nichts, ihn festzuhalten. Notieren Sie, ob der Fehler vor oder nach der Anmeldeaufforderung erschien und ob er nach einem Upgrade, einem Windows-Update oder einem neuen Sicherheitsagenten begann. Diese drei Antworten halbieren die Kandidatenliste meist, bevor Sie eine Einstellung anfassen.

Lesen Sie den Zeitpunkt, bevor Sie etwas ändern

Drei Fehlerstellen sehen ähnlich aus und sind es nicht. Erscheint der Dialog in dem Moment, in dem Sie Verbinden drücken, konnte der Client seine eigene Infrastruktur nicht starten, und genau darauf deutet diese Meldung hin. Erscheint er, nachdem Sie Anmeldedaten eingegeben haben, wurde die Tunnelgruppe erreicht, und das Problem liegt weiter hinten. Kommt der Tunnel hoch und fällt dann, wurde das Subsystem sauber initialisiert, und Sie jagen einem ganz anderen Fehler hinterher. Die drei zu verwechseln kostet einen Nachmittag mit Neuinstallationen, die nicht helfen können.

Nur der erste Fall gehört hierher. Die Meldung entsteht, bevor irgendeine Netzwerkentscheidung getroffen wird, also lösen eine falsche Gateway-Adresse, ein abgelaufenes Zertifikat oder ein schlechtes Passwort sie nicht aus.

Schritt 1: Prüfen, ob der Agent-Dienst läuft

Das Fenster, auf das Sie klicken, ist eine Oberfläche; die Arbeit findet im Dienst Cisco AnyConnect Secure Mobility Agent statt, der als vpnagent registriert ist. Ist dieser Dienst gestoppt oder deaktiviert, hat die GUI nichts, mit dem sie sprechen kann und meldet genau diesen Initialisierungsfehler. Prüfen Sie Zustand und Starttyp in einer PowerShell-Eingabeaufforderung mit erhöhten Rechten:

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

Ein Installationsprogramm, das einen zuvor manuell gesetzten Starttyp respektiert hat, ist der übliche Grund, warum das deaktiviert endet, prüfen Sie also StartType statt nur Start zu drücken. Startet und stoppt der Dienst binnen Sekunden, lesen Sie im Systemprotokoll die Einträge des Service Control Manager, bevor Sie auf Reparieren klicken:

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

Ein blockierter Treiber, eine in Quarantäne verschobene Datei oder ein Filtertreiber eines Sicherheitsprodukts von Drittanbietern nennt sich in diesen Ereignissen selbst. Reparieren installiert über dieselbe blockierte Datei und ändert nichts, deshalb kommt das Ereignisprotokoll zuerst.

Schritt 2: Den Offline-Zustand löschen, den der HTTP-Stack meldet

Der Client lädt sein Profil herunter und bewertet Richtlinien über Windows-HTTP-Komponenten, daher kann ein in den Internetoptionen des Benutzers gesetztes Offline-Flag die Initialisierung brechen, während jeder Browser weiter Seiten lädt. Prüfen Sie den Wert direkt:

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

Ein Wert von 1 bedeutet, dass der WinINet-Stack Aufrufern mitteilt, der Rechner habe keine Verbindung; dieser Zustand wird normalerweise über den Menüpunkt Offline arbeiten im Internet Explorer oder durch ein Automatisierungsskript gesetzt. Setzen Sie ihn zurück auf 0, melden Sie sich ab und wieder an und versuchen Sie die Verbindung erneut, bevor Sie etwas anderes ändern.

Wenn Sie diesen Rechner geerbt haben und nicht sagen können, warum das Flag gesetzt wurde, notieren Sie es im Ticket. Etwas anderes auf dem Rechner kann es absichtlich gesetzt haben, und es kommt bei der nächsten Anmeldung zurück.

Schritt 3: Den virtuellen Adapter von Hyper-V oder ICS befreien

Zwei Windows-Rollen können die Teile halten, die der Client zum Erstellen seines Adapters braucht. Hyper-V ist die erste: Laufen die Dienste des virtuellen Switches, kann die Adaptererstellung auf Arten fehlschlagen, die sich als dieser Fehler zeigen. Die Dienste zu stoppen ist eine Diagnose, keine Lösung:

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

Verbindet der Client bei gestoppten Diensten, ist der Konflikt bestätigt, und Sie wissen nun, worüber Sie mit dem Eigentümer des Hyper-V-Hosts verhandeln müssen. Starten Sie sie danach wieder, es sei denn, der Rechner braucht keine Virtualisierung mehr.

Internetverbindungsfreigabe ist der zweite Besitzer. Wird eine Verbindung freigegeben, kann der Client fehlschlagen, bevor er überhaupt einen Tunnel aufbaut. Prüfen Sie mit Get-Service SharedAccess und sehen Sie, falls sie läuft und auf automatisch steht, die Adapter nach einer freigegebenen Verbindung durch und schalten Sie die Freigabe nur auf diesem Adapter ab.

Es gibt auch eine billigere Erklärung, die zuerst auszuschließen ist. Ein Rechner ohne funktionierenden Internetzugang zeigt oft diese Meldung statt eines Erreichbarkeitsfehlers, prüfen Sie also, ob Test-NetConnection zur Gateway-Adresse und zu einem öffentlichen Host beide erfolgreich sind, bevor Sie den Client beschuldigen.

Prüfen, dann zurückrollen, was Sie nicht brauchten

Verifikation ist nicht das grüne Schild im Infobereich. Bestätigen Sie, dass der Adapter existiert, eine Adresse hat und Verkehr durchlässt: Get-NetAdapter -Name "Cisco AnyConnect*" sollte ihn als aktiv zeigen, ipconfig /all sollte die zugewiesene Adresse und die DNS-Server zeigen, und eine echte Anfrage an einen internen Namen sollte über den Tunnel statt über den lokalen Resolver aufgelöst werden.

Führen Sie eine kurze Liste jeder Änderung, mit dem gefundenen und dem gesetzten Wert. Funktioniert die Verbindung nach Schritt drei, stellen Sie die Hyper-V-Dienste wieder her und testen erneut, bevor Sie das Ticket schließen, denn eine Problemumgehung, die still die Virtualisierung abschaltet, wird vom nächsten Administrator, der es bemerkt, rückgängig gemacht.

Bewegt keiner der drei Schritte den Fehler, hören Sie auf, den Endpunkt zu ändern. Sammeln Sie Clientversion, Dienstzustand, den Zeitpunkt oben auf dieser Seite und das Diagnosepaket, das der Client erzeugen kann, und übergeben Sie diese mit der genauen Reihenfolge, die Sie versucht haben. Dieses Paket ist für den nächsten Techniker mehr wert als ein Screenshot des Dialogs, und es ist das einzige Artefakt, das zeigt, ob das Subsystem vor oder nach dem Kontakt mit dem Netzwerk fehlschlug.