AnyConnect skriver över din profil? Det är en namnkollision
Två gateways, ett filnamn: klienten behåller den senaste profilen i din mapp medan biblioteket är maskinvitt. Byt namn på kopiorna för att behålla båda.
Historien som cirkulerar är att AnyConnect tappade din andra gateway, eller att klienten är för gammal för att hålla två profiler. Inget av det hände. Det som hände är att klienten sparar varje profil den har sett som en fil som namnges efter det servern skickade, och dina två gateways kallar sin fil samma sak. Det finns en plats på disken för det namnet, så den andra nedladdningen tar den förstas plats.
Två mappar, och bara en av dem är din
Kopian som ändras är arbetskopian under din egen användarprofil, vanligtvis %LOCALAPPDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\preferences.xml. Den filen registrerar den senaste anslutningen du gjorde och vilken profil den använde. Eftersom den ligger i din mapp skriver klienten om den vid varje anslutning utan att begära förhöjda rättigheter.
Listan du ser i rullgardinsmenyn är något annat. Varje profil som maskinen någonsin har tagit emot kopieras till %PROGRAMDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile, och klienten listar de filer som ligger där. Att skriva till den mappen kräver administratörsrättigheter, vilket förklarar ett symptom som folk läser fel: att lägga till en profil manuellt som vanlig användare verkar fungera, och sedan försvinner posten.
Så filen per användare är en pekare och mappen för hela maskinen är biblioteket. En saknad post betyder att biblioteket ändrades, inte pekaren.
Klienten matchar filer efter namn, inte efter gateway
Profilidentiteten i den här klienten är filnamnet. Två enheter som båda skickar company.xml är, ur det lokala profillagrets synvinkel, samma profil publicerad två gånger. Den andra nedladdningen skriver över den första, och posten i fönstret pekar fortfarande på en fil som nu beskriver den andra platsen.
Därför ser felet så märkligt ut. Namnet i listan läses fortfarande som platsen du förväntar dig, autentiseringen lyckas fortfarande mot den gateway som faktiskt är konfigurerad, och ingenting rapporterar ett fel. Det som ändrades är innehållet bakom en etikett du litade på.
Läs HostAddress, inte etiketten
Öppna filen i en textredigerare och titta på serverlistan. En profil har ett HostName-element, som är en visningsetikett, och ett HostAddress-element, som är den gateway klienten faktiskt kontaktar. Etiketten är fri text som vem som helst kan redigera, och adressen avgör var du hamnar.
Jämför de två med den gateway du ville nå innan du drar slutsatsen att klienten är trasig.
Behålla båda gatewayerna, i ordning
Skaffa den godkända profilen för varje plats, antingen från platsen eller från en maskin som redan ansluter. Byt namn på varje fil så att de två namnen skiljer sig, till exempel site-a.xml och site-b.xml. Lägg båda i profilmappen för hela maskinen som administratör och spara originalen du fick. Starta sedan om klienten och bekräfta att båda posterna visas i rullgardinsmenyn.
När du har anslutit till var och en, öppna preferences.xml igen och kontrollera vilket profilnamn den nu registrerar som senast använd. Om namnet stämmer med posten du klickade på beter sig den lokala mappningen korrekt. Om inte, skjuter något fortfarande en fil över din omdöpta kopia.
Vad omdöpning inte åtgärdar
Ett nytt filnamn ändrar en lokal etikett och ingenting annat. Gatewayadressen, autentiseringsmetoden, certifikatet servern visar och alla gruppval inuti profilen förblir som de var. En omdöpt kopia av fel profil är fortfarande fel profil, och den ansluter dig till fel plats under ett övertygande namn.
Den överlever inte heller en hanteringspush som riktar sig mot det ursprungliga filnamnet.
När nästa push gör om det
Om din organisation distribuerar profiler efter namn ersätter en uppdatering varje fil som delar det namnet. Behandla de omdöpta kopiorna som en lokal bekvämlighet och upprepa anslutningstestet efter varje klientuppdatering, och kontrollera adressen och inte etiketten.
För en varaktig lösning, be om en supportad multi-gateway-konfiguration i stället för att underhålla filer manuellt. Ändringar i programmappen är det första en uppgradering tar bort, och filen med användarinställningar skrivs om enligt design.
Håll en rad per gateway: filnamn, HostAddress och vilken mapp den ligger i. Den anteckningen svarar på nästa rapport om fel plats snabbare än en ominstallation.