
------------------------------------------------------------------
NOV-W953.DOC -- 19970801 -- Email thread on NetWare and Windows 95
------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




Date: Fri, 25 Oct 1996 12:41:00 -0400
From: "QUIBELL: MARC" <txh8205@TEXCOM-HOOD.ARMY.MIL>
Subject: Re: WIN95 apps on NW4.1

>We have only recently begun running Windows 95 on some of our
>workstations.  All network apps have been DOS/WIN based, so far.
>
>I know that some systems need namespace support, but I'm unclear on
>whether or not this is true for WIN95.  Can I just install the W95
>apps to Novell as usual, or is it more complicated than that?

If your planning on moving long filenames to and from the file server from
32-bit programs, then not only will you need to add a long filename
namespace, but also will need a Network client to support this file
transfer. Client 32 will support LFN transfers, VLMs will not. If you are
going to run only 16-bit applications, then I wouldn't worry about LFN
support...Remember this before purchasing 32-bit network applications. You
must also be equipped with a 32-bit client, along with your 32-bit
operating system and 32-bit namespace.

------------------------------

Date: Fri, 25 Oct 1996 14:32:29 -0400
From: Jason Lester <jlester@NAXS.COM>
Subject: Re: Client32 Win31 Login

>Has anybody had similar problems:
>
>(Some) programs that run fine with a dos login fail in a variety of ways
>when used with a windows based login.
>
>We need to run programs from the login script.  Sometimes the script log box
>shows following error - sometimes it doesn't.  User does not matter.  Admin
>or guest get the error if they are going to get it.
>
>the login script line is
>#c:\command /c g:\login\update g:\login\starnav.scr
>
>the box shows:
>Error returned from '#c:\command /c g:\login\update g:\login\starnav.scr'
>command: 17

I had the same problem, it seems that you have to specify the extension
also.  On my system, #UPDATE wouldn't work, but #UPDATE.EXE would.  I'm not
sure if it's program related or a bug/feature of Client32.

------------------------------

Date: Sat, 26 Oct 1996 15:53:27 MST/MDT
From: "Evan J. Felix" <evanf@BADGER.SNOW.EDU>
Subject: Re: Capture for DOS printing

>>Need to use CAPTURE for DOS printing.
>>We are NW4.1 and run either the Novell or the MS 32 bit client.
>>When I setup the WIN95 printer icon I was given a choice to capture a
>>queue assignment (//FSCMLS/LAB_QUEUE) to a port such as LPT2: which I did.
>
>>I also can #CAPTURE within a login script. I do that in a Profile login
>>script e.g..
>
>>I have both of these enabled on a machine that runs Novell 32 bit client
>>for WIN95. Obviously I messed up somewhere; the machine locks as soon as
>>the CAPTURE window opens.
>
>>Could somebody please be so nice to set me straight on this issue?
>>Thanks in advance for your help.
>
>We are running the same type of configuration.  The only reason the capture
>statement is necessary is when you're printing from DOS.  Otherwise, when you
>install a printer in win95, and set it as your default printer, as long as
>you're on the network, it works, otherwise it holds it until the next time
>you restart and asks if you want to print them or delete them.
>
>We use a capture line to capture it for dos:
> #CAPTURE P=BEAVER NFF NB NT TI=5
>Windows 95 leaves the DOS window open unless you select the properties of the
>windows and tell it to close on exit, with which it creates a pif file where
>you can change some of the settings.

An easier and much simpler way is to put a @ instaed of the #, that
way win95 doesent wait for the capture window to close, it just runs
it and goes on.

------------------------------

Date: Tue, 29 Oct 1996 13:43:17 +1000
From: Michael Strasser <M.Strasser@MAILBOX.UQ.OZ.AU>
Subject: Bug in Win 95 Client32 2.11

I've just downloaded the new Client32 for Windows 95 and have found a
problem with it immediately. When logging in to our NetWare 3.12 server
from Windows 95, a small Win32 program is run that checks for new mail and
faxes and reports any using a message window. The log in process crashes
as soon as that program is run.

During an automatic login the error is in MPREXE when it calls
LOCWIN32.DLL and the machine is locked up tight. During a manual login the
error is in LOGINW95.EXE calling LOCWIN32.DLL: the PC doesn't lock up, the
login is successful but the remainder of the script doesn't run.

I know that scripts are not strictly necessary under Windows 95 but
they help me to manage things centrally.

The SetupNW Help file warns against multitasking when logging in (and
mentions that MPREXE might crash), but the Win32 program works fine with
version 2.1 of Client32 so I consider the behaviour of 2.11 to be a
bug.

------------------------------

Date: Fri, 1 Nov 1996 12:41:10 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Windows Batch files for WIN-95 or WIN-NT

>I am looking for a BATCH program for Windows-95
>and WIN -NT.   I have one for Windows 3.1 that runs
>great and is free.  (BATSH220).
>
>I need to map a drive to a Novell server, start the
>application and then remove the mapping and exit
>the the batch program.   BATSH.exe was freeware
>and I am hoping for the same price!
------------
	You don't need one! Win95 provides that facility already. Yes,
really. Please fetch either w95inst7.zip (PowerPoint v7) or w95insps.zip
(Postscript for same) from directory misc on netlab2.usu.edu. See near
the end the START /W  command and the example of running a .BAT file
within which is also a Windows program (Autocad/Windows in the example).
	Joe D.

------------------------------

Date: Tue, 5 Nov 1996 14:06:37 +0100
From: Steen Rahbek <SR@DFM.DTU.DK>
Subject: Re: Novell Client for Win95 Question

>I have a customer who maintains no password on their Novell 3.12
>server account and does not want to prompted for one when loggin in
>using the Microsoft client for Novell Networks. When logging on now,
>he is forced to click on OK even in the absence of a password on the
>server. Does anyone know if it is possible to do this and if so, how?

Even if it's a little 'off topic', I've had the same problem, we don't
use the Win95 password for anything, but FORCE users to have a NetWare
password.

Microsoft has an article  (Q152104) which tell you how to get rid of
the 'stupid' Win95 password, you can get the article at:

  http://www.microsoft.com/kb/articles/q152/1/04.htm

------------------------------

Date: Fri, 8 Nov 1996 13:58:34 -0600
From: Steve McHargue <SMCHARGUE@JW.COM>
Subject: Re: Capture and Win95 [added: Mapping]

>I am currently setting up a number of computer labs on a college
>campus with Win95. For the most part the UNC printing works well but
>in a few cases students need to print from DOS, thus my problem. If i
>set the capture in PRINTER|PROPERTIES|DETAILS it works fine until
>someone else logs into the network from that machine. It then asks if
>they want to connect as the original user who set the capture (they
>of course do not know my password, I HOPE) , when they say no it
>effectively flushes my capture down the toilet.
>
>Is there a way to set a DEFAULT QUEUE for specific machines and
>have them capture regardless who logs in ? ( other than adding a BIG
>batch file containing physical addresses  to the server to differetiate
>which lab the machine is in and which queue to use)

Here's what we do, I'd love a more elegant way: Win95, Client32 and NW
3.12

On each machine we set DPQ=xxx
DPQ stands for the Default Print Queue, xxx is the desired print queue
for this machine.

In the login script we just run capture Q=%<DQP>

That seems to workaround the problem.

Of course the problem is Win95 philosophy that a print capture is a user
resource and not a machine resource. Where I would consider drive
mappings something that needed to follow a user around regardless of
where they login a printer is something that is logically if not physically
tied to a machine location, don't you think?

------------------------------

Date: Wed, 13 Nov 1996 14:12:45 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: MS Networking not compatible with Win95 with VLM's?

>The problem is *not* sharing *from* the VLM workstations, but *accessing*
>*other* "normal" installations of Win95.  These other Win95 machines that
>are sharing their files/printers are obviously working...
>
>Basically the issue is that our students have their personal Win95 machines
>with sharing enabled, but since we need to use VLM's in our computer labs
>so we can run Win95 off of our file server, the students cannot access
>their dorm machines and we continue to get the occasional question of "why
>can't I see my computer?"  We do provide home directories on the server,
>but the students seem to still want to access their own machines.
------------
	As one of the people behind the "MS advertizing over IPX is evil"
may I add a few comments.
	First, never let folks advertize MS products over IPX, as the sign
above indicates. They pretend to be NW file servers (old, crippled) but
are not. NW clients can readily trip over them and end up connectionless
or taken for a one way ride on a trojan horse, and other bad things which
should never happen if users are not allowed to control the network.
	Second, there is no need for MS products to advertize over IPX.
	Third, NetBEUI is a crummy NetBIOS thing, not routable. But NW
servers can be told to bridge "type 20" (NetBIOS) packets. It's not a good
idea in any case.
	Fourth, people can use NetBIOS over TCP, named "RFC-NetBIOS" and
achieve routability and maybe even a tad of respectibility.
	Fifth, to ensure stray users do not disrupt the network use strong
filtering on your routers which let through IPX RIP/SAP for only an approved
list of NW machines. One must, really must, filter traffic on large nets.
	The time will come when a license to transmit will be needed before
attaching emitters to the network. That license can be as gentle as needs be,
but matters are cleared beforehand. The common good requires it. Our gentle
license is one must register an Ethernet board address in our master bootp
server database (no cost, trivially easy computer-based form), or suffer the
hub port being disconnected.
	Reading material: win95sap.txt in directory misc on netlab2.usu.edu,
or equivalently for the web browser limited, pub/mirror/misc on
netlab1.usu.edu.
	Joe D.

------------------------------

Date: Thu, 14 Nov 1996 16:51:00 PST
From: "Orde, Angus [CSU]" <A.Orde@LMU.AC.UK>
Subject: Re: Latest client32/win95 caused error on login process

>I had installed latest client 32 for win95 by extracting 95enu_n2.exe
>and runiing setup.exe under directory "english". (My win95 version is
>for Traditional Chinese anyway.)
>
>Everything seems OK.
>However, when I tried to login to a 3.11 Netware Server, the error
>message box with title "mprexe" appeared and I was forced to reset my
>computer.

The same thing happens to me.  The problem is the execution of the Login
Scripts. Turn them off, and it works fine.

There are a number of possible fixes (none of which work for me - any
additional help would be greatly appreciated), which may help you.
Additionally, you could uninstall Client32 entirely (using UNC32.EXE) and
reinstall - might work...



SYMPTOM

The following errors have been received on a Windows 95 client using
the Novell's Client32, usually at the begin or during the login
script processing:

General Protection Fault in MPREXE.EXE

MPREXE caused invalid page fault

MPREXE: This application performed an illegal operation and will be
shut down.

MPREXE caused an illegal page fault in module kernel32.dll

The following error was received when dialing out, when the station
was docked, or when using the dialup PPP connection:

MPREXE caused a stack fault error in Kernel32

CAUSE

MPREXE.EXE is a Microsoft file that allows Windows 95 to have
more then one client and protocol.  MPR stands for Multi (or
Multiple) Provider Router.  It's primary function is to route
incoming and outgoing packet between the adapter and different
clients.

SOLUTION

The following is a list of known solutions to a MPREXE error:

1.  Removing HIMEM.SYS from the CONFIG.SYS file will, in some
cases, resolve this error.  To do this, restart the computer,
press F8 when seeing "Starting Windows 95" on the top of the
screen, then select the option "Command prompt only" in the menu.
You will then be on a dos prompt.  Use EDIT to modify the
CONFIG.SYS and reboot the computer.

Two comments concerning this solution:

	a. Although HIMEM.SYS has been removed from the CONFIG.SYS, it
	will still be loaded by Windows 95 (it is needed to access the
	extended memory), but somehow that prevents the GPF from
	occurring.

	b. After removing HIMEM.SYS, you will not be able to load
	EMM386.EXE anymore, which means that you will not be able to
	enable the upper memory area.  As a consequence, all device
	drivers and TSRs will be loaded in conventional memory.

2.  Another solution to resolve this error is to delete and recreate
all the network printers defined.  To do this, remove HIMEM.SYS (see
above) and restart the computer.  When in Windows 95, go into the
printer folder and delete all the network printers.  Then, edit the
CONFIG.SYS to put back HIMEM.SYS and restart the computer.  Then,
recreate the network printers.  This solution is better than the
first one since you will still be able to load device drivers and TSRs
into upper memory, if needed.

3.  It has been determined that the MPREXE error has occurred when
attempting to capture during the Login Script with certain
conditions. The two solutions for this situation are:

	a. In a NetWare 4.1 environment, login to the Directory Tree
	instead of a Server by editing the properties for Client 32,
	Login Tab and selecting "Log in to Tree".

	b. Remove the capture statement from the Login Script and
	capture the print queue using Windows 95 network printer
	configuration.

4. Using the map change command in a login script could generate a
MPREXE error.

	For example:  map c ins W: s3:

Currently the only solution is to not use the map change command in
your login script.  This issue will be resolved with the next
release of Client32

5.Check the hardware specification of the computer if it ships with
Matrox Millenium video cards (MGA) . The shipping version of this
driver for the Matrox Millenium video cards (MGA)  will cause this
error. New drivers that solve the problem can be obtained from Matrox
at www.matrox.com/mgaweb/ftp.htm. The following computers were found
with this video card built in:
	Gateway P166 machines
	Compaq Deskpro 6000

6. In the case of using a dailup adapter and receiving a MPREXE
error, removing Microsoft's IPX/SPX compatible protocol and Novell's IPX
32-bit protocol from the dialup adapter bindings resolved the error.

In this case, TCP/IP was the only protocol required for the dailup
adapter.  In other situations, however,other protocols will be
required and further research will be needed to resolve the issue.

7.  Disable the GUI Login and run it from the startup folder. To
disable the Client 32 GUI login, create or modify the following
registry entry:

set 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Netw
ork\Real Mode Net\AutoLogon'  equal to 000 00.  If creating the
AutoLogon Key, right click on RealMode Net, choose New and Binary.
The value 0000 00 means no login on bootup.  000 01 means Login on
bootup.

8. Ensure that the SET PATH statement in the autoexec.bat is less
than 80 characters.  The path statement can be broken into multiple lines

which can be used to append together a statement that is longer than
80 characters.

	Example
	PATH C:\WINDOWS;C:\WINDOWS\COMMAND
	PATH C:\NOVELL\CLIENT32;%PATH%

9. MAP a regular drive to a server in the tree that has the master
replica.

10. Gateway P60 machines with bios revision 1.00.03.AF1 will not run
with Client 32 (Dos/Windows or Windows 95). Updating the bios to
revision 1.00.06.AF1 (available form Gateway) will resolve this
problem.

11. Remove references in the login script to invalid DS objects.
When the DS has been altered, but the login script still references an
invalid objects, this has caused this error.

12. Install the latest Client32 for Windows 95 that ships with
NetWare 4.11.

In rare cases when nothing else has worked, reinstalling Windows 95
on the workstation has resolved the issue.  It is important to recreate
the registry files during the reinstallation by completely deleting
the existing Windows 95 configuration from the hard drive prior to
reinstalling.

------------------------------

Date: Thu, 14 Nov 1996 15:03:09 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Novell Printing on Win95

>Novell provides two choices:  Nprinter with VLMs and a beta NPTR95.EXE
>to run Nprinter with Client 32.  I have no experience with Novell
>Betas, but if you trust it it may work for you,  I'll wait for the
>patch.  I haven't heard many good instances of using VLMs with Win 95.
----------
	Ok, here is one. I've been using VLMs and (remote booted from a
read-only file server) Win95 together since July 1995, in production mode.
They work together. There are no client-based printers; all printers are
attached to the file server or to the network wiring via tiny printer boxes.
Printers are HP Ruggedwriter dot matrix, HP 4M+ LaserJet, HP 1200C color
inkjet, NEC wide carriage dot matrix.
	There is no long filename support with VLMs, as most people know
