|
Archive-name: windows/win95/faq/part06
Last-Modified: 1998/11/08
Posting-Frequency: Every two months
URL: http://www.orca.bc.ca/win95/faq6.htm
Subject: 6. Novell NetWare (TM) Networking
* 6.1. How do I connect to NetWare servers?
* 6.2. What do I have to do to make the NetWare server work
safely with Win95 clients?
+ 6.2.1. NetWare 2.x
+ 6.2.2. NetWare 3.x
+ 6.2.3. NetWare 3.12
+ 6.2.4. NetWare 4.x (Directory Services)
* 6.3. How to I make NetWare-related TSRs work? They won't work
in the login script.
* 6.4. How do I use a client other than Microsoft's Client for
NetWare?
+ 6.4.1. NETX
+ 6.4.2. VLM
+ 6.4.3. Client32
* 6.5. How do I connect to the server from Single mode DOS?
(Outside of Win95)
* 6.6. How can I receive NetWare pop-up messages?
* 6.7. Why don't I get a login prompt when Win95 starts?
* 6.8. What bugs should I watch out for? Where can I get fixes?
+ 6.8.1. Automatic frame detection doesn't work
+ 6.8.2. NetWare C$ peer sharing bug
+ 6.8.3. WAN routing tables keep getting trashed
+ 6.8.4. Password caching bugs
o 6.8.4.1. How do I disable password caching?
+ 6.8.5. Server ABENDs when I start a Win95 client (and
other bugs)
* 6.9. Top ten NetWare client mistakes
* 6.10. What does Novell's Client32 offer that Microsoft's
Client for NetWare does not?
* 6.11. What's this I heard about MS's client only being NetWare
2.2 compliant?
* 6.12. How do I share my hard drive or printer to other NetWare
users? (Avoid if possible!)
+ 6.12.1. How do I share my printer through RPRINTER or
PSERVER instead?
+ 6.12.2. ...on a Directory Services network? (NetWare 4.x)
* 6.13. How do I make Win95's cool network features work on
NetWare?
+ 6.13.1. System Policies
+ 6.13.2. System Policies on a Directory Services network
+ 6.13.3. Group Policies
+ 6.13.4. User Profiles and Roving Desktops
+ 6.13.5. User-level Security
+ 6.13.6. Remote Administration
+ 6.13.7. Remote Admin on a Directory Services network
* 6.14. My suggestions for preparing an automated Win95
installation and workstation replication
This particular section is rather anti-Novell. Forgive me, but this is
a Win95 FAQ, not a NetWare FAQ. My objective is to make using Win95
easier, and if it means patching and hacking the server, so be it.
Chances are, you have a lot more clients than servers. :-)
Novell MHS mail system users will want to check out the MS
Exchange FAQ, especially the part about the MHS delivery service now
available from Infinite Technologies. This lets you use Exchange or MS
Outlook clients and not have to change your mail server.
Subject: 6.1. How do I connect to Novell NetWare (TM) servers?
First, ask your administrator if he prepared the server for Win95
clients. This is critical, if you want your administrator to like you.
Then, Install Client for NetWare networks, and fill in the "Preferred
Server" value in CNW's Properties. Set your primary login to "Client
for NetWare Networks".
Also, install IPX/SPX protocol (It will install automatically along
with Client for NetWare), and select a frame type in its Advanced
properties. Auto-detect does not always work. Your choice of frame
type depends on what the NetWare server uses. NetWare 3.11 and earlier
typically use 802.3, later servers use 802.2.
The next time you restart, you will get a NetWare login requester
asking for your name and password. When you feed it this, your NetWare
login script will execute.
More details for NetWare Directory Services later.
Subject: 6.2. What do I have to do to a NetWare server to work with Win95 clients?
Many, many, people have crashed NetWare servers with Win95
computers using Microsoft's Client for NetWare. A lot of this is from
the client pushing the server, but a lot more of it comes from
misunderstandings from users!
The most critical thing to do to a NetWare server is to update its
software. Old .LAN drivers might not keep up with the Win95 clients.
An old '386 or '486 class server will also have troubles keeping up
with Pentiums running Client for NetWare. Novell's VLM Client for DOS
causes many of these troubles too. Details are at Rich Graves'
Win95NetBugs site.
In each of these cases, get the latest .LAN driver for your server's
net cards, get the latest base OS patch sets for your server from
netwire.novell.com, and get the Admin edition of the Win95
Service Pack. The service pack tools, in particular, include
improvements in batch setup for NDS networks, and fix the nasty
problems caused by the original Win95 release.
Special notes for server versions below:
* 6.2.1. NetWare 2.x
Ensure you disable Packet Burst and long filenames on the Win95
clients, by adding these lines to the clients' system.ini file:
[nwredir]
SupportBurst=0
SupportLFN=0
You can also use a non-burst frame type (802.3), and enforce no LFNs
via system policies.
* 6.2.2. NetWare 3.x
These servers have a nasty time with Win95 clients using long
filenames and packet burst. Use the NetWare 2.x techniques above, or
apply pburst.nlm and the OS/2 name space fix, available at Novell's
NetWire site. Back up your server before powering up a Win95 client
for the first time!
Client for NetWare will not use long filenames on a NetWare 3.11
server unless you explicitly tell it to, meaning you KNOW you have the
name space patch installed. If you want to use long filenames on a
patched NetWare 3.11 server, you should set up a system policy to
enforce LFN usage, or include:
[nwredir]
SupportLFN=2
in system.ini
* 6.2.3. NetWare 3.12
This, according to my observations, is a patched and bug-fixed NW
3.11. This is the server that Microsoft did most of their client
testing on, and it will work with packet burst and long filenames
without patches. You still need the OS/2 name space to support long
filenames. Set the frame type on the Win95 stations to Ethernet_802.2.
* 6.2.4. NetWare 4.x (Directory Services)
If you don't need to use NDS and you have Bindery emulation available
on the server, you can use the Client for NetWare as per NetWare 3.12
servers. The big catch is it won't recognize an NDS login script! To
work around this, you can hand-copy the NDS system login script to
sys:public and call it net$log.dat. Another work-around is to log
into the server in Bindery mode (An option available in login.exe, or
just log in with regular Client for NetWare) and run a copy of NW
3.12's syscon to make system and user login scripts for Bindery mode.
Details are in KB article Q128253.
However, Microsoft released an NDS Service which will use NDS
login scripts and work with NDS programs. Install Services for NDS by
adding it as a Service (you still need Client for NetWare installed).
Services for NDS is part of Microsoft's Win95 Service Pack 1
complete disk set. You will also need the Shell32 Fix and the NWSERVER
fix, which come with Service Pack 1, and six DLL files from Novell
which come with the NetWare 4.x server. You will still need Bindery
emulation for peer sharing (File & print sharing for NetWare) and
Remote Administration. Set the User Level security provider to
point to this server running Bindery emulation and you're all set. Or
just don't bother with peer sharing via NetWare (Which you shouldn't
do anyway except for Remote Administration.)
I had the opportunity to finally try Services for NDS (25 APR 96) and
it appears to run just fine. After I hand-copied all DLL files from
Novell's SYS:\PUBLIC\CLIENT\DOSWIN directory to SYS:PUBLIC, I could
run nwadmin.exe and the other Win 3.1 NDS utilities in there.
WARNING: Novell now has a 32-bit NetWare API (32-bit versions of their
DLLs) and these DLLs, as far as I know, do NOT work with MS's NDS
client. I haven't tried them, but on more than one occasion I got a
letter from a user regarding them. For example, Pegasus Mail for Win95
requires the 32-bit NetWare DLLs but they don't work with MSNDS. Also,
for the 16-bit DLLs, use the ones in SYS:\PUBLIC\CLIENT\DOSWIN\ and no
others, because the ones that come with Client32 are really 16/32
stubs and require the Novell 32-bit DLLs.
NOTE: The NDS client still depends on accurate Bindery emulation
running on the Preferred Server. If you use any additional services
that depend on User Level Security (such as Remote Administration)
be sure you set the Bindery context to match the Organizational Unit
you want your user list for. In an absolute worst case, set the
Bindery context to point to each of your Organizational Units and
Organization. Type this at the server console, or include it in
AUTOEXEC.NCF (Of course, use your real unit names, not the example
MYORG):
Set Bindery Context = O=MYORG,OU=UNIT1.MYORG,OU=UNIT2.MYORG
Subject: 6.3. How do I make NetWare-related TSRs work? They won't work in the login script?
They won't, no matter how hard you try either. Win95 runs the login
script from a single DOS session, which completely unloads when the
login script finishes. Loading TSRs from a login script is stupid
anyway, in fact, loading DOS TSRs in Win95 in general is stupid.
But if you have to load network TSRs, Win95 did keep the old
winstart.bat capability. Place winstart.bat in your Win95 directory
where it will execute just after all the network components load, and
just before the login prompt comes on. Load your TSRs in that. They
will be available from all DOS sessions afterwards. Details are in KB
article Q127794. Yes this does work; I can run Cheyenne's ARCSERVE
(TM) for Windows 5.01 by loading BREQUEST.EXE this way. Which reminds
me: Do any of you know of a 32-bit BTRIEVE requester for Win95 yet? Oh
yes, TSRs loaded in WINSTART.BAT execute in an independent DOS session
which you'll never see.
Subject: 6.4. How do I use a client other than Microsoft's Client for NetWare?
I won't touch Client32 yet; you can read about it at Novell's
Client32 Home Page and make your own judgments. However, some
applications need to see real mode NetWare clients (even though all
the real mode hooks are there with Client for NetWare, and with
Services for NDS). So...
To use a DOS client, you will need all the regular DOS client software
(LSL, IPXODI, etc). Once you have all that in place, you can add Win
3.1 support from Network Control Panel as a Client.
* 6.4.1. NETX:
Novell no longer recommends running netx.exe, but it does work as it
did with Win 3.1. Install the DOS client, then add "Novell NetWare
Shell 3.x" as a Client from Network Control Panel. Setup will prompt
you for Novell's disks when needed.
* 6.4.2. VLM:
This works better with Win95 than NETX, and is "Safer" than Client for
NetWare for your finicky programs and NDS apps. Try this as a last
resort, if you can't get the app makers to clean up their programs.
Use Novell's regular DOS installation of this client (Don't add the
Windows software from Novell's setup), then add "Novell NetWare Shell
4.x and above" as a Client from Network Control Panel. Setup will
prompt you for Novell's disks when needed.
NOTE: Do NOT use Client for MS/File & Print Sharing for MS networks
alongside a real mode NetWare client! Neither Novell nor Microsoft
support this, and the mix of real mode/protected mode clients can
cause loss of hair for network administrators. Use all protected mode
clients and services if you want NetWare logins AND peer sharing.
Client/FPS for MS networks works great alongside Client for NetWare,
and even Client32 from Novell.
* 6.4.3. Client32
Much of the Client32 stuff that was here is unavailable as of
September 1998. Novell now has an even larger client install (11 MB!)
available from their Download site. You can bet that, when I dust
off my NetWare 4.11 demo CDs again, I'll be trying this.
Subject: 6.5. How do I connect to the server from Single mode DOS? (Outside of Win95)
Win95 Network Setup installed a real mode client for NetWare at the
same time as the protected mode one. If you exit to DOS ("Restart in
DOS mode") or boot to "Command Prompt Only", and you're using
Microsoft's Client for NetWare, you can log in to the NetWare server
by typing
NET START NWREDIR
at the DOS prompt. This will load a NETX compatible client using NDIS2
drivers and protocols. You can then change to your login drive and
perform a normal DOS client login. Since it's only a NETX compatible
client it can't perform NDS logins; so you could try:
NET START NWLINK
Which uses Novell's VLM client, to do NDS logins. I haven't tried
using Microsoft's IPX and Novell's client together, but in theory it
should work. If it doesn't, you can always load Novell's net card
drivers (LSL, etc) and VLM.
NOTE: NWREDIR's real mode components take more conventional memory
than a NETX client would, so you should only use this if your
application can't run in a DOS session, or if you're performing any
debugging. However, these components will automatically load high if
you have upper memory available. You should prepare a special PIF
file for this kind of configuration.
In addition, I found sometimes NET START NWREDIR would give a "This
file system is incompatible" style of message, which happens more
often on NetWare 4 servers. If this happens, NET START NWLINK followed
by NETX or VLM should work.
Subject: 6.6. How can I receive NetWare popup messages?
With Client for NetWare, use WINPOPUP. Add it from Add/Remove
Programs/Windows Setup, in the Accessories components. Keep this
loaded or you won't be able to see or send pop up messages. WINPOPUP
will receive messages from Bindery and NDS clients, but you can only
send messages to Bindery clients. Novell's SEND command in a DOS
session will let you send messages to NDS clients.
You can force WINPOPUP to load by keeping a copy of it in SYS:PUBLIC
(or any other public place) and enforce a System Policy to run it
on start-up. In Default Computer/System/Run, insert an entry with a
UNC path to WINPOPUP.EXE, such as \\SRV\SYS\PUBLIC\WINPOPUP.EXE. This
way, the users don't have any excuse for not seeing pop up messages.
NOTE: Enforcing a policy like this will prevent any other programs
that run from this Registry entry (like SAGE.EXE from MS Plus) from
running. If you have to, include an entry for SAGE.EXE as well (No
error messages come up if the file is missing, so no worries if some
machines don't have Plus) or any other programs that run from this
Registry key (Example: MSPSRV.EXE; Print Agent for NetWare). Again, if
a machine doesn't happen to have the file, the user won't notice an
error message or anything.
There are numerous Winpopup replacements available for download as of
September 1998. Most of these can force-start and even prevent the
user from stopping them.
For all of Novell's clients, their supplied NWPOPUP works just fine.
NWPOPUP however, looks for a Novell version of NETWARE.DRV (Yes I mean
the old 16-bit driver) and won't work with MS's NETWARE.DRV stub.
Subject: 6.7. Why don't I get a NetWare login prompt when Win95 starts?
This is related to a password caching problem I read about on
Win95NetBugs. If the .PWL file is around 900 bytes, it will
by-pass the NetWare login prompt and start Win95 straight away. Login
scripts won't execute, and the only way to get them to execute is to
Shut Down/Close all programs and log on as different user, and re-log
in.
To correct this, delete all .PWL files in your Win95 directory and
re-start the computer. While you're at it, disable password caching
via system policies.
Subject: 6.8. Bugs to watch out for, and patches
* 6.8.1. Automatic Frame Detection Bug:
Auto detect does not always work, especially in multi-protocol
networks. Bring up IPX properties and manually select a frame type.
Use 802.3 on pre-NetWare 3.12 networks, use 802.2 on 3.12 and later
networks.
* 6.8.2. NetWare C$ peer sharing bug:
If you use Remote Administration, it may keep the Admin share
active after you disconnect! Apply Service Pack 1 to fix.
* 6.8.3. WAN routing tables keep getting trashed:
When Win95 stations act like NetWare servers, all hell can break
loose. SAP traffic can bog the network, RIP routing tables get
re-built, clients might log in to a Win95 station instead of the real
NetWare server. Don't use File & Print Sharing for NetWare to share
out printers and files to non-Win95 clients; use the server and print
queues like you're supposed to, or use Client/FPS for MS networks
instead. More on print sharing via RPRINTER later.
NOTE: Novell's latest patch sets for NetWare 3.11, 3.12, and 4.1
correct routing problems caused by lots of SAP traffic. Visit
Novell's downloads site and get the base OS patch sets for your
version of NetWare. Also, to prevent non-Win95 stations from trying to
log in to Win95 machines using FPS for NetWare, set their Preferred
Server switch to the server you're supposed to log in to.
* 6.8.4. Password caching bugs:
Win95 will store your login password locally, and the password
encryption is easily cracked! Apply Service Pack 1 to fix, or better
yet, disable password caching and use User Level Security for
peer sharing. Check out the System Policies part to find out how
to do force this.
* 6.8.4.1. How do I disable password caching?
Set up a system policy file, and include "Disable Caching of
Login Password" or "Disable Password Caching" in Default
Computer/Network.
* 6.8.5. Server ABENDs when I start a Win95 machine (and other
bugs):
Any general mishap that occurs to the server that either causes an
ABEND or otherwise kills it (I won't get into technical details; all I
know is that Win95's demonstrated that it does bad stuff to NetWare
servers). Check the steps you need to prepare the server or
dis-arm the Win95 client.
Subject: 6.9. Top ten NetWare client mistakes
10. Using a '386 machine as a server with Pentiums running Win95 as
clients
9. Installing File & Print Sharing for NetWare without knowing what
you're doing
8. Enabling long filenames on a NetWare 3.11 server (Patch it
first!)
7. Installing Novell's Client32 out of fear
6. Capturing LPT1: to a network printer when you have MSPSRV (Print
Agent for NetWare) on some workstation
5. Turning on SAP advertising in a large routed network
4. Leaving "Auto-Detect" as the frame type for IPX
3. Not specifying the preferred server in Client for NetWare
properties
2. Not updating the server before adding Win95 clients
1. Not using system policies (Always a good idea to use system
policies for basic stuff)
Subject: 6.10. What does Client32 offer that MS's client does not?
Well, this is rhetorical since Novell no longer supplies Client32.
Grab Novell's 11 MB client download.
Subject: 6.11. What's this I heard about Client for NetWare only being NetWare 2.2 compliant?
I've heard bullsh*t about this since Novell's tech note announcement
regarding FPS for NetWare. In their tech document 2907903, Novell
states that Microsoft's File & Print Sharing for NetWare identifies
itself as a NetWare 3.12 NCP server, but really uses codes and packet
types from NetWare 2.2 servers. This is why that Client32 can't see
Win95 computers running FPS for NetWare, even with SAP advertising
turned on. Novell has a reputation for accuracy so I think this is
true.
OK, I believe that MS reverse-engineered NetWare 2.2 to make FPS work.
What I don't believe is everyone else claiming that the REST of Client
for NetWare is only 2.2 compliant. NetWare 2.2 clients (and MS's FPS
for NetWare) can't do Packet Burst. Client for NetWare and NetWare
3.12 servers (and better) can. NetWare 2.2 clients (like NETX) can't
log into NDS trees. OK, neither can Client for NetWare, but the NDS
add-on fills that gap. You're going to say that MS's NDS client is
only NetWare 2.2 compliant?
Novell's obviously published the NCP client and IPX specifications,
because other developers (notably Artisoft and IBM) released NetWare
clients for their products. Microsoft followed suit as well. I don't
expect Novell to release NCP SERVER specs, which lead, most likely, to
MS's decision to take NetWare 2.2 apart and re-write it as a Win95
service.
And so what if FPS for NetWare only acts like a 2.2 server? I only
recommended FPS for NetWare for sharing between Win95 machines
and for Remote Administration. In these two jobs, FPS for NetWare
works as designed.
And here's a good one for Novell. In the same document, they claim
that Remote Registry Service depends on FPS for NetWare. Wrong.
(Insert buzzer sound here.) While Remote Registry depends on User
Level Security, that security comes from a security API in Win95
(SECUR32.DLL), which goes through the security provider software that
comes with the CLIENT. It does not depend on any file sharing service,
though, yes, you would need file and print sharing to go peeking into
someone else's hard drive remotely. If Novell wanted to make Client32
work with remote administration, they could license code from
Microsoft (gasp!) and write their own security provider code. Bet they
can't do that in NLMs.
Subject: 6.12. How do I share my hard drive or printer to other NetWare users? (Avoid if possible)
Depending on whether the clients are Win95 clients or DOS clients, it
can be either really easy or really messy! Complications include the
SAP Advertising bug.
If the clients are other Win95 machines running Client for NetWare,
you merely have to install File & Print Sharing for NetWare networks,
and specify your NetWare server as the security provider in Access
Control. When you re-boot you can share out drives and printers to
specific users in the NetWare server's Bindery.
Now, if the client runs Win95 there's no real troubles, because Win95
will perform "Workgroup advertising" which works like the workgroup
naming service (browse master) in WFWG, and this won't interfere with
normal NetWare communication. To ease browsing troubles, set one of
the sharing machines (like the one with the printer attached) and have
Workgroup Advertising: "Enabled: Preferred Master" so the browse
master control doesn't bounce from machine to machine, and broadcast
useless messages to your server.
Beware if you want to share to non-Win95 clients via FPS for NetWare;
you have to turn on "Service Advertising Protocol" (SAP). This is how
NetWare servers become aware of each other, and if you turn on SAP for
a Win95 machine, it will appear in SLISTs and SYSCON etc as NetWare
servers. You can even get connection info (Server version: "Windows 95
4.00.950, 250 user") from SYSCON. Problem is, not only would SAP
advertising by a lot of Win95 systems cause a lot of network traffic,
it could possibly kill any routing in an inter-network, and make DOS
clients try to log in (as in Preferred Server login) to Win95 servers,
which won't work. If you really want to screw up your network, share
out your hard drive with the share name SYS and make a directory
called LOGIN, and watch what happens. NOTE: Please don't do this,
unless you LIKE getting beaten up by your network administrator.
A better solution is to install FPS for MS networks and put either
WFWG on the non-Win95 clients, or if they can't run Windows, Workgroup
Connection for DOS. Both of these can run alongside Novell's NETX and
VLM client software. OS/2 Warp Connect can load Windows and NetWare
clients simultaneously as well. To save on memory on the DOS
computers, consider using "Direct Hosting over IPX", which will remove
the need to use NetBEUI and save 40 KB of memory or so. The absolute
smartest way, however, is to use a common space on the server.
Now printer sharing is another story...
* 6.12.1. How do I share my printer through RPRINTER or PSERVER
instead?
Oh no... you can't run RPRINTER.EXE on a Win95 station because you
have to run it before Windows loads! Well, you could use VLM and
RPRINTER together but what's the point of real mode network software
on Win95? There is a better way. And no, running it from WINSTART.BAT
doesn't work.
Download and Install Microsoft Print Agent for NetWare. Add a
Service from Network control panel and hit "Have disk", then tell it
to look in ADMIN\NETTOOLS\PRTAGENT on the Win95 CD-ROM, or wherever
you extracted that download. Note that Print Agent will only work if
you run Client for NetWare; it won't run with VLM or Novell's
Client32. MSPSRV is a Queue Server (as opposed to a Remote Printer).
BE WARNED: MSPSRV was a last minute hack by Microsoft and doesn't have
the re-connect features, etc of Client for NetWare. In addition, it
requires a Bindery print server object. NetWare 4.x Administrators:
Use PCONSOLE to make Bindery mode print server objects.
UPDATE September 1998: Microsoft released bugfixes to a LOT of the
problems documented here. The files needed, however, appear
unavailable for download. According to KB article Q132786, the
following three files replaced will correct them:
* MSPSRV.EXE v4.00.952
* NWPP32.DLL v4.00.952 or later
* NWREDIR.VXD v4.00.952 or later
These come with Win95 OSR 2.1 and 2.5, but I've prepared a
special download that contains these updated files in case you
don't have one of these releases (minus NWREDIR.VXD because I only had
the NDS version).
Just before you re-boot, change your IPX properties so you have
Maximum Sockets and Maximum Connections set to at least 70, like
RPRINTER/PSERVER's recommended setting of
SPX CONENCTIONS=60
I suggest 70 instead of 60 because FPS for NetWare and Remote Registry
require additional free sockets. And speaking of Sockets, you can't
use a third party TCP/IP dialer if you plan to use MSPSRV, because it
uses the Winsock interface over IPX.
Now, also just before you re-boot, run PCONSOLE and create a new print
server object. Add one printer to it named "Printer 0", set for Remote
Parallel, LPT1 (Or just Parallel on NW 4.x servers). Attach it to a
print queue on the NetWare server, if necessary, detaching the queue
from any other print server object it was attached to. If you did
detach it from an existing print server object, you will have to
re-start that PSERVER, which usually means typing unload pserver and
load pserver xxxxxxxx (whatever the print server object's name was)
from the NetWare console.
Now finally, re-boot the Win95 station and log in. The local printer
attached to LPT1: will now have a "Print Server" tab in its properties
sheet. Be warned: This tab has bugs, so follow these six steps
precisely!
1. Select the Print Server tab and turn on "Enable print server for
NetWare". If you get any evil error message just ignore it.
2. Select the NetWare server with your new pserver object, from the
DROP DOWN LIST, even if it was already selected.
3. Select the pserver object you just created from the NetWare server
drop down list.
4. Select how often you want this computer to check the queue for
print jobs. The 30 second default is fine.
5. Hit OK.
6. Hit Start Menu/Shut Down, close all programs and log in as
different user, and re-log in. Now all jobs in that NetWare queue
will find their way to this printer.
The reason you have to re-log in, is you will lose your drive mappings
as soon as you OK those settings! MSPSRV is riddled with many dumb
bugs, but Microsoft seems to swear by it. Check out KB article
Q134747 for all the gory details. Every time you view this
"Print Server" tab, it seems you will lose all your drive mappings.
Re-logging in will restore them.
You will also have to create a print server object for EVERY Win95
computer sharing a printer this way, because each system becomes a
PSERVER look-alike (called a Queue Server), with all the requirements
of a stand alone PSERVER.EXE or PSERVER.NLM; the only difference is
that it multi-tasks. You will also have to remain logged in to keep
MSPSRV running, as logging out causes all programs to close, including
MSPSRV. It will re-start when you re-log in, or cancel the log in. On
machines with very active printers, you might want to consider setting
their Default Login to "Windows Logon" with a blank password, so they
automatically log in to NetWare on power-up, and re-enabling Automatic
NetWare Login for those specific machines, if you disabled it via
system policies.
Oh yeah, one more thing: Don't capture LPT1: to a network queue if
you're running MSPSRV to share a printer. This might have worked in
RPRINTER, but it doesn't work here. What will happen is that MSPSRV
will suck the job off the queue and send it to the printer hooked up
to LPT1, then that printer will send the job to wherever LPT1 was
captured to, instead of to the local printer! I've seen this happen!
Create a second printer in Win95 and have it point to the queue, if
you're afraid of cutting in front of other people's print jobs.
So to recap: Create a print server object with a single printer, for
each Win95 computer sharing a printer through MSPSRV. Attach a print
queue to each of them. Make sure you aren't capturing LPT1: to a
network printer. Install MSPSRV on the Win95 computers sharing
printers. Set Max Connections and Max Sockets to at least 70 in
IPX/SPX properties. Re-boot to activate. Select the "Print Server" tab
in the printer you want to share. Select the file server from the
drop-down list and the print server object from its drop down list.
Hit OK. Re-log in. And Pray.
* 6.12.2. ...on a Directory Services network?
I managed to get MSPSRV running on an NDS network. Originally, I
thought switching the NetWare 4.1 version of PCONSOLE to Bindery mode,
and creating Bindery queues and print server objects, would do the
job. Apparently not. NDS clients can't readily print to Bindery print
queues.
So, after a lot of fiddling I realized that Novell's Quick Setup
option in PCONSOLE does the job almost perfectly! Quick Setup creates
a new NDS queue, NDS printer, and NDS print server object, and makes a
Bindery version of the queue and print server object, granting
printing rights to everyone in the NDS tree. A little extra fine
tuning and it works straight away with MSPSRV. Here's what I did, with
my example object names in (parenthesis):
1. Use PCONSOLE's Quick Setup option, in NDS mode, to create an NDS
queue (Q1), printer (P1), and print server object (PS-INLINE). If
you already have an NDS print server object, be sure to specify a
NEW print server object and not use any existing ones.
2. Change the new printer object (P1) so it uses LPT1, IRQ 7, "Change
forms as needed", and have it service the NDS queue (Q1).
3. Switch PCONSOLE to Bindery mode (Press F4), edit the Bindery queue
(Q1) so its settings match the NDS queue. Add the Bindery print
server object (PS-INLINE) to the list of print servers for this
queue.
4. Edit the Bindery print server object (PS-INLINE) so its settings
match the NDS print server object, and create a Bindery printer
within this object with the same name as the NDS printer object
(P1), and the same settings (printer number 0, LPT1, IRQ 7, Change
forms as needed). Have this Bindery printer service the Bindery
queue (Q1). The big catch is that Bindery configurations aren't
accessed by NDS objects, or vice versa, as PCONSOLE's warning
tells you. Heed that warning.
5. With all that accomplished, the NDS objects and Bindery
equivalents will work together as if they were one set of objects.
Now, go to the Win95 station running MSPSRV and have it service
this print server object (PS-INLINE) as per the regular
instructions. If you're switching an existing queue to this new
print server, you'll need to stop and re-start PSERVER.NLM on the
server so it won't try to service that queue anymore.
All this fiddling may take a while, but it's the quickest way I could
get it working, so that both NDS and Bindery clients can print to the
printer shared via MSPSRV. And surprisingly, many of the bugs
Microsoft mentioned in KB article Q134747 above, don't show up this
time. Not bad at all! Yes, you have to do this for each Win95 station
sharing a printer this way.
Best of all, MSPSRV takes far less memory (a mere 64 KB on the
workstation) than Novell's NPRINTER Open Beta.
Rob Menasco outlined a few additional things to watch out for:
* Go through the Print Server tab and reselect all items, click on
"Apply". (This is documented in the MSPSRV KB article above;
reselect the print server from the drop down list)
* Re-boot, make sure print server is active. I do a USERLIST from
DOS and look for an attached print server in PCONSOLE.
* In the Spool button on Printer Setup: Set to "Direct Print" and
"Bi-Directional". This fixes the unknown system error. (I gather
this is so MSPSRV writes to LPT1: directly, rather than through
the Win32 print API)
* Watch for the source or error messages. The Spool errors come from
SPOOL32 or the PRINTERS folder.
* Watch for Rights problems (Use WINDOWS_PASSTHRU account; make sure
it has rights to the spool).
Subject: 6.13. How do I make Win95's cool network features work on NetWare?
It took a bit of practice but I managed to get everything working,
including Remote Registry. Some basic items to remember when
installing Client for NetWare alongside of these cool features:
* Use IPX Maximum Connections and Maximum Sockets values of 32 each
(70 if using MSPSRV too)
* Create a separate Administrators group if you have a team of
administrators to simplify setting up Admin permissions.
* Set aside lots of space (250 MB total about) on your SYS: volume
for user profiles. (About 200 KB per user)
* Install any patches needed to make long filename support work, in
fact, install the base OS patch set for your version of NetWare.
* Create a WINDOWS_PASSTHRU user with 0 KB disk space limit, a blank
password, and no privileges whatsoever. (This is so you can
administer workstations that don't have anyone logged in to. You
can do without this account, but someone will have to log into
that station before you can remotely administer it. Kinda
pointless actually.)
So here's how to do all those cool features...
* 6.13.1. System Policies
Prepare the CONFIG.POL file using POLEDIT.EXE (On the Win95 CD-ROM)
and copy it to your Preferred Server's SYS:PUBLIC directory. I finally
verified this and sure enough, it reads from SYS:PUBLIC. Make sure
that everyone has read and file scan rights to this directory,
including GUEST if you have such a user.
Useful policies for NetWare networks include:
* Network path for Windows files
* Remote Update: Automatic (Use default path. In this case, the
default path is \\loginserver\SYS\PUBLIC\CONFIG.POL)
* Disable/Enable Long Filename support (You have three choices here,
disable, enable, enable for NW 3.11 or older servers)
* Disable Password Caching
* Disable File and Print Sharing Controls (Remote
Administration still works)
* Disable Automatic NetWare Login
* Preferred Server
* Disable SAP Advertising
* User-Level Security (Use your server's name as security provider)
* 6.13.2. System Policies on a DS network
Microsoft's Services for NDS has some pretty cool extensions to this
policy logic; you can enforce policies dependent on whatever level on
the NDS tree you log in to (whatever your current context is),
including specific Organizational Units, or the entire Organization.
All this stuff only works if you installed MS's Services for NDS in
addition to the Client for NetWare, and you're doing NDS logins.
Otherwise, for Bindery logins, it still reads CONFIG.POL from
SYS:PUBLIC.
Let me make that clear: The NDS client has two separate rules, one for
a Bindery login (Same as for original Client for NetWare) and one for
a DS login. You need to specify the DS policy file and the Bindery
policy file separately if users switch between DS and Bindery logins.
To add NDS policies, change your POLEDIT template to the MAPLE.ADM
template included with Services for NDS. Then load your
previously-made CONFIG.POL file and make the appropriate NDS policy
changes. All other policy settings made from ADMIN.ADM will stay
unchanged.
Bring up your Organization and Organizational Unit icons up in Network
Neighborhood. If you have Admin privileges in these units, bring up
properties for them. You'll see an "NDS Administration Settings" tab.
Here, enable system policies and specify the volume name (including
context, such as MYSERVER_SYS.MYORG) and file name (including path,
such as PUBLIC\CONFIG.POL) for the policy file. The name need not be
CONFIG.POL; it can be INLINE.POL or whatever, but you should make sure
that the policy file is in a public place, such as the good old PUBLIC
directory. Do this for each Organizational Unit and for the whole
Organization as you see fit. Both Bindery and DS policies can come
from the same CONFIG.POL file.
NOTE: Policies don't flow down the NDS tree like other properties do.
You will have to re-apply the policy setting to each Organizational
Unit within your master Organization, or you may use different
policies for each Organizational Unit.
Two very useful NDS policies (Include these in the Organization's
properties along with other basic policies):
* Load NetWare DLLs at Startup (To make some dumb NDS apps work.
Also copy the DLLs themselves from SYS:PUBLIC\CLIENT\DOSWIN to
SYS:PUBLIC)
* Allow only NDS logins (To prevent User Profile and System
Policy screwups)
LICENSING ALERT: If you maintain multiple servers and one policy file,
a single login will consume one license on the default login server,
AND on the server with the policy file! If these are the same server
there's no problem, but if the policy file is on a different server
(as you specify with the NDS Admin settings), Win95 won't log out from
that server until the user logs out from that station (Perhaps not
until shutdown?)
One workaround could be to use that Win95 NCP server, as suggested in
section 6.16.7 below, to store the policy files (which has a "250
user" license, if SYSCON is to be believed). To accomplish this, first
add the Win95 machine in question to the DS tree, using NWADMIN, as a
NW 3.12 (or other non-DS) server. Then add a volume object which
matches one of that machine's share names. (You need this because the
policy file has to exist on a defined DS volume!) Finally, copy that
policy file there and specify it in the NDS Admin settings as normal.
This is a hair-brain scheme; I can't test it because I don't have
access to a DS network to try it on.
* 6.13.3. Group Policies
You will need to include group policy support on each workstation to
enforce policies for GROUPS of users, and the groups themselves must
exist in the server's Bindery or Directory.
To add group policy support, run Add/Remove Programs/Windows Setup,
hit "Have Disk..." and pick the path on the CD-ROM
ADMIN\APPTOOLS\GROUPPOL, and select Group Policy support. Once done,
Win95 knows to grab policies you set for groups of users as well as
specific users.
You can automatically install group policy support on workstations by
adding Group Policy support, using INFINST.EXE to add it to the server
copy.
* 6.13.4. User Profiles and Roving Desktops
Win95's Client for NetWare stores a user profile in their MAIL
directory, so be sure you give each user one. SYSCON automatically
creates a MAIL directory for each new user. The Win95 station copies
their profile to the MAIL directory on log out, and reads it in on log
in.
You should enforce "Enable User Profiles" as a system policy, to
keep multiple profiles straightened out.
Now regarding Roving Desktops. The Desktop directory and Start Menu
directory (which as you would recall, are just a bunch of .LNK
and .PIF files) get copied to the user's MAIL directory too, if they
turned on "Include Desktop" and "Include Start Menu" in Passwords/User
Profiles. Because Shortcuts have long filenames, you need to enable
LFN support on the SYS: volume. This will only work on patched NW
3.11, NW 3.12, or NW 4.x servers with the OS/2 name space installed.
Enforce LFN support via system policies.
You should also ensure you have enough space on your SYS: volume for
the shortcuts! Microsoft recommended setting aside 150 KB per user,
but my own custom profile eats 250 KB easily!
Services for NDS stores a user profile in the user's HOME directory
instead of the MAIL directory, so make sure you define a home
directory for each user, but the same rules regarding roving Desktop
and Start Menu (LFN support, space requirements) apply.
NDS clients can perform Bindery and NDS logins, so it is possible to
have two sets of profiles for each user, one in their HOME directory
and one in their MAIL directory! You should enforce NDS logins only,
via system policies, to prevent this mix up. Remember that MS's
NDS client has two separate policy rules for Bindery and DS logins.
* 6.13.5. User-Level Security
Quite easy. Do it through System Policies. In the CONFIG.POL you
create, specify User-Level Access, and type in the name of the server,
and specify the type of server as NetWare server.
If you do this on a DS network, the server you specify needs Bindery
Emulation turned on. To do this, make sure you have this somewhere in
your AUTOEXEC.NCF file on the server:
Set Bindery Context = 0=MYORG (and how many other OU= entries you want)
* 6.13.6. Remote Administration
Install FPS for NetWare or FPS for MS networks, install Remote
Registry service, and enable User level security (No choice
really for FPS for NetWare). Keep SAP advertising OFF. Then, from any
other Win95 station, log in as SUPERVISOR or ADMIN and get properties
on the Win95 station from Network Neighborhood. Use the new Tools tab
to access administrative programs.
Of the available remote admin tools, Net Watcher will also work for
viewing activity on the NetWare server, as well as the Win95 machines.
Net Watcher grabs the same information made available via SYSCON. You
may remove users from the server as needed too.
There is one bug in Remote Administration, that makes the remote
system keep sharing its hard drive, even when you end the Remote Admin
session. Install Service Pack 1 on the remote station to correct
this. To see if you have this bug, Administer the target machine (so
you can view its HD contents) then try logging in as someone else and
hit Start\Run... and type in \\machine\C$. If this brings up a window
with that drive's contents, you have the unpatched services on there.
Again, apply SP1 to fix it.
The most wicked tool available, Remote Registry, lets you edit the
remote machine's registry to fix Win95-specific problems. You need
this service is you want to run System Monitor, REGEDIT, or POLEDIT to
monitor or edit the remote machine.
* 6.16.7. Remote Admin on a DS network
Remote Administration (and many of Win95's NetWare add-ons) depend on
Bindery services running on your preferred server. Net Watcher and
Administer work without hassles, but anything requiring Remote
Registry (System Monitor, REGEDIT, POLEDIT) needs a separate Bindery
server to act as security provider. This is a SECUR32 bug in MS's NDS
client that they admitted to in KB article Q143398. If you use
the regular Client for NetWare on a DS network, you can use Remote
Registry on machines that have the NDS client.
So, if you can live without Remote Registry, or if you use the regular
Bindery client on your Admin machine, you can treat the administrative
setup like you would for a Bindery network. Of course you can't run
NWADMIN then, but...
I did manage to get Remote Registry running on an NDS network about
the same time I got MSPSRV working. Remember where MS said you needed
to have a separate Bindery server to provide security? Well... Win95
with FPS for NetWare acts as a Bindery server, so why not use another
Win95 station as a security provider? It does work! And I was able to
log in to the NDS tree and run Remote Registry, and NWADMIN, on other
stations with users logged into the NDS tree, and FPS for NetWare
worked normally too. This trick comes in handy if you also have
multiple servers and you're running into the licensing problem I
mentioned in section 6.13.12; this Win95 machine can also hold the
policy file and not eat up any licenses on your "real" servers.
Remember: You only need to do this if you want to use Remote Registry
service on a Win95 DS client running MS's services for NDS in a DS
network, and you're using MS's Services for NDS on the machine you're
administering from. Net Watcher and Administer both work without this
nonsense, and the standard Client for NetWare works with Remote
Registry straight away.
So here's what I did:
1. Set aside one Win95 computer (an 8 MB machine will do) and install
Client for NetWare and FPS for NetWare. No other clients or
services. Have its User Level Security settings point to your NDS
server. Check that server's Bindery context so it at least has
your Administrators' user names available. On that one machine
ONLY, turn on SAP advertising and turn off Workgroup advertising.
You might want to get the latest patches for NetWare 4.1, to
prevent SAP traffic from killing any routing in your network. This
machine won't work with Remote Registry, so don't bother
installing it.
2. On all the other Win95 machines running NDS, change their User
Level Security settings to point to this one Win95 machine. They
can still have their original Preferred Server and Preferred Tree
defaults the way they were. See that all these machines have
Remote Registry service and FPS for NetWare, and they have SAP
turned OFF. You can do this through System Policies, but the
machines will have to re-boot once to make this take effect.
3. After rebooting the other Win95 machines, change their Remote
Administration settings so they include users from the emulated
Bindery on the security-providing Win95 machine. You can even
specify this machine, if you wish, in MSBATCH.INF during a Win95
installation.
4. At this point, all Win95 stations except one are using that one
Win95 machine for a security provider. That one machine is using
the NetWare 4.1 server as a security provider, mirroring its user
list. Remote Registry services will work as they did for the
original Client for NetWare. If it prompts you for a password, use
your login name and password.
5. (Optional) You can even enforce this via System Policies; you
can add the single machine to the CONFIG.POL file (File/New
Computer...) and have it use the NetWare 4.1 server for security
and turn on SAP. Have the Default Computer settings use that one
machine as provider, and turn OFF SAP. This way you don't have to
go to each machine to change their security provider settings.
This is a lot of work really. At this point, most sysadmins would've
probably gone to Windows NT.
Subject: 6.14. My suggestions for preparing an automated Win95 installation
In the last few weeks (8 AUG 96) many administrators asked how they
can copy Win95 to several machines at once. Well, they are trying to
use XCOPY to copy the whole Win95 directory. Let me get one thing
straight: THIS DOESN'T WORK!!!!!!!!!
Why doesn't a straight XCOPY work?
* Long filenames
* 20 MB of hidden files
* Registry
* Unique IO.SYS and MSDOS.SYS
* Program Files directory
* Different system device drivers for different motherboard
chipsets!
OK? Image-copying Win95 doesn't work. Get over it. Would you
image-copy a NetWare server? An OS/2 client? An NT client? No. So
don't try to image-copy a Win95 client. Make a server based
installation using the steps below, and automate as much of the setup
as you can. This way, you can run a Win95 setup from the server and it
would take just a little longer than a straight XCOPY would, but be a
lot cleaner.
So, if you're building a Win95 network based on NetWare servers,
here's my suggestions. These come from my NDS experiments, so you can
omit any references to the NDS add-on if you aren't using a DS
network. I based this scenario on workstations that have their own
hard drives (minimum 200 MB) and copy all Win95 files to the station.
The stations themselves had these components automatically added to
them:
* Client for NetWare Networks
* IPX/SPX Protocol
* Net card driver of your choice
* File and Print Sharing for NetWare Networks
* Microsoft Remote Registry
* Microsoft Print Agent for NetWare
* Services for NetWare Directory Services
Believe me, don't waste time with minimal shared installs if you can
avoid it. You can do shared installs of the apps themselves later. The
stations featured full client functionality, Queue Server capability
as needed, and Remote Admin access.
Optionally, you can replace FPS for NetWare with Client for MS and FPS
for MS networks. The key to making Remote Admin work is to have some
kind of file sharing service and some kind of security provider. FPS
for MS networks does work with NetWare servers acting as a security
provider. If you do this, make sure you make the NetWare login the
primary login, and make sure the machines have enough memory to handle
both clients. If you're doing this on 8 MB machines or you're tight on
memory, just stick with the single client and services.
1. Download and install the base OS patch sets for all your NetWare
servers, and download the Admin edition of Win95 Service Packs.
2. Make an Administrative installation of Win95 using NETSETUP.EXE on
one, or more, of your servers. You will need to prepare one Win95
client to perform the Admin installation from, and this machine
will probably become your admin workstation. Prepare this Admin
machine just like you would any of the targets. You could also
make up your policy file using POLEDIT.EXE, and copy it to the
server.
3. Use INFINST.EXE to apply the service pack to the Admin copy. Run
INFINST, give it the Admin copy's UNC path
(\\server\SYS\PUBLIC\WIN95 or whatever), give it the path to the
Admin service pack, and let it install.
4. Keep using INFINST to apply the needed additional components
(Services for NDS, Remote Registry, MS Print Agent, etc) to the
Admin copy. Remote Registry and Print Agent are on the CD-ROM in
ADMIN\NETTOOLS\REMOTREG or \PRTAGENT. Don't forget to include the
Group Policy support here too, if you have group policies.
5. Exit INFINST and run BATCH.EXE (The new version that comes with
the service pack) and make all the settings you need. In the list
of Services, pay special attention to the ordering of services
(NWREDIR4, NWSERVER, REMOTEREG, PSERVER) for those three, because
MSPSRV (the PSERVER entry) will balk if you add PSERVER before
NWREDIR4. I know it sucks. You can switch them around later if you
need. Use BATCH.EXE to make any settings you want for the
automated install, but be extra sure to keep "Immediately re-boot
PnP and PCI machines" turned off to prevent Setup from exiting
prematurely. COOL TRICK: Use BATCH.EXE's "Read settings from
Registry" to copy the Admin machine's settings. Finally, save the
settings with filename MSBATCH.INF to the Win95 Admin copy's
directory.
6. Make up a network boot disk so you can access the server, and boot
up a target workstation so you can try installing Win95. Keep the
Admin machine on and logged in so you can make quick fixes during
this test.
7. As Setup runs, you should be allowed to install the right net card
driver. Also, when that network screen comes up, make sure you
don't get any errors about "Print agent cannot be installed
with...". If you do, change the ordering of services back in
BATCH.EXE and try again. Cancel the Setup here and try again,
until said message does not come up. PRTAGENT should be the LAST
entry in the Services box back in BATCH.EXE.
8. Pay attention to any error messages that occur during file
copying. You will probably get an error that it couldn't find
MSNDS.BAT or some such file. If so, go to your ADMIN machine and
copy the needed files from the NDS client copy to the shared copy
of Win95, then hit "Retry" on the test machine. You will only have
to do this ONCE; since the file now exists it won't complain the
next time you try.
9. During the second part of Setup, if you get any messages saying it
found new hardware and it wants you to re-start the computer, hit
"NO" so Setup can finish. Wait until Setup finishes before
allowing the system to re-boot.
10. After Setup finalizes the settings, check to make sure everything
works. Inspect the network properties so all your settings took as
you specified. You can then do some final tuning, like setting the
[vcache] entry in system.ini, and take whatever settings you did
in your final tuning, and use INFGEN.EXE to have them install
automatically next time.
11. Once you're comfortable with your automatic setup, make a few
copies of that boot disk and happily start making workstations.
You can continue to add components to this server copy and install
from them as needed (like the dial-up scripter, Ben Goetter's
Widgets for Exchange, etc).
NOTE: If you want to maintain more than one Admin copy of Win95, yes,
you CAN image-copy this Admin installation to multiple SERVERS. Make
up one good Admin copy, then spread it to all your servers in your WAN
if you choose.
90% of the NetWare networks out there have remote printers I'm quite
sure people want to print to. There is no harm in installing MSPSRV on
every machine (it only eats 64 KB of disk space, and it won't take up
memory unless you invoke it), or Remote Registry, or File & Print
Sharing if you disable file and print sharing controls via System
Policies.
If you add components to the server install AFTER you installed the
workstations, you can usually copy said components from Add/Remove
Programs/Windows Setup, then hitting "Have disk" and pointing to the
server copy of Win95. Anything you can install using INFINST.EXE is
installable from this control panel, and it will show in the list of
components to choose from. Definitely see about including a [vcache]
setting in a custom INF file you can create with INFGEN, and install
it automatically for a maximum cache size (1024 KB) to make room for
MSPSRV and Remote Registry.
INFGEN.EXE is a very valuable tool for inserting custom settings. You
can copy your computer's .INI or Registry settings to this .INF file,
then install those settings to the server copy using INFINST. It's
only available with the Win95 Service Pack's Admin edition.
--
==============================================================================
= I am Gordon of Winterpeg. Junk mail is futile. Post MakeMoneyFast =
= Find out why: http://spam.abuse.net/spam/ Or eat pink meat from a can =
= World's best computer: http://www.amiga.de/ they're both the same =
= Windows 95 FAQ: http://www.orca.bc.ca/win95/ http://ga.to/mmf/ =
==============================================================================
|
Safelist Submitter is a 100% automated cloud-based software helping clients advertise their businesses, You website faqs.org, products, blogs, and facilities following no effort on your part!
We pull off all your advertising feat for you!
https://rebrand.ly/peussfp
createsplashpages.com/splash.php?id=5940
Best Regards
City. Belkuchi
Districts. Sirajgonj
Countries in Bangladesh
My all proton working save normally
And rfcs link workings locks and blocking
Thank you
City. Belkuchi
Districts. Sirajgonj
Countries in Bangladesh
My all protocol working save normally
And rfcs link workings locks and blocking
Thank you
I'm shocked, this is solitary of the most engrossing videos in the fascinated by of macho that I watched.
I exhort to worry it, I indubitably could not tear myself away from watching it. Would suitor to do the lull and all again.
https://xcavy.com/videos/35213/letsdoeit-lana-rhoades-creampied-at-her-porno-academie-interview/
Who conclude help?