Win95 FAQ Part 7 of 14: Networking
gor...@intouch.bc.ca
Last-Modified: 1998/11/08
Posting-Frequency: Every two months
URL: http://www.orca.bc.ca/win95/faq7.htm
Subject: 7. Networking in General
* 7.1. Windows 95 networking basics you MUST know
* 7.2. How do I connect to...
+ 7.2.1. ...other Windows 95 computers?
+ 7.2.2. ...other Windows for Workgroups computers?
+ 7.2.3. ...Windows NT servers and Windows NT domains?
o 7.2.3.1. How do I get Win95 to honor NT %username% ?
o 7.2.3.2. Bugs to watch out for, and patches
o 7.2.3.3. How do I disable password caching?
o 7.2.3.4. How do I log in to multiple domains?
o 7.2.3.5. Top ten NT network mistakes
+ 7.2.4. ...Banyan Vines( tm) servers? (Who uses this
anyway?)
+ 7.2.5. ...LANtastic( tm) servers? (Yes Virginia there IS
a 32-bit LANtastic!)
+ 7.2.6. ...AppleTalk (tm) AFP servers?
+ 7.2.7. ...IBM OS/2 LAN Servers?
+ 7.2.8. ...other network servers? (DOS client advice)
+ 7.2.9. ...The Internet?
* 7.3. How do I share my hard drive or printer to...
+ 7.3.1. ...other Win95 users?
o 7.3.1.1. ...on The Internet?
+ 7.3.2. ...other Windows for Workgroups users?
+ 7.3.3. ...Macintosh (tm) users?
+ 7.3.4. ...other computers' users? (SAMBA network clients)
* 7.4. How do I run DOS TCP/IP or packet-driver apps in DOS
sessions in Win95?
* 7.5. How do I print to HP JetDirect (tm) printers on the
network?
+ 7.5.1. Port Aliasing, or How do I print from DOS programs
to JetDirect Printers?
* 7.6. How do I use these cool networking features...
+ 7.6.1. ...system policies?
o 7.6.1.1. ...on a Windows NT network?
o 7.6.1.2. ...on another network with a 32-bit client?
o 7.6.1.3. ...on another network with a DOS client?
o 7.6.1.4. ...on a peer to peer Win95 network? (It is
possible, but not easy!)
+ 7.6.2. ...user profiles?
o 7.6.2.1. ...on a stand-alone workstation?
o 7.6.2.2. ...on a Windows NT network so it'll follow
the user around?
o 7.6.2.3. ...on another network with a 32-bit client?
(Not possible on DOS clients)
o 7.6.2.4. Why user profiles is a really cool and
useful feature!
+ 7.6.3. ...remote administration?
o 7.6.3.1. ...on a Windows NT network?
o 7.6.3.2. ...on a Peer Win95 network?
+ 7.6.4. ...user level security to shared drives and
printers?
+ 7.6.5. ...server based installation?
* 7.7. Windows 95 has (this security bug). How do I fix...
+ 7.7.1. ...the "cancel" button on the login window?
+ 7.7.2. ...the Samba bug I heard about?
+ 7.7.3. ...the password caching bug?
o 7.7.3.1. How do I disable password caching?
o 7.7.3.2. How to enable user level access to
eliminate the need to cache passwords
* 7.8. Visiting Rich Graves' Win95NetBugs site for details
------------------------------
Subject: 7.1. Windows 95 networking basics you MUST know
I briefly described NDIS 3.1 back in the Hardware section, but
I'll cover it quickly here again. It's a Plug & Play version of
Microsoft's Network Device Interface Spec, which lets you do cool
stuff like disconnect from the network when you undock your notebook,
then re-connect as soon as you insert a PCMCIA network card, or dial
in with your modem.
Win95 has four classes of network components: Clients (For using
shared resources), Services (for sharing or controlling shared
resources), Transport Protocols (To communicate over network cards),
and the network cards themselves. Protocols can use any network card,
and usually, clients and services can use any protocol (there are
specific dependencies, such as Client for NetWare on IPX/SPX
Protocol). Clients are actually file system drivers, which use local
caching (VCACHE) to off-load the server a bit.
NDIS 3.1 software does NOT occupy conventional memory, so if you have
all Win95 clients, services, drivers, and protocols, you can run your
DOS programs within Win95 without worrying about how much RAM you
have. This goes for IPX network games too.
All net components in Win95 should conform to this, otherwise don't
waste your time.
------------------------------
Subject: 7.2. How do I connect to...
* 7.2.1. ...other Windows 95 computers?
Get a Win95 compatible net card for each machine, tie the cards
together however they're supposed to tie together, and install these
components on it:
* Client for MS networks
* Win95 net card driver (may also be Dial-up Adapter: See
section 8.5.1 for connecting via modems)
* NetBEUI Protocol (Or any single common protocol; NetBEUI's the
easiest to set up, but IPX will get you a bit more speed. If using
dial-up, ALWAYS use NetBEUI)
* File & Print Sharing for MS Networks
Usually, when you insert a net card for the first time, Win95 Setup
will install Client for MS and Client for NetWare networks, and all
the needed components, at the same time. After everything works you
can remove unneeded stuff to make it faster.
Use unique computer names and a common workgroup name in the
Identification tab. To ease browsing difficulties, set aside one
computer to be turned on all the time (the one that has the printer is
a good candidate), and set "Browse Master: Enabled" on that machine's
File & Print Sharing properties. If one of them is a dial-up server
(See section 8.5.1), make the dial-up server the "browse master"
instead of the dial-up client.
* 7.2.2. ...other Windows for Workgroups computers?
Set up the Win95 machine as you would for networking Win95 machines
together. The WFWG machines use the same protocols, from the Transport
protocol up, as Win95 does. On the WFWG machine, tell it to install
Microsoft Windows Network support.
Set aside one Win95 machine to act as Browse Master, as Win95 machines
take browse master precedence over WFWG machines. This will ease
browsing troubles. Set that machine's FPS properties to "Browse
Master: Enabled".
NOTE: If you use IPX Protocol on the Win95 machine and you're
connecting to WFWG servers, turn on "I want to enable NetBIOS over
IPX", because the WFWG servers normally use NetBIOS over IPX.
Otherwise change the WFWG station's protocol to "IPX/SPX Transport",
instead of "IPX/SPX Transport with NetBIOS". Microsoft refers to this
as Direct Hosting over IPX, rather than through NetBIOS, which
explains the speed boost you'd get.
* 7.2.3. ...Windows NT servers and Windows NT domains?
Microsoft released Windows NT 3.51 purely to support Windows 95
clients. If you have Windows NT servers or workstations and Win95
workstations, upgrade to NT 3.51. Save yourself the hassles.
If you aren't using NT domains, you can connect to the NT workstations
and servers as you could any MS Windows Network client; install
Client/FPS for MS networks.
Client for MS Networks can also perform NT domain logins, similar to
how the NetWare client performs NetWare logins. You just specify that
you want to log in to a domain in the Client for MS properties. You
needn't specify the name of the domain controller; just the name of
the domain. Unlike the domain client in Windows for Workgroups,
however, you log in to the domain first, then into Windows.
Upon re-boot, Win95 gives you an MS Client login prompt. Feed it your
user name and password, and your NT login script will execute.
* 7.2.3.1. How do I get Win95 to honor NT %username% ? (and other NT
user variables)
Win95 isn't Windows NT, so it can't receive NT user profiles which
include the environment variables. However, there's a cool LanManager
utility that works on NT servers: PUTINENV. PUTINENV copies all
the LanManager user variables (including %USERNAME%) to a DOS client.
But it only copies them to the local DOS session's environment; you
will need to copy the variable to the global Windows environment with
WINSET, a utility that comes with the Win95 CD-ROM.
So, to copy the user variables over during a login, copy PUTINENV.EXE
and WINSET.EXE to the domain controller's NETLOGON share, then add
these lines to the login script:
\\server-name\NETLOGON\PUTINENV L
\\server-name\NETLOGON\WINSET USERNAME=%USERNAME%
(Repeat the WINSET line for any other user variables in the user's NT
profile.)
You could also map a drive and run the programs from that mapped
drive, or even from the client's local hard drive. Since Win95
supports commands using network paths, however, it's far easier to
just copy them to the server.
For interest's sake, PUTINENV also works with Windows for Workgroups
clients. Of course WINSET won't work, being a Win32 program, but you
could use the same script for WFWG and Win95 clients without harm. NT
clients will GPF on running WINSET too. Read the note on Rich
Graves' Site.
Windows Magazine also has many tips on writing NT login scripts,
and have a sample master login script for your viewing pleasure. It
includes a Win 3.1 equivalent of WINSET called SETW.EXE too.
* 7.2.3.2. Bugs to watch out for, and patches
Since Microsoft meshed Win95 and NT so closely together there are
hardly "any" bugs, but Rich Graves does mention a few at his
Win95NetBugs site.
Hah, I lied! I know two bugs, and they relate to Remote
Administration...
Admin share (\\machine\c$) remains active after you terminate the
Remote Admin session (I noticed this since Service Pack 1)
Domain Admins can edit parts of an NT server's Registry!
To prevent these bugs from creeping up, make sure you protect that
Domain Admins group with your lives.
There's the Password Caching bug of course, but you can disable
password caching.
* 7.2.3.3. How do I disable password caching?
The best way is to set up a system policy which does so. You can
disable caching of the login password, or caching altogether.
* 7.2.3.4. How do I log in to multiple domains?
Although you can't LOGIN to multiple domains, LOGIN and ATTACH are two
very different actions. You will need to establish a Trust
relationship between the two domains, a topic best covered in
Microsoft's NT Resource Kit. Once set up though, you can map drives to
shares on the other domains through the login script, or browse
through Network Neighborhood, as though they were part of your domain.
* 7.2.3.5. Top ten NT network mistakes
10. Using a LanManager server as a domain controller (hah hah hah)
9. Using an NT version earlier than 3.51 for Win95 clients
8. Not using system policies (Always a good idea to use system
policies for basic stuff)
(oops... not enough mistakes to fill the list! You got any?)
* 7.2.4. ...Banyan Vines (TM) servers? (Who uses this anyway?)
Banyan has a 32-bit client for Win95. By what I read on their
installation instructions, it's a proper Win95 client for a VINES
server. I don't have access to a VINES server, so if you have any
insight on this, please tell me.
sda...@emporium.on.ca seemed to have very good success with the
Banyan Win95 client, but he hasn't told me about user profiles, system
policies, or any of the other cool toys. I can still use details on
these.
* 7.2.5. ...LANtastic (TM) servers? (Yes Virginia there IS a 32-bit
LANtastic!)
Artisoft has LANtastic 7.0 that pretty much works like Client for
MS networks! You can map and browse server drives, share drives with
the LANtastic service, capture and share printers, and have your
connections saved per user, via User Profiles. Because they use
the OS nicely, you could use the Client for NetWare, for example, and
LANtastic client at the same time, if for some unusual reason you
didn't want to use Client for MS for peer sharing. Now this is playing
nicely!
NOTE: Artisoft stopped offering their Client for LANtastic on their
web site. Visit Artisoft's site or your favorite vendor for LANtastic
for Windows 95.
* 7.2.6. ...AppleTalk (TM) AFP servers?
Miramar Systems has a Win 3.1 client and server for AFP, which
they managed to hack into Win95. Miramar told me via E-MAIL that they
will release a Win95 client and server in June 1996. With any luck it
can co-exist with other Win95 components.
COPStalk has a Designed for Win95 AFP client and server, but I haven't
checked it out yet. You can obtain a trial copy from
http://www.copstalk.com/ and see for yourself.
* 7.2.7. ...IBM OS/2 LAN Servers?
At first I thought MS would've abandoned OS/2 completely, but
according to KB article Q149206, Client for MS networks will work
with LAN Server domains. Specifically, they wrote that Client for MS
works with OS/2 LAN server versions 1.2, 1.3 (and CSD), 2.0, 3.0, and
4.0.
As such, you can treat the LAN Server domain like a Lan Manager or
Windows NT domain. Set up the Win95 client appropriately.
MS noted that file and print sharing are the only services that Client
for MS supports. Apparently, IBM's LAN Server management software
won't run on a Win95 station. Keep a Win 3.1 or DOS station handy for
this.
* 7.2.8. ...other network servers? (DOS client advice)
Microsoft TRIED to allow weird DOS clients, with Win 3.1 support, to
work in Win95 like they did in Win 3.1. Win 3.1 support for networks
shows up as a stand alone Client in Network Control Panel. For
example, if you install Novell NETX support, you don't need to add any
protocols or net card drivers. The big limitation is you can only
install ONE Win 3.1 network client.
The best advice I can give is to only use the network support the
vendor gives you. Don't try to use DOS clients alongside Client for MS
Networks, for example.
If you have to make more conventional memory available, you can use
real mode HIMEM.SYS and EMM386.EXE, and prepare a normal DOS
configuration that will start up before Win95 does. At this point it
would perform much like Win 3.1 did, but it should work.
* 7.2.9. ...The Internet?
Since Win95 comes with nearly all the components you need to connect
to The Internet, the easiest way is to grab Microsoft's Internet
Explorer and run it. The first time you run it, the Internet Setup
Wizard comes up and asks you a bunch of questions only your service
provider can answer. Get an answer sheet from your provider for these
settings:
* Dial-in phone number
* Login Name (Not E-MAIL name); may include descriptors like %PPP or
whatever
* Login Password (Whatever you chose when you signed up)
* IP address and Subnet mask if manually given, or use "My ISP
provides me one"
* DNS server addresses (in the form of XXX.XXX.XXX.XXX)
* Full E-MAIL address
* Mail server address (usually something like mail.nowhere.com)
* Mail server username (Usually the same as your login name)
* Mail server password (Usually the same as your login password)
* Items to have handy: News server address, outbound mail server
address, Gateway address (if not using default gateway)
These are the items the Internet Wizard will ask you for. The Wizard
will prepare IEXPLORE.EXE, the main Web browser, and Microsoft
Exchange for sending and receiving electronic mail. It will also
prepare a dial-up networking connection with all the right switches
turned on, or off, and install all the needed components from your
Win95 disks or CD-ROM. The only fine-tuning you'll need to do is to
add the news server address to Internet Explorer (or whatever news
reader you want to use), and maybe add an Outbound Mail Server name to
Exchange's Internet Mail properties, if the provider has a
different server to process outbound mail.
About 99% of us will connect to The Net using a modem and a dial-up
line, but for the rare few of us that have a direct network
connection, the Wizard will work with that too.
Oh yes, it will make you use Internet Explorer. No matter; just use it
to get your favorite Web browser, such as NCSA Mosaic for Win95, or
(ACK!) Netscape, and install that afterwards.
You can always re-run the setup wizard if the provider's settings
change, or if you change providers. You'll find it in your Accessories
group on the Start Menu. I cover the rest of the Internet stuff in
a separate page.
------------------------------
Subject: 7.3. How do I share my hard drive or printer to...
* 7.3.1. ...other Win95 users?
Install File & Print Sharing for MS networks in your network setup. If
you set up the computer like I told you back in the How do I
connect to other Win95 computers? section, this'll already be done.
Next, right-click on any drive or folder you want to share, and select
the "Sharing" menu. You can specify a read-only or full access share
like you could in Windows for Workgroups, or make it dependent on
password.
* 7.3.1.1. ...on The Internet?
This is pretty tricky because you need to run NetBIOS over TCP/IP. You
can't just type "\\206.116.13.2" and expect a list of shared resources
to appear. Running NetBIOS over TCP/IP usually requires a WINS server,
but you can also do NetBIOS naming through DNS, or by manually writing
an LMHOSTS file, neither of which I recommend.
One problem I noticed is, if you specify a name in HOSTS or LMHOSTS,
the machine you're referring to had to have the same name in its
Identification tab, on its Network Properties. This tidbit I got from
Rich Graves' site.
Your easiest bet is to obtain a free FTP server for Win95, available
at www.windows95.com. Then the other user can just use their FTP
client or browse using their web browser, using "ftp://206.116.13.2"
as the URL. To find out what your IP address is (if you have IP
addresses assigned to you on the fly), run WINIPCFG.EXE from the Win95
directory and bring up properties of the "PPP Adapter", while you're
connected.
NOTE: I've been asked to include Winserve's public WINS servers in
this category. Problem is, I don't like the notion of running MS
networking across the Internet because of the inherent security risks.
At least someone running an FTP server knows they're sharing over the
Internet, whereas someone who happens to have the full suite of MS
networking might not.
* 7.3.2. ...other Windows for Workgroups users?
Just like you would for Win95 users. Be careful if you use User
Level security, because WFWG clients won't recognize weird security
providers, like NetWare servers. Either share out to "The World", or
specify a Windows NT domain as your security provider, and have the
WFWG client log into it. Or, simply use Share Level security a'la
WFWG.
NOTE: If you chose IPX as your base protocol between Win95 and WFWG
computers, you should decide if you want to use NetBIOS or not,
because WFWG has one default (NetBIOS ON) and Win95 has another
default (NetBIOS OFF). Neither WFWG nor Win95 need NetBIOS over IPX
unless you're specifically running NetBIOS apps, so on the Win95
machine have "I want to enable NetBIOS" turned off in IPX properties,
and change the protocol on the WFWG machines to "IPX/SPX Transport"
instead of "IPX/SPX Transport with NetBIOS". Microsoft calls this
"Direct Hosting over IPX" which will give you a speed boost. Windows
NT and Workgroup Connection for DOS also support Direct Hosting over
IPX.
* 7.3.3. ...Macintosh (TM) users?
Miramar Systems will include an AFP and ASDP print service with
their MacLAN product, which they plan to release in June 1996. (So
where is it, now that it's February 1997?) In the meantime, they
managed to hack in their Win 3.1 Personal MacLAN into Win95.
COPSTALK is another AFP service, with the difference that it's a
"true" Win95 service.
Thursby Systems released a Client for MS Networks for the
Macintosh, which works like any other MS client over MacTCP or Open
Transport TCP/IP. This avoids needing special software on the Win95
machine and simplifies administering a network of PCs and Macs where
NT Servers reign.
* 7.3.4. ...other computers' users? (SAMBA network clients)
MS Windows Network has a short name: SMB, or "Server Message Blocks".
SAMBA is a GNU public-license SMB client for UNIX machines, with
versions available for The Amiga and several other smaller systems.
Visit one of many SAMBA FAQs, or visit the newsgroup
comp.protocols.smb, or if you want to connect to Amigas, visit
AMINET.
Download the latest SAMBA for Amiga from any Aminet mirror and use
SMBCLIENT on the Amiga to connect to Win95 machines.
Linux users can mount Win95 shares as remote file systems; it comes
with a complete SMB client (SMBFILE).
SAMBA clients exploit a nasty file sharing bug in Win95 and WFWG; if
the Win95 server shared out a directory, it will inadvertently share
the entire hard drive with the same restrictions! Ack! Microsoft fixed
this in Service Pack 1.
------------------------------
Subject: 7.4. How do I run DOS TCP/IP or packet-driver apps in DOS sessions?
Originally I thought MS's TCP/IP would allow for DOS apps to use
32-bit TCP/IP in the same way IPX apps would (such as NetDOOM or
Descent), but some TCP/IP apps provide their own complete TCP/IP
stack, and use the pure packet interface (characterized by Packet
Drivers that leave transport protocols to the apps themselves).
There's an NDIS 3.0 packet driver you can install as a Win95
"protocol" at http://ndtl.harvard.edu/ndis3pkt/ or at
ftp://nic.switch.ch/mirror/novell/drivers/ndis3pkt.zip which
provides the packet driver interface for any network card. The driver
is re-entrant so multiple DOS sessions can access it. The big catch
is, if you use MS's TCP/IP Protocol at the same time, AND you have DOS
packet apps that provide their own TCP/IP stack, you cannot have MSTCP
and the packet app use the same IP address. You are effectively
running two TCP/IP stacks (one for Winsock apps and the one provided
by the packet app) and these can't have the same IP address.
However, multiple DOS sessions running TCP/IP packet apps can use the
same IP address. This packet driver can interpret TCP/IP packets from
DOS packet apps and multiplex them. This is a special case which a
packet driver would not normally handle.
So with this aside, to install the virtual packet driver for Win95:
1. Download the ndis3pkt "protocol" from the above address
2. Install a net card driver for Win95
3. Install the packet driver as a Protocol
4. Check the Bindings tab for each net card you have, and make sure
you enable the Virtual Packet Driver only for the cards you want
to use it for (turn it OFF for the Dial-up Adapter).
5. Re-start the computer. Use your packet apps as normally in DOS
sessions.
------------------------------
Subject: 7.5. How do I print to HP JetDirect (TM) printers on the network?
Win95 includes a JetDirect service, which allows you to control and
attach to printers with JetDirect cards installed. HP JetAdmin depends
on IPX protocol, so install that as well.
Once you install the JetAdmin service, you can print to the JetDirect
printers like you could to any network print queue, but you cannot map
a DOS LPT port to one. Read below, to learn how to create new DOS
ports instead.
* 7.5.1. JetDirect Port Aliasing, or How do I print from DOS
programs to JetDirect Printers?
NOTE: HP has updated JetAdmin software that may take care of the need
to use this dumb Alias Port Monitor. I urge you to get the latest
JetAdmin update from HP's software support site at
http://www.hp.com/cposupport/indexes1/win95s.html to get DOS
session printing capability in "direct" mode. NOTE: This isn't needed
if you use HP JetDirect printers via a NetWare or other print server.
The alias monitor itself does have other uses, and you can get it from
ftp://ftp1.hp.com/pub/networking/software/alias1en.exe. One such
example is 32-bit redirection to a disk file, or to another device.
Originally I thought that MS's DLC protocol would allow for JetDirect
access, as it did in Windows NT. Nope. I had the chance to attempt it
myself and had to struggle with HP's Aliasing Port Monitor to
make it work.
Once you set up your JetDirect printer objects, install this dummy
printer driver. This will install the capability to add "Alias
Monitor" ports from printer properties. If you actually try to install
the dummy printer to the end though, it will fail. The port capability
will install correctly, however.
Then, install a new Windows printer, identical to your existing
JetDirect printer, except after you finish, change its port. From the
new printer's properties, in its Details tab, select "Add Port". Among
the Local Port choices, select "Alias Monitor". Type in a valid DOS
port name (such as LPT3:), a descriptor for it, and the name of the
existing Win95 printer object (like "HP DeskJet 1200C (MS)", exactly
as it appears in the Printers window). Once this is done, whenever you
print to this port, it will print to the Windows printer it points to.
You can change this port's target or other properties from "Port
Settings".
One advantage of this, is you can make your computer the print spooler
for it, and use a shorter share name (the share name
\\HP_Network_Printers won't work with Win 3.1 apps or Win 3.1 printer
drivers). Another advantage is you don't have to install JetAdmin on
each and every computer, if you do re-share it.
NOTE: This is only the beginning of HP's apathy towards Win95. Notice
how they supply ONE driver set for Win 3.1 and for Win95? Notice how
"You must use the SETUP program!" when you try to add the driver with
Add Printer? Just what the hell is HP trying to do here? Of course,
HP's newest DeskJet 1600 drivers don't work with JetDirect printers
this way because they're written for Win 3.1 and don't recognize this
long \\HP_Network_Printers share name. I suggest getting a
Lexmark PS4079 if you want good colour printing AND Win95
performance.
------------------------------
Subject: 7.6. How do I use these cool networking features...
* 7.6.1. ...system policies?
System Policies let you enforce a bunch of settings for Win95
computers on a network. This is real handy to disable long filename
support for NetWare, or disable password caching, for example, without
going to each and every computer on the network and editing SYSTEM.INI
or the Registry.
Copy the contents of ADMIN\APPTOOLS\POLEDIT from the CD-ROM, to a
convenient directory that only you (the Administrator) have access to.
The first time you run POLEDIT, it will ask you for a policy template.
Choose ADMIN.ADM. There are other policy templates for other networks
(including NDS), but ADMIN covers most of the stuff for now.
Have a nice look at all the settings you can enforce on, enforce off,
or not enforce. Notice you have three choices; an "On", "Off", and
"Don't Care"; the "Don't Care" state means that the computer will use
the setting it already has. "Default User" refers to people, and you
can add unique policies for unique users if you have a central
security provider (like an NT domain controller or NetWare server) by
adding users to this policy file. "Default Computer" refers to
computers, and you can add computers here as well, named by the
"Identification" tab back in Network Control Panel.
Definitely set these policies up at a bare minimum:
* Network path for Windows 95 files
* Remote Update: Automatic (Use Default Path). Remote Update refers
to updating local settings from the policy file, and Default Path
refers to the location of the policy file itself. The default path
depends on the kind of network client installed (Microsoft
Networks, NetWare, LANtastic, whatever) and this "Automatic"
option only works if you have a Win95 client for a central server
of some kind. You can do non-central policies too, but I'll cover
that later.
Save this policy file with the name CONFIG.POL and copy it to the path
your client expects to find it.
POLEDIT also works directly on a local Registry, which is really
convenient if you don't trust yourself with REGEDIT.
* 7.6.1.1. ...on a Windows NT network?
Create the CONFIG.POL and copy it to the NETLOGON share of your
primary domain controller. You can spread the policy file to all your
backup domain controllers as well, in which case, the "Load Balancing"
option can save some server overhead on slow WAN links.
Useful policies for NT networks:
* Log on to Windows NT (Specify domain name here too)
* Workgroup (Use same name as the domain to ease browsing troubles)
* Disable Password Caching
* Enable Load Balancing (If you use multiple domain controllers per
domain)
* 7.6.1.2. ...on another network with a 32-bit client?
Other Win95 clients will have their own policy templates and their own
unique location for the policy file. Check with the vendor for the
details. If there's no default path, you can enforce the "Manual
Update" policy and specify a UNC path to the policy file (like
\\SRV\POLICIES\CONFIG.POL), but you will need to run POLEDIT on each
station to set this in each Registry.
* 7.6.1.3. ...on another network with a DOS client?
You will have to set the "Manual Update" policy and set a DOS
Drive:\DIR\CONFIG.POL path on each station in each Registry. You will
also need to map this network drive before then end of AUTOEXEC.BAT as
well.
* 7.6.1.4. ...on a peer to peer Win95 network?
If you keep one Win95 station on all the time (Usually the machine
with the printer attached) you can put a policy file there. You will
still have to manually change the Remote Update path in each station,
but this time it can be a UNC path.
* 7.6.2. ...User Profiles?
User Profiles are a really, really, cool feature of Win95. Not only
can you set a personalized desktop for each user and have personal
Start Menus, but you can have personalized settings for MS Exchange,
Word for 95, or pretty much any program that stores user preferences
in HKEY_CURRENT_USER in the Registry! Profiles will also follow a user
around in a centralized network, copying their program settings to
each station as required.
To turn on User Profiles, run the Passwords control panel. Regardless
of whether you installed Networking or not, you turn on "Users may
select their own preferences" on the User Profiles tab.
Custom Desktops and Start Menus are actually one of these user
preferences. You can enable or enforce User Profiles, but it's up to
the users if they want their shortcuts to be unique to them.
Regardless of user profile preferences, Win95 creates a Profiles
folder, and a sub-folder for each user to store a personal copy of
USER.DAT, the user portion of The Registry. If the user chooses to
have custom Desktops and Start Menus, it stores them in that folder as
well. Deleting shortcuts from Win95's default Dekstop and Start Menu
folders will not affect a user's personal Desktop or Start Menu.
Profiles work best when you have all Win32 apps, and if you keep
copies of the apps in the local hard drives, that you install the apps
in the same place on each computer! The "C:\Program Files" Directory
is a good place for apps in a User Profile environment. Keep the
Windows directory the same name on all your workstations too.
SOFTWARE DEVELOPERS: Be VERY VERY CAREFUL where you store your program
settings! Hardware settings (like local cache directories or modem
preferences) belong in HKEY_LOCAL_MACHINE, mobile and user settings
(like bookmarks or spell check preferences) belong in
HKEY_CURRENT_USER. Test your software in a User Profile environment!
Netscape Communications gets kudos from me in this regard; Navigator 2
and 3 support user profiles.
* 7.6.2.1. ...on a stand-alone workstation?
The Password Control Panel is always there, whether you have a network
client loaded or not. In here, select the User Profiles tab, and
select "Users can customize their settings". Specific users can choose
to keep a custom Desktop and Start Menu included in their profile.
When you aren't on a network and you have User Profiles turned on, you
need to have a password for each user, otherwise it will happily
automatically use the last password-less user's profile. Selecting
"Shut Down" and "Close all programs and log on as different user" will
let you enter your own name and password.
* 7.6.2.2. ...on a Windows NT network so it'll follow the user
around?
NT clients keep their profiles in their HOME directory, so make sure
you define a home directory for each user, in User Manager. NT servers
3.5 or later have long filename support built in, even for FAT file
systems, so you have no worries regarding roving desktops and Start
Menus... just the space requirements.
Also, enforce "Enable User Profiles" through system policies, to
keep multiple profiles straightened out.
* 7.6.2.3. ...on another network?
Roving User Profiles require a central storage space, and are specific
to what network client you run. So the location of user profiles on
that network depend on that client. This won't work with Client for MS
networks without a Windows NT domain to log in to (So it doesn't work
on just a bunch of Win95 machines together), but you can define a
custom Desktop or Start Menu for each user, with POLEDIT.
In Default User (Or whoever user) Shell settings, you can define a
path for custom folders. The custom folders include Desktop, Start
Menu, Programs, NetHood, and "Hide Start Menu Subfolders". So for each
user (By selecting Edit/Add User) you can insert a custom path for
these items. If you do this in one master CONFIG.POL file stored in
one location, and you have "Remote Update: Manual Path" turned on, you
can enforce a different Desktop and Start Menu for each user without a
central server. Just make sure the path exists when Win95 starts
(Either by using a UNC path, or by logging in before running Win95, in
the case of real mode clients).
If you also enforce user profiles through the central policy file as
well, Win95 will store USER.DAT for each user on the machine, but it
will not follow the user around. If you want the benefit of full
roving user profiles, get a central server with Win95 client support,
and check with the network OS vendor about user profile support, if it
isn't an NT or NetWare server.
Oliver Knorr says it is possible to use roving user profiles on a
simple peer network. He explained some mistakes in the Win95 resource
kit that MS documented in KB article Q135849. You first need to
add Registry entries to each peer machine you want roving profiles to
work on as described in the article. Then create a PROFILES.INI file
on your central peer server (isn't "central peer server" a
contradiction of terms?) and edit one Registry key on all the stations
to point to that profiles.ini file.
* 7.6.2.4. Why user profiles is a really cool and useful feature!
One time I read a question on how to make Netscape 2.0 work with more
than one user's E-MAIL settings, so it would work with more than one
provider. The answer was simply: Turn on User Profiles in the
Passwords Control Panel. With that, Netscape had different settings
for each user, and what was better, each user had their own dial-up
networking preferences stored under their own profile!
User Profiles is cool because it offers a central control for
personalized settings, regardless of whose program you run! The
software developer doesn't have to account for multiple users for a
given program; they need only store personal settings in the USER.DAT
portion of The Registry, and let the OS take care of the rest. I know
this works with these programs:
* MS Office 95 suite
* Corel Graphics suite 6.0
* MS Exchange
* Netscape 1.2N up to 3.04 (You will need to fix the cache path for
each user though, or accept its default)
* NCSA Mosaic
Other programs Designed for Windows 95 had better work with this.
* 7.6.3. ...remote administration?
The Passwords Control Panel has a "Remote Administration" tab that
works only if you have networking installed. If you use a central
server, you can assign administrative privilege to a SUPERVISOR or
Domain Admin.
First, install File & Print Sharing for either MS networks (for a pure
Win95 or NT domain network) or NetWare (For NetWare networks). If you
use FPS for NetWare, keep SAP advertising OFF. In addition, install
the Remote Registry service from Network Control Panel, as a Service
(in ADMIN\NETTOOLS\REMOTREG on the CD-ROM) on the remote machines. You
can do this (and even enforce this) when you install Win95 as well.
Now, if the workstations use User level security (highly
advisable on NT Domains and NetWare networks), Setup will
automatically enable remote administration for ADMIN and SUPERVISOR
(NetWare) or DOMAIN ADMINS (NT Domain). If the stations use passwords
instead of user lists (Share level security), or you don't have a
central server, you will need to manually enable Remote Administration
and supply a password to each station. Remote Administration settings
will differ with each type of network client installed.
Once done, you (the administrator) can control computers via Network
Neighborhood. Right-click on any Win95 station and select
"Properties". You will see a "Tools" tab that lets you edit the
Registry, view network activity, or even browse the hard drives, on
the remote computer. REGEDIT and POLEDIT also works on these stations.
Of the tools listed, Remote Registry service is the biggest service
(250 KB). To free up memory so you don't slow down the machines, check
out How to Prevent Random Hard Drive Access, which also frees
lots of memory for these services.
* 7.6.3.1. ...on a Windows NT network?
Install FPS for MS networks, install Remote Registry service, and
enable User level security. Remote Admin privileges are
automatically given to anyone in the Domain Admins group on the domain
controller. Re-boot. Then, go to another Win95 station, log in as
Administrator (or anyone else in Domain Admins) and get properties on
the remote station from Network Neighborhood.
WARNING: This service will allow you to remotely edit an NT Server's
Registry! I was able to get in to several (but not all) Registry keys
on my own NT server by logging in as a member of Domain Admins. I'd
hate to think what could happen to my poor server if someone ran
REGEDIT on this network with malicious intent!
WARNING: Remember the NetWare C$ bug? It's back, this time in FPS for
Microsoft networks! Now if you perform a Remote Admin session on a
Win95 station and view its hard drives, the Admin shares
(\\machine\c$) remain active, available for read-only viewing when a
user types \\machine\c$ from Start Menu/Run. This bug may have always
been around, but I suspect it emerged with Service Pack 1.
* 7.6.3.2. ...on a Peer Win95 network?
You don't need to install Remote Registry service on the workstations
to use peer to peer remote administration. You only need a file and
print sharing service. When you use the Admin tools, the target
computer will prompt you for a password.
Be sure to set this password on all the workstations you want to
administer remotely.
NOTE: According to the Remote Registry readme files, Remote Registry
service only works if you use User Level Security from a central
server.
* 7.6.4. ...user level access?
User Level access spares us the potential of lost passwords and
multiple, security-killing, cached passwords, because the passwords
remain on the central security provider. You need only log in once and
type your password once, and you have access to any resources shared
on the network that have you on their access list.
Enable User Level security from Network Control Panel, in Access
Control. Pick a security provider (the name of an NT domain, NetWare
server, or other central server if your client/service software allows
for it). The next time you re-boot, all your share requesters and
password requesters will have user list requesters in their place. You
could also enforce user level security via system policies.
If the server is a NetWare 4.x server, you will need to set a Bindery
context on it. This will allow all NDS clients access to any Win95
stations sharing resources via FPS for NetWare.
Unusual combinations to avoid:
* FPS for MS networks, using a NetWare server as security provider
(WFWG stations can't get access then! Win95 machines could get
access, however)
* FPS for NetWare, using an NT server as a security provider (Quite
impossible, as the NCP server doesn't recognize NT security)
* FPS for NetWare, using Share level security (It won't let you; NCP
servers don't allow separate logins)
* 7.6.5. ...server-based setup and MSBATCH.INF?
I'm going to probably create a new FAQ page dedicated to this in the
new year. But in the meantime, here's some basic stuff to get your
server based setup running.
First, why do a server based installation of Win95 in the first place?
* Automated installation of several workstations
* Can apply software updates or widgets for everyone
* Can apply special changes to the systems, hacks or otherwise, in
all new machines quickly
* Save disk space on workstations by running pieces of Win95 off the
server
Oops... that last one isn't such a good idea, because it requires
real-mode (DOS) networking to start first, eating up conventional
memory. I'd say, make a normal installation of Win95, then use shared
copies of your apps to save disk space instead.
I cover basics in page 2, but in addition to this, get the Win95
SP1 Diskette Set and use the updated INFINST, INFGEN, and BATCH
tools instead of the ones that come with the CD-ROM.
------------------------------
Subject: 7.7. Win95 has (this security bug). How do I fix...
* 7.7.1. ...the "cancel" button on the login window?
You can demand log in for Win95 access, through system policies,
if you use a central security provider with a Win95 client. This way,
a failed log in or a canceled log in will give "Unable to log you in"
errors. Be warned: CTRL-ESC at a login prompt will bring up the task
manager, so you will also want to remove TASKMAN.EXE from that
computer. Windows NT does not exhibit this bug, so if you're really
paranoid about this bug you should consider using NT instead.
Win95 is not as secure as Windows NT, but some other security measures
will prove useful enough to keep the bad guys out. These include:
* Remove the floppy drive from the computer once you install Win95
* Disable REGEDIT.EXE via system policies, and rely on
Remote Administration
* Remove TASKMAN.EXE from the system; the task bar replaces it
anyway
* If you insist on keeping the floppy drive in the computer, force
it (through BIOS setup) to always boot from Drive C.
Password-protect your BIOS setup too.
* Edit MSDOS.SYS to prevent Safe Mode booting, force the system to
always boot into Win95 on power-up, and to set the boot delay to
zero.
* Hide components of the Control Panel, such as Network, via
system policies. You can hide quite a few Desktop components
via system policies too. Check them out.
* 7.7.2. ...the Samba bug I heard about?
Install Service Pack 1. Or just disable the binding to File &
Print Sharing for MS Networks to TCP/IP. Bring up TCP/IP properties
for each net card, hit "Bindings", and turn off the binding to FPS for
MS networks.
Microsoft claims this bug happens when Samba clients issue "Illegal
network commands" to the computer acting as a server. Fact is, this
bug was in WFWG originally, and I suspect it's even in NT Server!
Rich Graves has all the gory details. Microsoft seems to have
many troubles with Samba clients and servers; there was even a Client
for MS networks update in Service Pack 1 that fixed troubles with
Win95 accessing a Samba server.
* 7.7.3. ...the password caching bug?
Install Service Pack 1 or disable password caching via
system policies.
* 7.7.3.1. How do I disable password caching?
Password caching only happens if you have a Win95 network client
installed, OR you have User Profiles enabled on a stand alone
computer.
The clients for NetWare and NT have separate caching restrictions
(such as "Prevent caching of log on password") you can use, or you can
disable password caching entirely, in the Network section of POLEDIT.
* 7.7.3.2. How do I enable user level access to eliminate the need
to cache passwords?
Read all about it in User level security. You will need a central
security provider (like an NT domain or NetWare server) for this
though.
------------------------------
Subject: 7.8. Visiting Rich Graves' Win95NetBugs site for details
He's at
http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html and
while he's very anti-Microsoft, he does present the facts.
--
==============================================================================
= 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/ =
==============================================================================