by now. On the other hand, the need for long filenames is not pressing. And
on the third hand Client32 does not support remote booting at this time.
	The production server was NW 3.12 and is now NW 4.11 (NDS mode for
everything except one tiny printer box).
	Joe D.

------------------------------

Date: Mon, 18 Nov 1996 22:36:20 +0100
From: Sven Ostlind <sven.ostlind@SWEDAC.SE>
Subject: Win95 Client32 (New) problem

>I've applied the new Client32 to one of my Win95 machines for
>test purposes.  Since I've applied the patch, I'm having problems
>running my login script's CAPTURE statement.  We have the typical
>CAPTURE statement as follows:
<
> CAPTURE L=1 Q=TOR_HP4PLUS_8208 NB NFF TI=15
<
>However, when this command is issued, the followin error message
>appears:
<
> Unable to locate queue TOR_HP4PLUS_8208NB.
<
>So, it appears that it is dropping the space between the queue
>name and the NB for No Banner.  Is anyone having this problem or
>are aware of a fix?

I came to think about a similiar problem that we had accessing a NetWare
directory from ArcServe 6.0 and Intel Landesk Virus Protect 3.01. The
problem came with Win95 Client32. The solution then was to shorten the
name of the NW 4.1 server that initially exceeded 16 characters, and
rebuild the NDS tree.

Try to create a new queue with less characters and map to this.  I don't
know if it's applicable on Your specific problem but it's always worth a
try. How long is your server name?

The only information that we have to validate this issue is a fax from
Cheyenne (below). One of the Engineers at Cheyenne told us that Novell
are currently working on a solution but I haven't found anything about
it in Novell's databases.

================ FAX FROM CHEYENNE ==============================

PROBLEM

Client has installed ARCserve on a volume that has 8 character volume name.
Netware 3.11, running Windows 95 with Netware 32-bit client. When he run
the manager he gets message: "You do not have rights to ARCserve home
directory".

The actual syntax of the error is:

"You do not have access to the SERVERNAME/VOLUMENAME:PUBLIC dir.
Could not detect arcserve home directory. Ask your ADMIN to use users
profile to set..."

RESOLUTION

Install on a volume that has less than 7 characters in name or rename
volume. This error will also occur if the server name is over 16 character.

**NOTE** Same resolution applies to Novell's DOS/WINDOWS 32-bit client.

------------------------------

Date: Mon, 25 Nov 1996 20:53:50 -0600
From: Darwin Collins <dcollins@fastlane.net>
To: netw4-l@bgu.edu
Subject: Re: Client 32 files

>While following TID # 2905964, "Installing Client32 for Win95 Using
>MS-Batch", I have run into 2 files that I can not find.
>
>"Replace LOCWIN16.DLL and NWSETUP.DLL files with the same files
>dated 8/29/96 from the latest Client 32 utilities patch"

Go to:

	http://support.novell.com/search/

Specify  w95ut1.exe  in the Enter filename box (specify lowercase).



I have attempted to document some 'win95 rollout' info at:

	http://www.fastlane.net/homepages/dcollins/rollout.shtml

------------------------------

Date: Wed, 27 Nov 1996 22:56:38 -0500
From: Glenn Fund <gfund@HOMENET.ULTRANET.COM>
Subject: Novell App Launcher Bugs?

Has anybody else out there dabbled with the the latest NAL 1.1.

Yes, you do have to update to the the latest 32 bit clients, and NWADMIN
to the latest releases.

I am finding the following:

On Windows 3.1 workstations:

When you start up NAL, all icons appear correctly.  However, addtions and
deletions do not automatically show up (even when a 10 second poll rate is
selected).  Even an F5 to force a refresh does not work.  In addition, any
property changes to served applications do not show up on client
workstations until NAL is closed and then refreshed.

On Windows 95 and windows NT workstations:

Startup is just fine.  Icons do get added and go away as they are supposed
to based on NWADMIN modifications. However, property changes to icons do
not get transmitted down to the workstation here either.

We are working on a project that utilizes Seagate's WinInstall to do the
background application setup for the app launcher icons.  Setup of the
application and running an application is transparent to the user.  No
need to visit any clients anymore.  Establish the WinInstll script.  Go
into NWADMIN and create an application object that serves the script up
and then runs the application.

Really cool.  Lost of potential.

Has anyone else made more progress with NAL?  Does anyone have fixes for
the above problem areas?

------------------------------

Date: Mon, 2 Dec 96 11:14:33 -0400
From: "R. ian" <imackinn@fox.nstn.ca>
To: netw4-l@bgu.edu
Subject: Re: WIN95 Server Install

>>The problem is it cannot write to the msbatch.ini.  BTW, the user has
>>all rights to this server.
>
>Msbatch.ini is installed as Delete Inhibit, Rename Inhibit, Read-Only
>during Netsetup.  Just FLAG msbatch.ini +rw -di -ri

Tried that before mu plea of help :).  A Mr. D. Collins has me re-thinking
my strategy.  Great stuff on his web site at:

	http://www.fastlane.net/homepages/dcollins/rollout.shtml.

------------------------------

Date: Tue, 3 Dec 96 19:37:23 -0800
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: Groupwise 5 Conversion Help!!

>In converting from GW 4.1 to 5.0 I have been upgrading workstations to Win
>95. I installed Client 32 and I am trying to load the IPX/SPX and TCP/IP
>prococols. I can get the workstation connected with just the IPX/SPX
>protocol, but I also need the TCP/IP in order to run another application.

Use the IP stack with win95. Go to control panel, open networks, add
protocol, from Microsoft, tcp/ip, done.

------------------------------

Date: Sat, 7 Dec 1996 14:47:55 -0600
From: James Federline <federlin@CHEM.UMN.EDU>
Subject: Re: Win95 Server-Based setup

>I am getting ready to deploy win95 on my Novell 4.1 network.  We
>support three major groups on the network.  Students, Faculty, and
>Staff.  In particular there are several hundred student accounts that
>are accessed from a lab containing 40 workstations.

