How long does an idle UNC connection remain active before it is automatically disconnected?

When you access a resource via a UNC, the Windows network redirector keeps the virtual circuit open for a while even after you close the resource. This is done to take advantage of locality: If you access a network resource once, you're probably going to access it again in a short time, so the redirector leaves the connection open for a little bit, on the off chance that you're going to use it again. For example, if copying a bunch of files from a server via a UNC, once one file copy is complete, the next one is going to start very shortly thereafter.

If there is no activity on a connection for a while, then the redirector decides, "Okay, well, I guess that's all there is for that" and closes the connection.

The default duration for this "UNC grace period" is ten minutes. You can customize it by setting the KeepConn parameter. Increasing the value will keep the connection active longer, which is a greater convenience for the client, but it also increases the load on the server.

Comments (12)
  1. Leo Davidson says:

    @Joshua: Open a command prompt, type "net use" to list the connections, then "net use /d \serverwhatever" to delete the ones you don't want.

    Another trick is that you can connect to the same server using a different name for the machine (e.g. WINS name vs IP address) to fool Windows into allowing you two concurrent connections using different credentials.

  2. Pan_2@lj says:

    2Leo Davidson

    "net use/d" doesnt help sometimes

  3. Joshua says:

    What's funny is the only reason I ever notice is when I need to drop a connection so I can connect as another user.

    *Sometimes* I have the power to cycle the service to drop the connection.

  4. IIRC you can drop existing connections also in the compmgmt.msc console, under "SharesConnections" (or something like that).

  5. Gabe says:

    What causes a UNC connection to get reconnected? I've noticed that when a connection has been disconnected, sometimes accessing it from the command line fails but accessing from Explorer automatically reconnects. Does Explorer do the reconnection itself, or does it access the redirector some special way that causes reconnections?

  6. Cheong says:

    I found the authentication rules governing the use of share can be troublesome sometimes.

    In one of the companies that I work, there's one workstation that's disallowed to join the domain (it's provided by another company as a data exchange service point). There's a few shares that requires corresponding credential (local account) for each department for access, and then there's a few public folders.

    If the user access the departmential share first, he/she will be greeted with the login box, and there's no problem. But if the user happened to access the public folder first, he/she will be login as guest, and can no longer access the departmential folder without rebooting (users weren't administrators there).

    No big deal. Just create a logon script that'll map the drive each time. What further complicated the mix is that, on some of the machines, there're local reporting related services that runs on yet another credential, and need to access a shared printer on that server…

    I'll leave it as an exercise for people who interest to figure out what I did to workaround that.

  7. Jeffrey says:

    @Cheong: You can work around that if you use the map network drive window, there's a well-hidden link (XP) or a checkbox (Vista/7) to enter custom authentication credentials. Not something you can really teach your average user to do, but it's useful when doing admin work.

    It's quite surprising that there's been no real fix for that, I keep bumping into it when attempting to use HomeGroup with other shares. Would do really well to have a "log in as a different user" button on explorer/common controls authentication failure dialog boxes, should cover the majority of the cases where this is annoying… though the implementation complexity of that might be somewhat high considering how errors propagate to the user.

  8. LR says:

    @Jeffrey: I'm sure, Cheong knows that. His point is that this does not work (as documented by Microsoft) when there is already a connection to the remote system using another set of credentials. Sometimes you can work around that by using the IP address instead of the computer name in the UNC path, but on Windows 7, even that seems not to work anymore.

  9. Cheong says:

    @LR: Indeed. Since LANMAN connector won't allow you to logon with MORE THAN ONE credential on the same server, it won't work.

    The initial solution is to change the KeepConn parameter as Raymond said. But just like what Raymond mentioned, the users soon found the access to shares much slower than before.

    In the end, we negotiate with the provider of server to change the "Public shares" to "Authenticate Users" only, and get a new account for those who just required to access the public folder. When the report service try to access the printer, it would get "access denied" error and retry later (usually lunchtime or after-office hour, when the shared folder connection timeouted so the printing would succeed) The users are told that when they need to send urgent report, they might need to logout first.

    Not a very elegant solution, but it did worked.

  10. alt-92 says:

    Funny, it was my understanding that in a Windows AD domain UNC connections with your normal credentials tend to prefer Kerberos authentication (which, by design, uses hostname/fqdn).

    Hence the inability to connect using different credentials to the same servernameshare combo.

    Now, if you're accessing \, instead of Kerberos auth, you're reverting to NTNL authentication – which means you now can specify alternate credentials.

  11. alt-92 says:

    Drat- that should read NTLM authentication. Sorry..

  12. Cheong says:

    Since that server doesn't join any domain, all we can use is NTLM authentication anyway.

Comments are closed.