![[Update]](icons/update.gif){kind=icon}
![[New]](icons/new.gif){kind=icon}
Date: Wed, 10 Jan 96 15:12:00 -0800
From: Rich Graves <[email protected]>
Win95 can be configured to masquerade as a NetWare server/router. This will
cause rather severe problems in many situations. See the brief description
of the problem at http://rcr.csun.edu/ntg/win95.html#novell.
The CSUN page does not detail the steps to steal NetWare passwords with Win95,
but it's not hard to imagine. I believe InfoWorld, Communications Week, PC Week,
and most other trade publications covered the issue as long as nine months ago,
but Microsoft has not fixed the problem.
Another good explanation of the problem is at http://www-leland.stanford.edu/~llurch/win95netbugs/IPX-SAP-Bug.txt.
One of Microsoft's developers wrote a rather lengthy and only somewhat misleading response to this issue. It is saved at http://www-leland.stanford.edu/~llurch/win95netbugs/MS-SAP-Response.txt. The Windows 95 product manager told me on November 9th that this should be considered the official Microsoft position on the SAP problem.
Unfortunately, in public, Microsoft only acknowledges, by way of a highly misleading press release, a "Server Name Conflict Issue." By this they mean that if someone accidentally or intentionally names a Win95 box masquerading as a NetWare server (which Novell considers a copyright violation, by the way) the same as a real NetWare server, the server won't work. This is actually but a small subset of a larger problem.
Update 01/10/96 thanks to Scott McArthur: Microsoft Knowledge Base article Q130943 partially addresses this problem in a long footnote. They might improve the documentation further in the future. I suggest searching the Microsoft Knowledge Base for the latest "clarifications" from Microsoft.
Date: Thu, 07 Dec 95 10:15:00 -0800
From: Rich Graves <[email protected]>
Microsoft
acknowledges that the frame type used for IPX/SPX packets must be set
manually because the default "Automatic" frame type detection does not
always work. Most commonly this happens on very quiet or very busy multiprotocol networks.
You need to open IPX/SPX Compatible Protocol/Properties/Advanced and select it manually. There is a picture at http://www-dccs.stanford.edu/NetConsult/Win95Net/ipxprops.GIF.
Date: Wed, 27 Dec 95 14:56:00 -0800
From: Rich Graves <[email protected]>
Official information on Novell's Client32 NetWare Client for Windows 95,
which replaces Microsoft's client, is
available at
http://netwire.novell.com/home/client/client32/. At this writing, the
last update to the publicly available software was posted in early December.
Officially registered beta sites probably receive incremental updates.
Unlike some other computer companies, Novell has posted a reasonably open and honest FAQ. The only publicly discussed problem I don't see is that Client32 appears to be incompatible with Microsoft's NET command when run in a DOS box. This can be a major bummer if you use multiple network protocols.
Date: Wed, 27 Dec 95 14:59:00 -0800There have been many reports of Win95 clients causing NetWare servers to crash. [email protected] says computer magazines in the Netherlands are urging people not to install Win95 for this reason. Several things can cause this problem:
There are two ways to resolve the problem of packet bursts:
[nwredir]
supportburst=0
Date: Tue, 10 Oct 1995 20:00:00 GMT
From: ClubWin dude Ramesh and Rich Graves <[email protected]>
Just install the OS/2 namespace. This requires NetWare 3.12 or a patched 3.11. Most of
the time, it seems to work. If Win95 clients crash your server or something,
remove the OS/2 namespace and see the next question. I am not a CNE!
Don't ask me!.
Because of a little bug, Win95 will not use long file names on 3.11 servers when you use Policy Editor to tell it to do so. The easier workaround is to add the following to system.ini:
[nwredir]
SupportLFN=2
For more information on this problem, see
article Q137275
in the Microsoft Knowledge Base.
Because of another bug, you will probably need to apply the os2opnfx.nlm patch. One place to get it is ftp://ftp.novell.com:/pub/netware/nwos/nw311/311ptd.exe. The ReadMe for this patch says:
OS2OPNFX NLM 1409 02-02-93 7:10a This patch allows a user to use the "TYPE" command to view a file even though SCAN file rights have not been granted. Without this patch, if the user is granted all rights but the SUPERVISOR and SCAN file rights (including Read) the file still cannot be "TYPE"ed. This patch fixes this problem.[Um... yes. I'm sure it does. I don't think I want to know why Win95 cares.]
Date: Thu, 07 Dec 95 10:15:00 -0800
From: Rich Graves <[email protected]>
Contributions by [email protected]
(Ramesh Viswanathan) and
[email protected].
If you run POLEDIT (it's on the CD in admin\apptools\poledit) and open the registry, you can then go to Local Computer, Network, Microsoft Client for Netware Networks, and turn off use of long names on the server.
Alternatively, add the following to system.ini:
[nwredir]
SupportLFN=0
Date: Wed, 27 Dec 95 15:02:00 -0800
From: Rich Graves <[email protected]>
Contributions by Don Zimmer
([email protected])
and "ClubWin" member
[email protected] (Ramesh
Viswanathan)
By default, Win95 machines using Microsoft's 32-bit NetWare client do not receive NetWare broadcast messages. Novell recommends using their software instead.
You could also put WINPOPUP.EXE in your Startup folder. However, there's apparently no way to remove WINPOPUP from the task list or to stop users from quitting it.
Several people have also complained that WINPOPUP doesn't work for them, though we haven't been able to determine why. Please mail me if you have insight into this problem.
Novell's Client32 resolves this problem (and introduces some others).
Date: Tue, 10 Oct 1995 20:00:00 GMT
From: Rich Graves <[email protected]>
Yes, you can, with WinPopup, provided that IPX/SPX is your default protocol.
However, messages are limited to 38 characters, and there are other limits. See
article Q120223
in the Microsoft Knowledge Base.
Date: Wed, 27 Dec 95 15:06:00 -0800
From: Rich Graves <[email protected]>
Yes. Otherwise you won't be able to use NetWare servers. :-)
There is no authoritative answer to this question. It depends on which mix of bugs and features works best in your environment.
In a loosely "controlled" environment like mine, I have to support Microsoft's client, because it's the easiest to obtain and install, which means that people are going to use it anyway. Microsoft's client also seems to be the least likely to actually crash the Win95 machine. However, it is the most likely to crash your server.
You must use Novell's Client32 if you need one or more of the following features:
Date: Wed, 27 Dec 95 15:07:00 -0800
From: Rich Graves <[email protected]>
All publicly available updates to Windows 95 are available at the URL
http://www.windows.microsoft.com/software/updates.htm. You'll want
the NDS service, the shell update bug fix, and the security bug fix,
for starters. Please note that Microsoft's politically correct term for
these updates is "functionality enhancement."
Date: Thu, 07 Dec 95 10:15:00 -0800
From: Rich Graves <[email protected]>
Win95's built-in peer-to-peer sharing capabilities don't work over the built-in
IPX/SPX="compatible" protocol with share-level access control. You need to
enable user-level access control with an NT or NetWare server for authentication.
See article Q131354
in the Microsoft Knowledge Base.
In any case, you really shouldn't be sharing over IPX unless you really know what you're doing, because of the SAP problem, B.1. Sharing over SMB (NetBEUI or TCP/IP) is safer and faster.
Date: Tue, 10 Oct 1995 20:00:00 GMT
From: Rich Graves <[email protected]>
If your Novell NetWare login script contains a DISPLAY command with a very
long path, or uses an environment variable containing a very long path,
some information may not be displayed correctly. An internal buffer is too
small. Use a shorter path or environment variable.
See article Q132763
in the Microsoft Knowledge Base.
Novell's Client32 resolves this problem (and introduces others).
Date: Tue, 10 Oct 1995 20:00:00 GMT
From: Rich Graves <[email protected]>
If you are using a NetWare login script, INCLUDE and DISPLAY commands in
the login script that contain Universal Naming Convention (UNC) paths do
not work. The named files are not run or displayed. See
article Q135167
in the Microsoft Knowledge Base.
Novell's Client32 resolves this problem (and introduces others).
Date: Tue, 10 Oct 1995 20:00:00 GMT
From: Rich Graves <[email protected]>
If you are using NetWare login scripts that use lower-case drive letters, you need
to capitalize them. See
article Q132665
in the Microsoft Knowledge Base.
Novell's Client32 resolves this problem (and introduces others).
Date: Wed, 27 Oct 1995 15:10:00 -0800
From: Rich Graves <[email protected]>
If you need this functionality, use Novell's VLMs or NETX.
See article Q127794
in the Microsoft Knowledge Base.
Date: Thu, 07 Dec 95 10:15:00 -0800
From: Rich Graves <[email protected]>
Microsoft acknowledges that this is a problem with Win95.
See article Q130943
in the Microsoft Knowledge Base.
Do not turn on SAP, as Microsoft tells you to do, without considering the routing and security ramifications discussed in Section B.1.
Date: Tue, 10 Oct 1995 23:00:00 GMT
From: Rich Graves <[email protected]>
Microsoft recognizes this as a problem with Win95. You need to replace any commas in
your login scripts with ANDs, or use Novell's drivers rather than Microsoft's. See
article Q129145
in the Microsoft Knowledge Base.
Novell's Client32 resolves this problem (and introduces others).
Date: Tue, 10 Oct 1995 23:00:00 GMT
From: Rich Graves <[email protected]>
You need to use ODI drivers. See
article Q125425
in the Microsoft Knowledge Base.
Novell's Client32 resolves this problem (and introduces others).
Date: Mon, 2 Oct 1995 13:31:28 CST6CDT
From: Larry Field <[email protected]>
[email protected] (Larry Field) wrote:
>I'm using the Client for Netware as my primary logon client in Windows 95.
>However when I dial-up and login to my network I'm not getting the login
>script processed. I can go into Network Neighborhood and see my drives and
>directories on the network drive but I don't have any drive mappings, printer
>assignments, etc.
>
>Any ideas how I can get the logon procedure to execute the login script? I
>have the box checked that says "Process login script" so I'm at a loss as to
>why it's not processing.
Well I solved my own problem and here's the answer for anyone else
that experiences similar things.
My computer name in Control Panel | Network | Identification was the
same as my Netware logon name. Once I changed this it processes the
login script and maps all the drives just fine. I guess there's some
kind of conflict when the name of the machine and the logon id are the
same.
Larry Field
Sr. Systems Analyst
Texas A&M University
Date: Wed, 27 Dec 95 15:12:00 -0800
From: [email protected] (Gordon Fecyk)
I managed to get a WIn95 machine to act as RPRINTER using all 32-bit
services and clients! I only managed to get this working on a NetWare
3.11 environment so far, but the same applies to NetWare 3.12. 4.0 & 4.1
users can wait for Novell to clean up their Client32...
First off... Win95's PRTAGENT (this is what it's called on the Win95 CD, under ADMIN\NETTOOLS\PRTAGENT) requires exclusive access to a NetWare print server object. This means you need to create one separate Print Server object on the NetWare server for each Win95 station acting as RPRINTER.
Here's what each print server object looks like:
Each object has only ONE PRINTER, which is Printer 0, named "Printer 0". Set this printer to be a "Remote Parallel" printer using LPT1. You can tell it to use IRQ7 if you want.
Tell this one printer to service a particular print queue. A NW 3.1x server handles 16 queues, so pick one of them for this printer, within this print server object, to service.
OK now that you have a unique print server object for each Win95 machine running PRTAGENT, go to the machine in question and install "Microsoft Print Agent for NetWare", by adding it as a "service" in the network control panel. Hit "Have disk" and go to ADMIN\NETTOOLS\PRTAGENT.
After installing it, reboot.
Then, go to the printers folder and select the printer driver you want to service the Print Server object in the NW server. Select the Print Server tab, select the NW server and the Print Server object to service.
[More details might also be available in the Resource Kit and in the win95netbugs list archive]
Date: Thu, 07 Dec 95 10:15:00 -0800
From: Rich Graves <[email protected]>
If you have a non-English-language version of Windows 95, you can't, unless you
disable peer sharing and remote administration.
If you have the English-language version, get the patches from http://www.windows.microsoft.com/software/w95fpup.htm. Microsoft's clarification is incorrect (for starters, they didn't discover these problems; we know who pointed them out to them), but the patches appear to fix the problem.
Date: Fri, 13 Oct 1995 09:42:47 GMT0BST
From: Phil Randal <[email protected]>
[Just one of the liabilities of Microsoft refusing to participate in
NetWare interoperability testing.]
The Microsoft Windows 95 Netware Client does not recognize the
following two NetWare login script commands:
NO_DEFAULT and SET_TIME
They were introduced in version 3.65 of login.exe for NetWare 3.11 in
July 1992. I haven't checked the semicolons at end of strings, but
I'm almost willing to bet on it...
Here are the details from Novell's log365.doc dated July 20, 1992:
1) The current version of login does not recognize ;'s at the end
of a string in the login script. (The ; is used for string
concatenation.)
2) This version contains a NO_DEFAULT parameter to place in the
system login script. If a user login script does not exist, the
default login script will not be executed.
3) This utility also allows the user to specify if login.exe should
synchronize the workstation time with the file server time.
Currently, login always synchronizes the workstation time with the
file server time. This new LOGIN.EXE allows the user to specify
if this synchronization should occur by using a new command in the
login script. It is as follows:
SET_TIME [ON | OFF]
SET_TIME OFF will not synchronize workstation time with the file
server when logging in.
SET_TIME ON will cause the workstation time to synchronize with the
file server time when logging in. (default)
Date: Fri, 06 Oct 1995 11:25:30 -0800
From: Rich Graves <[email protected]>
Microsoft never acknowledged this bug, but they did fix it. The problem is that
under circumstances that have not been isolated, .PWL files can be created that
allow access to NetWare servers without even logging in. Among the people who
have seen this are Stephen R. Davis <[email protected]> and Gary Flynn
<[email protected]>.
Date: Tue, 10 Oct 1995 07:20:58 GMT
From: [email protected] (Ramesh Viswanathan)
Just ask Novell:
http://netwire.novell.com/ServSupp/client/win95/pnwfaq.htm
Tijs Coumans claims the same basic instructions work for NetWare Lite, though Novell says they don't.
Date: Sun, 15 Oct 95 09:28:23 -0700 From: MicrosoftSee Microsoft Knowledge Base article Q136591, http://www.microsoft.com:80/KB/PEROPSYS/win95/Q136591.htm.
Date: Wed, 1 Nov 1995 22:40:15 -0600
From: Eric Helfgott <[email protected]>
This is actually a very interesting bug in Win 95 which Microsoft denies
the existence of. Win 95 can actually be configured to cache both the
Windows and Netware passwords so that a user booting the system will
automatically be logged onto a netware network need not type any
password whatsoever - for Windows or Netware. If the .pwl files being
generated are ~900 byes long versus the regular 600 bytes, your system
is doing this. Naturally this bypasses any and all security of netware
networks.
My system behaves this way; and I can actually use it to create .pwl files for other systems which bypass the netware security on those systems as well. Microsoft claims this only works for "null" netware passwords - which is simply not true, but the system must be tricked into generating these .pwl files. As proof, if you wish to have such a .pwl file please request so of me via Win 95 Netbugs and I'll generate one for you which does this.
To stop your system from generating these pwl files, just delete all of those in your Windows directory, and change the primary network logon to Windows and then back to Microsoft Client for Netware and your system will stop generating these security killers. I actually find the bug useful for PCs in secured areas which one may wish to remotely reboot using remote access software like Stac Electronic's Reachout. :)
Eric Helfgott
Systems Engineer
Drug Intervention Services of America, Inc.
Date: 7 Nov 1995 20:29:02 GMT From: George ShawIn the Control Panel,Power Icon, if you turn "Off" Power Management, the mappings seem to quit going away. Damned if I can figure out why this works, but it does.
Date: 29 Dec 1995 20:30:00 PST
From: Rich Graves <[email protected]>
Lloyd Williams and a dozen others have reported this. This
is true. VLMs, Microsoft's Client for NetWare Networks, and Novell's Client32
do not have this problem. Novell doesn't really recommend using NETX nowadays
anyway...
Date: 29 Dec 1995 20:43:00 PST
From: Rich Graves <[email protected]>
It's not easy, but it can be done. See win95boo.txt and other files on JoeD's
machine, netlab2.usu.edu. Look in the
misc (not pub/misc) directory.
netlab2 is running Novell's brain-dead FTP server that does not support passive mode or many other modern niceties, so if your FTP client gives you an error message, try the UNIX or DOS command-line FTP clients.
Actually, since people seem to have trouble reading the above sentence, I'm now sort of mirroring these files, with JoeD's OK. The URL is http://www-leland.stanford.edu/~llurch/win95netbugs/From_JoeD/