This is our situation exactly with 40 staff, 40 faculty and a few hundred
student accounts. Our computer lab and instructional labs add up to about
40-50 "public" workstations.

>We currently run windows shared with individual desktops in private
>home directories.  This has worked well.

At risk of being devils advocate, a phrase comes to mind: "If it ain't
broke, don't fix it." :)

>What are the negatives of installing windows 95 source files on the
>server,  or servers and running windows 95 shared. I know it will run
>somewhat slower, but all the apps are on the server anyway.
>Personally and for eas of administration, II am
>leaning toward running netsetup.exe
>
>Any reason not to??

Yup.

1) Client32 doen't run on shared win95 installs. You are stuck with MS
client.

2) you lose a few remote administration goodies with shared setups.

3) the use of policies with local win95 installs (either network or
standalone) makes your win95 boxes more difficult to mess with than
win3.1 with PROGMAN.INI restrictions.

4) invariably, there is a windows program that wants to dump dll's in
your "system" directory, which is the server's shared windows dir.
Maintaining a coherent idea of what dll's go to what and worrying about
clashing versions of these dll's will make you hair turn white in a
heterogeneous environment like a college department.
	This #4 is where the argument for shared installs breaks down
("it takes less time to manage") - it takes more time I've found, to
manage a shared install ina highly heterogenous environment than
individual local installs that are highly restricted.

We run win95 installed entirely local, with Client32 2.11. We use static
local policies, and akeep a copy of poledit on the server in d directory
accessible by computing staff, as well as on a floppy to take with, and a
copy of the Admin.pol. We run all applications off the server (except
stuff like Win95 telnet, NetScape, IE, ... stuff that comes with Win95 or
is an easy to install extra that gets revved quickly like web browsers -
besides, I'd like to see you upgrade MSIE 2.0 to 3.0 on a shared install
and not have to visit each person's machine.)

We just had so many headaches with shared Windows install with 3.1, we
didn't even think twice about using local installs of 95, esp. after
seeing Client32 doesn't work with it.

------------------------------

Date: Wed, 18 Dec 1996 13:56:45 +1100
From: Rob Zietzke <robz@FOXLN.COM.AU>
Subject: Re: Slow access using Client32 v 2.11 for Windows 95

>Via the Network Neighbourhood, it takes 8 seconds to display a directory
>listing on a 3.12 box. The actual file copy time is not affected (10 MB
>in ~12 secs), but there is an 8 second delay before it starts to copy.

Found the answer to my own problem. It's covered in TID 2909432. I thought
I was using v2.11 of the client, but the date of client32.nlm was 26 Jan 96,
so it must be a previous version. How do I determine the version number of
the installed client?

------------------------------

Date: Wed, 18 Dec 1996 19:22:19 +0000 (GMT)
From: Richard Letts <R.J.Letts@salford.ac.uk>
Subject: Re: Slow access using C32 v2.11 for Win95

For windows 95:

File Cache Level Notes
Default:  3 (long-lived caching)
Range:  0 to 4
The values are as follows:

0 = Disabled
1 = Read-ahead and write-behind only
2 = Short-lived caching
3 = Long-lived caching
4 = Warehouse caching
	Network writes are not cached if True Commit is "on" or if Cache
	Writes is "off."

Warehouse caching:: use the local hard disk as a cache too!!

for the RAM cache:
Max Cache Size Notes

Default:  0
Range:  0 to 429,496,795 (KB)
Notes

When the value of this parameter is 0 (the default), the cache size is
dynamically set to 25% of the total amount of memory that is free when the
CLIENT32 NLM* software loads.

The amount of memory that is free when the CLIENT32 NLM loads can vary
significantly between workstations because it depends upon what other
software is installed.

When the value of this parameter is not 0, the cache size is set to the
specified value.  However, the cache size cannot be greater than 75% of
the total free memory.  For example, if you specify a value of 8192 for
this parameter and the total free memory when the CLIENT32 NLM loads is
only 8 MB, your cache size would be around 6 MB because 6 MB is 75% of
the free memory.

The client32 for windows help file is very comprehensive...

------------------------------

Date: Thu, 26 Dec 1996 12:21:25 -0500
From: "David E. Berry" <dberry@LAMINATIONS.COM>
Subject: Re: DOS Apps Printing Under Win 95 with Client 32

>There is SOMETHING wrong with Client 32 and Dos Apps Printing.
>
>We have 4 Dos based CD-ROM applications.  All four DOS applications can
>print with a capture from the login script.
>
>When we run the same apps from Windows 95, w/client 32 only 2 of the
>applications print.
>
>I don't know what's different from the VLMs running capture and the Win 95
>Client 32 capture, but something is, and it just isn't reliable.

Printing under Win 95 is MUCH different than printing in a native
DOS environment.  In Win 95, you print to an object as opposed
to a port.  Try "playing around" with capturing a port and installing
printer's into the local OS from the network neighborhood.  If the
DOS app is trying to print to that port and you aren't capturing the
actual port, then it will not work.  Make sure the port setting for
the printer object within 95 has the correct NDS path also.

------------------------------

Date: Fri, 3 Jan 1997 12:51:14 EST
From: Gilbert Armour <garmour@FRAMATECH.COM>
Subject: Re: Removal of Auto Login

>How do you remove the automatic login of users from Windows 95 PCs on
>a Netware 3.12 LAN?

If you want to load NW Client but not log in the user, then edit the
registry to not log in at boot.

Hive HKEY_LOCAL_MACHINE\

Navigate to SOFTWARE\Microsoft\Windows\CurrentVersion\Network\Real
Mode Net.

Add binary key AUTOLGON with value 00.  Value 01 enables autologon,
the default value.

Users can still log on by START -> Shutdown -> Close All Applications
and Log on as new user.

If you are running Novell's Client 32, then users can log on by START
-> Programs -> Novell -> NetWare Login.

------------------------------

Date: Fri, 4 Jan 1997 07:26:49 -0600
From: "Mike Avery" <mavery@mail.otherwhen.com>
To: netw4-l@bgu.edu
Subject: Re: Client32, Win95, Laptop

>The combination of Client32, Win95, and a Toshiba T4700CS just
>doesn't seem to work.  Here's what happens.

<snip>

>I think I've narrowed the crashes to having Client32 loaded. But if
>I start Win95 in 'Safe Mode with Network Support,' it works fine.
>But then it doesn't load the PCMCIA drivers, so I can't dial-up the
>network anyways. Here's a detailed description of what I have, and
>what I've done.
>
>Windows95, installed over Win3.1, Service Pack 1
>	(Everything works fine in this configuration)
>
>Toshiba T4700CS, 12mb ram, Toshiba T144PF4 PC Card modem
>	 (Updated the BIOS to PnP, using Win95 32bit drivers for the
>	 PC card)

Ahhhh.... what's your NIC?  The modem?

>Client32, Dial-Up Networking
>	(This is when it starts to crash)

Well, I'm not sure that Dial-Up Networking and the Client 32 drivers
are supposed to work together.

The last place I worked we had a number of laptops and found that we
were better off with the Microsoft drivers for them.  The Novell
drivers were a bit bigger than we wanted to load, and that when the
laptops were not using their ethernet cards they seemed to spend a
lot of time trying to re-establish the ethernet connection.  They
were unbelieveably slow.  This was not with the latest version of the
Client 32 for Win95, just for the first release.  Since I'm not there
any more, I have no real idea what's happening now.  It's worth
noting that trying to use NWIP on those machines made things worse.

As to instability, when we were playing with the drivers, we found
that attempts to switch between the Novell and Microsoft drivers led
to problems like the ones you are experiencing.  Both companies use
drivers with the same names, so if you have mostly Microsoft drivers
and a few Novell drivers, or vice versa, you can get into a lot of
trouble.

Some hints... when you are reverting to the Microsoft drivers you may
be asked a question about "You are about to replace a newer driver
with an older one".  They suggest you keep the newer one.  Usually
that is good advice, but when you are reloading the older Microsoft
drivers to get rid of the newer Novell drivers it's flawed advice.
Use the older drivers.

If you realize that you're going to be playing with the network
drivers, you might want to copy all the .CAP files to your local hard
disk before you get started (unless your laptop has a cd-rom drive).
Doing this will make sure you can re-load some network drivers.

Once things get really hosed, just unload all the network drivers,
reboot, and THEN re-install the network drivers you want to have
loaded.

A final comment... the Client 32 drivers weren't meant to be used via
modem, or in situations where you have disconnects.  The NetWare
Remote drivers are better for that.  In a trade show I saw a laptop
with a wireless LAN card and an Ethernet card hooked up via the
Ethernet.  The demonstrator started some LAN intensive task and
unplugged the Ethernet card from the cable.  The display slowed down
and he walked around showing us that it was still working on the
wireless link.  (The wireless link was a 2mbps link.)  Then he walked
to the front of the hall, plugged back into Ethernet - on a different
segment - and the Ethernet card came back to life and the laptop sped
up.

If you have mobile users, I'd look into NetWare Remote (or was that
NetWare Mobile?)

------------------------------

Date: Wed, 29 Jan 1997 15:08:13 -0700
From: Shawn <opeth@futureone.com>
To: netw4-l@bgu.edu
Subject: Re: Client32 & TCP/IP

>We had this problem here. It has happened on a few machines. Unfortunately,
>after I monkeyed with it for a while, and our helpdesk monkeyed with it for
>a while, we came to the conclusion that the easiest thing to do was
>reinstall windows 95. (We decided that the registry had somehow become
>corrupt.) That did fix the problem.

Well, prior to knowing about the Client32 uninstall program (a few weeks
ago), I wound up reinstalling Win95 - from diskette! This time, I used the
uninstall program (twice) and all was well. :) That uninstall utility is
(at least for me) invaluable!

------------------------------

Date: Tue, 4 Feb 1997 16:26:05 -0700
From: Shawn <opeth@FUTUREONE.COM>
Subject: NetWare 3.11 and OS/2 Name Space :)

Well, I finally got the long name space to work on our 3.11 server. For
those of you who are also trying to do it, here's what I did:

1) Download and installed LIBUPB
   --install the files in SYS:SYSTEM and let it overwrite the

     older files - after backing up or renaming the old ones

2) Download NAM312 and extract
   --Copy OS2.NAM to SYS:SYSTEM and c:\server.311 (the
     server.311 part can also be done in step 3 below)

3) Downloaded and installed 311ptg
   --extract the contents to a floppy disk
   --at the server console, type LOAD A:\PATCH311 and select
     the option to install the patches. It will then load all
     of the NLMs in your server directory, eg: c:\SERVER.311
   --Down the server
   --xcopy a:\native\loader\*.* c:\server.311
   --from server.311, type XLOAD LOADER.EXE SERVER.EXE
   --xcopy OS2.NAM to c:\server.311 (if this wasn't done in
     step 2)
   --SERVER

