[Vorherige] [Nächste] [Index]

[*] Windows 95 Networking FAQ, 6/7



Archive-name: ms-windows/win95netbugs/part6
Posting-Frequency: twice monthly
FAQ-Maintainer: Rich Graves <win95netbugs-owner@lists.stanford.edu>
Last-Change: 18 Jan 1996 by Rich Graves <win95netbugs-owner@lists.stanford.edu>
Version: 4.00.963
URL: http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html

--------------------------
Content-Description: Welcome and Index

  This FAQ concerns problems you might encounter with Win95's networking
  features after you have set everything up according to the directions, such
  as they are. This is section F, Windows.

F. Windows Networks (NT, WFW) Issues

  1. If your Windows NT client is unable to connect to a Windows 95 server.
  2. Incomplete Domain Listing on Large Networks.
  3. No Support for "Connect As" Option Like in Windows NT.
  4. How do I get Win95 to honor NT %USERNAME%?
  5. WFW machines can't log on to Win95 machines with access list from
     another domain.
  6. Troubleshooting Browsing with Client for Microsoft Networks.
  7. Can I log on to multiple NT domains?
  8. Error Message: "VNETSUP: Error 6102" (WORKGROUP corruption)
  9. Changing NT permissions w/Win95 mgmt tool doesn't work? 

--------------------------
Content-Description: F.1. If your Windows NT client is unable to connect to a Windows 95 server.
Date: Wed, 27 Dec 1995 18:10:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>

  From article Q131675 in the Microsoft Knowledge Base:

  The password encryption method used by Windows NT is different from the
  method used by Windows 95.

  You may be able to work around this problem by using one of the following
  methods:

     * Use all uppercase or all lowercase characters in the Windows 95 shared
       folder password.
     * Remove password protection from the shared folder.
     * Use user-level access control instead of share-level access control.

  Microsoft is researching this problem and will post new information here in
  the Microsoft Knowledge Base as it becomes available.

  [I suspect that the supposed .PWL bug fix, which basically replaced the
  old, buggy Windows for Workgroups password scheme with the newer, probably
  less buggy NT password scheme, might resolve this, and might introduce
  problems with Windows for Workgroups clients. Could somebody try this out
  and tell me?]

--------------------------
Content-Description: F.2. Incomplete Domain Listing on Large Networks.
Date: Tue, 10 Oct 1995 00:00:00 -0700
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>

  From article Q135279 in the Microsoft Knowledge Base:

  When you are browsing the network, Windows 95 stores the domain names in a
  table that is limited to 64K in size. When this table is full, no more
  domains are displayed.

  In addition, many WINS servers have a known problem that causes them to
  report that domains exist, even after these domains have been removed from
  the network. On large networks, or on networks where domains are frequently
  removed shortly after they are created, this problem may prevent domains
  that currently exist on the network from being displayed in Network
  Neighborhood.

  Microsoft has confirmed this to be a problem in Microsoft Windows 95. We
  are researching this problem and will post new information here in the
  Microsoft Knowledge Base as it becomes available.

--------------------------
Content-Description: F.3. No Support for "Connect As" Option Like in Windows NT.
Date: Tue, 10 Oct 1995 00:00:00 -0700
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>

  From article Q126573 in the Microsoft Knowledge Base:

  Microsoft Windows NT has an option that lets you connect to a network
  resource as someone else. This option uses a Connect As box in the Connect
  Network Drive dialog box.

  Microsoft Windows 95 does not have such an option in its Map Network Drive
  dialog box. The only way to connect to a network resource as someone else
  in Windows 95 is to log off and then log back on as a different user.

