For net use, Persistence Is Persistent

We’ve been seeing a certain issue arise for random users in the company where I’m doing support currently. It would run something like this. Someone would leave to work from home or on a business trip, they would restart their laptop, and they would lose all of their mapped drives.

Some of the time things of this sort just happen.  It is Windows after all.  Do the same thing twice and get two different results.  That’s not shocking.  But it was forming a pattern.  It was, shall we say, spreading.

I decided it wasn’t an issue each of these machines was having but rather something more systemic.  I asked to look at the login script responsible for mapping drives.  The original script looked something like this:

net time \\[our-dc] /set /yes

net use M: /delete:yes
net use P: /delete:yes
net use S: /delete:yes
net use T: /delete:yes
net use V: /delete:yes

net use M: \\[a-server]\[some-share]
net use P: \\[another-server]\[a-different-share]
net use S: \\[we-have-many-servers]\[and-lots-of-shares]

(We actually have several similar scripts depending on the role of the user, but they were all similar enough to this one. Also, don’t worry about net time which merely calls out a time server. There was a syntax problem there was well, but I corrected it and the syntax you see above is now correct. And, damn it, you are smart enough by now to recognize that the stuff in the [brackets] is for substituting.)

I was suspicious because I typically use the persistent argument and this script was thus lacking. So I did a little research into the matter. It turns out that the persistence flag is itself persistent. This means that if it is set to yes it is yes until something else changes it. As such a script as you see above can fail if something (anything) happens to alter the persistence on a system to no. Once that system is then rebooted, all drive mappings (since they are still set to persistence=no) will vanish silently leaving the user wondering what happened (and calling into technical support to have it corrected).

That’s easy enough to fix. Include persistence.

As you might notice from the script above there are mapped drives being called out for deletion which are not being mapped. I wanted to also capture that in my replacement script. This is what I wrote:

net time \\[our-dc] /set /yes

net use * /delete:yes

net use /persistent:yes
net use M: \\[a-server]\[some-share]
net use P: \\[another-server]\[a-different-share]
net use S: \\[we-have-many-servers]\[and-lots-of-shares]
net use /persistent:no

This version deletes any mapped drives (using the * wildcard). Then it sets persistent to yes and maps three drives. Finally it reverts persistence to no so that any other drives mapped by the system will fall off at reboot (unless they are specifically set to yes). This really covers all the bases and ensures that drive mapping is kept very clean. More importantly it ensures that these mapped drives will always remain persistent regardless of reboots or user locations.

My boss didn’t like the idea that the script would delete all mapped drives and he didn’t like the idea of leaving persistence set to no (in case users wanted to map their own drives persistently). So I altered the script again to satisfy those requirements:

net time \\[our-dc] /set /yes

net use M: /delete:yes
net use P: /delete:yes
net use S: /delete:yes

net use /persistent:yes
net use M: \\[a-server]\[some-share]
net use P: \\[another-server]\[a-different-share]
net use S: \\[we-have-many-servers]\[and-lots-of-shares]

Now you should have enough to write some very fine, proper, and best-practice login scripts. Conversely you could write some notoriously bad scripts which plague users with bizarre behaviors and which flood your help desk with strange calls. Either way, have fun with that.

Share

5 thoughts on “For net use, Persistence Is Persistent

  1. Thanks for this post. I’ve been having issues with mapping shared drives. My scripts currently delete each drive then add them. The problem arises when another user has a file open, and the user currently logging on is asked if they want to “force closed” and gets scared by the command prompt and does nothing. They then call me because they can’t access any of the shared drives, because the log on script never completed. I think the script your boss didn’t like is my solution! It will be much more efficient to rewrite all the scripts than to take the 3 service calls each week to train users what to do with the command prompt.

  2. I needed some help making my home NAS / network work a little more consistent without errors. And this script helped me to achieve it.

    But there seem to be error in your script.
    net use * /delete:yes does not seem to be valid command
    net use * /delete /yes This command works. (Windows 7 64bit)

    I guess for a home network it is enough to make sure the login for your network share is saved under credentials manager in windows 7, so you don’t have login saved in plain text in your batch file. I usually give a small delay as well. about 5 second before script starts, after windows is logged on. Else it tries to map network drives too fast, while network is not initiated.

    Currently my script looks like this:

    ——————
    netconnect.BAT
    ——————
    @echo off
    timeout /T 5

    net use * /delete /yes

    net use /persistent:yes

    net use U: \\NAS\download
    net use V: \\NAS\backup

    net use /persistent:no

    timeout /T 1
    “C:\Program Files (x86)\qBittorrent\qbittorrent.exe”

    ————–

    To not get the cmd window popping up when I reboot, I had to make another script.

    ——————
    MapNetworkDrives.VBS
    ——————

    Set myShell = CreateObject(“WScript.Shell”)
    myShell.Run chr(34) & “%USERPROFILE%\netconnect.bat” & Chr(34), 0

    ——————

    It would be nice if windows did this automatic. When you map a network drive it should just always work. Wheneveryou reboot or re-log or whatever. It should detect itself when network is ready, then initate these things.

    Very annoying we have to do these hack-workarounds.

    1. David — If it’s any consolation, Apple can’t seem to connect to network shares while logging in while on wireless. It appears the connection call happens before the wireless call.

      According to this page my syntax is correct and I am left wondering what your syntax is supposed to do. Have you tested to ensure your script is actually deleting shares as expected?

  3. After further testing it seems my computer is just too fast.
    It boots after a few seconds.
    Here are some simple steps to make network drives persist without errors.

    Step 1: map network drives through explorer, rightclick map network drive. rename if you want.
    Step 2: Make sure your pc requires password at bootup (start > run > netplwiz)

    done.
    This allows PC to start up network and whatever it needs required for the mapped network drives to persist and not give any errors.
    This requires no scripts, no workarounds. it just works. (for me at least).

    In a corporate setting your method might be required, but for simple home network, where this issue has plagued so many users, I believe this sollution is the most simple and elegant. I guess a lot of people has disabled “type password on login”.

    Might be a good extra layer of security, with the added side effect that networked drives now work flawless. not bad :)

Leave a Reply to JamesIsIn Cancel reply

Your email address will not be published. Required fields are marked *