AnyConnect Overwrites Your Profile? It Is a Name Collision

The story going around is that AnyConnect lost your second gateway, or that the client is too old to hold two profiles. Neither is what happened. What happened is that the client stores every profile it has seen as a file named after what the server sent, and your two gateways both call their file the same thing. There is one slot on disk for that name, so the second download takes the slot from the first.

Two folders, and only one of them is yours

The copy that keeps changing is the working copy under your own user profile, normally %LOCALAPPDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\preferences.xml. That file records the last connection you made and which profile it used. Because it lives in your folder, the client rewrites it on every connect without asking for elevation.

The list you see in the drop-down is a different thing. Every profile the machine has ever received is copied into %PROGRAMDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile, and the client lists whatever files sit there. Writing to that folder needs administrator rights, which explains a symptom people misread: adding a profile by hand as a normal user appears to work, then the entry vanishes.

So the per-user file is a pointer and the machine-wide folder is the library. A missing entry means the library changed, not the pointer.

The client matches files by name, not by gateway

Profile identity in this client is the file name. Two appliances that both push company.xml are, as far as the local profile store is concerned, the same profile published twice. The second download overwrites the first, and the entry in the window keeps pointing at one file that now describes the other site.

That is why the failure looks so strange. The name in the list still reads like the place you expect, authentication still succeeds against whichever gateway is actually configured, and nothing reports an error. What changed is the content behind a label you trusted.

Read HostAddress, not the label

Open the file in a text editor and look at the server list. A profile carries a HostName element, which is a display label, and a HostAddress element, which is the gateway the client actually contacts. The label is free text that anyone can edit, and the address is what decides where you land.

Compare those two against the gateway you meant to reach before concluding the client is broken.

Keeping both gateways, in order

Get the accepted profile for each site, either from the site or from a machine that already connects. Rename each file so the two names differ, for example site-a.xml and site-b.xml. As an administrator, place both in the machine-wide profile folder and keep the originals you received. Then restart the client and confirm both entries appear in the drop-down.

After connecting to each one, reopen preferences.xml and check which profile name it now records as last used. If the name matches the entry you clicked, the local mapping is behaving. If it does not, something is still pushing a file over your renamed copy.

What renaming does not fix

A new file name changes a local label and nothing else. The gateway address, the authentication method, the certificate the server presents and any group selection inside the profile all stay as they were. A renamed copy of the wrong profile is still the wrong profile, and it will connect you to the wrong site under a convincing name.

It also does not survive a management push that targets the original file name.

When the next push undoes it

If your organisation distributes profiles by name, an update replaces any file that shares that name. Treat the renamed copies as a local convenience and re-run the connect test after each client update, checking the address rather than the label.

For a permanent arrangement, ask for a supported multi-gateway setup instead of maintaining files by hand. Edits inside the program directory are the first thing an upgrade removes, and the per-user preferences file is rewritten by design.

Keep one line per gateway: file name, HostAddress, and which folder it lives in. That note answers the next wrong-site report faster than a reinstall does.