Mapped drive fails with 0x800704C3: multiple connections to one server

Fix it now

0x800704C3 is Win32 1219, and its published text tells you both the cause and the fix: multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed – disconnect all previous connections and try again. Nothing is wrong on the server.

net use
net use * /delete /y
net use \\server\ipc$ /delete
net use Z: \\server\share /user:DOMAIN\username *

1. Read net use first and note the user name shown against the server you are trying to reach. That is the identity currently holding the connection.
2. If a connection survives after the bulk delete, it is the administrative IPC one, which browsing the server in Explorer creates and which has no drive letter. The third command removes it.
3. Open Credential Manager (Control Panel, User Accounts, Credential Manager, Windows Credentials) and delete any stored entry naming that server, in every name form it appears under.
4. Map once with the identity you actually want, and type the password when prompted rather than letting a stored one be replayed.
5. If it still refuses, sign out and back in. Something inside your logon session is holding a connection the command line will not show you.

net use * /delete disconnects every mapped drive on the machine, including ones other applications are using. Anything with an open file on a share loses its handle, so save your work and warn anyone running a line-of-business application that maps drives at startup.

If the drive maps under the account you wanted, you are done. If it comes back at the next logon, the next section covers what recreates it.

Why it happens

The redirector keeps a table of the servers your logon session is connected to and the credentials used for each, and that table permits one credential set per server. When you ask for a second, Windows cannot quietly drop the first, because other processes may depend on it, so it refuses the request. Microsoft’s published text for Win32 1219 says exactly that, and it also gives the remedy: disconnect all previous connections to the server or shared resource and try again.

The table is keyed on the name you used rather than on the machine behind it. In practice that means the short name, the fully qualified name and the address behave as separate entries, which is how people discover by accident that mapping one drive by name and another by address works. It does work, and it is used widely. Treat it as a workaround rather than a design: it depends on a name form that cannot be matched against a service principal name, so it drops to NTLM, and anywhere NTLM is restricted it stops.

The other invisible participant is the administrative IPC connection. Browsing to a server in Explorer, or a management tool querying it, opens one. It carries credentials exactly as a mapped drive does, it has no drive letter, and it is the usual reason a mapping still fails after you have deleted everything visible.

Full reference

Telling the four codes apart

Those four look similar in a dialog and mean quite different things. 1219 is the identity conflict this article is about. 85 is a drive letter clash and has nothing to do with credentials. 67 means the share name does not exist on that server, which is usually a rename or a typo. 1222 means the client has no working network at that moment, so nothing else in this article applies.

Where connections hide

When it comes back at every logon

Clearing the table fixes the moment. It does not fix whatever recreates the conflicting connection, and if the error returns each morning something is putting it back. In order of likelihood: a Group Policy drive map, a logon script, a shortcut in the Startup folder, a scheduled task set to run at logon, and a backup or sync agent configured with its own credentials.

1. Sign in, and before doing anything else run net use and note what is already there. That list is what was created for you automatically.
2. Anything present at that point came from policy, a script or a startup item, not from you.
3. Fix it where it is defined rather than deleting it each day.
4. If the mapping has to exist under a different account, ask whether it should be a mapping at all – a scheduled task can authenticate on its own without holding a session for your whole logon.

The two-identity problem, honestly

• Windows is not going to let one logon session hold two identities against one server name. That is the design, not a bug to route around.
• Reaching the server by a second name works because the table is keyed on the name. It is fragile and it will stop where NTLM is restricted.
• The supportable answer where two identities are genuinely needed is a second session: a separate Windows sign-in, a Remote Desktop session, or running the tool that needs the second identity under that account.
• For scripted work, authenticate inside the task rather than mapping a drive for the whole logon.

Both remedies in this article are disruptive in their own way. net use * /delete cuts every mapped drive on the machine including other people’s applications, and EnableLinkedConnections changes how elevated and standard contexts relate for everything on the machine. Neither is a change to make quietly on somebody else’s PC.

Every code this article covers

Confirm the fix worked

1. Run net use and confirm exactly one entry for that server, with the user name you intended.
2. Open the mapped drive and create a test file, proving the credential carries write access.
3. Sign out and back in, then check the mapping reconnects without prompting or erroring.
4. Run Get-SmbConnection and confirm no second connection to the same server has reappeared.
5. If a policy or script was recreating it, confirm the change there rather than on the client.

Questions people ask about this