none
Windows 2008 R2 server unable to browse UNC shares

    Question

  • Hi All..

    I appreciate if anyone could assist with pointing me in the right direction. I have a 2008 R2 server which operates as our SCCM server. For some reason, in the last few days has lost the ability to browse UNC shares from itself, to any other host on the network or it's own local shares. 

    DNS resolution and WINS both are working correctly. The affected server can ping any other host on our network, via IP and host alias or FQDN.

    For purposes of trying to rule the problem out, I have tried combinations of disabling all WINS and NetBIOS settings on the server, simply in an attempt to see if the issue was DNS, WINS or NetBIOS related. In all cases, attempting to browse another host using the UNC share , i.e. <\\hostname\sharename> or <\\host-ip\sharename>

    Doing a net view \\localhost or net view \\remote-server returns the correct list of shares. When trying to map a drive via net use x: \\remote-server\share I get;

    System error 67 has occurred.
    The network name cannot be found.
    And when browsing via Windows explorer I get the message
    Error Code: 0x90070043
    The network name cannot be found

    The same results happen for netbios name, FQDN and IP address.

    From the other side, every other host that I've tested can access shares on the the affected server. (I've tested XPSP3, WIN7 64-bit, WIN2003 32-bit, WIN2008 & WIN2008R2 hosts)

    I have also tried a "nbtstat -a <remote-hostname>" and "nbtstat -a <remote-host-ip>" and the information returned corresponds with the WINS server details.

    I have also tried an "nbtstat -S 2" whlist attempting to open a UNC share, but no corresponding entries appear while attempting to UNC browse.

    I should point out that the error notification (of the failure to connect) is instantaneous as if the server isn't even attempting to try going remotely. (i.e. no timeout) Which leads me to thinking there's a configuration setting somewhere that's causing this problem??

    There are no 3rd party firewalls installed, the windows firewall service is started by default but all the profiles for the firewall are turned off. We have tried setting firewall to on and allow all traffic, but the problem remains. All ports are open inbound and outbound as I can telnet to ports 139 and 445 of other servers from this server. I have also tried enabling all netbios rules that were disabled on the windows firewall (in order to rule out any potential conflict).

    The server was running Sophos 9.7 AV, I have tested completely removing the AV software from the server in order to rule out any potential conflict. This did not resolve the issue.

    I have also verified that it's not down to a disabled computer domain account.

    The servers are only operating IPv4, and obviously have File and Print services enabled, and client for Microsoft Networks.

    The AD domain was upgraded, many weeks prior, from an AD2003 domain to an AD2008, and the server was operating as expected until I discovered that the UNC shares were no longer working on this affected host.

    While it is not affecting config manager clients connecting to the server, is has an impact if a SCCM task sequence needs to retrieve data from a UNC share.

    As mentioned the server is a 2008 R2 box, it's a virtual machine operating on ESXi 4.1U1. The OS is fully patched and and VMware tools are up to date. The server is a member server of our AD domain. We have many other similarly configured 2008 R2 servers operating on the same ESXi host; in fact we have 2008R2 hosts acting as SCOM, SCOM RMS and SQL2008 R2 servers. All these servers are operating on the same IP subnet. All of these servers are operating with the same network configuration (with the exception of different static IP addresses).

    We have tried removing and reinstalling the VMware tools, and removing and reinstalling the Intel NIC, this hasn't made any difference either. I have also tried changing from the Intel NIC to a VMware VMXnet NIC. This has not made a difference.

    Any suggestions would be really be greatly appreciated as I've not been able to solve this to date..I will gladly supply any additional info if it can help anyone in the future, should they come across this problem.

    DE


    -Dropped everything to work on the problem :D
    • Edited by Dropped Everything Wednesday, June 15, 2011 7:25 AM typo; had typed 'netstat' when it should have been 'nbtstat'. changed now
    Tuesday, June 14, 2011 8:37 PM