3) At this point, I already had the name space added to the volume, so I
didn't have to do it. But, if you haven't, at the console prompt, type:
LOAD OS2. After that, type ADD NAME SPACE OS2 to <volume>. Add LOAD OS2 to
Startup.ncf.

After all this, it still didn't work. So, I had to do the following (after
researching a little):

4) Launch Regedit. Go to:
Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\Nwredir
Then, Edit-->New-->Binary Value (_not_ DWORD, which is why POLEDIT doesn't
work)
Name the key SupportLFN. Modify the value to 2 (type 02).

5) Edit System.ini, ie: add the following
   [Nwredir]
   SupportLFN=2

6) Save System.ini and reboot. Voila! :)

You can check out the online sources I used to figure this out through the
"Windows 95 and NetWare Issues" section of my Networking Page (URL in my sig).

------------------------------

Date: Wed, 5 Feb 1997 10:49:10 +0800
From: Brett Looney <BLooney@COMTECH.COM.AU>
Subject: Re: DHCP (& BOOTP)

>Most DHCP servers keep track of these clients by storing
>their MAC address and NAME*, along with the respective IP
>in a database on the server. The NAME comes from either
>the username(for Netware) or the machine name(WIN95 & NT, etc.)

A curious thing about the NT DHCP server is that is uses the machine name
rather than the MAC address of the workstation to check for duplicate DHCP
requests/entries.

Naturally, if you're using the Client32 for DOS/Windows 3.1 then you don't
have a machine name set. To do this, put a set parameter in your
AUTOEXEC/STARTNET which does:

     set NAME=machinename
This is true for the NT 3.51 DHCP server. Microsoft may have change the
behaviour of their DHCP server in NT 4.0 - I haven't checked that yet.

------------------------------

Date: Thu, 6 Feb 1997 11:06:35 CDT
From: "Dan Creagan" <dcreagan@scholars.bellevue.edu>
To: netw4-l@ecnet.net
Subject: Re: Moving Files in Win 95

>Is moving files from one server Novell 4.1 to another one through
>network using WIN95 can cause a server Abend ????

I've heard of this on 3.12 machines.  In fact, I did it on my home
machine (3.12, 12 meg, transferred 124 meg of files using Win95 and
it killed the volume .. first abend in 3 years).  There are also
several messages on this in the Win95 bug list.  The problem on 3.12
is in the packet size/packet burst area.  Win95 apparently doesn't
handle this correctly and overruns the server.  The stated solution
is at the netbugs site (recently posted by Arthur B):

http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html

>Also what are the settings that need to be fine tuned to prevent the LAN
>from becoming slow when you move a lot of files from one server to
>another one

Use a client and set a background task, add tons of RAM to the server,
you could try increasing the Dirty Disk Cache Delay Time to max (10 sec),
this will hold the transferred files as long as possible before
doing the disk write (this would, I suppose, allow other users into
the system more quickly - or ... not .. but it is a recommended
procedure in the books if you are making frequent writes).

------------------------------

Date: Fri, 7 Feb 1997 10:38:02 -0600
From: Brian Scott <bscott@SYSTEMA.WESTARK.EDU>
Subject: Re: AUTOMATIC LOGIN IN W95'

>Is possible turn on the pc's and automatically load windows 95' and
>login to a network with a predetermined user without the user press
>any key ?.

Yes, I am doing this.  The lab that is doing this is using Windows95
version 4.00.1111 and Client32 version 2.11(?) (the one that comes on
the Netware 4.11 CD).  The only way I have found to do it is the
following:
In REGEDIT go to
	HKEY_LOCAL_MACHINE\Network\Logon
and delete everything except "username".  If you are using policies,
you might not want to delete the policy related stuff like
"PolicyHandler".

The user names I am using to do this do not have passwords.  I have
not tried this with passwords, but I assume that it would just get
the password from windows *.pwl files.


BTW: Where can I find the documentation about Client32's registry
keys and what each one means.  The only book that has been of any
help is "The Windows 95 Regisrty" by John Woram, but this is just
standard win95 information.  The "Windows95 resource kit" is usless
in this area.

------------------------------

Date: Tue, 11 Mar 1997 22:25:29 +0000
From: John Wells <jwells@PACIFICCOAST.NET>
Subject: Re: How to turn off print banner in Win95.

>go to printers
>printer properties
>details
>capture printer port
>the settings should be in there
>
>If using Client32
>go to the point where you capture the port and go to lpt settings

I agree this *should* work, but with all the Win95 PCs I've been using
(using either the default MS NetWare client or Client32) the capture
settings under a printer's Properties don't actually affect captures made
using the Capture Port button (at least they don't affect the banner and
form feed settings which I'm using concerned with).

The only way I've been able to control the parameters for persistent
captures (via Capture Port) is to use Client32, and go to Control
Panel/Network/Client32/Properties and select the Default Capture tab.
Changes made there do affect subsequent port captures.

------------------------------

Date: Thu, 20 Mar 1997 12:59:03 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: ....Client32 & NT...dead horses, beating

>I am using the NW Client32 on a Win95 workstation with the Client for
>Microsoft Networks.  The Primary Network Logon is NW Client32.
>The Properties for the Microsoft Client show to log on to a
>Windows NT Domain, with an existing Domain Name entered.  Upon booting
>I am asked to login to my Novell network and then to the Microsoft
>Domain but, when looking in Network Neighborhood I see ONLY the NW
>servers.  NO Microsoft servers or Workgroups.  If I do a Find on an NT
>server, it is there and I can attach to it, I can map a drive to an NT
>server but why don't they appear in the 'Hood?.
---------
	Stop, think. Microsoft loves NETBios as transportation. NetBEUI
is its name when sent in bare bones 802.2 Ethernet frames. It's terrible;
it's not routable, but you are stuck with that or NetBIOS over TCP/IP.
Configure your station for that in addition to IPX and it should see the
Microsoft stuff.
	Joe D.

---------

Date: Fri, 21 Mar 1997 10:09:49 -0500
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: ....Client32 & NT...dead horses, beating

>>What protocols are you running?  NWLINK by it self will not browse,
>>you must either add NetBEUI or NetBIOS support over NWLINK to browse
>>the neighborhood.  MS will browse over IP natively, but not across
>>subnets with out additional steps.

If I may add to the madness...

It achieves this by periodically asking EVERY device on the subnet what its
NETBIOS name is.  You know, Microsoft recommends installing applications
locally, and not on a network server, right?  This is partly because the
network is busy constantly asking everyone what their name is  - too busy to
handle silly little things like file services.

... but at least you can play Pinball on an NT server.

------------------------------

Date: Thu, 27 Mar 1997 09:22:46 +0100
From: David van Duijne <anroserv@WORLDACCESS.NL>
Subject: Information concerning Windows '95 System Policies

Windows '95 has a great ability to "lock" pc's configuration and
abbilities. If you have searched the WIN95RK.HLP then you should have
noticed it.

Now, we have a config of two servers and 30 users. Couple of them use
Win '95, others win 3.x. And I am happy to say that the Win '95 machines
have better protection than the 3.x machines.

Here is how to protect (even "alien") pc's from globbering your network:
Minor setback is, you have to enable Users Profiles in the Network
settings.

- Install POLEDIT on your Administrating PC.
- Open a new file named CONFIG.POL and put it in the directory
F:\PUBLIC.
- Open the DEFAULT USER.
- Disable the configuration, Use the ALLOW ONLY REGISTRED WINDOWS
APPLICAIONS feature to disable Setup.exe etc.
- On the DEFAULT COMPUTER, enable Profiles (This can be done
automaticly, you won't have to jump all around campus to do that.)
  The only thing you have to do is, config the machine to use the
  Netware login as the default login.
- Copy this file (CONFIG.POL) into every server PUBLIC direcotry.
- CAUTION !!!

  Do not forget to add a user with your name and enable the POLEDIT.EXE
  or you won't be able to do your tasks.

  Yes, with this thing you can assign different users different rights
  to certain parts.

When a user first logs in, this will create a sub directory under his
MAIL Dir and Win '95 uses it as the START MENU. Do disable this, use the
USE THIS DIRECTORY FOR START MENU under the Shell option in the Default
User. Set this to WINDOWS\START MENU.

------------------------------

Date: Mon, 31 Mar 1997 09:53:22 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Win95 with Netware 3.12 - Questions!!

	May I make a simple suggestion? Don't put hard disks on clients.
You don't need to and by removing them you also remove almost all the
problems asked about below.
	May I point you at my Win95 installation doc which shows how to
construct a system for diskless clients booting Win95 from a read-only
NW file server, and related material. It's in the FAQ (please do read).
Files w95inst7.zip (or w95insps.zip as Postscript only), msoff95.txt,
drived.txt, all in directory misc on netlab2.usu.edu and pub/mirror/misc
on netlab1.usu.edu. These are for the 24 Aug 1995 release of Win95, not
for OEM versions or other variations.

>   a) Win95 hopefully installs the hardware settings locally and the
>user settings in another place, right? Why i ask this? I need to know
>if there is a way for a normal user to change screen resolution,
>without changing video drivers. Can this be done on the policy
>editor? Or only is possible to disallow all control panel access,
>even to simple things like keyboard speed?

	Between you and Microsoft. But it helps to understand what Win95
does, and that's discussed in my docs cited above.

>   b) Client32, we tried it. We have to take out that cancel option.
>All users are FORCED to login using client32, there cant be any other
>way. We cant have anyone coming here, selecting cancel and using
>tcp/ip and netscape, or whatever, even if they dont have access to
>the server disks.

	This presumes Client32 is part of the solution, and that is
not necessarily so. VLMs work just fine.

>   c) Client32 processing the login script, runs a dos windows for
>each line. Probably a silly question, but i noticed it in the past
>here in this mailing list. How can it be avoided?

	This has been covered many many times, and is a Win95 fundamental.
Look at the properties of the DOS box, please.

>   d) I dont recall if installing win95 on a network allows us to
>install the normal windows 'applets' in a centralized directory. If
>so, i guess it must be done from a already working win95 station, to
>allow access to the server disks, right? Anyway, we must reduce at
>the minimum the effects of a 'drunk' user deleting all the files of a
>local hard disk (believe it or not, it has happened :-) )

	Problem solved by no hard drives. One does not need hard drives
to run DOS, Win 3.1, Win95 apps in almost (but not quite) all cases. Seeing
this may require some thought, but because I have been doing just this
for years you can be assured it is possible and practical in a production
environment.
	Joe D.

------------------------------

Date: Tue, 1 Apr 1997 09:52:27 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Client32 using too many server licenses.

