-------------------------------------------------------------------- NOV-MAP.DOC -- 19980322 -- Email thread on NetWare and Drive Mapping -------------------------------------------------------------------- Feel free to add or edit this document and then email it back to faq@jelyon.com Date: Wed, 06 Sep 1995 13:04:19 -0400 From: Loren Carter To: netw4-l@bgu.edu Subject: auto mapping and starting Windows apps -Reply "Auto Attach for Windows" will make an icon, connect to a File Server, map a drive, and execute a Windows or DOS program, then when you are done in the program, it will detach you from the File Server (and the licensed connected), and as a result the drive mapping disappears. Unfortunately, it is not NetWare 4.X or DS aware but it works well in bindery emulation mode. My choice was to create bindery users in the portions of my DS tree where bindery emulation was set, or make a single "common" user that everyone could use to attach to the application in question. --------- Date: Wed, 6 Sep 1995 15:25:45 EST From: "Chuck Overberger" To: netw4-l@bgu.edu Subject: Re: auto mapping and starting Windows apps >Fellow admins and netters, Does anybody know of a utility, program, >etc, that will allow a person to to set up an icon that will map a >drive to a Windows application directory on the server and then >start the application? Take a look at Net Tools by McAfee Associates. This product will give you complete scripting as well as many other nice features. I have also tried a program called Winbatch but I can't find it anywhere ! --------- Date: Mon, 25 Sep 1995 18:53:03 -0600 From: Joe Doupnik Subject: Re: lost drive paths,mapping >I have a path/drive mapping problem. > >On a couple of my novell workstations, they lose the most recent >drive dos path statements. >autoexec.bat sets the path...c:\;etc... >loging in sets the search drives and adds to the path...Z;c:\;etc. >after login, autoexec run a batch prog that adds a network drive >hard coded to the path statement...h:\;z:\;c:\;etc. >then the problem happens at random times, on 4 of my workstations. >with no error or warning...the h:\ part of the path is gone... >the original part and the part the login script added are intact. >this happens 2 times a day on one workstation, 1 time a week on >another, and never to the rest, I have never seen anything like this. >Any ideas? > >I have 75 workstations, win 3.1, vlm, 3.12 servers. The systems >are one year to one week old. ------------- Ensure that every username has an individual login script, no matter if it as short as REM , and that there is a system login script, no matter how short. That will cure PATH corruption introduced (still, yet, all these years) by the default script within login.exe. In addition, avoid hard coding drive letters in scripts. Use MAP INSERT where possible, and say SYS: etc as the volume identifier. The first script command can be MAP *1:=SYS:\ to map the first available drive letter (what shows as F: in manuals for simple clients) to the root of volume SYS: or whereever you want it. MAP *1 and MAP INSERT keep matters "relative" and convenient. Do not hard code PATH statements if you can; there is almost no need to go to that extreme. KISS applies here too. Joe D. ------------------------------ Date: Wed, 1 Nov 1995 11:18:50 MET From: "Niels Chr Nielsen, 5551" Subject: Re: Trouble with Network Drives in Path under 4.1 >>We are seeing netware 4.1 truncate path statements at login when they >>include network drives. Has anyone else seen this? Is there a way to >>keep references to network drives in your path under 4.1? >> >>a sample might look like: >> >>path= c:\dos;c:\windows;c:\;W:\netdir >> >>before login. After login.exe finishes executing, the path looks like >> >>path= c:\dos;c:\windows;c:\ This is normal. There are good reason(s) for this behaviour: When you log in, you'll want the well-defined network environment you have specified in the login script. This means that network drives should be as they are mapped in the system and user login scripts (NW3) or container, profile and user login scripts (NW4); No more, no less. There is no guarantee what-so- ever that a user will be mapping the same network directories to the same drive letters as the previous user on that WS, although often (s)he will do so. Because of this, and because a new LOGIN (except /NS to another server) implies a LOGOUT (after which you have no access to server disks) the login/logout program deletes all network drive mappings except one (which is mapped to SYS:LOGIN) and removes all references to network drives) from the path (to avoid possible 'invalid drive in search path' errors). Work-around: Put MAP INS S16:=W:\NETDIR in your (system) login script. Niels C --------- Birch Grove Software has a product called LinkLaunch that will do what you want. It will perform one or more drive mappings as a Windows application is launched, and it will unmap the drives as the application terminates. In Netware environments it will attach and unattach as needed. For NDS servers it will do the authentication in the background. For 3.x servers it will prompt the user for a password. If more than one application is running on a server that was dynamically attached using LinkLaunch, the connection is not severed until the last app using the server terminates - REGARDLESS OF THE ORDER OF APPLICATION LAUNCH OR TERMINATION. LinkLaunch is NDS aware and supports volume objects and directory maps. Demos are available upon request. They are also available on the CompuServe NOVUSER forum. Herb Axilrod Birch Grove Software 214-340-6982 ------------------------------ Date: Fri, 1 Dec 1995 16:26:13 GMT From: Phil Randal Subject: Re: Dynamic drive mapping in Windows >Does anyone know of any utilities (shareware or commercial) that maps >drives (search, logical, working directory, etc.) on the fly for Windows >apps? For CD-ROM access? > >I have heard of two packages: LinkLaunch and Winfinet. Check out Winbatch 95 - it comes with NetWare extenders to let you log in/ attach to a server, map a drive, run an application, then unmap and logout, all in windows. Comes in windoze 3.1x and windoze 95 versions. http://www.windowware.com/ or ftp.windowware.com and browse. ------------------------------- Date: Mon, 11 Dec 1995 20:57:04 -0600 From: Joe Doupnik Subject: Re: VLM Install >I'm attempting to convert from the ODI drivers to the newest VLMs, >but I've run into a problem. I cannot get the VLM install program >to recognize my Windows directory which is loaded/executed from a >Netware volume. When I enter I:\USERS\user_name\WINDOWS for the >Windows directory location, the Install program beeps and tells me >that I'm entering an invalid drive letter. But I do have drive I: >mapped to the appropriate directory. I get the same error if I >attempt to use the advanced install setting for network >installations. -------- Probably because I: is the result of a peculiar MAPing. Generally I never touch mapped drive letters as such and always refer to the primary volume pointer, arranged by default or through MAP *1:=volume-name:\. The common default for small machines is F:, higher for more elaborately equipped desktops. *1 means the first available networkable drive letter. Rather than depend upon a cascade of particular drive letters it's better to use MAP INSERT for Path searching and forget about letters beyond the basic one above (F:). Joe D. ------------------------------ Date: Mon, 18 Dec 1995 09:46:08 +0000 From: "David Beaudoin" To: netw4-l@bgu.edu Subject: Re: WFW and 4.1 VLMs >>After installing the latest VLMs (1.2) onto my PC, I am having some >>problems with my Windows for Workgroups setup. If I load the VLMs, >>login to a Novell 3.11 server, start Windows, then open a DOS shell, >>none of the network drives mapped in my login script are valid. For >>example, F: is mapped to SYS/LOGIN. Even stranger, I cannot change to >>a higher level directory (i.e. cd\ has no effect). It is as if the >>drives have been mapped with a MAP ROOT command. >> >I'm replying in a rather uninformed state.... but I had a problem loading >WFW onto our existing 3.12 network, then had success only AFTER getting >Netware attached to the server... then issuing the windows network commands. I've found the following sequence seems to work best for me: Attach to Novell 4.1 server using VLMs, login to 3.11 server using bindery login, start WFW, then login to 4.1 server using NWUser. This allows me to keep my login scripts from the 3.11 server and then map additional drives when I login to the 4.1 server without erasing the previous mappings. David Beaudoin ------------------------------ Date: Sun, 7 Jan 1996 18:37:50 GMT From: bhardy@SLIP.NET Subject: Re: Windows Mappings... >Does anyone know of a utility that can map drives from within >windows, on the fly??? I have a CDROM server that has multiple CDROM >databases on it. Users access the CDROM server from accross our >backbone. In the dos environment the software attaches to the CDROM >server, maps one drive letter to the software directory, and one >letter to the cdrom itself, and then removes them after. (I am using >SCSI Express). For the dos environment this works fine, BUT, some of >the database packages now come with Windows versions. I don't really >want all the users to make a connection to the CDROM server before >they run windows, that would take just a few too many connections :- >). I need to be able to click on an icon, and behind the scenes >connect to the CDROM server, map the drives, and be able to search >the CD. If you're using 3.11 just use the file manager - you can browse the servers/volumes, pick an available drive letter, and map either by the session or permanently on re-connect. Better yet, if you've got it, use the Windows client for NetWare - maps using drap and drop and would painlessly accomplish your stated desires - it comes with the OS install disks for 3.12. If you're using Windows95, use the explorer/tools function to map a drive just like the 3.11 file manager. One assumes you run NetBeui and IPX for these operations. Usually, on CD servers, you map a single drive letter to the device, and the CD volume labels are seen as sub-directories. You can then control sharing/permissions, etc. ------------------------------ Date: Sun, 7 Jan 1996 23:59:47 GMT From: "Craig P. Nelsen" Subject: Re: Windows Mappings... >>Does anyone know of a utility that can map drives from within >>windows, on the fly??? I have a CDROM server that has multiple CDROM >>databases on it. Users access the CDROM server from accross our >>backbone. In the dos environment the software attaches to the CDROM >>server, maps one drive letter to the software directory, and one >>letter to the cdrom itself, and then removes them after. (I am using >>SCSI Express). For the dos environment this works fine, BUT, some of >>the database packages now come with Windows versions. I don't really >>want all the users to make a connection to the CDROM server before >>they run windows, that would take just a few too many connections :- >>). I need to be able to click on an icon, and behind the scenes >>connect to the CDROM server, map the drives, and be able to search >>the CD. > > If you're using 3.11 just use the file manager - you can browse the >servers/volumes, pick an available drive letter, and map either by the >session or permanently on re-connect. Better yet, if you've got it, >use the Windows client for NetWare - maps using drap and drop and >would painlessly accomplish your stated desires - it comes with the OS >install disks for 3.12. If you're using Windows95, use the >explorer/tools function to map a drive just like the 3.11 file >manager. One assumes you run NetBeui and IPX for these operations. >Usually, on CD servers, you map a single drive letter to the device, >and the CD volume labels are seen as sub-directories. You can then >control sharing/permissions, etc. He wants to be able to do it with one step and do two mappings at once. There are several ways to do this. The cheap way is to use something like WinBatch from wilson window ware at http://www.windowware.com/wilson/pages/ . You could also check out some of the network management programs like Saber menu from Mcaffe. WinBatch allows you to write a window script to make the mappings, run the program and delete the mappings. It supports both NW4 and NW3 and other network o/s's. ------------------------------ Date: Tue, 9 Jan 1996 08:55:40 +0100 From: Peter Scherrer Subject: Re: Windows Mappings >: >>Does anyone know of a utility that can map drives from within : >>>windows, on the fly??? I have a CDROM server that has multiple CDROM >: >>databases on it. Users access the CDROM server from accross our : >>>backbone. In the dos environment the software attaches to the CDROM >: >>server, maps one drive letter to the software directory, and one : >>>letter to the cdrom itself, and then removes them after. (I am using >: >>SCSI Express). For the dos environment this works fine, BUT, some >of : >>the database packages now come with Windows versions. I don't >really : >>want all the users to make a connection to the CDROM server >before : >>they run windows, that would take just a few too many >connections :- : >>). I need to be able to click on an icon, and >behind the scenes : >>connect to the CDROM server, map the drives, and >be able to search : >>the CD. > You could simply use the windows recorder to record the steps >neccessary to accomplish your task and then (having created a new icon >to run the recording) just click apon the icon to do your work in the >background. In this manner you could even include the app that >requires such mapping so that when the person wants WP6.1 it will map >to the nessary drives and then run WP6.1 in just one double click of >an icon. (not sure, off hand, how to include an unmapping of the >drives, perhaps this is not desired though) Well, I don't think that the windows recorder is good for anything in the real world. For the problem with CD-mapping, I suggest a much better solution: dynamic mapping. You map the drive, then the application is started, and you free the same drive, after the application is closed. You don't know in advance, which drive letter is free, so you first have to find it out. The following examples shows how that can be done. ; get free drive letter availdrive = DiskScan(0) ; returns string in the form "X: Y: Z:" ; are there any drives available? DrvLen = StrLen(availdrive) IF DrvLen <> 0 THEN GOTO continue2 Message("No free drive available", "Close one of the CD-ROM applications.") GOTO done :continue2 ; map last drive availdrive = StrSub(availdrive, DrvLen - 2, 2) n4Map("\\SERVER2\NSEPRO:",availdrive) ; Get VIEWS.INI IF FileExist("C:\WORK\VIEWS.INI") == @FALSE THEN FileCopy("W:\NSEPRO\VIEWS.INI","C:\WORK\WIN31",@FALSE) : : ; adapt INI-File IniWritePvt("Infobase Directory","Network Support Encyclopedia - GroupWare","%availdrive%\NSE_GW.NFO","C:\WORK\WIN31\LNAME.INI") ; run CD RunZoom("%availdrive%\PROGRAMS\WIN\BVIEWS.EXE","%availdrive%\NSE_SYS.NO") ; wait until application has been closed AppWaitClose("%availdrive%\PROGRAMS\WIN\BVIEWS.EXE") ; free drive letter n4MapDelete(availdrive) :done The tool I used for that is called WinBatch, from Wilson WindowWare (www.windowware.com). We have 35 CDs mounted on our servers, and everybody has access to alle of the CDs. Instead of starting the application directly, we start a winbatch and do things like these shown above. ------------------------------ Date: Wed, 10 Jan 1996 17:43:17 GMT From: Bruce Webber Subject: Re: Need Utility to map drives within Windows >A while ago I requested any info on utilities to map drives on the >fly from within Windows. The CD Mapper utility that someone kindly >put me on to works but needs to run an .exe file which is no good >for music CD Roms and would mean setting up seperate icons for every >application that wanted access to it. > >Does anyone know of any others that will just map a drive that is then >available to any application that is subsequently run ? WinBatch, from WilsonWare, is excellent. You can write "batch files", using the WinBatch language, which run from within Windows. If you purchase the compiler (~$395) you can create executables that you can distribute. Such an executable can attach to a server, map drives, and run an application, reading information from the command line or from an INI file. There is good support for Netware 3.x and 4.x. ------------------------------ Date: Fri, 12 Jan 1996 10:27:45 +0000 From: Marc Bornebusch Subject: Re: Need Utility to map drives within Windows >A while ago I requested any info on utilities to map drives on the >fly from within Windows. The CD Mapper utility that someone kindly >put me on to works but needs to run an .exe file which is no good >for music CD Roms and would mean setting up seperate icons for every >application that wanted access to it. > >Does anyone know of any others that will just map a drive that is then >available to any application that is subsequently run ? Try WinLogin. It is available at ftp.u-net.com/com/netutils/winlog3.zip. ------------------------------ Date: Fri, 12 Jan 1996 22:26:59 GMT From: Herb Axilrod Subject: Re: Mapping and Batch Files >I have a question reguarding MS Windows, Mapping and Batch Files. If >I can remember correctly, this was discussed earlier in this list. Is >there a software program that will allow me to take a windows program and >write a batch file to be executed in windows that will 1) Map drives that >are needed to execute program, then 2) Execute the MS Windows program and >3) Allow me to delete the drive mappings so that I can use them again for >another windows program. Anybody that has worked with this or experienced >this same problem, I would like to hear how you solved this problem. Any >help would be greatly appreciated. Birch Grove Software has a Windows utility called LinkLaunch that does exactly what you want and more. Dynamic drive mapping, automatic login and logout. NDS support. Dynamic search drives. For more info and a demo send mail to bgrove@onramp.net or call 214-340-6982. ------------------------------ Date: Wed, 17 Jan 1996 11:53:44 -0800 From: rgrein@halcyon.com (Randy Grein) To: netw4-l@bgu.edu Subject: Re: Drive mapping connection software -Reply >Why not just set up an icon to run the login.exe? That is what I did and >it works fine! Also, have the login in the autoexec.bat when the >workstation boots. In WFW, you have to check the "Global drives & paths" >box under the nwuser setup (Press F6 or run nwuser, look under the "key" >icon). If you don't set this, then when the shell exits, all the drive >connections are reset back to what they were before you did the login. >I also have an icon setup for logout too. > >Under Win 3.1, you have to explicitely put the line to allow this in the >system.ini file. In the [Netware] section (you may have to add it!) add >the line: > >[Netware] >NWShareHandles=1 > >The sharehandles line allows mappings and captures done in a DOS shell to >be retained when the shell exits. Roger, not only is this method unsupported, but you're the first person I've heard of to get it to work at all! (And lots try, it's a logical way to try to solve the problem.) The word I've had on the subject when I asked Novell was that because of Windows shortcomings, even if you can get it running it hoses up the environment or something. Fortunately the 32 bit client for DOS/Windows will be out soon (about 6 weeks?), which will handle logins from windows properly. ------------------------------ Date: Tue, 23 Jan 1996 12:21:49 -0600 From: Joe Doupnik Subject: Re: Remote boot and Windows >I am having trouble running Windows from my 3.11 server on remote boot >workstations. When the shared version of Windows for Workgroups is started, >it shows the Windows logo and the stops, providing the error message that >emm386 failed to load. I have used emm386's /y switch to point to the >network search drive for my DOS directories, ie > device=emm386.exe /y=y:emm386.exe noems x=cc00-cfff >yet this switch seems to be ignored. I have done this with both the DOS >6.22 version of emm386 and the version (older) that came with WFW. --------------------- Some general advice on drive mappings. In the login script material start with this line MAP *1:=SYS:\ That makes the first (1) available network drive letter (*) refer to the file server's main volume (sys:). Leave it that way. It's often F:. Then you can reference all server files via that single drive letter. I never use the "automatic" letters such as that y: above because they change depending upon setups. Be explicit, such as /y=F:\dos\386emm.exe rather than vague (y:) and wishy washy (no explicit path). The end of alphabet search drive letters are basically unused except by the PATH searching part of things; I never use them in a script or by hand. The 386emm.exe /y switch applies in CONFIG.SYS only, not in Windows. Joe D. --------- Date: Thu, 25 Jan 1996 12:02:47 -0800 From: Dale Horita Subject: Re: Remote boot and Windows >>I am having trouble running Windows from my 3.11 server on remote boot >>workstations. When the shared version of Windows for Workgroups is started, >>it shows the Windows logo and the stops, providing the error message that >>emm386 failed to load. I have used emm386's /y switch to point to the >>network search drive for my DOS directories, ie >> device=emm386.exe /y=y:emm386.exe noems x=cc00-cfff >Use Joe D.'s suggestion: /y=f:\public\whatever\emm386.exe >>yet this switch seems to be ignored. I have done this with both the DOS >>6.22 version of emm386 and the version (older) that came with WFW. Thanks for the responses. Joe D's two suggestions were the key 1. in the system login script map *1:=sys:\ 2. in the boot image file's config.sys device=emm386.exe /y=f:\public\msdos\v6.22\emm386.exe and this now works fine. I still don't understand why Windows when loading (cause DOS stuff worked fine) distinguished between /y pointing to a search drive to DOS versus pointing to the mappings for F: as in the lines directly above, but I can live with that a lot better than with Windows not loading. Thanks Joe, and all others who responded. ------------------------------ Date: Wed, 24 Jan 1996 21:25:25 -0600 From: Daryl Banttari Subject: Re: DOS PATH lost on login to 3.12 server >Recently we upgraded from a 3.11 server (10 user) to a 3.12 server >(25 user). We had a consultant firm set-up and install the new >server along with netware, all the NLMs, etc.... > >The problem that I am experiencing (and the consulting firm doesn't >know how to fix) is that DOS PATH variable settings in a >workstation AUTOEXEC.BAT file are overwritten when a user logs in. >As I understand it, they should be converted to search drives. >Change all the MAP S1:=SYS:blahblahblah to MAP INS S1:=SYS:blahblahblah If you dont use MAP INS then the n'th search path gets overwritten before: PATH=C:\DOS;C:\WINDOWS;C:\UTILS action: MAP S2:=SYS:PUBLIC (wrongly not using INS) after: PATH=C:\DOS;Z:.;C:\UTILS when correctly using MAP INS: PATH=C:\DOS;Z:.;C:\WINDOWS;C:\UTILS ------------------------------ Date: Fri, 26 Jan 1996 03:56:18 -0500 From: Debbie Becker Subject: Re: Multiple servers, logins >Actually I should have stated my concern as to whether or not >accessing the resources of each of the services under the hood >of the NDS must require a tick on the concurrent license >utilization on each of the servers. I have server users that need >to concurrently access several servers, but I'm not happy with >their having to utilize that many licenses... Lot's of us aren't too happy with this, but that's the way it is right now (unless you're a mega-corp and can get site licensing). Right now, each MAP and CAPTURE that your user has to different servers is using up a licensed connection. Have seen some mention on here of utilities that can be used to dynamically map a drive just prior to loading the app and then delete the map after you exit the app -- sounds like a good idea to me! Meantime, we can just all keep nagging Novell to get with it and look at real "network" licensing (as opposed to server-based!) ------------------------------ Date: Sat, 27 Jan 1996 18:00:55 -0600 From: Brian Scott Subject: Re: More than 26 drives >I have two servers with more than 21 disk-drives, most are CD-Roms. >Is it possible in Novell 3.12 for example map's CD-Rom drives as >one Drive-letter + Directory, so that every CDrom more than Z can mapped. > >Example: > 1 = SERVER1/CDDISK1: > 2 = SERVER1/CDDISK2: > >Mapped as X:\CDDISK1\[directories] > X:\CDDISK2\[directories] There is no practical way of mapping more than one volume to a drive letter. For dos applications you simply have batch files that map the volume, execute the application, and unmap the volume. This means that every dos application can use the same drive letter. In windows make sure that "global drive and paths" is not set. This enables each dos session to have it's own set of mappings to prevent conflicts. Some windows applications can work without having the volume mapped to any drive, by using the full UNC path (ie //server/vol/path). If you have more than 20 or more application's that do not fall into either of the above catigories the you may have to train the users how to map drives as they need, or purchase software that can do dynamic drive mapping. ******** BRAIN FLASH ********* Now that I have said all of that, there is an easy way to do just what you described. Simply purchase large drives and copy the cd's to the drive. With just one 9 gig drive (and about 64 meg more ram) you could combine at least 13 cd's into just one volume and speed up access time. ------------------------------ Date: Sat, 27 Jan 1996 21:48:43 GMT From: Teo Kirkinen Subject: Re: More than 26 drives >I have two servers with more than 21 disk-drives, most are CD-Roms. >Is it possible in Novell 3.12 for example map's CD-Rom drives >as one Drive-letter + Directory, so every CDrom more than Z can mapped. At least SCSI Express version 2.x can do that, so other (less expensive) software may also support it. But the free CDROM.NLM which come with NW 3.12 and 4.1 don't. ------------------------------ Date: Wed, 31 Jan 1996 13:36:41 -0600 From: Joe Doupnik Subject: Re: Setting the path in login scripts >Sometimes when I or my users log in, the DOS path is magically altered to >have z:.;y:.; put on the front of the path. Sometimes, it doesn't >happen. Can anyone tell me why? > >And if I wanted to make that change from a login script, how would I? >I've tried all of the following > >SET PATH=Z:.;Y:.;%PATH >SET PATH="Z:.;Y:.;"%PATH >PATH=Z:.;Y:.;%PATH -------------- Red Manual time. We went over this a week or two ago, but here is a cryptic short form. 1. Always have both system and user login scripts, no matter how short. Reason: login.exe has a default which will absolutely eat the PATH from the left, for reasons never explained and it has never been fixed. 2. Start a login script like this MAP *1:=sys:\ or the volume of choice. It says map the first available network drive (*) to that place. It's often F:, and don't play with it further. 3. Use MAP INSERT S:=place to lengthen the PATH. Do NOT use MAP letter if you can avoid it, and don't say MAP S because that definitely clobbers the 'th PATH entry. 4. Pay no attention whatsoever to drive letters other than that from part 2. This couples to item 3 on avoidance of MAP letter. 5. Never tinker with PATH at DOS level after exiting autoexec.bat. Try these rules; observe and think about what you see. Joe D. ------------------------------ Date: Thu, 1 Feb 1996 09:34:24 EST From: Dan Cullinan <25004@2300-S-1.PORTS.NAVY.MIL> Subject: Re: Setting the path in login scripts >>Sometimes when I or my users log in, the DOS path is magically altered to >>have z:.;y:.; put on the front of the path. Sometimes, it doesn't >>happen. Can anyone tell me why? >> >>And if I wanted to make that change from a login script, how would I? >>I've tried all of the following >> >>SET PATH=Z:.;Y:.;%PATH >>SET PATH="Z:.;Y:.;"%PATH >>PATH=Z:.;Y:.;%PATH >>Can anyone explain this to me? > Joe Doupnik replied: > Red Manual time. We went over this a week or two ago, but here is >a cryptic short form. > 1. Always have both system and user login scripts, no matter how >short. Reason: login.exe has a default which will absolutely eat the PATH >from the left, for reasons never explained and it has never been fixed. As a reminder, it is not necessary to have both system & user login scripts... as a matter of fact, in a large network environment the use of user login scripts becomes an administrative burden. We have not run user login scripts since installation in 1988 and have not had problems. > 2. Start a login script like this MAP *1:=sys:\ or the volume >of choice. It says map the first available network drive (*) to that place. >It's often F:, and don't play with it further. > 3. Use MAP INSERT S:=place to lengthen the PATH. Do NOT >use MAP letter if you can avoid it, and don't say MAP S because >that definitely clobbers the 'th PATH entry. Exactly. Should the System login script include a direction for the "Z:;Y:;etc" drives to reside, this "magic alteration" of paths would not exist. As Joe states, by using the MAP INSERT function, DOS paths are maintained and you can put the Netware search drives any place you'd like. By using Joe's explanation: MAP INS S1:=FS1/SYS:PUBLIC MAP INS S7: FS1/SYS:SYSTEM This scenario prevents disturbance of the DOS path, with the exception of placing your search drives where you want them, and allows up to Netware's max of 16 search drives. ------------------------------ Date: Sat, 3 Feb 1996 08:46:51 +0100 From: Peter Scherrer Subject: Re: More than 26 drives >>Now that I have said all of that, there is an easy way to do just >>what you described. Simply purchase large drives and copy the cd's >>to the drive. With just one 9 gig drive (and about 64 meg more ram) >>you could combine at least 13 cd's into just one volume and speed up >>access time. > >I've got 4 gig drive and did just that. I loaded about 8 cd's onto >it. I broke it into multiple volumes since some CDs need to have >their own drive letter. However, some are able to operate in a >subdirectory. This saves drive letters and does speed up access a >lot. Now I use the CD rom stack for text based CDs only. The >multi-media stuff goes straight to a hard drive. > >Unfortunately, I'm still running out of drive letters. Running out of available drive letters, is not only a problem with CDs but also with volumes and servers (NW 4.1). As stated in earlier postings, there is one good solution for the problem: DYNAMIC MAPPING. You map the drive, then start the application. You free the same drive, after the application is closed. You don't know in advance, which drive letter is free, so you first have to find it out. The following example shows how that is done for the NSEPRO CD. ; get free drive letter availdrive = DiskScan(0) ; returns string in the form "X: Y: Z:" ; are there any drives available? DrvLen = StrLen(availdrive) IF DrvLen <> 0 THEN GOTO continue2 Message("No free drive available", "Close one of the CD-ROM applications.") GOTO done :continue2 ; map last drive availdrive = StrSub(availdrive, DrvLen - 2, 2) n4Map("\\SERVER2\NSEPRO:",availdrive) ; Get VIEWS.INI IF FileExist("C:\WORK\VIEWS.INI") == @FALSE THEN FileCopy("W:\NSEPRO\VIEWS.INI","C:\WORK\WIN31",@FALSE) ; run application RunZoom("%availdrive%\PROGRAMS\WIN\BVIEWS.EXE","%availdrive%\NSE_SYS.NO") ; wait until application is closed AppWaitClose("%availdrive%\PROGRAMS\WIN\BVIEWS.EXE") ; free drive letter n4MapDelete(availdrive) :done The tool I used for that is called WinBatch, from Wilson WindowWare (www.windowware.com). We have 40 volumes, including CDs mounted on our servers, and everybody has access to alle of the volumes. Instead of starting the application directly, we start a winbatch and do things like these shown above. ------------------------------ Date: Mon, 5 Feb 1996 19:22:11 +0000 From: Richard Letts Subject: Re: More than 26 drives >Running out of available drive letters, is not only a problem with >CDs but also with volumes and servers (NW 4.1). As stated in earlier >postings, there is one good solution for the problem: DYNAMIC >MAPPING. You map the drive, then start the application. You free the >same drive, after the application is closed. You don't know in >advance, which drive letter is free, so you first have to find it >out. The following example shows how that is done for the NSEPRO CD. Please check out the following utility -- It will map the next available drive letter, and set an environment variable ftp://ftp.salford.ac.uk/network/utils/mapnext.zip Program: MAPNEXT.EXE Version: 1.00 Distribution: Unlimited [no system impact] Source: \\whitworth-a\utility\build\nov_util\mapnext Libraries: NW4SDK(mapping) NW3SDK(environment services) Author: Richard Letts Description: Map root the first free (unmapped) network drive to the path specified Does no attempt to log the user into a fileserver Sets an environment variable specifying what letter has been mapped errorlevel set on exit: 0 - success 1 - Out of environment space 2 - no free drive available for mapping 3 - path invalid 4 - some other error [bad arguments] Usage: mapnext [options] options: -d debugging output [lots!] -v produces verbose output [path mapped, and drive letter] Example Usage: mapnext mail X:ccmail2.0 equivalent to map root i:=apps:\ccmail2.0 set mail=I [if I: is the first unmapped network drive] ------------------------------ Date: Wed, 21 Feb 1996 00:41:07 -0500 From: James B Revennaugh Subject: Re: Drive Mapping Problem w/ Client32 and 4.1 >I just finished installing a new 4.1 network with Win95 workstations >running Client32. Everything was working fine until I installed >Arcada Backup Exec 7's Win95 agent on the workstations. > >Now, when you try to map root to a directory, the drive letter is simply >mapped to the volume. > >Example: > >map root f: = sys: home\rsperry > >simply maps f to the volume sys. > >The truly peculiar part of this is that the mappings were working fine >until I installed Arcada's Win95 agent. Removing the agent, however, does >not solve the problem. > >Does anyone have any ideas what the problem is? Thanks. Why not simply go into 'My Network Neiborhood' and select the folder you want and drag it into 'My Computer'? Unless you need true DOS mappings then that should suffice. Else type the following: map f:=sys:\home\rsperry You can also add that to your autoexec.bat file and it'll map a true DOS drive letter after every boot up. ------------------------------ From: "Chris Tilbury" Date: Thu, 21 Mar 1996 13:25:39 GMT Subject: Re: Setting the path in login scripts >>>Sometimes when I or my users log in, the DOS path is magically altered to >>>have z:.;y:.; put on the front of the path. Sometimes, it doesn't happen. >>>Can anyone tell me why? >> >>Joe Doupnik replied: >> Red Manual time. We went over this a week or two ago, but here is >>a cryptic short form. >> 1. Always have both system and user login scripts, no matter how >>short. Reason: login.exe has a default which will absolutely eat the PATH >>from the left, for reasons never explained and it has never been fixed. > > As a reminder, it is not necessary to have both system & user login >scripts... as a matter of fact, in a large network environment the use of user >login scripts becomes an administrative burden. We have not run user login >scripts since installation in 1988 and have not had problems. Depends. Joe's right if you don't EXIT from the system login script. If there is no personal login script in the users mail directory, and you don't "EXIT" from the system login script, then the LOGIN.EXE program will run a "default" script which, as joe mentions, conveniently eat's the PATH from the left inwards. Nice. If you do "EXIT" from the system login script, then this default doesn't get executed and the above doesn't happen. Anyway, it's worth noting that it is a *very* bad idea not to create at least an tiny login script in each users mail directory. Why? Because EVERYONE has at least the [C] right to every subdirectory in the SYS:\MAIL tree (this is how software such as Pegasus Mail delivers mail to each user). Hence, if you don't have a file called LOGIN in your mail directory, anyone on the server can create an arbitrary login script in your there. Should, for some reason, the EXIT command be removed from the system login script, you could find yourself (or your users) running potentially damaging scripts. ------------------------------ Date: Wed, 3 Apr 1996 18:06:01 -0800 From: STEVEN WAI-TIEN YUEN Subject: Re: CD Mapper FTP Site For those many people, who e-mailed me regarding the FTP site for the CD Mapper program, here it is: ftp://ftp.library.health.ufl.edu/vol1/user/guest/cdm or depending on your client, it could also be: ftp://ftp.library.health.ufl.edu/cdm ------------------------------ Date: Tue, 11 Jun 1996 14:29:00 CDT From: "Goodman, Roger W." Subject: Re: Shared Drives/Licensing.... >>I know that the minute I map to a volume I use a license on the server >>that that volume is on. >> >>We have two servers set up with a 250 user license on each. What I >>need to do is map a volume on one server to everyone (about 400 >>people). As I understand it, my licensing will only let the first 250 >>people to map to that server access it, whether they are actually >>using the drive or not. Is there a way around this?? Maybe a third >>party utility that will allow dynamic mapping, so that the only time >>people are actually using a license on the server is when they are >>actually using the drive? > >We use a commercial product called LinkLaunch which does dynamic >mapping and application launching, tears down the map when the >application ends. Would recommend it very highly (on the basis of >experience - I've no commercial interest in this product). > >Laurence Asquith I use a free program called cdmapper written by Bill Kuntz and Ned Stewart at library.health.ufl.edu. Works fine for me. ------------------------------ Date: Sun, 30 Jun 1996 15:38:12 MDT From: "John L. Stevens" Subject: Drive Mapping in Login Script for Client32(95) >I've just try the client32 for win95 on netware 4.10 and it seems >that all our drive mapping done in the system login scripts do not >work. I can only map the drive in win95 itself ... anyway to make >login script work ?? I have been off for most of last week so if this has been answered and I missed it .......... so be it. Change your MAP INS Sn:=... statements to MAP ROOT INS Sn:=... Many many months ago I had the same problem until I discovered this. Also you will need to check if some of your programs use the same logical drives as is the map statementsbut closer to the root. Pegasus comes to mind at the moment as one I had to adjust the .INI file. ------------------------------ Date: Wed, 18 Sep 1996 16:06:08 EDT From: Kelly Stevens Subject: Simple Windows Batch Freeware BATCH Here is the Windows Batch file program I chose today: The program is BATSH.exe and is freeware. http://www.chips.navy.mil/oasys/w-util/files.html Here is how it works: I have a CD-ROM database called FastReferenceFacts. You create a simple text file, say FASTREF.BSH. This would be the windows equivalent of FASTREF.BAT. It would need three lines: NETADD S: \\GALE_CD\DATA:\FRF (This is server location of CD on hard drive) NETADD R: \\GALE_CD\DATA:\ (This is root drive letter for the applications) RUN R:\FASTREF\FASTREF.BAT (This starts the program) (It makes an EXIT command automatically.) Make a Windows Icon and alter the command Line properties to read: BATSH.EXE FASTREF.BSH My Example is with a DOS program, but this will run Windows Programs also. ------------------------------ Date: Mon, 7 Oct 1996 13:37:12 -0600 From: Joe Doupnik Subject: Re: MS client vs NW client [Floyd: long problem description deleted] --------------- I can't answer your question directly. However, based on experience I avoid using any search drive letter explicitly. I always do a MAP *1:=sys: or similar to ensure the first networkable drive (*1), typically F: for many folks, is mapped to the desired volume, and then all explicit references use F: as the initial path component. You may have to check the sundry .ini files to ensure that they too avoid search drive letters. Further, for Windows programs there is much less need to map any drive letters for those programs. Use Windows facilities to define the "working" directory. Joe D. ------------------------------ Date: Fri, 8 Nov 1996 17:08:06 -0500 From: Clay Gibney Subject: Re: Mapping to 4.x from 3.12 bindery connections -Reply >>We are currently a 3.12 shop with 5 servers, one primary data server with >>several peripheral servers. We will be migrating to 4.11 in the near >>future, one server at a time, hoping to limit the trauma. One of our >>concerns is the fact that the first machine will not be the primary server, >>but one of the peripherals. We will be loading our Email package on that >>server, which means that everyone needs to be able to map a drive to that >>server. >> >>Our clients are currently Netx, changing to 1.20b VLMs. When we login to >>our primary server (3.12), are we going to have any problems attaching and >>mapping to the 4.11 server? We will be upgrading that server to 4.11, but >>several weeks after the first. Anybody have ANY suggestions on things to >>look out for/avoid? > >I have no problems mapping to the 4.10 server from 3.12.. However, be >sure to LOGIN to the 4.1X server prior to attempting to map. (can't >ATTACH, I don't think. You get an error message that the command is >not recognized.) I am currently logging into 3.12 servers, but I have several branch-office 4.1 servers, and I can ATTACH and I can MAP a drive just as if the 4.1 servers were 3.x servers. The bindery emulation under 4.1 works fine. I don't have to LOGIN first, I can either run MAP (which will prompt me to login), or I can attach first. ------------------------------ Date: Mon, 9 Dec 1996 13:00:56 -0600 From: Joe Doupnik Subject: Re: File Management >On a related topic, this server and it's file structure are legacy >systems. I need to somehow "re-do" the file structure and the login >script because we're running out of space and drive letters. This is >on a NW3.12 server (fully patched) and mostly win95 clients (just a >few legacy windows 3.1 clients). Has anyone out there had experience >with thinking, "Oh, I'll just clean up this login script," only to >find yourself hopelessly tangled in a file structure that doesn't >really make sense anymore, but seems too complex to simplify? I have servers with a very large number of applications needing drive letters, and the PATH is always very short. How? By simply using .BAT files and a sys:\batch directory located first in the PATH search list. This works well for DOS and for Win95. Windows programs often need no drive letter. But if you are running Win95 clients which do need drive mappings then there is an easy solution: back to those .bat files and sys:\batch. But you say, those are Windows programs not DOS programs and the .bat files would be run from a DOS box. No problem, I reply. Get w95inst7.zip or w95insps.zip from directory misc on netlab2.usu.edu (or pub/mirror/misc on netlab1.usu.edu for web browsers) and read about invoking Windows programs from a DOS box .BAT file (and the users need never know you have done the DOS box trick). I short, only a very few drive letters are needed at one time, so create and destroy them dynamically upon need. Joe D. ------------------------------ Date: Tue, 10 Dec 1996 17:21:13 +1300 From: "Baird, John" Subject: Re: Moving volume between drives >Last weekend I moved the volume VOL: of my fully patched 4.10 server to >another harddrive. Explicitly, what I did, was: >1.) back up the volume via SBACKUP >2.) dismount and rename it >3.) create a new volume VOL: on the destination drive >4.) restore via SBACKUP > >I didn't change anything in NDS, neither via INSTALL.NLM nor NETADMIN, >because I dont want to lose all the references to the volume object in >the processe (users' homedirs most noticably, print queue spool dirs and >what-do-I-know-else). In preparation I checked with DSVIEW that the >volume object in NDS only references the name of the volume, not any >server-centric IDs or such. > >Everything went smooth so far -- but there's just one little disturbing >detail: when one maps a drive to the volume, the response is not > >Drive R: = SERVER_VOL:\ > >but > >Drive R: = SERVER\VOL:\ > >That happens exclusively with VOL: not with any other volume which has >a NDS object. The problem occurs because you messed around with the volumes. What is happening is this: Map.exe, having established the mapping, calls a function named NWGetVolumeExtendedInfo to find the NDS volume object associated with the physical volume. This function does not do an NDS lookup, but retrieves the object ID of the corresponding volume object from somewhere in the volume definition tables. The NDS volume object name is then obtained from the ID. If that ID does not match an existing volume object, then map.exe outputs the physical volume name rather than the volume object name. When you create a volume using install, the ID of the associated volume object is written into the volume definition tables providing a convenient means of locating the matching volume object. You must have deleted the new volume object. Unfortunately, there is no facility to correct this situation. --------- Date: Mon, 9 Dec 1996 21:43:29 -0600 From: Joe Doupnik Subject: Re: Moving volume between drives [above message snipped] ------------- Once again John provides concise technical insight. Last summer I played around with logical (server_vol:) versus physical (server/vol:) names in script files in an attempt to reduce the packet count while logging in. There were differences, but not enough to be worth the trouble in my case. Joe D. ------------------------------ Date: Tue, 25 Feb 1997 12:40:23 +0800 From: BLooney@comtech.com.au To: netw4-l@ecnet.net Subject: Re: Login mapping... >When logging into our 4.1 server (login and map updates applied along >with all others), i automatically get search drive 1 and 2 taken up by >sys:public and sys: (respectivly). Even if i rem out every line in the >login i still get this (for any user). Yet if i login with the /ns (no >login script) then i don't get it. Somebody help me with the big >picture please? This happens in both 4.x and 3.x if you do not have a _user_ login script. LOGIN.EXE will run the "default" login script which does the following: map ins s1:=sys:public map ins s2:=sys:public\%machine\%os\%os_version The second line usually resolves to: map ins s2:=sys:public\ibm_pc\msdos\v6.22 If you are running MS_DOG and v6.22 of such. If this directory doesn't exist you get a mapping to SYS:PUBLIC. Anyhows - to stop it you can do two things: (a) Put in a user login script (urgh) (b) Put a line in your Container/Profile (or in 3.x System) login script which says "NO_DEFAULT". Odd note: some really early version of LOGIN.EXE (from 3.x) just did a MAP (not MAP INS) which meant that if you ran the default and logged in/out a few times, you'd lose all your path... ------------------------------ Date: Thu, 19 Jun 1997 11:18:05 +1000 From: Sam Currie Subject: Re: NW4.1 mapping question >Is it common to face an available drive letters shortage? After using >A-E for local drives and O-V for CD server drives, that doesn't leave >much for server mapping. With multiple servers, it would seem to >make things even worse. See is some of the CDrom's will run of UNC connections, this way you will not need a mapping for the cd. I've just put 20 cd's online. Of course I didn't want 20 drive letters going so I used UNC where possible. Only 2 cd's needed their own drive letter. ------------------------------ Date: Tue, 24 Jun 1997 01:55:47 GMT From: Herb Axilrod Subject: Re: NW4.1 mapping question >Is it common to face an available drive letters shortage? After using >A-E for local drives and O-V for CD server drives, that doesn't leave >much for server mapping. With multiple servers, it would seem to >make things even worse. > >I have a mix of Win3.1 and Win95 machines spread across the campuses >in student labs. The students do not have unique logins, so customized >login mapping is not really feasible. Simply put, each machine logs >in at boot and *all* network applications are only a click away. > >I can see the day RAPIDLY approaching where I'll need to have a method >in place to make more sense out of the current mapping strategy. Your >thoughts/methods/advice would be helpful. Take a look at LinkLaunch from Birch Grove Software. http://www.bgrove.com/bgrove. Although it doesn't have the ability of NAL to automatically deliver applications to users' desktops, its more versatile than NAL for dynamic drive mapping. ------------------------------ Date: Fri, 18 Jul 1997 09:42:26 +0100 From: Phil Randal Subject: Re: Need justification for MAP ROOTing User's Home Director >It makes training somewhat easier as well. We setup our network to map >root users' private files to the U: drive. When we want people to go to >their private files, it's much easier to say "Go to the U: drive", rather >than "Go to U:\SYSTEMS\KEVINM". > >Map rooting also helps solve other problems as well. Someone told me >once that they had a user with two drives mapped to the same volume. >The user saw the same file on both drives, assumed that the files >were independent, and deleted the file from one of the drives. >Later they called the helpdesk saying that they deleted one of >the files, and "both" disappeared. Some users have a real hard >time understanding that two dr > ive letters can map to the >same place. > >Don't use the MAP ROOT command to become lax on security, though. >Anyone can discover MAP and try to poke around.... Another very good use for Root mappings is in your search drives. MAP INS R S16:=SYS:PUBLIC for example, ends up with a root mapped search drive. (I wish I'd thought of that when I set up our networks). Without it, Windoze users have a habit of browsing the Z: drive with file mangler and thus changing the current directory that Z: points to, losing all the NetWare utilities. ------------------------------ Date: Wed, 1 Oct 1997 08:19:31 -0400 From: Bob Whipple Subject: Drive Mappings - Reply >I have several labs setup on a Netware 4.1 LAN and none of the >student accounts have login scripts. In the Container login script, >the last two statements are > >Map f:=sys2:user >Map g:=sys2:user > >The students get logged in ok and the login script does get >processed, but the drives are not mapped. When they look under my >computer drive f: is mapped to sys: and g: doesn't exist. The labs >are all running windows 95 with MS NDS service pack installed. This >problem also happens if the computers are running VLMs instead of >netx. If I put a login script in for a student then the drives get >mapped appropriately. John, I'm running a 4.1 server and ran into similar problems with drive mappings over a year ago. Try placing the line NO_DEFAULT in the container script above the drive mappings. You should also be sure that you're running the most current version of LOGIN.EXE - there is an update at Novell's site. --------- Date: Wed, 1 Oct 1997 09:28:17 -0700 From: Tim Madden Subject: Re: drive mappings >>I have several labs setup on a Netware 4.1 LAN and none of the >>student accounts have login scripts. In the Container login script, >>the last two statements are >> >>Map f:=sys2:user >>Map g:=sys2:user >> >>The students get logged in ok and the login script does get >>processed, but the drives are not mapped. When they look under my >>computer drive f: is mapped to sys: and g: doesn't exist. The labs >>are all running windows 95 with MS NDS service pack installed. This >>problem also happens if the computers are running VLMs instead of >>netx. If I put a login script in for a student then the drives get >>mapped appropriately. > >I think the last statement in the login script needs to be NO_DEFAULT >so that no other login scripts are inadvertantly run. It doesn't have to be the last statement. I've always made it my first line! >Otherwise, is there a LASTDRIVE=Z statement in CONFIG.SYS? Lastdrive=Z is part of the IO.SYS code in Win95, so it's not necessary in the config.sys anymore. >If there already is, then edit the container login script, and just >before the mapping statements, put the following commands: > >MAP DISPLAY ON >MAP ERRORS ON > >This will cause the mapping messages and errors to display. Log in >as a student, and see what the error messages say. Excellent advice! One more thing: the "container login script" in question is the student's parent container, isn't it? Remember, a user will only execute it's immediate parent container's script, and not any above that. So, for the tree [Root] O OU User User will execute OU's script, but not O's. ------------------------------ Date: Fri, 31 Oct 1997 16:16:32 -0500 From: George Bakos Subject: Re: search maps under win95 >>How can I set a search map in Win95 environment? In win 311 NWUSER >>let me do that, but I do not know how to do it win Win95. > >Must be done prior to launching, during the login script OR you can open >a DOS window and map that way for that session/window. Close the window >and lose the map. Actually, this is one of the enhanced features of Client32 v2.12 and 2.20. If you open "Network Neighborhood" and right click on the directory (or directory map object), one of the menu selections is "Map search drive". ------------------------------ Date: Thu, 6 Nov 1997 08:45:26 -0600 From: Brian Scott Subject: Re: Mapping under windows 95 GUI? >Circumstances require me to have cdroms avaible everywhere on the network. >(on demand) The problem is: Windows based cdroms require dedicated drive >letters or mapped under Network tools. We are going to be installing more >windows based cdroms, soon we will be out of drive letters. Test each app to see if they even need a drive letter. Windows apps do not normally need a drive letter, although most of the installation programs do require it. Attempt to install and run the app with the UNC name \\server\volume\path\app.exe and see if it works. --------- Date: Thu, 6 Nov 1997 12:46:24 -0500 From: Eliot Ware Subject: Re: Mapping under windows 95 GUI? >>How about NAL - You could define mappings for applications so that when the >>app was launched, the mapping would be done....quite similar in practice to >>what you are currently doing with your DOS apps. In addition, NAL will let >>you put apps in the NDS so that users can be given a new app simply by >>giving them rights. > >Forgot to mention that I we are running under novell 3.12. Try LinkLaunch. It does what you want http://www.on.com/ec/products/linklaun.html ------------------------------ Date: Thu, 6 Nov 1997 19:48:04 +0000 From: "David G. Pile" Subject: Re: Mapping under windows 95 GUI? >>the windows 3.1 VLM's (Network tools or is it nwtools) but >>for windows 95? > >With Win95, if you right-click the "my computer" icon, it will show >a short menu. On that menu is "map network drive" and "disconnect >network drive". These lead to simple dialogs for choosing drive >letters and network resources. It is still possible to use NWUSER.EXE under Win 95 if you want quick but temporary mappings, etc. Our support team regularly uses this tool and finds it is more helpful than Explorer, etc. Novell's site has a TID on what you need to do to enable its functioning under 95. It consists of a 2 line edit job to the NETWARE.INI file, adding the [restrict] section as follows: [restrict] Win95AllowDRVUI=1 Once you restart windows 95 and have copied NWUSER.EXE into the windows\system directory you are in business. While not elegant, it is familiar for most people. ------------------------------ Date: Fri, 28 Nov 1997 07:21:43 +0000 From: "J.M.Ram¡rez" Subject: Re: Directory Map problems with client32 and Windows 95 >Directory Map problems with client32 and Windows 95. > >Users log onto a IntranetWare 4.11 server/tree and attach to a Netware 3.11 >server which has an inhouse Dataflex accounting program. >For the application to work, 6 directory maps need to be established one of >which is a search map. This is done through a batch file. This all works >fine when using Windows 3.11 with 16 bit VLM client v1.20a.. > >Problem: >I upgraded Windows 3.11 to client32 and the mappings are erratic where some >of the maps worked and some do not, occasionally they work but not often. >The letter is always mapped to a volume but not to the desired directory. >The same happens no matter how may times the batch file is run. >This also happens on a Windows 95 machine even with the latest client32 >version 2.2. > >Has anyone had the same mapping problem using client32 or on Windows 95 >client and what is the solution please. I would like to move the users to >Windows 95 and this problem is preventing this. I can't move the application >to the IntranetWare fileserver which is another issue. > >Note: All client software mentioned is by Novell. You can use the shortafx.nlm from Novell, and load it in your 3.11 server, of course you need the patchman.nlm too. This nlm fixes the problem with the map and the search path in the login scripts and others problems. This nlm is found in the \admin\patches\nw311 directory where the client32 was installed from. --------- Date: Sat, 29 Nov 1997 02:11:47 +0200 From: Mike Glassman - Admin Subject: Directory Map problems with client32 and Windows 95 This is a well known problem when using the client software. To solve, simply change your batch file so that all mappings are set as root mappings. For eg : Map h:=xxxxx changes to map root h:=xxxxx This will solve your problem both in win 3.11, Win95 and Dos. ------------------------------ Date: Wed, 3 Dec 1997 08:43:37 +1100 From: Dave Cottle Subject: Re: Unavailable letters for mapped drives >>We have a mixed IntraNetWare and Windows 95/NT4 environment >>and all users get drives mapped to the INW Servers. Our problem >>is that the drive letter will not be visible from some applications >>e.g. MS Office, due to the long UNC-name. What he means is very different from all the replies you people have kindly sent in! When the open file dialog box is presented under Win95 or NT, in the "Look in" drop-down menu at the top of this standard dialog box, a list of drives is presented. Only the left-hand end of this is shown to users (it's a very short box). So a long UNC path mapping is ALWAYS shown before the drive letter, and hence the small dialog box obscures the drive letter, which is on the end of this. I do not know of any simple solution for this, save using SUBST instead of MAP. I am aware of some difficulties with subst under Win95, so this is probably only a viable solution for NT. The key is that we all would like the std. open file dialog box to have drive letter first, then the unc-style path that that drive is mapped to. Complain to MS. ------------------------------ Date: Mon, 22 Dec 1997 09:49:00 +0100 From: Sven Ostlind Subject: Re: MS Word 97 TID 2929518: Client 2.20 loses drives in Word97. (Last modified: 05DEC1997) Symptom Drive mappings disappear after exiting an MS Word from the Office 95 or Office 97 application suite. This can be caused by performing the following instructions: With IntranetWare Client for Windows 95 v2.20 and MS Office 97 (running on the local workstation), copy a Word 97 shortcut to a 4.11 server. Open Network Neighborhood and find the folder the shortcut is in on the server. Run Word 97. Click on File, Properties (or type something). Exit Word 97 any way you like and when asked if you want to save the changes to Document1, answer No. Look at drive mappings and connections--the connection to the 4.11 server is gone. NOTE: If the shortcut on the 4.11 server has the working directory information filled in, the problem doesn't happen. If you run the Word 97 shortcut from Explorer or My Computer, the problem doesn't happen. If you use IntranetWare Client for Windows 95 v2.12, the problem doesn't happen. If you test other MS Office 97 apps (Excel, Powerpoint, Access), the problem doesn't happen. Problem happens with Windows 95 v950, 950a and 950b. Problem happens with or without the Service Release 1 for Office97. (sr1off97.exe) UPDATE: when closing an Office 97 application, the following error is seen: "this connection must be maintained for NDS use on the tree , It should only be removed after logout from the tree. Do you with to logout from ? (Yes/No)". This is another symptom of the same problem. Search Text: Lose drive mappings office 97 excel word, Microsoft Solution This issue has been resolved with an updated version of NOVELLNP.DLL. Download Novell's latest Client and Patch for the IntranetWare Client for Windows 95 from the SUPPORT.NOVELL.COM. If the NOVELLNP.DLL is not dated 9/25/97 or newer, then open an incident with Novell Technical Services to obtain a field-test version of the file. --------- Date: Mon, 22 Dec 1997 11:58:25 +0000 From: Phil Randal Subject: Re: MS Word 97 >Solution >If the NOVELLNP.DLL is not dated 9/25/97 or newer, then open an incident >with Novell Technical Services to obtain a field-test version of the file. ftp://ftp.novell.com/outgoing/novellnp.exe ------------------------------ Date: Wed, 31 Dec 1997 18:22:56 -0700 From: Joe Doupnik Subject: Re: Mapping Home Directories >> Is there any way to access the home directory path on the environment >> tab for use in a login script like the following: >> >> MAP ROOT M:=ENVIRONMENT:HOMEDIR > >If you're looking for a way to access the exact contents of that field >on the Environment page, I'm not aware of any way to do it. However, by >default home directories are named after the login name of the user. >So, a command such as: > > MAP ROOT M:=SYS:%LOGIN_NAME > >Will work just fine. Of course, change the volume name as needed. ------- Nope. The NDS item is %HOME_DIRECTORY. That is not necessarily the same as %LOGIN_NAME. HOME_DIRECTORY includes the volume, as one can see by writing it in a test login script. By default there is no NDS HOME_DIRECTORY property assigned to usernames, though such can be created. This information is appropriate to INW 4.11. Joe D. ------------------------------ Date: Thu, 8 Jan 1998 17:38:02 PST From: Kevin Miller Subject: Re: Fw: Drive mappings -- converting from NetWare to NT 4.0 >Desperately need help -- am converting from Netware 3.12 to NT 4.0 over >Christmas. Workstations are Windows 95 using the Microsoft 32-bit >client. Under Netware I was able to perform a Map Root in the system >login script that enabled each user to find their personal directory >mapped directly to the I: directory without having to go through >subdirectories. > >In NT, I've been successful using a share to get the personal directory >to map using Net Use //servername/foldername, but have run into two >problems: > 1. Can't map to subdirectories >(//servername/userfolders/foldername), meaning I have to create >individual shares to each user's folder; and > 2. Can't use a %username% in the login script to get automatic >mappings for each user (net use n: //servername/%username%) This is just the "way it is" with NT and shares. You have to setup a share FOR EACH home directory. One of the reasons to never use NT as your Network OS backbone, IMO. ------------------------------ Date: Fri, 27 Feb 1998 20:37:08 -0800 From: Anthony Baratta Subject: Lost Drive Mappings w/ Office97 and NW C32 O.k. gang here is the latest in my fight with Win95 and NW C32... As reported here previously, by many many people, Novell has issued a beta patch for dropped drive mappings while using Office97 Apps and Client 32 for Win95. However, I could not get this patch to work with the Retail Version of Win95, Client 32 v2.2 and Outlook97. The machine would still Fatal Exception Error while attaching files from a Novell Mapped Drive and/or drop all drive mappings on the close of Outlook97. I upgrade NIC drivers, swapped NICs, cables, and changed ports on the hub to no avail. So a thought hit me (ouch!), maybe I should try OSR2? That way I was getting the latest and greatest version of Windows95. So I ripped out the retail copy of Win95, installed OSR2 (from our handy MS Developers Kit). Without the beta patch from Novell, bomb-city. But WITH the patch - things stablized. Hmmmm. My next adventure will be to patch Win95 with all the various patches that make up OSR2 to find the "magic" dll that works with the NW C32 beta patch. Since I can't legally install OSR2 on all my workstations and patching would be easier than ripping out what I have setup (highly customized). ------------------------------ Date: Wed, 18 Mar 1998 14:42:08 -0500 From: MaryBeth Stuenkel Subject: Re: Last Network Drive >From the NetWare documentation "Supervising the Network": "You can map a local drive (usually A: through C:) to a network directory, but you cannot access the local drive until you remove the network drive mapping. "- You must not map a redirected drive, such as a CD-ROM drive, to a network drive." What you really want to do is prevent drive F: from being used. You can use the MAP *n in the login script. Again from the same documentation: "- Instead of specifying drive letters such as F: or G:, you could use an asterisk followed by a number n to represent the nth network drive. For example, if your first network drive is F: then using MAP *3:= would assign H: {F G H---1 2 3}, or if your first network drive is D: then using MAP *4:= would assign G: {D E F G---1 2 3 4}. "This allows drive letters to reorder themselves automatically when local drives are removed or added or when the first network drive is changed. "This also allows users to log in from workstations with a different number of local drives than their regular workstation." Or simply avoid mapping drive F: >I have a desktop using Windows95 and Client32. > >This machine has local drives A-F. > >The system login script maps F and half steps on his CD-ROM drive, >(ie. the computer still presents it as a CD-ROM drive called sys, not >servername\sys: like other mapped drives, and when I open it I can >see volume SYS: and I cannot see the CD in his local drive.) > >map del F: at the DOS prompt solves the conflict. > >In IntrNetWare Client properties the First Network Drive is set to G: > >Heres the bottom line... >Why would the First Network Drive (set to G:) be ignored and the >map statement still executed for that station? --------- Date: Wed, 18 Mar 1998 17:46:17 -0500 From: "Donald G.W. Voss" Subject: Re: Last Network Drive Try this: map *1:=server/vol:path/path map *2:= ... map *3:= .. in the login scripts. This will let the drive letter[s] float and respect the first network drive setting of clients. [ or hard drive[s]/devices ] in older clients. I only hard map a drive in the drive letter areas known to be free .. l,m,n,o .. t . Then search drives come up .. with map s16:= ... >I have a desktop using Windows95 and Client32. > >This machine has local drives A-F. > >The system login script maps F and half steps on his CD-ROM drive, >(ie. the computer still presents it as a CD-ROM drive called sys, not >servername\sys: like other mapped drives, and when I open it I can >see volume SYS: and I cannot see the CD in his local drive.) > >map del F: at the DOS prompt solves the conflict. > >In IntrNetWare Client properties the First Network Drive is set to G: > >Heres the bottom line... >Why would the First Network Drive (set to G:) be ignored and the >map statement still executed for that station? Am I missing a patch? >I can't find anything in Novell's Knowledgebase. ------------------------------ Date: Sun, 22 Mar 1998 18:52:05 -0500 From: Rowan Hawkins Subject: Re: Last Network Drive >Try this: > >map *1:=server/vol:path/path >map *2:= ... >map *3:= .. > >in the login scripts. > >This will let the drive letter[s] float and respect the first network >drive setting of clients. [ or hard drive[s]/devices ] in older >clients. I only hard map a drive in the drive letter areas known to >be free .. l,m,n,o .. t . Then search drives come up .. with map >s16:= ... The only problem I have run into with doing things that way is that certain applications hard code the path (with drive letter) directly into the application. The most notable is MSOffice but other applications do it as well. ------------------------------