| |||||||||||||||||||||
FAQ 77. Networking in General
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. This includes avoiding Novell's Client32, because they're forcing a 32-bit ODI, and .NLMs, and crap that belong in a NetWare server. Be Warned: I'm quite anti-Client32, and I tend to preach using MS's clients for the sake of simplicity and speed. If you have a problem with this, leave this page now. 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:
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. 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. 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. 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 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. NOTE: I couldn't find this file again for the longest time, but today (28 FEB) I found it again. The link above is a local copy of putenv.zip copied from wuarchive.wustl.edu's NT archive. You should also get SETW.EXE if you have WFWG machines and want to take advantage of NT environment variables in both Win 3.1 and Win95. 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. The best way is to set up a system policy which does so. You can disable caching of the login password, or caching altogether. 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. 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?) 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. sdawson@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. 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. 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. 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. 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 cards. 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. 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:
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. 7.3. How do I share my hard drive or printer to... 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. 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. 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. 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. Thursby Systems recently 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. 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. 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 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:
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. NOTE: HP has updated JetAdmin software that may take care of the need to use this dumb Alias Port Monitor. Since the link below has kinda disappeared (ARRRGH.... HP Lamers....) I urge you to get the latest Web JetAdmin update from HP's software support site at Web Jetadmin 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. 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 JetDirect 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 'coz 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. 7.6. How do I use these cool networking features... 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:
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. 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:
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. 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. 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. 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, 3, and Communicator all support user profiles. 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. 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. 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. 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:
Other programs Designed for Windows 95 had better work with this. 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 program (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. 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: Apparently, 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. 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. 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:
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?
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 Admin edition and use the updated INFINST, INFGEN, and BATCH tools instead of the ones that come with the CD-ROM. 7.7. Win95 has (this security bug). How do I fix... 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:
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. Install Service Pack 1 or disable password caching via system policies. 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. 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. 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. |
|
|