ftp.pasteur.org/FAQ/

home *** CD-ROM | disk | FTP | other *** search

/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / windows / win95 / faq / part06 < prev next >

Wrap

Text File | 1998-11-09 | 59.3 KB | 1,171 lines

Newsgroups: comp.os.ms-windows.win95.misc,comp.os.ms-windows.setup.win95,comp.os.ms-windows.networking.win95,comp.os.ms-windows.apps.compatibility.win95,comp.os.ms-windows.apps.utilities.win95,comp.answers,news.answers Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsfeed.sgi.net!feeder.qis.net!newsfeed.cwix.com!204.174.67.209!news.bctel.net!srv4.reelwest.bc.ca!not-for-mail From: gordonf@intouch.bc.ca Subject: Win95 FAQ Part 6 of 14: NetWare (tm) Networking Message-ID: <19981108.8D7FAB8.1237E@ras4vpn10.reelwest.bc.ca> Date: Sun, 8 Nov 98 20:10:40 Approved: news-answers-request@MIT.EDU Followup-To: comp.os.ms-windows.win95.misc Summary: These postings list many questions asked in said newsgroups, and answers them as best as I can. I make references to other Web sites and FAQs when appropriate. Visit the WWW home of this FAQ (http://www.orca.bc.ca/win95) for the appropriate links. This section is the 6th: NetWare (tm) Networking Organization: Personal and Win95 FAQ maintainence X-NoSpamWanted: This address is not for unsolicited commercial e-mail X-ImNotKidding: By sending UCE to this address you agree to pay $50.00 CDN X-pensive-spam: Payable to G. Fecyk, c/o P.O. Box 373 Oakville, MB R0H 0Y0 X-ploded-spams: Stop e-mail trespassing. <http://www.orca.bc.ca/dul/> X-federal-bill: Section 302, HR3888 / S1618, R.I.P. Lines: 1147 Xref: senator-bedfellow.mit.edu comp.os.ms-windows.win95.misc:326152 comp.os.ms-windows.setup.win95:77830 comp.os.ms-windows.networking.win95:59633 comp.os.ms-windows.apps.compatibility.win95:17898 comp.os.ms-windows.apps.utilities.win95:62526 comp.answers:33785 news.answers:143971 Archive-name: windows/win95/faq/part06 Last-Modified: 1998/11/08 Posting-Frequency: Every two months URL: http://www.orca.bc.ca/win95/faq6.htm Subject: 6. Novell NetWare (TM) Networking * 6.1. How do I connect to NetWare servers? * 6.2. What do I have to do to make the NetWare server work safely with Win95 clients? + 6.2.1. NetWare 2.x + 6.2.2. NetWare 3.x + 6.2.3. NetWare 3.12 + 6.2.4. NetWare 4.x (Directory Services) * 6.3. How to I make NetWare-related TSRs work? They won't work in the login script. * 6.4. How do I use a client other than Microsoft's Client for NetWare? + 6.4.1. NETX + 6.4.2. VLM + 6.4.3. Client32 * 6.5. How do I connect to the server from Single mode DOS? (Outside of Win95) * 6.6. How can I receive NetWare pop-up messages? * 6.7. Why don't I get a login prompt when Win95 starts? * 6.8. What bugs should I watch out for? Where can I get fixes? + 6.8.1. Automatic frame detection doesn't work + 6.8.2. NetWare C$ peer sharing bug + 6.8.3. WAN routing tables keep getting trashed + 6.8.4. Password caching bugs o 6.8.4.1. How do I disable password caching? + 6.8.5. Server ABENDs when I start a Win95 client (and other bugs) * 6.9. Top ten NetWare client mistakes * 6.10. What does Novell's Client32 offer that Microsoft's Client for NetWare does not? * 6.11. What's this I heard about MS's client only being NetWare 2.2 compliant? * 6.12. How do I share my hard drive or printer to other NetWare users? (Avoid if possible!) + 6.12.1. How do I share my printer through RPRINTER or PSERVER instead? + 6.12.2. ...on a Directory Services network? (NetWare 4.x) * 6.13. How do I make Win95's cool network features work on NetWare? + 6.13.1. System Policies + 6.13.2. System Policies on a Directory Services network + 6.13.3. Group Policies + 6.13.4. User Profiles and Roving Desktops + 6.13.5. User-level Security + 6.13.6. Remote Administration + 6.13.7. Remote Admin on a Directory Services network * 6.14. My suggestions for preparing an automated Win95 installation and workstation replication 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. :-) 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. This lets you use Exchange or MS Outlook clients and not have to change your mail server. ------------------------------ Subject: 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. ------------------------------ Subject: 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 netwire.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: * 6.2.1. NetWare 2.x 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. * 6.2.2. NetWare 3.x 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 * 6.2.3. NetWare 3.12 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. * 6.2.4. NetWare 4.x (Directory Services) 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 complete disk set. 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 (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.exe 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 ------------------------------ Subject: 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. Place winstart.bat in your Win95 directory where it will execute 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. ------------------------------ Subject: 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. * 6.4.1. NETX: Novell no longer recommends running netx.exe, 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. * 6.4.2. VLM: 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. * 6.4.3. Client32 Much of the Client32 stuff that was here is unavailable as of September 1998. Novell now has an even larger client install (11 MB!) available from their Download site. You can bet that, when I dust off my NetWare 4.11 demo CDs again, I'll be trying this. ------------------------------ Subject: 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 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. ------------------------------ Subject: 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. There are numerous Winpopup replacements available for download as of September 1998. Most of these can force-start and even prevent the user from stopping them. 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. ------------------------------ Subject: 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. ------------------------------ Subject: 6.8. Bugs to watch out for, and patches * 6.8.1. Automatic Frame Detection Bug: 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. * 6.8.2. NetWare C$ peer sharing bug: If you use Remote Administration, it may keep the Admin share active after you disconnect! Apply Service Pack 1 to fix. * 6.8.3. WAN routing tables keep getting trashed: 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 Novell's downloads site 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. * 6.8.4. Password caching bugs: 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. * 6.8.4.1. How do I disable password caching? Set up a system policy file, and include "Disable Caching of Login Password" or "Disable Password Caching" in Default Computer/Network. * 6.8.5. Server ABENDs when I start a Win95 machine (and other bugs): 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. ------------------------------ Subject: 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) ------------------------------ Subject: 6.10. What does Client32 offer that MS's client does not? Well, this is rhetorical since Novell no longer supplies Client32. Grab Novell's 11 MB client download. ------------------------------ Subject: 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. ------------------------------ Subject: 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... * 6.12.1. How do I share my printer through RPRINTER or PSERVER instead? 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. 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. UPDATE September 1998: Microsoft released bugfixes to a LOT of the problems documented here. The files needed, however, appear unavailable for download. According to KB article Q132786, the following three files replaced will correct them: * MSPSRV.EXE v4.00.952 * NWPP32.DLL v4.00.952 or later * NWREDIR.VXD v4.00.952 or later These come with Win95 OSR 2.1 and 2.5, but I've prepared a special download that contains these updated files in case you don't have one of these releases (minus NWREDIR.VXD because I only had the NDS version). 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! 1. Select the Print Server tab and turn on "Enable print server for NetWare". If you get any evil error message just ignore it. 2. Select the NetWare server with your new pserver object, from the DROP DOWN LIST, even if it was already selected. 3. Select the pserver object you just created from the NetWare server drop down list. 4. Select how often you want this computer to check the queue for print jobs. The 30 second default is fine. 5. Hit OK. 6. Hit Start Menu/Shut Down, close all programs and log in as different user, and re-log in. Now all jobs in that NetWare queue will find their way to this printer. 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. * 6.12.2. ...on a Directory Services network? 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): 1. Use PCONSOLE's Quick Setup option, in NDS mode, to create an NDS queue (Q1), printer (P1), and print server object (PS-INLINE). If you already have an NDS print server object, be sure to specify a NEW print server object and not use any existing ones. 2. Change the new printer object (P1) so it uses LPT1, IRQ 7, "Change forms as needed", and have it service the NDS queue (Q1). 3. Switch PCONSOLE to Bindery mode (Press F4), edit the Bindery queue (Q1) so its settings match the NDS queue. Add the Bindery print server object (PS-INLINE) to the list of print servers for this queue. 4. Edit the Bindery print server object (PS-INLINE) so its settings match the NDS print server object, and create a Bindery printer within this object with the same name as the NDS printer object (P1), and the same settings (printer number 0, LPT1, IRQ 7, Change forms as needed). Have this Bindery printer service the Bindery queue (Q1). The big catch is that Bindery configurations aren't accessed by NDS objects, or vice versa, as PCONSOLE's warning tells you. Heed that warning. 5. With all that accomplished, the NDS objects and Bindery equivalents will work together as if they were one set of objects. Now, go to the Win95 station running MSPSRV and have it service this print server object (PS-INLINE) as per the regular instructions. If you're switching an existing queue to this new print server, you'll need to stop and re-start PSERVER.NLM on the server so it won't try to service that queue anymore. 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. Rob Menasco outlined a few additional things to watch out for: * Go through the Print Server tab and reselect all items, click on "Apply". (This is documented in the MSPSRV KB article above; reselect the print server from the drop down list) * Re-boot, make sure print server is active. I do a USERLIST from DOS and look for an attached print server in PCONSOLE. * In the Spool button on Printer Setup: Set to "Direct Print" and "Bi-Directional". This fixes the unknown system error. (I gather this is so MSPSRV writes to LPT1: directly, rather than through the Win32 print API) * Watch for the source or error messages. The Spool errors come from SPOOL32 or the PRINTERS folder. * Watch for Rights problems (Use WINDOWS_PASSTHRU account; make sure it has rights to the spool). ------------------------------ Subject: 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: * Use IPX Maximum Connections and Maximum Sockets values of 32 each (70 if using MSPSRV too) * Create a separate Administrators group if you have a team of administrators to simplify setting up Admin permissions. * Set aside lots of space (250 MB total about) on your SYS: volume for user profiles. (About 200 KB per user) * Install any patches needed to make long filename support work, in fact, install the base OS patch set for your version of NetWare. * Create a WINDOWS_PASSTHRU user with 0 KB disk space limit, a blank password, and no privileges whatsoever. (This is so you can administer workstations that don't have anyone logged in to. You can do without this account, but someone will have to log into that station before you can remotely administer it. Kinda pointless actually.) So here's how to do all those cool features... * 6.13.1. System Policies 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: * Network path for Windows files * Remote Update: Automatic (Use default path. In this case, the default path is \\loginserver\SYS\PUBLIC\CONFIG.POL) * Disable/Enable Long Filename support (You have three choices here, disable, enable, enable for NW 3.11 or older servers) * Disable Password Caching * Disable File and Print Sharing Controls (Remote Administration still works) * Disable Automatic NetWare Login * Preferred Server * Disable SAP Advertising * User-Level Security (Use your server's name as security provider) * 6.13.2. System Policies on a DS network 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 separately 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): * Load NetWare DLLs at Startup (To make some dumb NDS apps work. Also copy the DLLs themselves from SYS:PUBLIC\CLIENT\DOSWIN to SYS:PUBLIC) * Allow only NDS logins (To prevent User Profile and System Policy screwups) 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. * 6.13.3. Group Policies 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. * 6.13.4. User Profiles and Roving Desktops 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. * 6.13.5. User-Level Security 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) * 6.13.6. Remote Administration 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. * 6.16.7. Remote Admin on a DS network 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: 1. Set aside one Win95 computer (an 8 MB machine will do) and install Client for NetWare and FPS for NetWare. No other clients or services. Have its User Level Security settings point to your NDS server. Check that server's Bindery context so it at least has your Administrators' user names available. On that one machine ONLY, turn on SAP advertising and turn off Workgroup advertising. You might want to get the latest patches for NetWare 4.1, to prevent SAP traffic from killing any routing in your network. This machine won't work with Remote Registry, so don't bother installing it. 2. On all the other Win95 machines running NDS, change their User Level Security settings to point to this one Win95 machine. They can still have their original Preferred Server and Preferred Tree defaults the way they were. See that all these machines have Remote Registry service and FPS for NetWare, and they have SAP turned OFF. You can do this through System Policies, but the machines will have to re-boot once to make this take effect. 3. After rebooting the other Win95 machines, change their Remote Administration settings so they include users from the emulated Bindery on the security-providing Win95 machine. You can even specify this machine, if you wish, in MSBATCH.INF during a Win95 installation. 4. At this point, all Win95 stations except one are using that one Win95 machine for a security provider. That one machine is using the NetWare 4.1 server as a security provider, mirroring its user list. Remote Registry services will work as they did for the original Client for NetWare. If it prompts you for a password, use your login name and password. 5. (Optional) You can even enforce this via System Policies; you can add the single machine to the CONFIG.POL file (File/New Computer...) and have it use the NetWare 4.1 server for security and turn on SAP. Have the Default Computer settings use that one machine as provider, and turn OFF SAP. This way you don't have to go to each machine to change their security provider settings. This is a lot of work really. At this point, most sysadmins would've probably gone to Windows NT. ------------------------------ Subject: 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? * Long filenames * 20 MB of hidden files * Registry * Unique IO.SYS and MSDOS.SYS * Program Files directory * Different system device drivers for different motherboard chipsets! 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: * Client for NetWare Networks * IPX/SPX Protocol * Net card driver of your choice * File and Print Sharing for NetWare Networks * Microsoft Remote Registry * Microsoft Print Agent for NetWare * Services for NetWare Directory Services 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. 1. Download and install the base OS patch sets for all your NetWare servers, and download the Admin edition of Win95 Service Packs. 2. Make an Administrative installation of Win95 using NETSETUP.EXE on one, or more, of your servers. You will need to prepare one Win95 client to perform the Admin installation from, and this machine will probably become your admin workstation. Prepare this Admin machine just like you would any of the targets. You could also make up your policy file using POLEDIT.EXE, and copy it to the server. 3. Use INFINST.EXE to apply the service pack to the Admin copy. Run INFINST, give it the Admin copy's UNC path (\\server\SYS\PUBLIC\WIN95 or whatever), give it the path to the Admin service pack, and let it install. 4. Keep using INFINST to apply the needed additional components (Services for NDS, Remote Registry, MS Print Agent, etc) to the Admin copy. Remote Registry and Print Agent are on the CD-ROM in ADMIN\NETTOOLS\REMOTREG or \PRTAGENT. Don't forget to include the Group Policy support here too, if you have group policies. 5. Exit INFINST and run BATCH.EXE (The new version that comes with the service pack) and make all the settings you need. In the list of Services, pay special attention to the ordering of services (NWREDIR4, NWSERVER, REMOTEREG, PSERVER) for those three, because MSPSRV (the PSERVER entry) will balk if you add PSERVER before NWREDIR4. I know it sucks. You can switch them around later if you need. Use BATCH.EXE to make any settings you want for the automated install, but be extra sure to keep "Immediately re-boot PnP and PCI machines" turned off to prevent Setup from exiting prematurely. COOL TRICK: Use BATCH.EXE's "Read settings from Registry" to copy the Admin machine's settings. Finally, save the settings with filename MSBATCH.INF to the Win95 Admin copy's directory. 6. Make up a network boot disk so you can access the server, and boot up a target workstation so you can try installing Win95. Keep the Admin machine on and logged in so you can make quick fixes during this test. 7. As Setup runs, you should be allowed to install the right net card driver. Also, when that network screen comes up, make sure you don't get any errors about "Print agent cannot be installed with...". If you do, change the ordering of services back in BATCH.EXE and try again. Cancel the Setup here and try again, until said message does not come up. PRTAGENT should be the LAST entry in the Services box back in BATCH.EXE. 8. Pay attention to any error messages that occur during file copying. You will probably get an error that it couldn't find MSNDS.BAT or some such file. If so, go to your ADMIN machine and copy the needed files from the NDS client copy to the shared copy of Win95, then hit "Retry" on the test machine. You will only have to do this ONCE; since the file now exists it won't complain the next time you try. 9. During the second part of Setup, if you get any messages saying it found new hardware and it wants you to re-start the computer, hit "NO" so Setup can finish. Wait until Setup finishes before allowing the system to re-boot. 10. After Setup finalizes the settings, check to make sure everything works. Inspect the network properties so all your settings took as you specified. You can then do some final tuning, like setting the [vcache] entry in system.ini, and take whatever settings you did in your final tuning, and use INFGEN.EXE to have them install automatically next time. 11. Once you're comfortable with your automatic setup, make a few copies of that boot disk and happily start making workstations. You can continue to add components to this server copy and install from them as needed (like the dial-up scripter, Ben Goetter's Widgets for Exchange, etc). 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. -- ============================================================================== = I am Gordon of Winterpeg. Junk mail is futile. Post MakeMoneyFast = = Find out why: http://spam.abuse.net/spam/ Or eat pink meat from a can = = World's best computer: http://www.amiga.de/ they're both the same = = Windows 95 FAQ: http://www.orca.bc.ca/win95/ http://ga.to/mmf/ = ==============================================================================