This article discusses a Beta release of a Microsoft product.
The information in this article is provided as-is and is subject
to change without notice.
No formal product support is available from Microsoft for this
Beta product. For information about obtaining support for a Beta
release, please see the documentation included with the Beta
product files, or check the Web location from which you
downloaded the release.
The information in this article applies to:
- Microsoft Windows 95
- Microsoft Windows 95 OEM Service Release version 1
- Microsoft Windows NT Workstation version 4.0
- Microsoft Windows NT Server version 4.0
- Microsoft Windows 95 OEM Service Release version 2
- Microsoft Windows 95 OEM Service Release version 2.1
- Microsoft Windows 2000 Professional
- Microsoft Windows 2000 Server
When you attempt to connect to a share on a Windows 95-based
computer from a Windows NT 4.0 workstation or server or Windows
2000, the connection attempt may not succeed and you may receive
an "Access Denied" error message if the following
This behavior can also occur with Windows 98-based computers
connecting to Windows 95-based computers, and from Windows
95-based computers with the DFS client installed talking to
Windows 95-based computers.
- The Windows 95 server has user-level security enabled
(instead of share-level security), and the security provider
is a Windows NT domain.
- You are attempting to connect to the Windows 95-based
computer by using a UNC name (\\servername\sharename)
instead of by mapping a drive letter to the share.
- The Windows NT 4.0 workstation or server has Service Pack
2 or Service Pack 3 installed.
This symptom is the result of an interoperability problem
between Windows NT 4.0 with Service Pack 2 or Service Pack 3
installed and Windows 95. Windows NT 4.0 with Service Pack 2 or
Service Pack 3 makes a connection using a null user name, which
Windows 95 does not handle correctly.
This issue is resolved by the following updated file for
Windows 95 and OSR1, and later versions of this file:
This issue is resolved by the following updated file for Windows
95 OSR2 and OSR 2.x, and later versions of this file:
VSERVER.VXD version 4.00.954 dated 4/24/97 108,288 bytes
VSERVER.VXD version 4.00.1112 dated 7/24/97 112,904 bytes
Microsoft has confirmed this to be a problem in Microsoft
Windows 95 and OEM Service Release 2 (OSR2). An update to
address this problem is now available, but is not fully
regression tested and should be applied only to computers
experiencing this specific problem. Unless you are severely
impacted by this specific problem, Microsoft does not recommend
implementing this update at this time. Contact Microsoft
Technical Support for additional information about the
availability of this update.
This issue is resolved in Microsoft Windows 98.
Windows NT 4.0 Service Pack 2 (SP2) uses a new version of the
Multiple UNC Provider (MUP) that contains new code for DFS. This
code establishes a null session when you connect to a server.
The Windows 95 File And Print Sharing service for Microsoft
does not handle the null session correctly and tries to use a
null user name to check for the access rights. When the MUP null
session requests arrives at Vserver,
SessSetupX calls AccessLogon.
Because smb_uid is always zero, even for TESTUSER, there is no
way to distinguish user TESTUSER from the null-session user. Vserver
uses the null user name for credentials checking in further SMB
commands and you receive the
For additional information about issues resolved by updates to
this component, please see the following articles in the
Microsoft Knowledge Base:
Connecting to Windows 95 User Level Share Results Event ID
Updated Drivers for File and Printer Sharing Security
For additional information about Windows 95 updates, please see
the following article in the Microsoft Knowledge Base:
Implementing Windows 95 Updates
Additional query words: win95 win95x winnt browse browsing
Keywords : kberrmsg kbnetwork osr2 NTSrvWkst
Version : WINDOWS:2000,95; winnt:4.0
Platform : WINDOWS winnt
Issue type : kbprb