This is a discussion on Removable storage vs network drive letter problem - FIXED ! - Netware ; I remember a couple of people posted about this recently so just thought I'd share the hack I've put in place which works in our environment. I also noticed that a lot of people replied who didn't actually understand the ...
I remember a couple of people posted about this recently so just thought
I'd share the hack I've put in place which works in our environment. I
also noticed that a lot of people replied who didn't actually understand
the problem. This fix is only needed when :
1) Users are not permitted to use disc manager to change drive letters.
2) Where countless numbers of different makes and models of devices could
be used, preventing manually allocated drive letters from sticking
I gave this some thought and I've found a fix which works - for us at
least. It's a touch dirty, but in the absence of a clean solution it's the
best I can offer at present..
Just for reference we run NW6.5, ZfD6.5, XP with DLU (Restricted User). All
machines have local C: and D: drives, and our video suites have E: aswell.
Network mappings at the front end of the alphabet are F: and H:.
A device plugged in will install correctly but will not be visible in
Windows Explorer. This is because the device is installed by the system
user, who knows nothing about user network drive mappings and hence uses
F: as the perceived first available letter (there is no way to configure
Windows to use specified letters when countless multiple devices are
involved). The user will still see their network F: drive and the usb
stick will be unavailable unless they disconnect the network mapping at
which point it magically appears. Oppositely, if you plug in the usb
stick before logging in, it WILL be available, but the login script will
fail to map your home directory as the system user has already allocated
The way round this is to trick system into thinking that network drives
(ie. F: and H are in use, and this must be done between the running of
the login script, and the insertion of the usb key. If this is done before
the login script runs, the network maps will fail, but when run shortly
there-afterwards, the user can see and use their F: and H: mappings whilst
at the same time, invisibly in the system space, F: and H: are set as
substitute references to the D: drive therefore occupying those letters
from the perspective of the disc management system.
To do this I have used the subst command, and called the following 2 batch
files from the scheduler to run as secure system :
on login :
subst F: D:\
subst H: D:\
and on logout to remove subst refs :
subst F: /d
subst H: /d
A reboot automatically clears the references.
Hope this is of use to someone.
Leeds Met University