| |||||||||||||||||||||
FAQ 66. Novell NetWare (TM) Networking
This particular section is rather anti-Novell. Forgive me, but this is a Win95 FAQ, not a NetWare FAQ. My objective is to make using Win95 easier, and if it means patching and hacking the server, so be it. Chances are, you have a lot more clients than servers. :-) However, I do want to start a Client32 sub-FAQ in here. Client32 experts are welcome to provide answers to FAQs about it and I'll collect them into a separate section. Please help, and you'll get your name in lights on this page. Novell MHS mail system users will want to check out the MS Exchange FAQ, especially the part about the MHS delivery service now available from Infinite Technologies. 6.1. How do I connect to Novell NetWare (TM) servers? First, ask your administrator if he prepared the server for Win95 clients. This is critical, if you want your administrator to like you. Then, Install Client for NetWare networks, and fill in the "Preferred Server" value in CNW's Properties. Set your primary login to "Client for NetWare Networks". Also, install IPX/SPX protocol (It will install automatically along with Client for NetWare), and select a frame type in its Advanced properties. Auto-detect does not always work. Your choice of frame type depends on what the NetWare server uses. NetWare 3.11 and earlier typically use 802.3, later servers use 802.2. The next time you restart, you will get a NetWare login requester asking for your name and password. When you feed it this, your NetWare login script will execute. More details for NetWare Directory Services later. 6.2. What do I have to do to a NetWare server to work with Win95 clients? Many, many, people have crashed NetWare servers with Win95 computers using Microsoft's Client for NetWare. A lot of this is from the client pushing the server, but a lot more of it comes from misunderstandings from users! The most critical thing to do to a NetWare server is to update its software. Old .LAN drivers might not keep up with the Win95 clients. An old '386 or '486 class server will also have troubles keeping up with Pentiums running Client for NetWare. Novell's VLM Client for DOS causes many of these troubles too. Details are at Rich Graves' Win95NetBugs site. In each of these cases, get the latest .LAN driver for your server's net cards, get the latest base OS patch sets for your server from support.novell.com, and get the Admin edition of the Win95 Service Pack. The service pack tools, in particular, include improvements in batch setup for NDS networks, and fix the nasty problems caused by the original Win95 release. Special notes for server versions below: Ensure you disable Packet Burst and long filenames on the Win95 clients, by adding these lines to the clients' SYSTEM.INI file: [nwredir] SupportBurst=0 SupportLFN=0 You can also use a non-burst frame type (802.3), and enforce no LFNs via system policies. These servers have a nasty time with Win95 clients using long filenames and packet burst. Use the NetWare 2.x techniques above, or apply PBURST.NLM and the OS/2 name space fix, available at Novell's NetWire site. Back up your server before powering up a Win95 client for the first time! Client for NetWare will not use long filenames on a NetWare 3.11 server unless you explicitly tell it to, meaning you KNOW you have the name space patch installed. If you want to use long filenames on a patched NetWare 3.11 server, you should set up a system policy to enforce LFN usage, or include: [nwredir] SupportLFN=2 in SYSTEM.INI This, according to my observations, is a patched and bug-fixed NW 3.11. This is the server that Microsoft did most of their client testing on, and it will work with packet burst and long filenames without patches. You still need the OS/2 name space to support long filenames. Set the frame type on the Win95 stations to Ethernet_802.2. If you don't need to use NDS and you have Bindery emulation available on the server, you can use the Client for NetWare as per NetWare 3.12 servers. The big catch is it won't recognize an NDS login script! To work around this, you can hand-copy the NDS system login script to SYS:PUBLIC and call it NET$LOG.DAT. Another work-around is to log into the server in Bindery mode (An option available in LOGIN.EXE, or just log in with regular Client for NetWare) and run a copy of NW 3.12's SYSCON to make system and user login scripts for Bindery mode. Details are in KB article Q128253. However, Microsoft released an NDS Service which will use NDS login scripts and work with NDS programs. Install Services for NDS by adding it as a Service (you still need Client for NetWare installed). Services for NDS is part of Microsoft's Win95 Service Pack 1, Admin Edition. You will also need the Shell32 Fix and the NWSERVER fix, which come with Service Pack 1, and six DLL files from Novell which come with the NetWare 4.x server. You will still need Bindery emulation for peer sharing (File & print sharing for NetWare) and Remote Administration. Set the User Level security provider to point to this server running Bindery emulation and you're all set. Or just don't bother with peer sharing via NetWare (Which you shouldn't do anyway except for Remote Administration.) I had the opportunity to finally try Services for NDS this week (25 APR 96) and it appears to run just fine. After I hand-copied all DLL files from Novell's SYS:\PUBLIC\CLIENT\DOSWIN directory to SYS:PUBLIC, I could run NWADMIN and the other Win 3.1 NDS utilities in there. WARNING: Novell now has a 32-bit NetWare API (32-bit versions of their DLLs) and these DLLs, as far as I know, do NOT work with MS's NDS client. I haven't tried them, but on more than one occasion I got a letter from a user regarding them. For example, Pegasus Mail for Win95 requires the 32-bit NetWare DLLs but they don't work with MSNDS. Also, for the 16-bit DLLs, use the ones in SYS:\PUBLIC\CLIENT\DOSWIN\ and no others, because the ones that come with Client32 are really 16/32 stubs and require the Novell 32-bit DLLs. NOTE: The NDS client still depends on accurate Bindery emulation running on the Preferred Server. If you use any additional services that depend on User Level Security (such as Remote Administration) be sure you set the Bindery context to match the Organizational Unit you want your user list for. In an absolute worst case, set the Bindery context to point to each of your Organizational Units and Organization. Type this at the server console, or include it in AUTOEXEC.NCF (Of course, use your real unit names, not the example MYORG): Set Bindery Context = O=MYORG,OU=UNIT1.MYORG,OU=UNIT2.MYORG 6.3. How do I make NetWare-related TSRs work? They won't work in the login script? They won't, no matter how hard you try either. Win95 runs the login script from a single DOS session, which completely unloads when the login script finishes. Loading TSRs from a login script is stupid anyway, in fact, loading DOS TSRs in Win95 in general is stupid. But if you have to load network TSRs, Win95 did keep the old WINSTART.BAT capability. WINSTART.BAT, in your Win95 directory, executes just after all the network components load, and just before the login prompt comes on. Load your TSRs in that. They will be available from all DOS sessions afterwards. Details are in KB article Q127794. Yes this does work; I can run Cheyenne's ARCSERVE (TM) for Windows 5.01 by loading BREQUEST.EXE this way. Which reminds me: Do any of you know of a 32-bit BTRIEVE requester for Win95 yet? Oh yes, TSRs loaded in WINSTART.BAT execute in an independent DOS session which you'll never see. 6.4. How do I use a client other than Microsoft's Client for NetWare? I won't touch Client32 yet; you can read about it at Novell's Client32 Home Page and make your own judgments. However, some applications need to see real mode NetWare clients (even though all the real mode hooks are there with Client for NetWare, and with Services for NDS). So... To use a DOS client, you will need all the regular DOS client software (LSL, IPXODI, etc). Once you have all that in place, you can add Win 3.1 support from Network Control Panel as a Client. Novell no longer recommends running NETX, but it does work as it did with Win 3.1. Install the DOS client, then add "Novell NetWare Shell 3.x" as a Client from Network Control Panel. Setup will prompt you for Novell's disks when needed. This works better with Win95 than NETX, and is "Safer" than Client for NetWare for your finicky programs and NDS apps. Try this as a last resort, if you can't get the app makers to clean up their programs. Use Novell's regular DOS installation of this client (Don't add the Windows software from Novell's setup), then add "Novell NetWare Shell 4.x and above" as a Client from Network Control Panel. Setup will prompt you for Novell's disks when needed. NOTE: Do NOT use Client for MS/File & Print Sharing for MS networks alongside a real mode NetWare client! Neither Novell nor Microsoft support this, and the mix of real mode/protected mode clients can cause loss of hair for network administrators. Use all protected mode clients and services if you want NetWare logins AND peer sharing. Client/FPS for MS networks works great alongside Client for NetWare, and even Client32 from Novell. Well, I don't believe in it myself, because Novell introduced its server concepts to Win95; concepts that belong in the server. Read all about it in Novell's Client32 FAQ. I don't have the web space to write about this, but I would like any and all input on using this client (preferably from administrators who don't work for Novell.) Basically, you get the big 4 MB download, extract it to SYS:PUBLIC\CLIENT\CLIENT32 (or other convenient space) and either run its Setup program, or install it from Network Control panel as a Client. The Setup program will automatically remove any other NetWare client for you, but it has a hard time with Client for NetWare. You're probably better off manually removing CNW and installing Client32 by hand. Installing this client also installs a Novell version of IPX protocol, which extends MS's NWLINK (You still need MS's IPX protocol for Win95 compatibility). You can use any Win95 net card driver, or use Novell's 32-bit ODI drivers. I suggest you keep it simple and use a proper Win95 NDIS 3.1 driver. Client32's properties are quite extensive, so take the time to view that client's properties and settings, as is their IPX32 protocol. Novell also has instructions for forcing Client32 into a Win95 setup using the MSBATCH.INF file. You may also use BATCH.EXE (from the Win95 CD-ROM) to attach it to a server-based installation. Ultimately, I don't think Client32's needed except for very special cases (basket cases maybe?) so try to avoid this, unless you like seeing multiple instances of IPX or you don't use a notebook computer (Novell didn't get Dial-up Networking working right with Client32 quite yet). If you update the server, Win95 clients can run VLM or Client for NetWare safely. WARNING: Novell's got a Windows 95 conspiracy going. (OK this is my imagination but think about it for a bit...) They released an NPRINTER "Open Beta" a while back, which requires their Client32 because it uses NLMs instead of VxDs. Read about Win95 NLMs in Novell's Client32 FAQ; they're basically writing a CLIB/NLM subsystem for Windows 95 that completely replicates Win95's VxD functionality and takes up more space. I figured out how to make MSPSRV (Microsoft's PSERVER for Win95) working in NDS so you can use that instead. 3Com now includes special drivers for Client32 in their network card software kits. Why do I care? You ever see Novell writing NLM subsystems for the Macintosh client? For the OS/2 client? No. So why are they wasting their time here? What makes Novell so special they can't work with the OS instead of against it? 6.5. How do I connect to the server from Single mode DOS? (Outside of Win95) Win95 Network Setup installed a real mode client for NetWare at the same time as the protected mode one. If you exit to DOS ("Restart in DOS mode") or boot to "Command Prompt Only", and you're using Microsoft's Client for NetWare, you can log in to the NetWare server by typing NET START NWREDIR at the DOS prompt. This will load a NETX compatible client using NDIS2 drivers and protocols. You can then change to your login drive and perform a normal DOS client login. Since it's only a NETX compatible client it can't perform NDS logins; so you could try: NET START NWLINK VLM Which uses Novell's VLM client, to do NDS logins. I haven't tried using Microsoft's IPX and Novell's client together, but in theory it should work. If it doesn't, you can always load Novell's net card drivers (LSL, etc) and VLM. NOTE: NWREDIR's real mode components take more conventional memory than a NETX client would, so you should only use this if your application can't run in a DOS session, or if you're performing any debugging. However, these components will automatically load high if you have upper memory available. You should prepare a special PIF file for this kind of configuration. In addition, I found sometimes NET START NWREDIR would give a "This file system is incompatible" style of message, which happens more often on NetWare 4 servers. If this happens, NET START NWLINK followed by NETX or VLM should work. 6.6. How can I receive NetWare popup messages? With Client for NetWare, use WINPOPUP. Add it from Add/Remove Programs/Windows Setup, in the Accessories components. Keep this loaded or you won't be able to see or send pop up messages. WINPOPUP will receive messages from Bindery and NDS clients, but you can only send messages to Bindery clients. Novell's SEND command in a DOS session will let you send messages to NDS clients. You can force WINPOPUP to load by keeping a copy of it in SYS:PUBLIC (or any other public place) and enforce a System Policy to run it on start-up. In Default Computer/System/Run, insert an entry with a UNC path to WINPOPUP.EXE, such as \\SRV\SYS\PUBLIC\WINPOPUP.EXE. This way, the users don't have any excuse for not seeing pop up messages. NOTE: Enforcing a policy like this will prevent any other programs that run from this Registry entry (like SAGE.EXE from MS Plus) from running. If you have to, include an entry for SAGE.EXE as well (No error messages come up if the file is missing, so no worries if some machines don't have Plus) or any other programs that run from this Registry key (Example: MSPSRV.EXE; Print Agent for NetWare). Again, if a machine doesn't happen to have the file, the user won't notice an error message or anything. I've tried a couple of ways of getting WINPOPUP in people's faces without disturbing the Run Registry key. One of them is to set up a custom Startup folder in the server, but this requires User Profiles and prevents anything else running from the Startup group. I've also tried including it in the system login script (#C:\WIN95\WINPOPUP); this works very well but it won't start minimized. I can't seem to get the START.EXE command working in a login script but feel free to try it; the login script processor will run any DOS or Windows program. There's of course, putting it in load= in WIN.INI, or better yet, sticking a shortcut (WINPOPUP.LNK) in the load= in WIN.INI so you can start it minimized, but you have to go edit each Win95 station to do it. (Sigh) Another way to do the load= entry in WIN.INI would be to add it to Client for NetWare's .INF file, so it adds this line when it installs. This way you wouldn't have to go around and change it afterwards. Or you may also use INFGEN.EXE (Part of the Win95 service pack 1 Admin Edition) to build an .INF file which adds said line to WIN.INI, and then merge it to MSBATCH.INF using BATCH.EXE to install it automatically. For all of Novell's clients, their supplied NWPOPUP works just fine. NWPOPUP however, looks for a Novell version of NETWARE.DRV (Yes I mean the old 16-bit driver) and won't work with MS's NETWARE.DRV stub. 6.7. Why don't I get a NetWare login prompt when Win95 starts? This is related to a password caching problem I read about on Win95NetBugs. If the .PWL file is around 900 bytes, it will by-pass the NetWare login prompt and start Win95 straight away. Login scripts won't execute, and the only way to get them to execute is to Shut Down/Close all programs and log on as different user, and re-log in. To correct this, delete all .PWL files in your Win95 directory and re-start the computer. While you're at it, disable password caching via system policies. 6.8. Bugs to watch out for, and patches (and links to appropriate Win95NetBugs pages) Auto detect does not always work, especially in multi-protocol networks. Bring up IPX properties and manually select a frame type. Use 802.3 on pre-NetWare 3.12 networks, use 802.2 on 3.12 and later networks. If you use Remote Administration, it may keep the Admin share active after you disconnect! Apply Service Pack 1 to fix. When Win95 stations act like NetWare servers, all hell can break loose. SAP traffic can bog the network, RIP routing tables get re-built, clients might log in to a Win95 station instead of the real NetWare server. Don't use File & Print Sharing for NetWare to share out printers and files to non-Win95 clients; use the server and print queues like you're supposed to, or use Client/FPS for MS networks instead. More on print sharing via RPRINTER later. NOTE: Novell's latest patch sets for NetWare 3.11, 3.12, and 4.1 correct routing problems caused by lots of SAP traffic. Visit support.novell.com and get the base OS patch sets for your version of NetWare. Also, to prevent non-Win95 stations from trying to log in to Win95 machines using FPS for NetWare, set their Preferred Server switch to the server you're supposed to log in to. Win95 will store your login password locally, and the password encryption is easily cracked! Apply Service Pack 1 to fix, or better yet, disable password caching and use User Level Security for peer sharing. Check out the System Policies part to find out how to do force this. Set up a system policy file, and include "Disable Caching of Login Password" or "Disable Password Caching" in Default Computer/Network. Any general mishap that occurs to the server that either causes an ABEND or otherwise kills it (I won't get into technical details; all I know is that Win95's demonstrated that it does bad stuff to NetWare servers). Check the steps you need to prepare the server or dis-arm the Win95 client. 6.9. Top ten NetWare client mistakes 10. Using a '386 machine as a server with Pentiums running Win95 as clients 9. Installing File & Print Sharing for NetWare without knowing what you're doing 8. Enabling long filenames on a NetWare 3.11 server (Patch it first!) 7. Installing Novell's Client32 out of fear 6. Capturing LPT1: to a network printer when you have MSPSRV (Print Agent for NetWare) on some workstation 5. Turning on SAP advertising in a large routed network 4. Leaving "Auto-Detect" as the frame type for IPX 3. Not specifying the preferred server in Client for NetWare properties 2. Not updating the server before adding Win95 clients 1. Not using system policies (Always a good idea to use system policies for basic stuff) 6.10. What does Client32 offer that MS's client does not? This question bugs me all the way down to Hell. Novell Client32's features probably won't be used by about 90% of us. For the remaining 10%, I will assume you already know everything about Windows 95, and this FAQ will consequently be useless to you. OK, back to reality: What does Client32 have extra?
There are a couple of other tidbits, but these are the biggest attractive features of Client32. Here are my arguments against the above features:
The point I'm trying to make is, try to use the stuff that comes with the OS before resorting to memory-hogging add-ons. Client32's the biggest hunk of code to grace the networking scene and it complicates the system far too much for 90% of us. 6.11. What's this I heard about Client for NetWare only being NetWare 2.2 compliant? I've heard bullsh*t about this since Novell's tech note announcement regarding FPS for NetWare. In their tech document 2907903, Novell states that Microsoft's File & Print Sharing for NetWare identifies itself as a NetWare 3.12 NCP server, but really uses codes and packet types from NetWare 2.2 servers. This is why that Client32 can't see Win95 computers running FPS for NetWare, even with SAP advertising turned on. Novell has a reputation for accuracy so I think this is true. OK, I believe that MS reverse-engineered NetWare 2.2 to make FPS work. What I don't believe is everyone else claiming that the REST of Client for NetWare is only 2.2 compliant. NetWare 2.2 clients (and MS's FPS for NetWare) can't do Packet Burst. Client for NetWare and NetWare 3.12 servers (and better) can. NetWare 2.2 clients (like NETX) can't log into NDS trees. OK, neither can Client for NetWare, but the NDS add-on fills that gap. You're going to say that MS's NDS client is only NetWare 2.2 compliant? Novell's obviously published the NCP client and IPX specifications, because other developers (notably Artisoft and IBM) released NetWare clients for their products. Microsoft followed suit as well. I don't expect Novell to release NCP SERVER specs, which lead, most likely, to MS's decision to take NetWare 2.2 apart and re-write it as a Win95 service. And so what if FPS for NetWare only acts like a 2.2 server? I only recommended FPS for NetWare for sharing between Win95 machines and for Remote Administration. In these two jobs, FPS for NetWare works as designed. And here's a good one for Novell. In the same document, they claim that Remote Registry Service depends on FPS for NetWare. Wrong. (Insert buzzer sound here.) While Remote Registry depends on User Level Security, that security comes from a security API in Win95 (SECUR32.DLL), which goes through the security provider software that comes with the CLIENT. It does not depend on any file sharing service, though, yes, you would need file and print sharing to go peeking into someone else's hard drive remotely. If Novell wanted to make Client32 work with remote administration, they could license code from Microsoft (gasp!) and write their own security provider code. Bet they can't do that in NLMs. 6.12. How do I share my hard drive or printer to other NetWare users? (Avoid if possible) Depending on whether the clients are Win95 clients or DOS clients, it can be either really easy or really messy! Complications include the SAP Advertising bug. If the clients are other Win95 machines running Client for NetWare, you merely have to install File & Print Sharing for NetWare networks, and specify your NetWare server as the security provider in Access Control. When you re-boot you can share out drives and printers to specific users in the NetWare server's Bindery. Now, if the client runs Win95 there's no real troubles, because Win95 will perform "Workgroup advertising" which works like the workgroup naming service (browse master) in WFWG, and this won't interfere with normal NetWare communication. To ease browsing troubles, set one of the sharing machines (like the one with the printer attached) and have Workgroup Advertising: "Enabled: Preferred Master" so the browse master control doesn't bounce from machine to machine, and broadcast useless messages to your server. Beware if you want to share to non-Win95 clients via FPS for NetWare; you have to turn on "Service Advertising Protocol" (SAP). This is how NetWare servers become aware of each other, and if you turn on SAP for a Win95 machine, it will appear in SLISTs and SYSCON etc as NetWare servers. You can even get connection info (Server version: "Windows 95 4.00.950, 250 user") from SYSCON. Problem is, not only would SAP advertising by a lot of Win95 systems cause a lot of network traffic, it could possibly kill any routing in an inter-network, and make DOS clients try to log in (as in Preferred Server login) to Win95 servers, which won't work. If you really want to screw up your network, share out your hard drive with the share name SYS and make a directory called LOGIN, and watch what happens. NOTE: Please don't do this, unless you LIKE getting beaten up by your network administrator. A better solution is to install FPS for MS networks and put either WFWG on the non-Win95 clients, or if they can't run Windows, Workgroup Connection for DOS. Both of these can run alongside Novell's NETX and VLM client software. OS/2 Warp Connect can load Windows and NetWare clients simultaneously as well. To save on memory on the DOS computers, consider using "Direct Hosting over IPX", which will remove the need to use NetBEUI and save 40 KB of memory or so. The absolute smartest way, however, is to use a common space on the server. Now printer sharing is another story... Oh no... you can't run RPRINTER.EXE on a Win95 station because you have to run it before Windows loads! Well, you could use VLM and RPRINTER together but what's the point of real mode network software on Win95? There is a better way. And no, running it from WINSTART.BAT doesn't work. Actually I haven't tried loading it from WINSTART.BAT; if you want to try it out, please let me know how you made out. But otherwise... Download and Install Microsoft Print Agent for NetWare. Add a Service from Network control panel and hit "Have disk", then tell it to look in ADMIN\NETTOOLS\PRTAGENT on the Win95 CD-ROM, or wherever you extracted that download. Note that Print Agent will only work if you run Client for NetWare; it won't run with VLM or Novell's Client32. MSPSRV is a Queue Server (as opposed to a Remote Printer). BE WARNED: MSPSRV was a last minute hack by Microsoft and doesn't have the re-connect features, etc of Client for NetWare. In addition, it requires a Bindery print server object. NetWare 4.x Administrators: Use PCONSOLE to make Bindery mode print server objects. Just before you re-boot, change your IPX properties so you have Maximum Sockets and Maximum Connections set to at least 70, like RPRINTER/PSERVER's recommended setting of SPX CONENCTIONS=60 I suggest 70 instead of 60 because FPS for NetWare and Remote Registry require additional free sockets. And speaking of Sockets, you can't use a third party TCP/IP dialer if you plan to use MSPSRV, because it uses the Winsock interface over IPX. Now, also just before you re-boot, run PCONSOLE and create a new print server object. Add one printer to it named "Printer 0", set for Remote Parallel, LPT1 (Or just Parallel on NW 4.x servers). Attach it to a print queue on the NetWare server, if necessary, detaching the queue from any other print server object it was attached to. If you did detach it from an existing print server object, you will have to re-start that PSERVER, which usually means typing "unload pserver" and "load pserver xxxxxxxx" (whatever the print server object's name was) from the NetWare console. Now finally, re-boot the Win95 station and log in. The local printer attached to LPT1: will now have a "Print Server" tab in its properties sheet. Be warned: This tab has bugs, so follow these six steps precisely!
The reason you have to re-log in, is you will lose your drive mappings as soon as you OK those settings! MSPSRV is riddled with many dumb bugs, but Microsoft seems to swear by it. Check out KB article Q134747 for all the gory details. Every time you view this "Print Server" tab, it seems you will lose all your drive mappings. Re-logging in will restore them. You will also have to create a print server object for EVERY Win95 computer sharing a printer this way, because each system becomes a PSERVER look-alike (called a Queue Server), with all the requirements of a stand alone PSERVER.EXE or PSERVER.NLM; the only difference is that it multi-tasks. You will also have to remain logged in to keep MSPSRV running, as logging out causes all programs to close, including MSPSRV. It will re-start when you re-log in, or cancel the log in. On machines with very active printers, you might want to consider setting their Default Login to "Windows Logon" with a blank password, so they automatically log in to NetWare on power-up, and re-enabling Automatic NetWare Login for those specific machines, if you disabled it via system policies. Oh yeah, one more thing: Don't capture LPT1: to a network queue if you're running MSPSRV to share a printer. This might have worked in RPRINTER, but it doesn't work here. What will happen is that MSPSRV will suck the job off the queue and send it to the printer hooked up to LPT1, then that printer will send the job to wherever LPT1 was captured to, instead of to the local printer! I've seen this happen! Create a second printer in Win95 and have it point to the queue, if you're afraid of cutting in front of other people's print jobs. So to recap: Create a print server object with a single printer, for each Win95 computer sharing a printer through MSPSRV. Attach a print queue to each of them. Make sure you aren't capturing LPT1: to a network printer. Install MSPSRV on the Win95 computers sharing printers. Set Max Connections and Max Sockets to at least 70 in IPX/SPX properties. Re-boot to activate. Select the "Print Server" tab in the printer you want to share. Select the file server from the drop-down list and the print server object from its drop down list. Hit OK. Re-log in. And Pray. I managed to get MSPSRV running on an NDS network. Originally, I thought switching the NetWare 4.1 version of PCONSOLE to Bindery mode, and creating Bindery queues and print server objects, would do the job. Apparently not. NDS clients can't readily print to Bindery print queues. So, after a lot of fiddling I realized that Novell's Quick Setup option in PCONSOLE does the job almost perfectly! Quick Setup creates a new NDS queue, NDS printer, and NDS print server object, and makes a Bindery version of the queue and print server object, granting printing rights to everyone in the NDS tree. A little extra fine tuning and it works straight away with MSPSRV. Here's what I did, with my example object names in (parenthesis):
All this fiddling may take a while, but it's the quickest way I could get it working, so that both NDS and Bindery clients can print to the printer shared via MSPSRV. And surprisingly, many of the bugs Microsoft mentioned in KB article Q134747 above, don't show up this time. Not bad at all! Yes, you have to do this for each Win95 station sharing a printer this way. Best of all, MSPSRV takes far less memory (a mere 64 KB on the workstation) than Novell's NPRINTER Open Beta. 6.13. How do I make Win95's cool network features work on NetWare? It took a bit of practice but I managed to get everything working, including Remote Registry. Some basic items to remember when installing Client for NetWare alongside of these cool features:
So here's how to do all those cool features... Prepare the CONFIG.POL file using POLEDIT.EXE (On the Win95 CD-ROM) and copy it to your Preferred Server's SYS:PUBLIC directory. I finally verified this and sure enough, it reads from SYS:PUBLIC. Make sure that everyone has read and file scan rights to this directory, including GUEST if you have such a user. Useful policies for NetWare networks include:
Microsoft's Services for NDS has some pretty cool extensions to this policy logic; you can enforce policies dependent on whatever level on the NDS tree you log in to (whatever your current context is), including specific Organizational Units, or the entire Organization. All this stuff only works if you installed MS's Services for NDS in addition to the Client for NetWare, and you're doing NDS logins. Otherwise, for Bindery logins, it still reads CONFIG.POL from SYS:PUBLIC. Let me make that clear: The NDS client has two separate rules, one for a Bindery login (Same as for original Client for NetWare) and one for a DS login. You need to specify the DS policy file and the Bindery policy file if users switch between DS and Bindery logins. To add NDS policies, change your POLEDIT template to the MAPLE.ADM template included with Services for NDS. Then load your previously-made CONFIG.POL file and make the appropriate NDS policy changes. All other policy settings made from ADMIN.ADM will stay unchanged. Bring up your Organization and Organizational Unit icons up in Network Neighborhood. If you have Admin privileges in these units, bring up properties for them. You'll see an "NDS Administration Settings" tab. Here, enable system policies and specify the volume name (including context, such as MYSERVER_SYS.MYORG) and file name (including path, such as PUBLIC\CONFIG.POL) for the policy file. The name need not be CONFIG.POL; it can be INLINE.POL or whatever, but you should make sure that the policy file is in a public place, such as the good old PUBLIC directory. Do this for each Organizational Unit and for the whole Organization as you see fit. Both Bindery and DS policies can come from the same CONFIG.POL file. NOTE: Policies don't flow down the NDS tree like other properties do. You will have to re-apply the policy setting to each Organizational Unit within your master Organization, or you may use different policies for each Organizational Unit. Two very useful NDS policies (Include these in the Organization's properties along with other basic policies):
LICENSING ALERT: If you maintain multiple servers and one policy file, a single login will consume one license on the default login server, AND on the server with the policy file! If these are the same server there's no problem, but if the policy file is on a different server (as you specify with the NDS Admin settings), Win95 won't log out from that server until the user logs out from that station (Perhaps not until shutdown?) One workaround could be to use that Win95 NCP server, as suggested in section 6.16.7 below, to store the policy files (which has a "250 user" license, if SYSCON is to be believed). To accomplish this, first add the Win95 machine in question to the DS tree, using NWADMIN, as a NW 3.12 (or other non-DS) server. Then add a volume object which matches one of that machine's share names. (You need this because the policy file has to exist on a defined DS volume!) Finally, copy that policy file there and specify it in the NDS Admin settings as normal. This is a hair-brain scheme; I can't test it because I don't have access to a DS network to try it on. You will need to include group policy support on each workstation to enforce policies for GROUPS of users, and the groups themselves must exist in the server's Bindery or Directory. To add group policy support, run Add/Remove Programs/Windows Setup, hit "Have Disk..." and pick the path on the CD-ROM ADMIN\APPTOOLS\GROUPPOL, and select Group Policy support. Once done, Win95 knows to grab policies you set for groups of users as well as specific users. You can automatically install group policy support on workstations by adding Group Policy support, using INFINST.EXE to add it to the server copy. Win95's Client for NetWare stores a user profile in their MAIL directory, so be sure you give each user one. SYSCON automatically creates a MAIL directory for each new user. The Win95 station copies their profile to the MAIL directory on log out, and reads it in on log in. You should enforce "Enable User Profiles" as a system policy, to keep multiple profiles straightened out. Now regarding Roving Desktops. The Desktop directory and Start Menu directory (which as you would recall, are just a bunch of .LNK and .PIF files) get copied to the user's MAIL directory too, if they turned on "Include Desktop" and "Include Start Menu" in Passwords/User Profiles. Because Shortcuts have long filenames, you need to enable LFN support on the SYS: volume. This will only work on patched NW 3.11, NW 3.12, or NW 4.x servers with the OS/2 name space installed. Enforce LFN support via system policies. You should also ensure you have enough space on your SYS: volume for the shortcuts! Microsoft recommended setting aside 150 KB per user, but my own custom profile eats 250 KB easily! Services for NDS stores a user profile in the user's HOME directory instead of the MAIL directory, so make sure you define a home directory for each user, but the same rules regarding roving Desktop and Start Menu (LFN support, space requirements) apply. NDS clients can perform Bindery and NDS logins, so it is possible to have two sets of profiles for each user, one in their HOME directory and one in their MAIL directory! You should enforce NDS logins only, via system policies, to prevent this mix up. Remember that MS's NDS client has two separate policy rules for Bindery and DS logins. Quite easy. Do it through System Policies. In the CONFIG.POL you create, specify User-Level Access, and type in the name of the server, and specify the type of server as NetWare server. If you do this on a DS network, the server you specify needs Bindery Emulation turned on. To do this, make sure you have this somewhere in your AUTOEXEC.NCF file on the server: Set Bindery Context = 0=MYORG (and how many other OU= entries you want) Install FPS for NetWare or FPS for MS networks, install Remote Registry service, and enable User level security (No choice really for FPS for NetWare). Keep SAP advertising OFF. Then, from any other Win95 station, log in as SUPERVISOR or ADMIN and get properties on the Win95 station from Network Neighborhood. Use the new Tools tab to access administrative programs. Of the available remote admin tools, Net Watcher will also work for viewing activity on the NetWare server, as well as the Win95 machines. Net Watcher grabs the same information made available via SYSCON. You may remove users from the server as needed too. There is one bug in Remote Administration, that makes the remote system keep sharing its hard drive, even when you end the Remote Admin session. Install Service Pack 1 on the remote station to correct this. To see if you have this bug, Administer the target machine (so you can view its HD contents) then try logging in as someone else and hit Start\Run... and type in \\machine\C$. If this brings up a window with that drive's contents, you have the unpatched services on there. Again, apply SP1 to fix it. The most wicked tool available, Remote Registry, lets you edit the remote machine's registry to fix Win95-specific problems. You need this service is you want to run System Monitor, REGEDIT, or POLEDIT to monitor or edit the remote machine. Remote Administration (and many of Win95's NetWare add-ons) depend on Bindery services running on your preferred server. Net Watcher and Administer work without hassles, but anything requiring Remote Registry (System Monitor, REGEDIT, POLEDIT) needs a separate Bindery server to act as security provider. This is a SECUR32 bug in MS's NDS client that they admitted to in KB article Q143398. If you use the regular Client for NetWare on a DS network, you can use Remote Registry on machines that have the NDS client. So, if you can live without Remote Registry, or if you use the regular Bindery client on your Admin machine, you can treat the administrative setup like you would for a Bindery network. Of course you can't run NWADMIN then, but... I did manage to get Remote Registry running on an NDS network about the same time I got MSPSRV working. Remember where MS said you needed to have a separate Bindery server to provide security? Well... Win95 with FPS for NetWare acts as a Bindery server, so why not use another Win95 station as a security provider? It does work! And I was able to log in to the NDS tree and run Remote Registry, and NWADMIN, on other stations with users logged into the NDS tree, and FPS for NetWare worked normally too. This trick comes in handy if you also have multiple servers and you're running into the licensing problem I mentioned in section 6.13.12; this Win95 machine can also hold the policy file and not eat up any licenses on your "real" servers. Remember: You only need to do this if you want to use Remote Registry service on a Win95 DS client running MS's services for NDS in a DS network, and you're using MS's Services for NDS on the machine you're administering from. Net Watcher and Administer both work without this nonsense, and the standard Client for NetWare works with Remote Registry straight away. So here's what I did:
This is a lot of work really. At this point, most sysadmins would've probably gone to NT. 6.14. My suggestions for preparing an automated Win95 installation In the last few weeks (8 AUG 96) many administrators asked how they can copy Win95 to several machines at once. Well, they are trying to use XCOPY to copy the whole Win95 directory. Let me get one thing straight: THIS DOESN'T WORK!!!!!!!!! Why doesn't a straight XCOPY work?
OK? Image-copying Win95 doesn't work. Get over it. Would you image-copy a NetWare server? An OS/2 client? An NT client? No. So don't try to image-copy a Win95 client. Make a server based installation using the steps below, and automate as much of the setup as you can. This way, you can run a Win95 setup from the server and it would take just a little longer than a straight XCOPY would, but be a lot cleaner. So, if you're building a Win95 network based on NetWare servers, here's my suggestions. These come from my NDS experiments, so you can omit any references to the NDS add-on if you aren't using a DS network. I based this scenario on workstations that have their own hard drives (minimum 200 MB) and copy all Win95 files to the station. The stations themselves had these components automatically added to them:
Believe me, don't waste time with minimal shared installs if you can avoid it. You can do shared installs of the apps themselves later. The stations featured full client functionality, Queue Server capability as needed, and Remote Admin access. Optionally, you can replace FPS for NetWare with Client for MS and FPS for MS networks. The key to making Remote Admin work is to have some kind of file sharing service and some kind of security provider. FPS for MS networks does work with NetWare servers acting as a security provider. If you do this, make sure you make the NetWare login the primary login, and make sure the machines have enough memory to handle both clients. If you're doing this on 8 MB machines or you're tight on memory, just stick with the single client and services.
NOTE: If you want to maintain more than one Admin copy of Win95, yes, you CAN image-copy this Admin installation to multiple SERVERS. Make up one good Admin copy, then spread it to all your servers in your WAN if you choose. 90% of the NetWare networks out there have remote printers I'm quite sure people want to print to. There is no harm in installing MSPSRV on every machine (it only eats 64 KB of disk space, and it won't take up memory unless you invoke it), or Remote Registry, or File & Print Sharing if you disable file and print sharing controls via System Policies. If you add components to the server install AFTER you installed the workstations, you can usually copy said components from Add/Remove Programs/Windows Setup, then hitting "Have disk" and pointing to the server copy of Win95. Anything you can install using INFINST.EXE is installable from this control panel, and it will show in the list of components to choose from. Definitely see about including a [vcache] setting in a custom INF file you can create with INFGEN, and install it automatically for a maximum cache size (1024 KB) to make room for MSPSRV and Remote Registry. INFGEN.EXE is a very valuable tool for inserting custom settings. You can copy your computer's .INI or Registry settings to this .INF file, then install those settings to the server copy using INFINST. It's only available with the Win95 Service Pack's Admin edition. |
|
|