Answers

  • For anyone still tuned in, I have discovered the cause of the problem.. finally. And in the interest of assisting anyone else who comes across this problem; here's how I resolved it.

    After lots of digging, comparing on a window by window basis.. I noticed that the "provider order" tab was missing from "advanced settings" window.

    This led me to do some digging into a way of trying to get the window to re-appear.

    I found this URL, which related to a similar 'provider order' issue, but on XP. See this link --> <http://www.petri.co.il/forums/showthread.php?t=43087>

    Anyways This led me to looking into the following registry key HKLM->System->CurrentControlSet->Control->NetworkProvider->Order-> ProviderOrder

    On my affected server this setting was as follows: "ProviderOrder"="RDPNP,hgfs"

    On my working servers, this setting was: "ProviderOrder"="RDPNP,LanmanWorkstation"

    So I changed my non-working server to this above setting (taking a backup of the registry, in advance, of course).. and rebooted, and problem solved!

    From the link above the HGFS component is related to VMware, I'm not sure at what stage did this VMware setting get implemented. We did recently put our VM's into an esxi 4.1 cluster, which required the upgrade of the VMware tools and the VMware hardware... so maybe it's related to this.

    If someone has any suggestions, on how this happens, it would be appreciated. I don't have the time to chase this up right now, due to the time spent trying to resolve the above issue. But I'd very much welcome feedback.

     


    -Dropped everything to work on the problem :D
    Tuesday, June 28, 2011 8:12 AM

