I have a few network drive mappings that I want to be available to various programs upon reboot. However, they remain disconnected until I visit them manually.
If a program, such as OneNote which reads notes shared on a network drive, tries to connect, it does not see the share and does not cause auto-reconnect.
I am looking for a fully automated solution, preferably just a setting to make Windows natively reconnect on machine boot.
For example, right now drive Y and Z are disconnected and X is connected because I accessed it manually:
Edit: I have to change my question slightly but with quite a significant impact on the answers. The drives are indeed NOT available at logon. They only become reachable after I open an ssh tunnel.
Therefore, the main question is - how do you make applications force the drive alive when they try to access it?
I guess another approach would be to automatically run a script when the tunnel gets established. It's probably my best bet if the above is not possible.
Well, first of all, while mapping the drive you could tick the checkbox saying XP should reconnect the drives. It's not perfect. The other option is to write a script and place it in user's Startup folder:
Read this thread: https://web.archive.org/web/1/http://techrepublic%2ecom%2ecom/5208-11184-0.html?forumID=47&threadID=178558&messageID=1818197. The guy basically says to change this:
We used to have a similar issue at my last place and this seemed to help.
Hope this helps.
Are they accessible if you try to open them? AKA, is this the age old issue of a mapped drive appearing to be disconnected, but when trying to open it, you find that it actually is connected?
But to answer the question as i read it:
To map a drive from a command prompt, and have it remain after a reboot, is to make it persistent.
Or, right click on My Computer, click map network drive, choose the location, and make sure "Reconnect at logon"
We encountered issues with this where we had a 2003 file share mounted in a Unix filesystem. The "disconnect" would happen, and jobs that used it would potentially end up having to be run twice - the first time to wake up the share, the second time to actually do the job for real.
This wasn't satisfactory as - of course - sometimes the first run worked, so in the end one of our developers ended up writing a job to regularly poll the share and keep it warm. Note that in this case changing keepalive times on the server wasn't an option as the share was mounted in the filesystem, and jobs could potentially have gaps of up to a week or so between them.
Why they didn't just connect at the start of each job and disconnect when done, or wake up the share via another method before running the actual job, I can't say.
Anyway, I'm not certain of the implementation details, but I expect that a scheduled task that just retrieves a directory listing would have the same end result for a Windows client if you were going to go down that route. It's one way of doing it, but I'm sure there are better.
The moral of the story anyway is that Unix/Windows interoperability sure ain't as seamless as some folks would have you believe. But that's digressing from the question.