>I thought I should add  Re: The (bad but working) solution ---
>Does not work in our case.  I added a logout to the specific server
>as late as possible in the process to eliminate the possibility of a
>connection being established after.   The last (automated) process
>in a Win95 workstation login may be in the startup folder.  This is
>where I process the logout from the problem server.
>
>When this did not keep the connection from re-establishing itself I
>went one further step.  I set up accounting on the Administrative
>server and set a zero balance on the student users of the other
>servers, charging for connection time with no unlimited balance for
>the student users.
>
>The connection is repeatedly Killed and re-established! This has
>been reported by my users to cause many workstation hangs.
>
>It seems I have four options.
>
>1) Stop using  Policies through  config.pol and go to a  ".man" type
>of policy enforcement.  (Unlikely solution but one I will try.)
>
>2) Go to Joe D.'s solution of a diskless workstation.  ( He
>probably has not commented on this one because he is running
>Win95/client 32 workstations without using policy enforcement
>through config.pol.)
>
>3) Remove the problem server from the tree.  (It' my opinion that the
>Master replica holder will turn in to the problem server.  I intend to
>test this by making another server master for a while.)
>
>4) Stop using Client 32.
--------------
	I wonder if you are on to something with .pol files. Might it be
Win95 is reaching out to all servers to locate .pol files? We know that
Windows is insistently braindamaged about retrying access, as fast as it
can go, to things it is not allowed to touch (typically files marked
read-only or similar in local experience).
	Two ways of exploring this hypothesis are putting a monitor on
the wire to snoop file activity, and creating a new Client32 installation
which does not try invoking .pol stuff. Recall, policy files are used only
if you want them to be. I ran afoul of them during the Client32 development
stage and hit the ceiling with the engineers, to no avail. Ditto huge
client memory caches.
	Just a word on my approach to running Win95. Clients need not be
diskless in the end. What counts during normal operations is snagging
system.dat and user.dat registry files (from the file server in my case)
to the apparent boot drive before the GUI interface starts (which means one
can go to DOS level first, move files, then run win.com). Naturally there
is Catch22 with Client32 because you need network access to snag from the
file server, but Client32 needs the GUI before network access is available.
Hence I run VLMs locally and lose without regret long filenames.
	Joe D.

------------------------------

Date: Mon, 7 Apr 1997 08:36:29 -500
From: Jon Dustin <jdustin@USM.MAINE.EDU>
Subject: Re: Remote Boot Win 95 with PCI NIC?

>Well, yesterday night I was browsing www.bootware.com (Lanworks
>Technologies web site).  We've been using their Bootroms for a while now
>quite successfully.  There were several conflicting items in their tech
>support pages that seemed to indicate that Win 95 remote booting from
>Netware would not work with a PCI NIC.  Other posts indicated that it
>would.  Still another said that the Intel PCI card worked, as did the
>3c595, but not the 3c905.

Windows 95 *does* have a problem with using PCI network cards in a
'shared installation'. We spent many hours last summer trying various
configurations, even talking to MS tech support...

The problem revolves around the installation, and when the PCI bus is
'enumerated' (initialized). PCI cards do not get scanned by Win95
until the 'second boot' of Win95. This causes problems with the Win95
setup.

However, you can still use the VLM setup as documented by Joe D.

As far as the 3c905 cards, we have been using them since last summer
with no problems. (But we like the Intel cards better...)

---------

Date: Tue, 8 Apr 1997 11:00:40 -0700
From: John Kerti <johnk@KWANTLEN.BC.CA>
Subject: PCI vs Win95 remote boot

As a followup to my earlier question regarding a problem with remote
booting win95 using a PCI network card, I got a call back from Lanworks
Technologies and this is what they had to say:

1) There is a known problem with INSTALLING Win95 for remote boot using
   a PCI NIC.  This is caused by Win95 initiallizing PCI devices the
   second type setup requires a reboot.

2) Some PCI NICS will work properly on workstations by installing Win95
   using an ISA card, then editing the Registry to reflect the new PCI
   NIC.

3) According to their tests, the Intel Etherexpress Pro 100/B will
   work without having to do the workaround in item 3.

4) The problem is with Win95 rather than the NIC or Bootrom.

------------------------------

Date: Mon, 14 Apr 1997 16:42:56 -0400
From: Daniel Tran <dtran@UCLA.EDU>
Subject: Re: FILE & RECORD LOCKS ERROR

>I'm trying to get Client 32 for Windows 95 working with a Novell 4.11
>network.  Our company was absorbed by a larger one that does not yet
>support Win 95 so I've been left on my own for now.
>
>When I have such things open as Maximizer (database), CCMail or Access for
>Windows, it doesn't take long before my screen turns red and white and the
>following message appears:
>
>	Network Status:
>	Client 32: Please wait while <program name such as w32mkde.exe>
>retries reqeues to <server name>.
>	To stop waiting press ENTER.
>	Netware will then return an error and try to reconnect in the
>background.
>	[O]k
>
>According to Document ID 2919046 date 06 Jan 97 on http://support.novell.com
>I should "increase the number of file and record locks per connection".  I
>went to the server screen and went to a File Locks screen that would allow
>me to increase each of 4 settings that had to do with locks - I basically
>doubled all of them.  ANY RECOMMENDATIONS ON WHAT TO SET THESE AT?  Also, do
>I have to reboot the server for them to take effect.

From Microsoft TechSupport, they recommend increasing the maximum record
per connection to the 10000

Exceeding the Server Lock Count on a Novell NetWare Server
----------------------------------------------------------

If you exceed the server lock count while running a Microsoft Windows
95 client that accesses a remote database on a Novell NetWare server,
your application may appear not to work properly. For example, you can
run out of locks when running very large bulk set operation queries or
when you are using data access object (DAO) code with explicit
transactions that affect large numbers of records.

To avoid this problem, open the table with exclusive access (to
preventing page-level locking) or use DAO code without explicit
transactions to make the updates.

You can also increase the number of locks on the server. By default,
NetWare allows 500 locks per connection. You can modify this limit (up
to a maximum of 10,000 locks per connection) by adding the following
two entries to the server's Autoexec.ncf file:

   set maximum record locks per connection = 10000
   set maximum record locks = 200000

------------------------------

Date: Mon, 14 Apr 1997 21:01:08 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Client32 and Win 95 Shared Install

>We are planning to setup a *shared* install of Windows 95 this summer
>on a Novell 4.1 & 4.11 network.  My problem is that I can't even get
>a test lab functioning with Novell's Client32 2.11, and I don't see
>any extra docs in 2.12 that would support it.
>
>What I am wondering is if anyone has gotten a Shared Win95 setup to work
>with Client32 and if so, please explain how you did it (more detail the
>better).
>
>My other alternative is to look at MSNDS, but I am rather reluctant
>to do so given the number of "bugs" that have been found in that
>client.
-----------
	What I'm about to say may not help but it might illuminate the
problem a little.
	Client32 for Win95 starts AFTER the GUI, which says that there
must be enough of Win95 (basically the entire thing) available to do its
startup stuff before it gets around to the network part. The full system
is up and running before the NW login box appears.
	Now that raises the question of what you think is being shared.
Applications? Sure, no problem. Desktops? Win95 main body? Nope, local in
these cases from the required startup steps.
	Ok, let's change the perspective just for discussion purposes.
You might hope to have Win95 on the server and clients own their own
desktop areas. The problem is Client32 won't let you run this way because
it needs Win95 running first; Catch22. But VLMs will let you run this way,
at the cost of no long filename support to the server, because the network
is started at DOS level before the GUI protected mode material is touched.
The VLM approach lets the entire Win95 suite be on the server, and before
starting the GUI the registry files are brought to the "apparent boot drive."
Each user can have their own desktop area etc on the server. You don't need
client disks, but you can have them if desired.
	This VLM approach is described in detail, and even illustrated,
in my "diskless boot of Win95" paper: w95inst7.zip in directory misc on
netlab2.usu.edu (aka pub/mirror/misc on netlab1.usu.edu).
	Finally, because I answer the Win95 question at least once a day every
day of the year, for going on two years now, network traffic from placing
the windows swap file on the file server (an option) will be nearly zero
if, and only if, the client has enough memory to begin with. This year
"enough" seems to be around 32MB. I do put swap files on the server, and
I observe carefully what happens (nothing). Wide range of client activity.
	I'm not trying to sell an approach, but I am trying to clarify the
technical environment just a little.
	Joe D.

---------

Date: Fri, 18 Apr 1997 21:22:28 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Client32 and Win 95 Shared Install

>>	I'm not trying to sell an approach, but I am trying to clarify the
>>technical environment just a little.
>>	Joe D.
>
>Joe, can you confirm that your comments about WIN95 & VLMs vs C32 apply
>equally to WIN/NT?
--------
	No, not directly I can't because I discarded my latest copy of
NT (3.50). NT does have an elaborate MS-networking style remote boot
procedure, whose directions I have in some NT developer's material
(not distributable) and which I think must be released by now. But
from what I do surmise the strategic problems are nearly the same.
	That is, the GUI stuff rolls along inspecting the system and only
most of the way through that process does it reinitialize the lan adapter
hardware and start up the network connection. What Microsoft has done
in Win95, and apparently in NT too, is boot to real mode NDIS drivers,
stuff connection information into setmdir (yeah, that item does many strange
jobs) as a bridge, and then at the appropriate late moment kill the real
mode drivers and load the protected mode kind.
	The strategy is probe the machine, init hardware, and after the main
GUI has stabilized in protected mode then start networking (needs the GUI
for popup menus etc). It is going on two years since I looked into the MS
material, so please forgive the errors.
	There are certain advantages to being the creators of that muddle
rather than trying to outwit it by reverse engineering (which is basically
what Novell faces). However, we see a *possible* similar strategy for Novell,
if they were to pursue it fully. Needless to say, it too would be messy. You
can increase their awarness of such need for a remote bootable Client32 by
making constructive noises to your Novell area representative for relaying
to Provo. The programming effort would be substantial, and hence in
competition for resources devoted to similar projects (NT client being the
lastest such effort).
	[I say this having just finished yet another quick re-reading of
ODI remote boot rom code for DOS. Difficult stuff, that.]
	I'd be happy seeing say TLMs (Top Level Modules), which would be the
VLM material put on top of DOS as a true shell (NETX style) rather than
beneath the surface as a formal redirector, and hence able to play the long
filename game fully while being real-mode remote bootable. But we know that
as soon as something like that appeared there would be suddenly a Win95C
which is mysteriously incompatible with that approach...
	Joe D.

------------------------------

Date: Wed, 16 Apr 1997 18:54:03 -0500
From: Jason Lohrenz <jmlohren@INST.AUGIE.EDU>
Subject: Info on Shared Win95 Installation

Here's the info.  Note, I haven't tried this as a shared install, but
according to the article it works.  I only used it to merge Client32 to
my Network Win95 install.

1. Get network install of Client32
2. Decompress it and copy decompressed stuff to network directory
   Wait to copy files from \INSTALL\ADMIN\BATCH directory
3. Rename or remove all .inf files in the network directory you
   copied the client to.
