none
File Sharing with Vista SP2

    Question

  • I have a quick question with file sharing and Vista SP2.  I would share files over the network using a Winxp laptop to access my Vista SP1 tower with no problems.  Now I installed Vista SP2 RC and all of a sudden I can no longer access the Vista tower from my XP laptop.  It says you might not have permission to use this network resource.  Contact the administrator of the server to find out if you have access permissions.  Access is denied.  It worked fine before the SP2 upgrade, no changes other than the SP install.  Also of note, I had the same problem with Vista SP2 Beta and had to rollback to Vista SP1.  I can access the WinXP laptop fine from the Vista SP2 RC tower, but not vice versa.  Please help as I feel my tower is so much faster and more stable with Vista SP2.  
    Monday, February 23, 2009 1:25 AM

All replies

  • Hi,

    Sorry that you are seeing this issue. Can you please update me with following information so that we can debug more into this issue :-

    1) SP2 version on your machine ? You can go to run--> msinfo32. Hardware Abstraction Level tells you the SP2 build on your machine ?
    2) Can you ping your XP machine from your Vista Machine.To check this you can go to command prompt and type "ping XP machine name or ip of Xp machine" (Replace XP machine name with actual name or ip of the XP machine) ?
    3) Is there any work around you follow to tackle this issue apart from uninstalling SP2 ?

    Thanks,
    Sachin
    Tuesday, February 24, 2009 12:16 AM
  • 1)6.0.6002 Service Pack 2 V.286 Build 6002
    2) Pings are successful.
    3)There is no password protected file sharing on, I even tried enabling Guest Account.  Only common denominator is SP2.  No settings were changed before SP2 was installed and it worked flawlessly before this.
    Saturday, February 28, 2009 7:38 AM
  • I am having the same problem. Vista Home Premium on one machine and XP Home SP3 on another connected via a local network. When I installed Vista SP2 (via Windows update) I was no longer able to access the Vista machine from XP. A window would pop up on the XP machine asking for a user name and password. I don't use passwords on either of the machines. Both machines are single user machines. Password protected file sharing is OFF on the Vista machine. However, file sharing does still work in the other direction - I am still able to access the XP machine from the Vista SP2 machine. I uninstalled Vista SP2 and reverted back to SP1 and now everything is back to normal.

     

    Sunday, May 31, 2009 4:13 PM
  • I started seeing the same issue following an upgrade to SP2 on a Vista Ultimate machine.  Shares on my XP SP3 machine are no longer accessible -- when I try to navigate to a shared folder, I'm now challenged for credentials, but even a valid username and password are rejected.  I've found no errors logged in any of the event logs, or by the firewall software.

    This was working correctly pre-Vista SP2.
    Tuesday, July 07, 2009 5:31 PM
  • You might want to check the network setting (home or work) and make sure network discovery is turned on, on the Vista PC.
    Tuesday, July 07, 2009 6:55 PM
  • Thanks for the suggestion.  I did check but Network Discovery was already turned on and both machines are on the same home subnet.  While I was in Network Settings, I clicked on Diagnose Network Connection Problems and although this reported 'no problems found', when I tried to access the failing remote share again, it just worked !

    So I'm pleased the problem went away (but confused how it fixed itself).
    Wednesday, July 08, 2009 8:07 AM
  • I have the same issue, and it appears to be widespread.  I have an independent testing and development lab not affiliated with Microsoft.

    This testing is done in a Workgroup environment, not a Microsoft Domain environment.

    After installing Service Pack 2 on Vista, none of our XP, Win 2000 Pro, Win 2000 Server, Win 2003 Server regardless of service pack release can see the shares on the Vista machine.  The shares were visible before Vista SP2.

    The errors on Win 2000,  Win 2003, and Win XP indicate it is a fault with the \\computer\IPC$ administrative share when requesting a list of resources from the computer.

    On the Vista machine, the Windows Event Log (security) shows successful network login and logout of the Win 2000, Win 2003, and Win XP computers, but the client computers are showing access failures.

    The Vista machine Windows Event Logs (application and system) show no faults or information messages.

    The SP2 for Vista that was releaced by Microsoft appears to be the same SP2 for their Windows 2008 Server.

    I am still able to access the file shares on Win 2008 Server with older operating systems after applying SP2.

    Older operating systems show access denied errors on Vista shares (regardless of share type) after Vista has been updated with SP2.

    I have not installed Windows 7 yet on any of our computers for testing.

    My biggest security concern with Vista, if a rollback to SP1 is performed, is that the Microsoft delivery of
    security patches will be invalidated, requiring a reinstall of SP2 and its network failure issues.

    Network folder sharing on Vista before SP2 also had some significant issues.  I had a Vista based computer
    with multiple user accounts.  It had a shared folder on which the users were co-owners.  I found that
    not all files in the folder were visible.  It appears that file visibility was owner specific.  An account
    could see its own files in the folder and not files entered by other accounts.  The resolution was to
    re-share the folder on Vista for all files in the folder to become visible to all authorized accounts.

    Since Vista SP2, only Vista and newer operating systems can see the shared folder resources on Vista.

    If you have the luxury of having an older operating system or a Windows Server, use it to host your shared
    folders instead of the Vista workstation.

    I am eagerly awaiting a HotFix from Microsoft to resolve the Vista folder sharing issue, but word from Microsoft
    appears extremely silent on the issue.




    Good systems are supportable
    Saturday, October 31, 2009 9:25 PM
  • FOLDER SHARING ISSUES - VISTA/WIN-7/2008 <-> XP/2000/2003

    Some issues arise out of differences between NTLM-V1 and NTLM-V2.

    Some issues arise while trying to prepare an isolation network
    where Vista, and Server 2008 have persistent TCP/IPv4 default routes.

    Some issues arise if a 3rd party firewall is not compliant with
    NTLM-V2 network messages.

    Operating systems that use NTLM-V1:
     XP, Windows 2000, Server 2000, Server 2003, Server 2003 R2

    Operating systems that use NTLM-V2:
     Vista, Windows 7, Server 2008

    Operating systems that do not persist the TCP/IPv4 default routes:
     XP, Windows 2000, Server 2000, Server 2003, Server 2003 R2

    Operating systems that do have persistent TCP/IPv4 default routes:
     Vista, Server 2008 (I have not tested Windows 7)

    The current ZoneAlarm firewall is NTLM-V2 compliant.  An older release
    blocks some NTLM-V2 messages and creates interoperability problems
    between Vista and older operating systems like XP, 2000, and 2003.

    Any 3rd party firewall you deploy must be NTLM-V2 compliant and
    have the capability to explicitly trust the computers for which
    you intend to use Windows resource sharing.  The 3rd party firewall
    products are also able to block untrusted computers and
    networks.

    I use 3rd party firewalls on any computer with multiple network
    interfaces.  The standard Windows firewall will either trust or
    untrust all attached network interfaces.

    SOME HELPS TO RESOLVE NETWORK SHARING ISSUES

    I have no definitive comments from Microsoft about these recommendations.
    I have tested this capability in a closed WORKGROUP network environment.
    This information has been shared with the Microsoft Vista-SP2 help desk.
    I hope that this information becomes validated by Microsoft and becomes
    released in the searchable knowledge base of articles.

    The default network routes for (0.0.0.0) are persistent in Vista/Win-7/2008
    and can cause phantom "unidentified network" locations that are difficult
    to remove.  I hope that the default routes for (0.0.0.0) revert back to
    what XP/2000/2003 use - they do not persist in the routing table but are
    bound to the network interface definition.

    Vista-SP2 has fixed the sharing issue where the computer has multiple
    accounts (TESTA) and (TESTB) with shared folder (FOLDER).  Before SP2,
    the files in (FOLDER) owned by (TESTA) were invisible to (TESTB) until
    after the (FOLDER) on Vista was re-shared.  Now with Vista-SP2, the
    visibility precedence assumes the share-permissions instead of the
    account-ownership permissions.

    These notes are intended to help troubleshoot and fix resource sharing
    problems between Vista (using NTLM-V2) and XP (using NTLM-V1) messaging.

    SAVE YOUR NETWORK CONFIGURATIONS

    1. Start the command window as Administrator.

    2. Run the following command to save the network configurations.

     NETSH DUMP >netsh-dump.txt

       Later, when testing is completed, you can restore your
       network configurations.

     NETSH EXEC netsh-dump.txt

    CREATE AN ISOLATED NETWORK - WINDOWS WORKGROUP

    1. Unplug or remove the internet firewall-router from the local network.

    2. Unplug or remove any untrusted network connections.

    3. Remove all default routes - using the command window as Administrator.

     ROUTE DELETE 0.0.0.0

       This removes all default routes from all interfaces.  It also removes
       the persistent default routes that may create a phantom "unidentified
       network" on Vista, Windows 7, and Windows 2008 computers.

       This does not remove the other persistent routes you may have configured
       to access computers on other network segments.

    4. Vista, Windows 7, and Windows 2008 require a default route on
       at least one network interface.

       If there is no default route for network 0.0.0.0, then the network
       becomes an "unidentified network" and defaults to public permissions
       with no sharing capability.  Such a network location cannot be renamed.

       On Vista, Windows 7, and Windows 2008 computers, choose a reachable
       TCP/IPv4 address that is reachable.

    *   DO NOT USE THE LOCAL ADDRESS OF THE LOCAL NETWORK INTERFACE.
       THIS WILL CAUSE A PHANTOM "unidentified network" TO BE CONFIGURED
       because of a persistent default route that is unusable.

    *   If you have the PHANTOM "unidentified network" it can be removed
       using the ROUTE DELETE 0.0.0.0 command from the Windows Command
       Screen. Afterwards choose a reachable TCP/IPv4 address that is
       reachable on the local network.

    5. Make sure that the WORKGROUP has the same name on all computers
       to be tested on the isolated network.

    6. Make sure that User Accounts have the same names and passwords
       on all computers to be tested on the isolated network.

    7. Make sure that the local firewalls support NTLM-V2 and support
       at least the following sharing permissions are enabled:

     Network Discovery (enabled)
     File Sharing (enabled)
     Password Protected Sharing (enabled)

       The other sharing permissions are optional:

     Public Folder Sharing
     Printer Sharing
     Media Sharing

    8. Share folders on selected computers, assign users and their
       folder sharing permissions.  Share only what you need with the
       permissions you need.

       Before Vista SP2, there was a problem in a shared folder that
       files owned by one account were not visible to another account
       unless the folder was re-shared.  This problem appears fixed
       in Vista SP2.  The share permissions now take precedence over
       account ownership permissions.

    CREATE NTLM ASSISTANCE RESOURCES FOR HOSTNAME RECOGNITION - LMHOSTS

    Computers using NTLM-V2 have problems recognizing NTLM-V1 computers.

    Computers using NTLM-V1 have problems recognizing NTLM-V2 computers.

    1. Use a "lmhosts" file, WINS service, NT Domain, or Active Directory

       Relying on the "hosts" file or DNS is probably insufficient.

       You should probably configure one of the Microsoft browsing directory
       services to aid NTLM-V1 and NTLM-V2 computers for finding each other.

       There may otherwise be significant delays for computer hostname
       recognition on the network necessary to find Microsoft shared
       resources.

    2. Creating a "lmhosts" file

       A sample file is located at:
         %windir%\system32\drivers\etc\lmhosts.sam

       Copy this file to a user directory as filename "lmhosts.txt" and
       edit the file with notepad.

       You should not need to worry about #PRE and #DOM:workgroup-or-domain.

       Just populate your "lmhosts.txt" with the TCP/IPv4 addresses and
       hostnames of the computers on your network. For example:

       192.168.10.10   TESTA
       192.168.10.11   TESTB
       192.168.10.12   TESTC

       # TestA can be a XP host
       # TestB can be a Vista host
       # TestC can be a 2008 server

       Installing this file can assist Windows when browsing network
       segments for hostnames to find shared resources.  It helps resolve
       some browsing issues between NTLM-V1 and NTLM-V2 hosts.

       Host accessability timeouts can still be frustrating.

    3. Install the "lmhosts.txt" file onto specific computers to:
         %windir%\system32\drivers\etc\lmhosts

       This can be accomplished through the Windows Control Panel.

       [WINDOWS XP]

       Control Panel ->
         Network Connections ->
           Local Area Connection ->
             Client for Microsoft Networks (enabled) ->
               [Windows Locator]
             File and Printer Sharing for Microsoft Networks (enabled)
             Internet Protocol (TCP/IP) ->
               Properties ->
                 Advanced ->
                   WINS ->
                     Enable LMHOSTS Lookup
                     Import LMHOSTS
                       Select the path to your "lmhosts.txt"
                       - replaces %windir%\system32\drivers\etc\lmhosts
                     Enable NETBIOS over TCP/IP

       [WINDOWS VISTA]

       Control Panel ->
         Network Sharing Center ->
           Manage Network Connections ->
             Local Area Connection ->
               Client for Microsoft Networks (enabled) ->
                 [Windows Locator]
               File and Printer Sharing for Microsoft Networks (enabled)
               Internet Protocol Version 4 (TCP/IPv4) ->
                 Properties ->
                   Advanced ->
                     WINS ->
                       Enable LMHOSTS Lookup
                       Import LMHOSTS
                         Select the path to your "lmhosts.txt"
                         - replaces %windir%\system32\drivers\etc\lmhosts
                       Enable NETBIOS over TCP/IP

       Reset the Local Area Connection interface (disable, enable).

    4. Test if network browsing and resource sharing is operational.

       If NET VIEW reports
         System error 6118 has occurred.
         The list of servers for this workgroup is not currently available

       See Knowledge Base Article Q298804 - Windows Firewall may need
       to be disabled.

       The proper fix is to make sure that all local firewalls enable
       the required messages of NTLM trust for network discovery and
       resource sharing.  Windows Firewall may not need to be disabled.

       Problem hosts may need their network interface reset.
       Disable then enable the network interface.  This may force a
       another network segment master browser negotiation, and therefore
       find the missing computers on the network.

       If resetting the network interface does not solve the problem,
       then reboot the operating system.

       Recheck the computer hostnames, account names, account passwords,
       resource (i.e. folder) sharing permissions, and firewall trust.

       Two other system errors that are commonly seen are:

       System error 5 has occurred.
       Access is denied.

          The computer is found but the shared resource either does
          not exist or permissions on the share are refused.

          Vista may also show this error if the "default path" on the
          network interface is unreachable.  See also if your network
          location name is "unidentified network".  Vista, 2008, and
          Windows 7 may require a reachable default TCP/IP address.

          DO NOT CHOOSE the local adapter TCP/IP address as the default
          address on Vista, 2008, and Windows 7 computers.  It requires
          issuing the ROUTE DELETE 0.0.0.0 console command to be issued
          to remove the phantom "unidentified network" location.

       System error 53 has occurred.
       The network path was not found.

          The computer hostname cannot be resolved or the computer
          network path is unreachable.

    AIDS TO MICROSOFT NETWORK SEGMENT BROWSING - RESOURCE SHARING

    We currently are not using WINS or Active Directory.  We are not
    using Linux/Samba, but I have configured such systems.

    Network segment browsing only - has significant delays and
    computer recognition stability between NTLM V1 and NTLM V2 systems
    unless some additional assistance is deployed.

    The network browsing assistance can be obtained using LMHOSTS,
    WINS, NT Directory, or Active Directory services.

    I am unsure how robust the Microsoft WINS capability has become.

    The Linux WINS capability requires a Linux/Samba system on each
    network segment - which can be difficult for most administrators
    to properly configure.

    The Linux/Samba can be configured as a functional LDAP replacement
    for the Microsoft Active Directory Service.  This is also very
    dificult for most administrators to properly configure.

    The Linux/Samba can be a client for Microsoft NT-Domain and
    Active Directory Services.  This is often used by Unix based
    network sites.

    <EOD>


    Good systems are supportable
    Thursday, November 05, 2009 9:58 PM
  • Work around :

    1. Copy the dfsc.sys file form (c:\windows\system32\drivers) working machine and then copy that on the machine which is having SP2 ( should on same location). make sure you rename the file before update the new one.

    2. While doing the rename you might be finding some problem as won;t allow you to do that   so for that you need to go to the safe mode or change that file permission owner to administrator and then try to rename it. 

    hopefully it will work ....

    Tuesday, November 29, 2011 12:38 PM