--------------------------
Content-Description: F.4. How do I get Win95 to honor NT %USERNAME%?
Date: Sun, 01 Oct 1995 13:03:42 GMT
From: johnr@ids.net (John Robinson)
Newsgroups: comp.os.ms-windows.win95.misc

  >Date: Sun, 10 Sep 95 11:00:40 PDT
  >From: Scott McArthur <scottmca@microsoft.com>
  >To: win95netbugs-owner@lists.stanford.edu
  >Subject>: RE: Win 95 and NT server
  >
  > Tony Chandler <T.Chandler@blds.canterbury.ac.nz> wrote:
  >>I have a NT 3.51 server.  I have set up users with a home directory
  >>in there user profile.  I have also got a logon script that sets up
  >>drives using %USERNAME%.
  >>Windows 95 clients logging into the NT server cannot see their home
  >>directory or the drives setup with the %username%, username is
  >>undefined. Has any body got this going?
  >
  >This is a Resource Kit documentation error.  Windows 95 does not support
  >these variables.  Only supported by NT workstations.  NT sets these
  >variables on boot whereas Win95 does not.  At a NT box do a set at a
  >command prompt and you will see all these variables.  You can set a home
  >directory in user manager by setting "connect to" to a \\server\share
  >designation and on the 95 client doing a
  >
  >net use h: /home
  >
  >the h drive will then be mapped.  It will not be the default directory
  >apps will save to though.

  I am using %username% but it took a lot of digging. You need two
  programs-PUTINENV and WINSET (on the win95 CD). I am using NT server
  with a logon script. The game is to get the environment variables of
  the user who just logged on using PUTINENV L and then to put this
  info into the Win95 master environment with WINSET. You then can map
  a drive to the user's home directory and have all the benefits of
  the %username% variable. Below is my login script -- hope this helps.

  if %os%==Windows_NT goto END

  \\server\netlogon\putinenv L

  \\server\netlogon\winset username=%username%

  net use f: /home

  \\server\netlogon\winset eudora=f:\%username%
  :END

  John Robinson <johnr@ids.net>

--------------------------
Content-Description: F.5. WFW machines can't log on to Win95 machines with access list from another domain.
Date: Tue, 10 Oct 1995 00:00:00 -0700
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>

  If a Windows for Workgroups machine is logged on to an NT server in one
  domain, it cannot log on to a Win95 machine with user-level access control
  specifying an NT server in another domain. See article Q125925 in the
  Microsoft Knowledge Base.

--------------------------
Content-Description: F.6. Troubleshooting Browsing with Client for Microsoft Networks.
Date: Thu, 07 Dec 95 10:15:00 -0800
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>

  Article Q134304 in the Microsoft Knowledge Base gives some tips for what to
  try when browsing in the Network Neighborhood doesn't work.

--------------------------
Content-Description: F.7. Can I log on to multiple NT domains?
Date: Tue, 10 Oct 1995 00:00:00 -0700
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>

  A corollary to F.3. is that you can't. Don't bother making sure your
  password is the same in both domains -- it won't work. Credit Tom Walker
  <tom.walker@labatt.com> and the other fine folks on win95netbugs for trying
  every conceivable workaround. You need to log off and log on again as
  another user.

--------------------------
Content-Description: F.8. Error Message: "VNETSUP: Error 6102" (WORKGROUP corruption)
Date: Tue, 10 Oct 1995 00:00:00 -0700
From: Rich Graves <win95netbugs-owner@lists.stanford.edu>

  You might get this error because Windows 95 has corrupted your workgroup
  name. Open the network control panel and enter it again. Microsoft has
  confirmed that this is a problem in Windows 95. See article Q126569 in the
  Microsoft Knowledge Base. Save this article, because it might happen again.

--------------------------
Content-Description: F.9. Changing NT permissions w/Win95 mgmt tool doesn't work?
Date: Wed, 06 Dec 95 09:18:19 CST
From: grcopeland@mmm.com (Glen R. Copeland)

  The directory the tools are located in (usually C:\SRVTOOLS) needs to be in
  your PATH. Put this into your AUTOEXEC.BAT.

--------------------------
Rich Graves <win95netbugs-owner@lists.stanford.edu>, friends, and enemies.
Copyright 1996 Rich Graves, Stanford University, and Friends.
Redistribution and mirroring are encouraged provided the source is credited