4. copy NWCLIENT, NWTRANS, and NWLAYOUT inf files from
   \INSTALL\ADMIN\BATCH  to the network directory that has the client
   (also copy nwip.inf for NWIP, and NWSERV.inf for SNMP support)
5. Run batch.exe from the Win95 CD (admin\nettools\netsetup)
   Click on network options
   Remove all options and specify you do not want default settings
   Select done
   Save file as msbatch.inf
6. Check the msbatch.inf file to ensure that under the [Network]
   section Clients has NOVELL32 and that protocols has NWLINK, NOVELLIPX32
7. Run the inf installer (\admin\nettools\netsetup)
   You will need to specify the Windows directory on the network
   Click on install INF
   browse to the network install location of Client32 and select
   NWCLIENT.INF
8. If you are prompted to keep existing netware.drv replace it with
   the one included with Client32
9. Copy the netdef.inf file from the Client32 install
   (\install\admin\batch) to the following locations
   (where the drive is mapped to area that contains Windows95 network
    install directory)
	F:\Win95
	F:\Win95\SUWIN
	F:\INF

That's it.  Hope it helps you all.  As I stated I never tried the shared
install method.  The article also noted that you should use the latest
version of The client since older versions didn't support shared installs.

------------------------------

Date: Thu, 17 Apr 1997 10:59:20 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: windows 95 - client 32 and dosboxes

>I've installed client 32 on a Windows 95 machine. The client seems to
>work perfect with Windows 95, the problems start when i open a DOS
>box.
>
>The problems seem with accessing drives and directories.
>
>For example.. when i try to access drive G: this can be done without
>any problem, but when i try to access a directory called TEMP (fill in
>any other name) i can't and get the message invalid drive of
>directory.
>
>When i do the same with the Windows 95 internet explorer it's no
>problem.
-----------
	Please look at the PATH string while in a DOS box. Also, I
avoid created drive letters whenever possible and stick with the
letter for that volume (or the entire server), such as classical F:.
	Joe D.

------------------------------

Date: Thu, 17 Apr 1997 12:05:04 -0700
From: Tim Madden <tmadden@ASPENRES.COM>
Subject: Re: Client 32 Automatic Update Program

>>The other way was calling a dos batch script which then uses
>>the start command to call the setup.exe /acu program.  From
>>there it installs correctly, but the dos window that was created
>>from the .bat file stays up on the screen.  Even the dos EXIT
>>command does not work.  It is possible to manually close the
>>dos window and then it will continue, exit and reboot but this
>>is not a seemless installation.
>
>If you use that window's properties to set it to close on exit, it will
>create a pif file in \windows\pif (a hidden directory).  Copy this pif
>file to each station as part of the batch file that invokes the update,
>and the window will close upon completion of the update.  Regards, Bob.

Actually, I think you can just copy the pif file into the same
directory as the bat file and it will also close automatically.  That
way you can edit the pif centrally if need be.

I tried this with batch file yesterday, and encountered the same
annoyance, so I moved the pif in with the bat, executed the bat, and
the dos box closed automagically.  Note, I did delete the pif from
the workstation so I'd be sure I was executing the pif from the net,
not local.

------------------------------

Date: Fri, 18 Apr 1997 09:01:06 -0600
From: James Hooper <HOOPER@WPOGATE.SLU.EDU>
Subject: Windows 95 (B) and Client 32

>I just installed the latest release of Windows95 (B), and put the
>latest version of Client32 (2.11) on it.  Now when I dial in to the
>Connect server, it can't see the 4.11 server, so I have nothing to
>login to.  Anyone else have problems with this new version

Just a note about Windows 95, construct 4.00.950 B (version B)... I was
told by Microsoft that version B is an OEM version only, and is not and
will not be released on cd or disk.  Also, it is NOT covered under
previous licenses for constructs 4.00.950 and 4.00.950 A.  If you have a
volume license agreement for Windows 95, any construct EXCEPT
version B may be used to reinstall or modify your systems.

When I asked how significant the OEM number was to licensure (it
appears in Control Panel, System), Microsoft told me that it was NOT
directly related to licensure and was ONLY for customer service
tracking.  However they recommended that we retain the little white book
with the blue-green certificate pasted to the front as proof of licensure
on our purchased systems that came with Win 95 (OEM).  They also said
that when the number appears like  XXXXXX-XXXX-XXX with a bunch of
x's it means that it was a network install.

Also, one more Win95 factoid,  if you installed from CD and keep getting
asked for the Windows 95 CD when making changes and want to use
disks, you must extract the layout.inf file from the precopy2.cab file on
disk 2 and replace the one that is in the c:\windows\inf directory.

