> How to increase the number of drives that can be mapped in the Login > scripts? Beyond 7 drives oes login from Windows gives error.
It was my understanding that Windows (later versions at least) could handle drive letters A through Z so 7 drives seems a little low and suggests a problem somewhere.
Which version of Windows are you using? Which version of the Novell/Micro Focus client are you using? How are you mapping drives in the login script?
HTH. -- Simon Micro Focus Knowledge Partner
------------------------------------------------------------------------ If you find this post helpful and are logged into the web interface, please show your appreciation and click on the star below. Thanks. ------------------------------------------------------------------------
In article <email@example.com>, Srinivaskv wrote: > How to increase the number of drives that can be mapped in the Login > scripts? Beyond 7 drives oes login from Windows gives error.
I've used up all 26 drive letters before (even without floppy drives attached), and have clients who currently use more than a dozen. So something is off and answering Simon's questions are a good start to figuring this out.
This is the mapping I have in the login script map s1:=\\lfa2\vol1\ map s2:=vol2:\ map s3:=vol3:\ map s4:=\\lfa2\vol4\ map s5:=\\lfa2\vol5\ map s6:=\\lfa2\vol6 map s7:=Vol2:\Srinivas map s8:="\\lfa1\vol2\SupplierPlanning\Supplier Material Issue
> This is the mapping I have in the login script > map s1:=\\lfa2\vol1\ > map s2:=vol2:\ > map s3:=vol3:\ > map s4:=\\lfa2\vol4\ > map s5:=\\lfa2\vol5\ > map s6:=\\lfa2\vol6 > map s7:=Vol2:\Srinivas > map s8:="\\lfa1\vol2\SupplierPlanning\Supplier Material Issue
If I change from s1, s2 , etc versions of map to S:, T: version (from search drive method to using Drive letter method), then it is working ok. So It could be problem with using search drive notation. It may not be problem with folder names (At first I had problem with using folder names containing
> If I change from s1, s2 , etc versions of map to S:, T: version > (from search drive method to using Drive letter method), then it is > working ok. > So It could be problem with using search drive notation. It may not be > problem with folder names (At first I had problem with using folder > names containing
Maybe you're just hitting the maximum length of the path variable. Should be easy to check by simply looking at it or extending the path before logging in to check whether the error strikes earlier in the script.
> If I change from s1, s2 , etc versions of map to S:, T: version > (from search drive method to using Drive letter method), then it is > working ok.
Potentially hitting some issue with the PATH variable is also a good possibility, too. While Windows itself long ago increased the maximum PATH variable data length, I do believe that the eDirectory login script parser has a shorter limit. Or maybe that was when trying to "SET" or "DOS SET" the PATH variable directly; I can't find a reference to any known issue at the moment.
But the first thing that stands out is that the current MAP statement syntax is "replace this item in the PATH with this search drive mapping" (e.g. "MAP S1:" to overwrite first item in PATH, "MAP S2:" to overwrite second item in PATH, etc.)
As opposed to "please insert this into the beginning of the PATH" ("MAP INS S1:") or "please insert this at the end of the path" ("MAP INS S16:").
Which makes me wonder whether the error you got once you hit "MAP S8:" wasn't simply because whatever was in the seventh position of the existing PATH variable (the one replaced by the previous MAP statement) was critical enough to cause failure when Windows tried to handle the next MAP statement.
I would say "usually" you want network paths to be at the end of the PATH contents, so that all local paths are searched first before resorting to searching the network for things that will exist locally. If that's the case, simply repeating "MAP INS S16:" for all of the MAP statements might create the search drives in the most desired manner.
There could still be some other condition we're not expecting, such as something that is unique with the PATH variable data that is already set. (Since both MAP S1: or MAP INS S1: still have to parse and understand what's in the PATH regardless.) So if MAP INS doesn't already resolve it, maybe also confirm what's in the path before starting the MAP statements.
Thanks for all your suggestions. 1. I tried MAP INS S16: for all drives. I get the same error 9002 for the last drive (8th) mapping. 2. I reversed the order of mapping. Now also same error 9002 for the last drive in the list (8th). 3. I removed whole lot of paths from the PATH variable. and tried the above. Same error 4. I do mapping using drive letters: S:, T:, etc , no error. 5. I removed the path string with