All replies

  • Hi,

     

    Thanks for posting here.

     

    What if access the sharing folder where locate at itself ? via IP, hostname or FQDN?

    Just want to check if you have changed any system setting on this server before this issue occurred recently, hotfix installation or software upgrade?

    BTW, for the Error Code: 0x90070043, can you confirm that if the number is correct ? since I can find any document that regarding with it.

     

    Thanks.

     

    Tiger Li


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Wednesday, June 15, 2011 9:47 AM
  • Hi Tiger Li,

    Apologies for the delay getting back to you.

    The error code is a typo, on my behalf, the correct error is 0x80070043 "The network name cannot be found"

    On the affected SCCM server;
    If I try to open a file share which is hosted on the server (e.g. \\sccmservername\client) I will get the same error code returned.
    If I try "\\<ipaddress-of-sccmserver>\client" I will also get the same error message
    If I try \\localhost\client, I will get the error message

    The server is able to ping or perform an 'nslookup', etc of any other host on the network.
    I can also perform a "net view /domain:<MYDOMAINNAME>" and it will return the correct information. (I performed a "nbtstat -RR" prior to running the "net view" command).

    It's not an issue with time as the time is correctly in sync with the domain controller. (I have confirmed this by running "net time /domain set")

    ** EDIT**

    I missed the query about changes to the server. So I will clarify;

    There have been no changes to the server that I'm aware of (other than additional config manager clients added to SCCM).

    The first time I noticed a problem, was due to a ping of a win7 system responding with an incorrect IP address. I discovered that WINS had an old IP address showing for the WIN7 machine, so I purged the offending entry from the WINS server. So it appeared that the server was resolving the hostname through WINS firstly, then DNS. I did notice that the computer browser server was not running on the server initally, so I enabled this and set it to start automatically and rebooted. After the reboot, there was still no change.

    We have two WINS servers in operation, so I then attempted to switch the WINS server order. This didn't make any change to the problem.

    Each time I’d purge the netbios cache [‘nbtstat –R’  &  nbtstat –RR], to make sure the server queries the WINS server rather than use a local cache.

    I’ve double checked that ‘netlogon’, ‘server’ and ‘computer browser’ are running.. dependencies appear to be correct, and working.

    I don't consider the issue to be a GPO issue, otherwise all of my WIN2008 servers would have the same issue.

    In addition; when I changed the Network card from 'intel' to vmxnet, I opened a command prompt and ran "set devmgr_show_nonpresent_devices=1" then checked device manager, showing hidden devices, to ensure that there was no instances of disabled network cards showing. 

    If there's anything further you would like me to validate, please advise.

    Many thanks for taking the time to assist.

     

     


    -Dropped everything to work on the problem :D
    • Edited by Dropped Everything Wednesday, June 15, 2011 12:50 PM addition to clarify setup
    Wednesday, June 15, 2011 11:37 AM
  • If anyone has any suggestions on troubleshooting processes to take it would be really appreciated.

    My hunch/guess/opinion is that there's a problem with the netbios functionality, or authentication - this opinion is based on the system is immediately refusing to attempt a connection to the host, as opposed to an attempt to try and communicate with the host.

    I am at a point were I will have to consider rolling back to a system backup, while it's the easy way out, it doesn't help identify the issue.

    If I have to resort to a restore, I'd like to keep the system active in an isolated zone, in order to get to the bottom of this issue, in order to provide feedback on the root cause of the issue experienced. But theres a point in time where I'll have to purge it.

    As always, any assistance is gratefully appreciated

     


     


    -Dropped everything to work on the problem :D
    • Proposed as answer by Alex-31 Thursday, March 13, 2014 2:25 PM
    Friday, June 17, 2011 8:34 AM
  • Hi,

    Just giving this thread a bit of a bump on this thread as I'm still trying to figure this one out..

    I did resort to restoring from backup, to get my server working, but I'm encountering the issue on another 2008 R2 box, which is not good. So any suggestions you can think of would be appreciated. I think that this issue is more of a network protocol related nature, rather than application issue.. I'd appreciate if anyone could suggest how to proceed further on this one..

    Below are two snippets of wireshark captures, one is between the affected 2008 R2 host & a windows 2003 server, and the second one is between a working 2008 R2 host and the same 2003 server (used in the first example). In the test examples, I am simply doing a start -> run; then typing \\2003servername\ and pressing enter. Below is the network traffic between the two hosts, after I hit return;

    TEST#1 - Affected server (192.168.125.33), target remote server (192.168.125.6) - Affected server is 2008 R2, remote server is 2003 R2 Enterrpise 64-bit SP2

    465	6.020857	192.168.125.33	192.168.125.6	TCP	52716 > microsoft-ds [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8 SACK_PERM=1
    474	6.021445	192.168.125.6	192.168.125.33	TCP	microsoft-ds > 52716 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 SACK_PERM=1
    475	6.021479	192.168.125.33	192.168.125.6	TCP	52716 > microsoft-ds [ACK] Seq=1 Ack=1 Win=65536 Len=0
    476	6.021533	192.168.125.33	192.168.125.6	SMB	Negotiate Protocol Request
    481	6.022013	192.168.125.6	192.168.125.33	SMB	Negotiate Protocol Response
    482	6.022596	192.168.125.33	192.168.125.6	TCP	[TCP segment of a reassembled PDU]
    483	6.022601	192.168.125.33	192.168.125.6	SMB	Session Setup AndX Request
    484	6.022809	192.168.125.6	192.168.125.33	TCP	microsoft-ds > 52716 [ACK] Seq=182 Ack=2356 Win=65535 Len=0
    485	6.023891	192.168.125.6	192.168.125.33	SMB	Session Setup AndX Response
    486	6.024115	192.168.125.33	192.168.125.6	SMB	Tree Connect AndX Request, Path: \\2003servername\IPC$
    487	6.024321	192.168.125.6	192.168.125.33	SMB	Tree Connect AndX Response
    488	6.024455	192.168.125.33	192.168.125.6	SMB	Trans2 Request, GET_DFS_REFERRAL, File: \2003servername\.
    489	6.024653	192.168.125.6	192.168.125.33	SMB	Trans2 Response, GET_DFS_REFERRAL, Error: STATUS_NO_SUCH_DEVICE
    490	6.024821	192.168.125.33	192.168.125.6	SMB	Tree Connect AndX Request, Path: \\2003servername\.
    491	6.024995	192.168.125.6	192.168.125.33	SMB	Tree Connect AndX Response, Error: STATUS_BAD_NETWORK_NAME
    492	6.025136	192.168.125.33	192.168.125.6	SMB	Tree Connect AndX Request, Path: \\2003servername\.
    493	6.025313	192.168.125.6	192.168.125.33	SMB	Tree Connect AndX Response, Error: STATUS_BAD_NETWORK_NAME
    516	6.221682	192.168.125.33	192.168.125.6	TCP	52716 > microsoft-ds [ACK] Seq=2700 Ack=709 Win=64768 Len=0
    I can reproduce the same network traffic against 2008 R2 host, only the SMB traffic will show as SMBV2

    TEST#2 - To compare this, I ran the same test (above) using a working 2008 R2 host, against the same 2003 remote server. You will see that it is considerably more network traffic, than the above failed example.

    321	5.277323	192.168.125.14	192.168.125.6	TCP	64518 > microsoft-ds [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8 SACK_PERM=1
    322	5.277482	192.168.125.6	192.168.125.14	TCP	microsoft-ds > 64518 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 SACK_PERM=1
    323	5.277509	192.168.125.14	192.168.125.6	TCP	64518 > microsoft-ds [ACK] Seq=1 Ack=1 Win=65536 Len=0
    324	5.277575	192.168.125.14	192.168.125.6	SMB	Negotiate Protocol Request
    325	5.277978	192.168.125.6	192.168.125.14	SMB	Negotiate Protocol Response
    326	5.278537	192.168.125.14	192.168.125.6	SMB	Session Setup AndX Request
    327	5.278758	192.168.125.6	192.168.125.14	TCP	microsoft-ds > 64518 [ACK] Seq=182 Ack=2358 Win=65535 Len=0
    328	5.279557	192.168.125.6	192.168.125.14	SMB	Session Setup AndX Response
    329	5.279803	192.168.125.14	192.168.125.6	SMB	Tree Connect AndX Request, Path: \\2003servername\IPC$
    330	5.279992	192.168.125.6	192.168.125.14	SMB	Tree Connect AndX Response
    331	5.280129	192.168.125.14	192.168.125.6	SMB	Trans2 Request, GET_DFS_REFERRAL, File: \2003servername\.
    332	5.280316	192.168.125.6	192.168.125.14	SMB	Trans2 Response, GET_DFS_REFERRAL, Error: STATUS_NO_SUCH_DEVICE
    333	5.280471	192.168.125.14	192.168.125.6	SMB	Tree Connect AndX Request, Path: \\2003servername\.
    334	5.280607	192.168.125.6	192.168.125.14	SMB	Tree Connect AndX Response, Error: STATUS_BAD_NETWORK_NAME
    335	5.280742	192.168.125.14	192.168.125.6	SMB	Tree Connect AndX Request, Path: \\2003servername\.
    336	5.280877	192.168.125.6	192.168.125.14	SMB	Tree Connect AndX Response, Error: STATUS_BAD_NETWORK_NAME
    337	5.281675	192.168.125.14	192.168.125.6	SMB	NT Create AndX Request, FID: 0xc006, Path: \wkssvc
    338	5.281933	192.168.125.6	192.168.125.14	SMB	NT Create AndX Response, FID: 0xc006
    339	5.282084	192.168.125.14	192.168.125.6	DCERPC	Bind: call_id: 2, 3 context items, 1st WKSSVC V1.0
    340	5.282252	192.168.125.6	192.168.125.14	SMB	Write AndX Response, FID: 0xc006, 160 bytes
    341	5.282354	192.168.125.14	192.168.125.6	SMB	Read AndX Request, FID: 0xc006, 1024 bytes at offset 0
    342	5.282523	192.168.125.6	192.168.125.14	DCERPC	Bind_ack: call_id: 2 Unknown result (3), reason: Abstract syntax not supported
    343	5.282633	192.168.125.14	192.168.125.6	WKSSVC	NetWkstaGetInfo request Level:100
    344	5.282907	192.168.125.6	192.168.125.14	WKSSVC	NetWkstaGetInfo response
    345	5.283036	192.168.125.14	192.168.125.6	SMB	Close Request, FID: 0xc006
    346	5.283195	192.168.125.6	192.168.125.14	SMB	Close Response, FID: 0xc006
    347	5.283449	192.168.125.14	192.168.125.6	SMB	NT Create AndX Request, FID: 0xc00a, Path: \srvsvc
    348	5.283666	192.168.125.6	192.168.125.14	SMB	NT Create AndX Response, FID: 0xc00a]
    349	5.283793	192.168.125.14	192.168.125.6	DCERPC	Bind: call_id: 2, 3 context items, 1st SRVSVC V3.0
    350	5.283957	192.168.125.6	192.168.125.14	SMB	Write AndX Response, FID: 0xc00a, 160 bytes
    351	5.284059	192.168.125.14	192.168.125.6	SMB	Read AndX Request, FID: 0xc00a, 1024 bytes at offset 0
    352	5.284210	192.168.125.6	192.168.125.14	DCERPC	Bind_ack: call_id: 2 Unknown result (3), reason: Abstract syntax not supported
    353	5.284302	192.168.125.14	192.168.125.6	SRVSVC	NetSrvGetInfo request
    354	5.284527	192.168.125.6	192.168.125.14	SRVSVC	NetSrvGetInfo response
    355	5.284638	192.168.125.14	192.168.125.6	SMB	Close Request, FID: 0xc00a
    356	5.284790	192.168.125.6	192.168.125.14	SMB	Close Response, FID: 0xc00a
    358	5.339168	192.168.125.14	192.168.125.6	SMB	NT Create AndX Request, FID: 0x000e, Path: \srvsvc
    359	5.339549	192.168.125.6	192.168.125.14	SMB	NT Create AndX Response, FID: 0x000e
    360	5.339689	192.168.125.14	192.168.125.6	DCERPC	Bind: call_id: 2, 3 context items, 1st SRVSVC V3.0
    361	5.339839	192.168.125.6	192.168.125.14	SMB	Write AndX Response, FID: 0x000e, 160 bytes
    362	5.339905	192.168.125.14	192.168.125.6	SMB	Read AndX Request, FID: 0x000e, 1024 bytes at offset 0
    363	5.340056	192.168.125.6	192.168.125.14	DCERPC	Bind_ack: call_id: 2 Unknown result (3), reason: Abstract syntax not supported
    364	5.340130	192.168.125.14	192.168.125.6	SRVSVC	NetShareEnumAll request
    365	5.340276	192.168.125.6	192.168.125.14	SMB	Write AndX Response, FID: 0x000e, 92 bytes
    366	5.340336	192.168.125.14	192.168.125.6	SMB	Read AndX Request, FID: 0x000e, 1024 bytes at offset 0
    367	5.340482	192.168.125.6	192.168.125.14	SMB	Read AndX Response, FID: 0x000e, 1024 bytes
    368	5.340547	192.168.125.14	192.168.125.6	SMB	Read AndX Request, FID: 0x000e, 2480 bytes at offset 0
    369	5.340722	192.168.125.6	192.168.125.14	TCP	[TCP segment of a reassembled PDU]
    370	5.341016	192.168.125.6	192.168.125.14	SRVSVC	NetShareEnumAll response
    371	5.341045	192.168.125.14	192.168.125.6	TCP	64518 > microsoft-ds [ACK] Seq=4575 Ack=5925 Win=65536 Len=0
    374	5.341538	192.168.125.14	192.168.125.6	SMB	Close Request, FID: 0x000e
    375	5.341693	192.168.125.6	192.168.125.14	SMB	Close Response, FID: 0x000e
    401	5.603988	192.168.125.14	192.168.125.6	TCP	64518 > microsoft-ds [ACK] Seq=4620 Ack=5964 Win=65536 Len=0

    Again, I can repeat the same test against a 2008 R2 server, and I will get the same output, except the SMB traffic will be SMBV2

    It appears to me that the issue is protocol related, as you can see in test#1 between the second-last and the last line of network traffic, it jumps from "STATUS_BAD_NETWORK_NAME" to a TCP/IP [ACK] response. Yet in test#2 you can see that after line 336 (shown below), you can see it calls "wkssvc", which I'm assuming is the workstation service.. which we don't see at the first (failed) test..

    ....
    337 5.281675 192.168.125.14 192.168.125.6 SMB NT Create AndX Request, FID: 0xc006, Path: \wkssvc 338 5.281933 192.168.125.6 192.168.125.14 SMB NT Create AndX Response, FID: 0xc006 339 5.282084 192.168.125.14 192.168.125.6 DCERPC Bind: call_id: 2, 3 context items, 1st WKSSVC V1.0
    ....

    If there's anyone out there that can assit, it really would be much appreciated.

    Thanks in advance..


    -Dropped everything to work on the problem :D
    Monday, June 27, 2011 4:26 PM
  • For anyone still tuned in, I have discovered the cause of the problem.. finally. And in the interest of assisting anyone else who comes across this problem; here's how I resolved it.

    After lots of digging, comparing on a window by window basis.. I noticed that the "provider order" tab was missing from "advanced settings" window.

    This led me to do some digging into a way of trying to get the window to re-appear.

    I found this URL, which related to a similar 'provider order' issue, but on XP. See this link --> <http://www.petri.co.il/forums/showthread.php?t=43087>

    Anyways This led me to looking into the following registry key HKLM->System->CurrentControlSet->Control->NetworkProvider->Order-> ProviderOrder

    On my affected server this setting was as follows: "ProviderOrder"="RDPNP,hgfs"

    On my working servers, this setting was: "ProviderOrder"="RDPNP,LanmanWorkstation"

    So I changed my non-working server to this above setting (taking a backup of the registry, in advance, of course).. and rebooted, and problem solved!

    From the link above the HGFS component is related to VMware, I'm not sure at what stage did this VMware setting get implemented. We did recently put our VM's into an esxi 4.1 cluster, which required the upgrade of the VMware tools and the VMware hardware... so maybe it's related to this.

    If someone has any suggestions, on how this happens, it would be appreciated. I don't have the time to chase this up right now, due to the time spent trying to resolve the above issue. But I'd very much welcome feedback.

     


    -Dropped everything to work on the problem :D
    Tuesday, June 28, 2011 8:12 AM
  • Thank you!

    This solved my problem as well. I did not have the same ProviderOrder as you did initially, but changing it to "RDPNP,LanmanWorkstation" helped.

    Again, thank you for giving us the solution, inspite that no one here helped you.



    Tom Aafloen, IT-security Consultant Onevinn AB

    Monday, February 18, 2013 10:06 PM
  • And in my case, the upgrade to W 8.1 added an extra comma in the value of ProviderOrder so that the mount action broke off with error value 0x80070043 (and system error 67 with "net use").  Solution was to remove the extra comma.
    Sunday, October 27, 2013 1:23 PM
  • Thank You!

    We had exactly the same Problem on an sbs2011 Server.

    It was driving me nuts an we tried a lot of the things you did.

    But the LanmanWorkstation entry fixed the Problem of accessing the NAS SMB Shares.

    The Server was also a VM upgraded some time ago from ESXi 4.1 to 5.0.

    Thanks again!


    • Edited by www.gk-edv.de Saturday, December 14, 2013 1:52 AM spelling
    Saturday, December 14, 2013 1:51 AM
  • I had similar problem on Server 2008 R2 and VMware. Any machine on the network could browse and connect to shares on it but could not browse or connect from the 2008 server to any share on the network. Was getting error code 0x80004005. Tried everything, enabling computer browser services, shutting down the firewall, rejoining the machine to the domain, etc. nothing helped. After seeing your post I gave it a shot and when I saw the setting for the provider order I thought it was another dead end. As I was about to move on I noticed that the provider order setting was ",RDPNP,LanmanWorkstation". I removed the leading comma and BAM! It works now.

    Thanks for thew post.

    Friday, February 14, 2014 4:20 PM
  • Thank You. It resolved the issue in one of our VM ( Win-2k8 R2-64 Bit ) running on ESXi5.1 Host.
    Monday, February 17, 2014 4:36 PM
  • your solution worked for me as well.  we have never had this issue before with our VMware vm W2K8 R2 servers before.  I dont know what caused it with this one rogue server, but nonetheless your fix was what was needed.  I shared it with our server team.

    our environment is ESXi 5.0

    the server was a fresh build from a  template.

    Thanks,

    scott

    Thursday, March 13, 2014 2:31 PM
  • I had a problem almost like it when trying to access a Onedrive (SkyDrive) from a 2008r2 server.
    The missing webclient entry in the registry was added when i installed the Webclient (Desktop Experience) feature for 2008r2.

    Works fine now, just like when i map from my win7 workstation.

    No more System error 67/Error Code: 0x90070043 after that





    Monday, March 24, 2014 9:34 AM
  • Thank you so much for posting this resolution.  We have spent days looking into this issue and your answer has sorted it.  :)
    Monday, March 31, 2014 1:12 AM
  • I had this error recently on a 2008 r2 after breaking a networking bridge. Turned out, for me, client for microsoft networking had gotten removed. After trying most everything, I found that it was missing. I hadn't uninstalled it, but when the bridge got removed that component got removed as well.
    Wednesday, July 09, 2014 5:48 PM
  • Thank you!!

    Finally found this solution at 2 AM after a night of trying to recover a P2V-ed server that just had to work.. You sir, are my hero!

    Tuesday, November 25, 2014 12:36 AM
  • Dropped Everything!!!

    I have no words to express my joy

    your solution worked like a charm

    I am really thanking you for providing the solution


    Thanks & Regards S.Swaminathan Live & let others live!!!

    Thursday, January 29, 2015 10:26 PM
  • Thank you!!!!

    You rock, I have been pulling my hair all day trying to fix this problem!!!

    Wednesday, March 11, 2015 2:11 AM
  • Why do I always get the hard ones?  My issue is extremely similar to this in that the symptoms are the same (can't browse any UNC shares by IP or server name, but can ping them fine), however using net view I get error 53 rather than 67.  Also, unfortunately, the registry entry that fixed it for so many of you is already correct for me :(  It is set to "RDPNP,LanmanWorkstation" without any preceding or trailing comma... :(
    Thursday, September 17, 2015 2:30 PM
  • Thanks for the post!  I had the same exact issue on a Windows2008 R2 server.  Worked like a charm!
    Friday, November 13, 2015 3:50 PM
  • Thanks for all these post I had a 2012 server after an update I could ping itself, NSLOOKUP resolved, all workstations on the network could connect but it couldnt map a network drive to itself. The server had ",RDPNP,LanmanWorkstation" and I was thinking the comma wasnt an issue, turns out I removed it and its up. Thanks was getting tired of going around in circles.
    Tuesday, December 08, 2015 4:59 PM
  • Thanks very much. That solved my problem which took 2 hours from me.
    Thursday, January 07, 2016 10:37 AM
  • Hi NJDfan1711,

    I know it's been a while since you posted the above but was wondering if you ever resolved this?

    I'm in the exact same position as you where the registry entry is correct, no commas etc., yet I cannot browse any UNC paths by IP nor by FQDN and the same error 53 code. My OS is Windows 7.

    Thursday, March 03, 2016 1:08 PM
  • This maybe helpful to some and I would have liked to have come across this fix prior to the 6 hours it's taken me to suss it out!

    Issue was unable to browse or even get a login prompt from Win 7 client to a newish 2008 R2 file server that serves homedrives to 95% of users, but not all. Users/admins cannot browse using IP, or FQDN but can ping, nslookup, RDP to server etc, just cannot browse shares.

    Narrowed it down to SMB2 being disabled on some Windows 7 clients. This may have been a software installation at some stage but I'm unable to find the culprit, and to be fair, I've lost the will and don't care how it was caused.  It may bite but at least it's working.

    I had tried disabling SMB2 on the 2008 R2 server which worked, but my RDS server shouted loudly, so I put SMB2 back on quickly.

    Fix was:

    Enable SMB2 on the Client

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation 
    edit DependOnService and add MRxSmb20 
    so it should look like: 
    Bowser 
    MRxSmb10 
    MRxSmb20 
    NSI

    ps. Bowser is NOT a Browser typo! 

    THEN 

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\mrxsmb20 

    Change Start to 3. (it was 4 = disabled) 

    Reboot client

    Hope this makes someone as happy as I am....

    Tuesday, January 17, 2017 2:01 PM
  • Hi,

    It resolved the issue of accessing shares


    Regards, Dennis

    Monday, February 27, 2017 8:20 AM