In regards to troubles with Client32 and Windows 95, I have had a few.
They were all solved by using Client32 uninstall, followed by a
reinstallation of Client32.  I have seen an upgrade or reinstall of Windows
95 really screw up Client 32.  Sometimes its to the point that you only get
the pretty orange Client 32 splash, but no login dialog box. :(

Anyone have any suggestions for getting Win95 to a server subdirectory
so that I can install it from there?  ... other than copying the
/windows/options directory which doesn't always work.  I have tried
copying the 30 disks there, but it chokes.  Is there a special network
install?

------------------------------

Date: Fri, 18 Apr 1997 10:38:01 -0400
From: Don Voss <voss@CASCOMP.ALBANY.EDU>
Subject: Re: Help on WIN95 and Client32

>Please help if you can offer some advice with respect to this
>problem: We run client32 on all of our WIN95 desktops (we utilize
>WIN3.X as well but use netx).  On some of the WIN95 desktops, after
>logging in, the user may use WIN95 dialup networking for an online
>service.  On some of these machines, when dialup networking connects
>to the online host, Client32 relogs-in the user on the ethernet LAN.
>
>It does so without showing the splash screen or the login screen
>but it does show the desktop attaching/authenticating to the LAN
>servers and running the login scripts.
>
>Why is this and how can it be stopped?

Here is a try at a overview that would explain the behavior you see.
For the moment disregard any merit of and / or  real working issues
of win95.

WIN95 comes up alone trying to emulate the network model, such as
there can be mutiple users,profiles,  thus a win95 login.

Add a layer. The NW client32 material.

The WIN95 network model is, roughly, that at each "net access"  it
will check if there will be any " controls used to modify the
interface; if so;  enable them. Then throw up the interface. [ read
GUI and I guess there is a pun in there too..] These controls might
be: profiles, policies, NW login scripts, NT profiles.

Back to your users.  Station up, user logged into station and
NWclient32 enabled, logged in to server[s]. Win95 has checked and
used all its known controls to setup interface. Interface up.

Then your user fires off dialup networking. This is treated as
another full user / network login.

Win95 has no idea if this is just to hit a newsreader or if the new
network login will reset/restrict all/some interface settings with
new policies, scripts, etc.

So ..the NW client gets dropped, [ + more..], new net access is
made, nothing tells the WIN95 OS NOT to use the NW client again. The
OS has settings enabled to always use it, so it does and re-logs in,
thank you very much.

As far as stopping it...  Do you want to do that?  I don't think so.
As far as a more elegant way to have these access needs merge for
your users...  I will not hazard a reply.

---------

Date: Fri, 18 Apr 1997 15:33:43 GMT
From: Serge Adam <sadam@PATHCOM.COM>
Subject: Re: Help on WIN95 and Client32

[Floyd:  The above ...OR...]

Goto Start/Programs/Accessories/Dial Up Networking

- Highlight the icon for that online service
- Right-click and select properties
- Click on 'server type'
- Uncheck 'Log on to network'
- Click on OK until your back to the DUN folder

------------------------------

Date: Sun, 27 Apr 1997 10:26:51 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Win95b and Client32

>I don't know if this has been covered, but has anyone else had problems
>with Client32 for Win95.
>
>I have a Vectra VL series 5 with an Intel10/100BTX card, that when I load
>Client32, it freaks----loss of network community is the most minor of it.
> I had to reload windows entirely. (Make me happy that my main machine is
>a Macintosh).
>
>Are there patches for Client32?
------------
	Look for memory conflicts above the top of physical memory. The
Intel Etherexpress 100B uses such a memory buffer, and alas so do some
video adapters, and they can conflict to lose video and/or communications.
	There is an undocumented command to the Intel driver, IOMAPMODE=1,
which changes the board from shared memory to port i/o. But so far I see
no way of stating that change with the Win95 version of Client32, and I
spent part of Saturday trying. The alternative is to tinker with the video
board settings/driver while within Win95.
	What is needed is a way of stating command line options for the
Intel driver when it loads. That is not present in the current Win95
Client32 material. Alternatively, the option ought to be expressable to
the Intel board's CMOS setup, and that's on my list to probe.
	The memory conflict problem does not appear at DOS level; it happens
when the Windows drivers get cute about dense graphics modes.
	The fallback is to use the 16-bit real mode driver E100BODI.COM.
	Additional info: the identical problem occurs with Client32 for
Win31. But the cure is very easy because we add that phrase to the LOAD
line of the driver, like this:

SET NWLANGUAGE=ENGLISH
C:\NOVELL\CLIENT32\NIOS.EXE
LOAD C:\NOVELL\CLIENT32\LSLC32.NLM
LOAD C:\NOVELL\CLIENT32\CMSM.NLM
LOAD C:\NOVELL\CLIENT32\ETHERTSM.NLM
LOAD C:\NOVELL\CLIENT32\E100B.LAN slot=10001 SPEED=10 IOMAPMODE=1
 TXTHRESHOLD=200 FRAME=Ethernet_II
(line above is broken into two for mailing)
LOAD C:\NOVELL\CLIENT32\E100B.LAN slot=10001 FRAME=Ethernet_802.2
LOAD C:\NOVELL\CLIENT32\E100B.LAN slot=10001 FRAME=Ethernet_802.3
LOAD C:\NOVELL\CLIENT32\E100B.LAN slot=10001 FRAME=Ethernet_SNAP
LOAD C:\NOVELL\CLIENT32\IPX.NLM
LOAD C:\NOVELL\CLIENT32\CLIENT32.NLM /c=c:\novell\client32\net.cfg
c:\qemm\loadhi c:\novell\client32\lsl
c:\qemm\loadhi c:\novell\client32\pdoseth

	Joe D.

------------------------------

Date: Sun, 27 Apr 1997 19:39:53 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Getting Rid of the '95 Logon

>I've looked long and hard everywhere including Novell's site. But
>cannot find any documentation on how to turn off, the windows '95 logon
>banner that comes after the Novell logon. Can you please help or point
>me in the right direction.
---------
	It's a bit mapped image, isn't it. That suggests a likely file
extension is .BMP. So dir *.bmp /s/p and see what's there. Lo, and behold,
win95\system\nvdrvlgo.bmp. So, move it elsewhere.
	You can be more elegant, however. There's a option in win95\netware.ini
which is something like  logo=0  or similar.
	Joe D.

------------------------------

Date: Mon, 5 May 1997 17:10:16 -0700
From: Tim Madden <tmadden@ASPENRES.COM>
Subject: Re: Client32 question

>Is there anyway to disable the cancel button so the user has to login?
>We are using the latest client 32 drivers.

You can get into Win95 Policies, which can "Require validation by
network for Windows access" as a machine setting.  The specifics are
lengthy and rather cumbersome, but I've done this at a community
college.  Download the most recent policy editor from MS, which I
believe is ver 2.x, as this one allows multiple templates to be
loaded concurrently.  The poledit.exe that comes with Win95 only
allows one template at a time, which can quickly become annoying.
You'll then use the client32.adm from novell and admin.adm from
win95, and possibly others, to set your policies.

The Win95 Resource Kit, avail on the Win95 CD or on-line at MS, is
essential.

------------------------------

Date: Mon, 12 May 1997 09:30:56 -0700
From: Tim Madden <tmadden@ASPENRES.COM>
Subject: Re: Client32, Win95 & Microsoft

>I just thought that I would pass along a comment that was told to me by a
>Microsoft Support person when I called Microsoft for Windows95 support of an
>'initialization error' that I was receiving upon entering Windows 95.
>
>We were doing some troubleshooting until I happened to mention that I had
>previously installed 'Netware Client32' on the machine.  The support rep
>than told me that "Microsoft doesn't provide support for machines with
>Client32 installed on it, nor will they provide support with machines
>previously having Client32 installed".  When I asked him the reasoning
>behind this, he noted that Microsoft does not know what the Client32
>installation process does but it often messes up the Win95 registry.  He
>then suggested that I reference the Microsoft Knowledgebase on the Internet
>to find out how to uninstall Client32 and suggested as an alternative
>solution I may need to do a 'clean' installation of Win95 on the machine.
>
>I was able to resolve the issue without the help of the rep.  The issue had
>to do with a PCMCIA NIC being configured for 10Base2 on a 10BaseT topology.
>
>I find it very interesting - and somewhat irritating, on what this rep said.
>I am sure (at least I hope) that this is not a Microsoft 'Policy' and that
>the rep was just ill-informed or improperly trained.
>
>Has anyone received comments like this previously from Microsoft regarding
>Client32?

While I've not experienced the problem before, I was aware that MS
would not support any Client32 related problem - which means any
networking problem once Client32 is installed.  As for it "messing up
the registry" and requiring a re-install of Win95, it doesn't say
much for MS if *any* program could be that bad to the registry.
Client 32 is not so devestating that Win95 should be re-installed.

As for the uninstall, Novell's Client32 uninstall works very well.
It is, unfortunately, required any time you change network cards, in
my experience.

Finally, the fact that the service rep couldn't help you is 100%
expected.  I wouldn't even consider calling Win95 help desk anymore.
I have three time in the past all with the same results...the tech
was stumped and I figured it out on my own.

------------------------------

Date: Mon, 12 May 1997 11:58:27 -0400
From: Michael Murphy <murphy@SCHEV.EDU>
Subject: Re: Client32 retry error resolved!

Well... finally success!!

This saga went on for almost 4 months.  Things were running smoothly
with WFW an NetWare 4.10.  Then we started upgrading to WIN95 and
Client32.  The Client32 retry errors started to grow and become more
common as the installed base of WIN95 with new 3C0M TR adapters
increased.  Of course we/I blamed WIN95 and the adapters for all the
problems.

After a month of tinkering with visits to Novell Support page, this list's
FAQ and various hardware tech support centers/pages, an incident was
started with Novell's Client32 support group.  They basically sucked!!  It
was not the real Client32 group that works for Novell, rather a farmed out
support service, which I didn't know until at Brainshare I started talking to
the Client32 group.

We had gotten a bare bones copy of Lanalyzer from Novell Client32
support to help trouble shoot the problem.  They were not much help.
Their main interest was to close the incident, not fix it.
But,  the Lanalyzer did help us discover on our own that we had a lot of
Burst and a small number of Line errors on our network.

A few facts about our network:
We had a 4MB Token Ring (IBM type 2 cable... 9 years old)
Roughly 60 nodes
Synoptics Token Ring hubs
2 Compaq Proliant servers with Netflex TR adapters
Cisco 4000 router with TR adapter
IBM RS6000 with IBM TR adapter
2 very old Jetdirect adapters an 2 new Jetdirect adapters
A mix of 3COM, IBM, SMC TR adapters at the client end w/WIN95

Some things we had done,
*Upgraded to a fully patched Client32
*Apply WIN95b service pack
*Patched all 4.10 servers fully
*(Later) Upgrade  both servers to 4.11 (patched)
*Turn off Packet Burst
*Removed several old Jet Direct cards
*Removed client32 installed MS client for NetWare, reinstalled client32
keeping the NDIS driver for the 3com adapters.
*Tested various SPX settings on the client, and servers
*Tested various auto-reconnect settings at client
*Setting the protocol type to TokenRing and TokenRingSnap only.

There may have been some other small changes that didn't work.  The
Lanalyzer pointed out 2 areas of trouble for us.  Packet Burst errors and
line errors. This bare bones model of Lanalyzer was useful but we
needed more information.

We purchased Managewise 2.1 and a Cable tester from Microtest.

With Managewise we found assorted Congestion reports and A/C errors.
 An error prone TR adapter in the RS6000.  The 2 older Jetdirect adapters
were also a problem.  We replaced the Jetdirect and IBM adapters, no
help.
We had the capacity to upgrade to 16 MB ring speed and decided to
tackle the congestion problem first.  Our biggest fear was that the actual
cable system would need to be replaced.
The upgrade to 16 MB went smoothly and we realized immediate benefits.

The next morning some users who had in the past, many Client 32 errors,
were now error free.  But, some users could hardly connect to the
network or start a network application with out errors.

Turns out it was a combination of a couple of different problems.

1.   4MB ring was being saturated due to traffic and errors and needed to
be upgraded to 16mb
2.  Bad cables, specifically at the client end.  Lobe cables and patch
cables were in bad shape in at least 10 to 15 offices.
3.  Some junction boxes at the office end, needed to be reworked if the
lobe or patch cable didn't fix the problem.  3 offices needed this done.

In each case, a physical cable solution fixed the remaining problems.
We have now been Client32 error free for a couple of days.

I suggest an investment into a package like Managewise is money well
spent.  It could have helped us avoid some of the problems that we have
been experiencing for the last 3 months.

I want to thank this list also, when I first posted the question about the
client32 errors, all I got was hey... you need a sniffer of some sort.  I
thought it was a lame answer and that someone should have a nice pat
solution for me.
Turns out they were exactly right.  The type of problems I was having
needed more information about my physical network in order to trouble
shoot the problem with any degree of certainty.
Also, any kind of network analysis/ monitoring tool is a great proactive
approach to keeping your sanity, avoiding problems  and getting solutions
much faster.

------------------------------

Date: Wed, 21 May 1997 12:03:12 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Win95 Diskless - Netsetup Question

>We've been trying to install Win95 on a NW 3.11 server for use with
>Diskless clients using VLMs.  I've been following Joe D.'s document
>on the subject (dated June 1996), but have run into a problem near the
>beginning.
>
>Page 2 describes running "netsetup.exe, found in nettools\netsetup portion
>of the distribution CD-ROM".  I've been unable to find such a file.  I've
>looked on a Win95 ver. A and ver B. CDROM.  There was a netsetup.bat file
>in a different directory and it does copy some files to the server, but
>not netsetup.pol (refered to later in the document as being copied to the
>server).
-------------
	From your description I'd say you do not have the standard release
Win95 CD-ROM but rather an OEM version or a later version. My standard
release copy says "Microsoft Windows 95 Upgrade" on it, the 24 Aug 1995
initial release, aka Build 950. Because many millions of this edition are
in circulation you should be able to find a copy.
	Again, for other readers, my how-to docs on the matter have pointers
available on a supplemental web page on netlab1.usu.edu. That's literally
netlab1.usu.edu, not www.xxxx nor ftp.xxxx nor xxxx.com. That supplement has
clickable filenames displayed, so just click and the files are yours.
	Joe D.

------------------------------

Date: Thu, 22 May 1997 13:09:53 -0400
From: Tim Munro <Tim_Munro@CARLETON.CA>
Subject: Client32/Win95/Script saga; there is light at the end...

For those of you who have been following the troubles of Scripting
with Win95 and Client32 package, I have just install their newest BETA
v2.20 Client32. Low and behold all my scripting problems are gone. It
works wonderfully. To those who are experiencing these problems it may
well be worth your while trying the beta release.

------------------------------

Date: Tue, 27 May 1997 15:44:01 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Client32 - NDIS or ODI - more info

>According to the README that comes with Client32 for Win95 2.20 (the
>new beta)...
>
>>ODINSUP.386 is software especially for IBM. It is will run on LAN
>>Client or any adapter; it does not distinguish.  However, it does
>>only support Ethernet and Token Ring.  Arcnet and FDDI are not
>>mapped.
>>
>>You can't install ODINSUP unless Windows for Workgroups 3.11 is
>>installed on your system.
>
>So, apparently, you WON'T see ODINSUP if you're running Win95, only if
>you're running WFWG.
--------
	It's amazing what "facts" folks deduce from thin air. No, the
above conclusions are not accurate. ODINSUP is the ODI to NDIS converter
shim letting NDIS-based apps run over ODI drivers. The name translates
to ODI to NDIS Support. It has nothing particular to do with IBM.
	Please keep something in mind here, if you are technically curious.
NDIS is a raw mode thingy, a packet hander-outer software object, which
passes entire frames through intact to applications (and requires the same
from applications). The obvious inference is every NDIS application must
have full knowledge of the frame/media kinds it is to run over so it can
both decode arriving material and compose outgoing material. How much are
we willing to wager that app authors have that much networking knowledge
and if they do then how often do they get it right. That's NDIS for you.
	ODI says leave media and framing details to ODI and just send/receive
the payload. The same app can run over wet string (IPX type 9999) without
being aware of it. The details are written once and put into ODI. Further,
ODI is smart enough to figure out the particular protocol in a frame and
hand it to the registered consummer (app); NDIS polls every app in turn,
offering a peek at the packet header, to find any takers, for every packet.
	Joe D.

------------------------------

Date: Mon, 2 Jun 1997 14:13:17 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: C32 update

>I tried to update my workstations to the latest Client 32 on my Novell 4.10
>network using the network install method. (the station were running the
>original Client 32.) First computer upgrade went fine. However, the rest was
>not that successful.
>What is happing is that now when the computer boots and win95 is loading, I
>see a red message "Command line parameter for DLKPCI,supported slot values
>are:1. When I press enter it continnues to load Win 95 and even prompts me
>to login but not before I got another message:
>Module C:\NOVELL\CLIENT32\DLKPCI.LAN did not remain resident. PCI board
>disappeared.
>I am using Dlink 100BaseT PCI cards.
>
>I am not sure what is going on. I tried even to use C32 uninstall but the
>message still comes up.
-------
	If file nbihw.cfg exists in the Client 32 directory delete it and
reboot. If your board requires a  slot=  command line option then give it.
And finally, C32 has a bunch of problems resolving loading a driver more
than once.
	Joe D.

------------------------------

Date: Thu, 12 Jun 1997 09:12:47 +0000
From: Chad Pranger <cpranger@REMC7.K12.MI.US>
Subject: Client 32 Retry on Token Ring info

If anyone has been having client 32 retry problems on a token-ring
network using IBM shared RAM adapters and Windows 95, this might be
of interest.

I have found a solution to our own particular "Client 32 retry"
problem.  After setting up LANAlyzer and observing the findings over
the course of a day we learned a great deal about the trends and
tendencies of our network.   I set up a stress test (heavy file copy
to and from the server) on a few of the stations that frequently
received the Client 32 error.  Sure enough, it appeared.  LANalyzer
reported excessive receive congestion errors for the machines doing
the heavy file copying.  Other machines would have receive congestion
problems with minor network activity.

A trip to the IBM file download area produced some literature
regarding receive congestion errors on IBM shared RAM Token-Ring
Adapters.  We are using the 32 bit networking built into Windows
95. The default driver Windows 95 uses for all IBM Token-Ring shared
RAM adapters is ibmtok4.vxd.  This driver will yield excessive
receive congestion errors.  The recommended course of action was to
install the new ibmtok5.vxd driver.  I thought that I was using the
latest driver on my machine, but apparently that version of driver is
only shipping with the IBM Turbo Token-Ring adapters, not with the
latest IBM Auto 16/4 Driver disk that I was using.  I downloaded the
driver diskette for the IBM Turbo adapter, installed the new driver
and the congestion errors went away.  In addition to solving the
client 32 retry problem it has also solved many of those "mysterious
problems" that pop up during the day.

LANAlyzer or equivalent is an absolutely essential
tool for any network.  It was a tremendous help in troubleshooting
this situation.  By getting a feel for your network growth, you can
be proactive about network maintenance, before things get out of hand
and start causing problems.  (WHERE have I heard that before? :-))
Without LANAlyzer, many attempts at troubleshooting network problems
end up being speculation.

