Du klickar på Anslut och dialogrutan svarar nästan direkt: det gick inte att initiera anslutningsdelsystemet. Inget nådde gatewayen, så det finns ingen certifikatutväxling, inga inloggningsuppgifter och inget val av tunnelgrupp i andra änden. Det betyder att koncentratorns loggar visar en tom session och att supporten ber om en skärmbild av en dialog som aldrig innehöll något användbart. Arbeta med slutpunkten i stället, i fast ordning, och stanna vid det första steget som ändrar resultatet.

Tidpunkten är det mest värdefulla beviset du har, och det kostar inget att anteckna den. Skriv ner om felet kom före eller efter inloggningsbegäran, och om det började efter en uppgradering, en Windows-uppdatering eller en ny säkerhetsagent. De tre svaren halverar vanligtvis kandidatlistan innan du rör en inställning.

Läs tidpunkten innan du ändrar något

Tre felpunkter ser likadana ut och är det inte. Om dialogen visas i samma ögonblick som du trycker på Anslut kunde klienten inte starta sin egen infrastruktur, och det är vad det här meddelandet pekar på. Om den visas efter att du skrivit inloggningsuppgifter har tunnelgruppen nåtts och problemet ligger längre fram. Om tunneln kommer upp och sedan faller initierades delsystemet korrekt och du jagar en helt annan bugg. Att blanda ihop de tre slösar bort en eftermiddag på ominstallationer som inte kan hjälpa.

Bara det första fallet hör hit. Meddelandet skapas innan något nätverksbeslut fattas, så en felaktig gatewayadress, ett utgånget certifikat eller ett dåligt lösenord skapar det inte.

Steg 1: bekräfta att agenttjänsten körs

Fönstret du klickar på är bara en frontend; arbetet sker i tjänsten Cisco AnyConnect Secure Mobility Agent, registrerad som vpnagent. Om den tjänsten är stoppad eller inaktiverad, har gränssnittet inget att prata med och rapporterar exakt det här initieringsfelet. Kontrollera status och starttyp från en förhöjd PowerShell-prompt:

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

Ett installationsprogram som respekterade en tidigare manuellt inställd starttyp är den vanliga orsaken till att detta slutar inaktiverat, så kontrollera StartType i stället för att bara trycka på Start. Om tjänsten startar och stoppar inom sekunder läser du System-loggen efter Service Control Manager-poster innan du klickar på Reparera:

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

En blockerad drivrutin, en fil i karantän eller en filterdrivrutin från en säkerhetsprodukt från tredje part namnger sig själv i dessa händelser. Reparera installerar om över samma blockerade fil och ändrar ingenting, därför kommer händelseloggen först.

Steg 2: rensa offlineläget som HTTP-stacken rapporterar

Klienten laddar ner sin profil och utvärderar policy via Windows HTTP-komponenter, så en offlineflagga i användarens internetinställningar kan bryta initieringen medan varje webbläsare fortfarande laddar sidor. Kontrollera värdet direkt:

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

Ett värde på 1 betyder att WinINet-stacken säger till anropare att datorn inte har någon anslutning; detta tillstånd sätts vanligtvis av menyalternativet Arbeta offline i Internet Explorer eller av ett automatiseringsskript. Ställ tillbaka det till 0, logga ut och in igen och försök med anslutningen på nytt innan du ändrar något annat.

Om du har ärvt den här datorn och inte kan säga varför flaggan sattes, anteckna det i ärendet. Något annat på datorn kan ha satt den med avsikt, och den kommer tillbaka vid nästa inloggning.

Steg 3: frigör den virtuella adaptern från Hyper-V eller ICS

Två Windows-roller kan hålla delarna som klienten behöver för att skapa sin adapter. Hyper-V är den första: när tjänsterna för den virtuella växeln körs kan skapandet av adaptern misslyckas på sätt som visar sig som det här felet. Att stoppa tjänsterna är en diagnos, inte en åtgärd:

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

Om klienten ansluter med dessa tjänster stoppade är konflikten bekräftad och nu vet du vad du ska förhandla om med ägaren till Hyper-V-värden. Starta dem efteråt igen, om inte datorn inte längre behöver virtualisering.

Delning av internetanslutning är den andra ägaren. Om en anslutning delas kan klienten misslyckas innan den ens skapar en tunnel. Bekräfta med Get-Service SharedAccess och, om den körs och är inställd på automatiskt, gå igenom adaptrarna efter en delad anslutning och slå av delning bara på den adaptern.

Det finns också en billigare förklaring att utesluta först. En dator utan någon fungerande internetåtkomst visar ofta det här meddelandet i stället för ett nåbarhetsfel, så bekräfta att Test-NetConnection till gatewayadressen och till en offentlig värd lyckas båda innan du skyller på klienten.

Verifiera och rulla sedan tillbaka det du inte behövde

Verifiering är inte den gröna skölden i aktivitetsfältet. Bekräfta att adaptern finns, har en adress och släpper igenom trafik: Get-NetAdapter -Name "Cisco AnyConnect*" bör visa den uppe, ipconfig /all bör visa den tilldelade adressen och DNS-servrarna, och en riktig begäran till ett internt namn bör lösas via tunneln och inte via den lokala resolvern.

Håll en kort lista över varje ändring, med värdet du hittade och värdet du satte. Om anslutningen fungerar efter steg tre återställer du Hyper-V-tjänsterna och testar igen innan du stänger ärendet, eftersom en tillfällig lösning som tyst inaktiverar virtualisering rullas tillbaka av nästa administratör som märker det.

Om inget av de tre stegen flyttar felet slutar du ändra slutpunkten. Samla in klientversionen, tjänstens status, tidpunkten högst upp på den här sidan och det diagnostikpaket som klienten kan skapa, och lämna över dem med den exakta ordning du provade. Det paketet är värt mer för nästa tekniker än en skärmbild av dialogen, och det är den enda artefakt som visar om delsystemet misslyckades före eller efter att det rörde nätverket.

Relaterade artiklar