------------------------------

Date: Tue, 17 Jun 1997 15:24:56 UTC
From: Robert Moss <RMOSS@VM.TULSA.CC.OK.US>
Subject: Re: Win95 Registry

I recently asked for help with the Win95 Registry.  I received the
following suggested sources:

- Newsgroup FAQ at ftp.demon.co.uk under /mirrors/win95netbugs

- "Win95 Resource Kit" found on the Win95 CD as a .hlp file format

- "Windows95 Registry Troubleshooting"  - New Riders

- "Windows95 Registry, Survival Guide for Users" - John Woram, MIS:Press

---------

Date: Tue, 17 Jun 1997 15:11:06 -0700
From: "Rappaport, Shawn" <shawn.rappaport@SPECASTRO.COM>
Subject: Re: Win95 Registry

There's also a good Registry FAQ at:
http://www6.zdnet.com/cgi-bin/texis/swlib/hotfiles/info.html?fcode=000BD3

------------------------------

Date: Mon, 7 Jul 1997 02:18:22 GMT
From: Eric Wikman <eric_wikman@141.COM>
Subject: Re: (Fwd) FW: Client32 and Win95 on Dell

>Client32 installation problems on Dell machines...
>This is 3Com problem. In fact the latest drivers for 3Com Etherlink XL
>cards (which Dell preinstalls on their machines) causes problems with
>client32. The problems you get are GPFs when running the client32
>installation program (this is fixed in v2.20 of client32), and
>reliability problems when using ODI drivers.

I had some trouble with a PC(that is not Dell) with a 3com card that
would never finish the installation process of Client32.  Later I
tried installing the Client32 from the Network Control Panel by
clicking Add then Client then Have Disk.  We now use this procedure
for installing all of our Client32's on all of our PC's.

------------------------------

Date: Wed, 23 Jul 1997 09:55:23 -0400
From: Frank Scaturro <SCATURRO@ADLIBV.ADELPHI.EDU>
Subject: WINDOWS95 NETWORK INSTALL

>I recently installed windows95 to my novell server. And I wanted to
>run the client from the server. When I installed the client, it
>installed about 70meg of data instead of 2meg(which the book says it
>should install). Is there an option like ..."setup /n"?

I'm sorry, that question was a little unclear..but if you have ever
done a windows 3.x network installation you would know that
"setup /n" is for the client install of windows. I ended up calling
microsoft for the answer anyway. For those of you that would like to
know...
you have to setup machine directories using netsetup. It's on the
same install screen for installing the server. Netsetup is found on
windows 95 upgrade CD's only.

------------------------------

Date: Thu, 24 Jul 1997 17:29:11 +0200
From: Corne de Loos <cornedl@DDS.NL>
Subject: Re: Disk Locking Utilities

>Does anyone have any experience using or know of a good program that
>will allow you to completely eliminate the access to local C: drives
>and also not allow them to boot from a floppy. We are a University
>running WIN95 and only want the students to have access to the
>desktop. We also do not want them to be able to CTRL-C or CTRL-BRK
>out of the boot process.

In the Win95 registry there can be an entry:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\
Explorer\NoDrives

[Floyd: Above two lines of stuff are meant to be one]

in which you can put a (hex or dec) number to eliminate drives. This
number is a 26 bit mask to enable or disable drives. For every drive
you want to disable you put a 1 and for every drive you want to enable
you put a 0. The least significant bit contains the mask for the A:
drive and the most significant bit for the Z:-drive.

This disables the drives in all win95 apps. In a DOS-box you are still
able to use all 26 drives.

------------------------------

Date: Fri, 25 Jul 1997 18:01:21 -0500
From: Pete Turner <Peter.Turner@FAMHS.ORG>
Subject: "Gotchas" using Long file name (suggestion) -Reply

Keep in mind the little detail that the SFN for a LFN can
change depending on the directory it is copied to.  If an
ABCDEF~2.TXT goes to a directory without a
ABCDEF~1.TXT the ABCDEF~2.TXT becomes
ABCDEF~1.TXT.  VERY confusing for users.

------------------------------

Date: Wed, 30 Jul 1997 13:11:04 GMT
From: Geoff Taylor <carinehs@VIANET.NET.AU>
Subject: Re: How can I ensure that users run the login script ?

Use C:\windows\regedit.exe on the Win95 workstation to edit the registry
as follows...

Go to
HKEY_LOCAL_MACHINE  \   Network   \   Logon

Then enter the new DWord value ( Edit} New } DWORD Value )
 "LogonMustBeValidated"

Double click the new Name just entered and type in the data
 "1"

After that, a user is forced to log in and cannot just press esc and
bypass the login.

------------------------------

Date: Wed, 30 Jul 1997 13:04:00 -0700
From: Kevin Miller <kevinm@UHS.BERKELEY.EDU>
Subject: Re: Novell Clients, NT 4.0 Server w/FPNW ????

There is a bug (rather, an implementation error) in Microsoft's FPSW
that makes it incompatible with Client 32 clients.  There is a patch
for this on Microsoft's WWW site.

------------------------------

Date: Thu, 31 Jul 1997 19:06:24 +0200
From: Renke Hobbie <Renke.Hobbie@CIP.PSYCH.MED.UNI-ERLANGEN.DE>
Subject: Re: Has *anyone* got a Shared networked Windows95 solution ???

>Is anyone successfully using a shared installation of windows95?

We are using a shared installation of Windows95!
The PCs are connected over a Fast-Ethernet line to a NW4.11-server.

It took me over one year of testing to find all bugs and all tricks to
make it work.

I can't explain every detail here, but here are some of them
(please excuse my poor English writing)

- Look into the Recource Kit and into the Recource Kit error-list at the
  Microsoft Knowledge Base

- It only works with the Microsoft client for Novell networks.
  (With service for NDS, but the server and every user have to bee in the
  same container)

- Machine-directory is on the server. Booting from Hard-Disk.
  system.dat, swapfile and temp-folder on Hard-Disk.

- You can install a shared windows95-PC !only! with a non-PNP ISA Network card!
  So put an ISA (NE2000) and a PCI (3C905) card into the PC, run the
  installation process with the NE2000, and after the 2nd boot, deactivate
  the NE2000 and switch to 3C905. It works! (with some tricks, you have to
  modify the protocol.ini 2 times) And afterwards, Windows95 boots on a
  Pentium 166 over Fast-Ethernet in about 35 seconds.

- Use batch.exe from service pak 1 to create the msbatch.inf.
  Here is an extract of my msbatch.inf:

[BatchSetup]
Version=2.0 (32-bit)
SaveDate=02.14.97

[Setup]
Express=1
InstallDir="G:\WIN95"
EBD=0
ChangeDir=0
OptionalComponents=1
Network=1
System=0
CCP=0
CleanBoot=0
Display=0
PenWinWarning=0
InstallType=3
DevicePath=0
TimeZone="W. Europe"
Uninstall=0
VRC=0
NoPrompt2Boot=1

[NameAndOrg]
Name="CIP - PC-1"
Org="F A U - Psychiatrische Klinik"
Display=0

[Network]
ComputerName="pc-1"
Workgroup="CIP-TREE"
Description="CIP PC-1"
Display=0
PrimaryLogon=NWREDIR
Clients=NWREDIR
Protocols=NWLINK
IgnoreDetectedNetCards=0
ValidateNetCardResources=1
HDBoot=1
RPLSetup=0
WorkstationSetup=1
DisplayWorkstationSetup=0
Security=NWSERVER
PassThroughAgent="BLAUBAER"
Services=, NWREDIR4

[*pnp80d4]
InterruptNumber=3
IOBaseAddress=300

[NWLINK]
Frame_Type=2
NetBIOS=0

[NWREDIR]
FirstNetDrive=F:
PreferredServer=BLAUBAER
ProcessLoginScript=1

[NWSERVER]
BrowseMaster=1
Use_SAP=0

[VREDIR]
ValidatedLogon=0

[VSERVER]
LMAnnounce=1
MaintainServerList=0

[System]
DisplChar=24,1024,768

[NWRedir4]
PreferredTree=CIP-TREE
NameContext=CIP.FAU

[OptionalComponents]
...


- System policies and roving user profiles are working very good. And with
  some tricks I managed to store the user profiles only in the
  home-directories and not at "<machine-directory>\profiles\<username>"

- With a write-protected user.dat in the machine-directory (Novell inherited
  rights filter) I can prevent the users from  logging in as the default user.

- Shared installations of internet-explorer 3.01 and office 97 are working.

Our installation is running for over 4 month on 15 PCs with now 134 users.

------------------------------

