Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have an unusual problem with a Windows Server 2003 (Standard x86) box.

It appears the machine will not accept connections to its shares (locally and from other domain member servers) by using its ip address in a UNC path. The error returned is: "no network provider accepted the given network path"

This is the case with the machine's ip address \\10.0.8.x = FAIL

and even the loopback address \\127.0.0.1 = FAIL

and even \\localhost = FAIL

but using the hostname (fqdn or not) works!!! \\server & \\server.domain.local

The local windows firewall for this server is off, ping/rdp/other services respond fine using the IP address.

The following services are running and have been restarted:

  • Computer Browser
  • Workstation
  • Server

The server itself has been rebooted too. Event 8032 in the system log indicates that:

The browser service has failed to retrieve the backup list too many times on transport \Device\NetBT_Tcpip_{29A6A925-AFB3-47E2-BA59-DDA086DEAE7A}. The backup browser is stopping.

The domain controller has not been restarted, no other servers have experienced this problem, yet there are a number of browser (8021) related errors in the logs on this server.

Does anyone have any suggestions? I would like to avoid rejoining this server to the domain if possible.

share|improve this question
    
I have the same problem for one of his servers. (also a 2003 server) We configured an alias for that server in the DNS. Both names of the server are resolving to the same IP address. However, I can only use the original hostname to access the shares on the server. The http request are of course not affected. - Nevertheless, I would stay away from using the IP adresses anyway. The hostname or an alias are good abstraction layers, so you can change the IP adresses later without changing apps that use the server. Makes it easier to consolidate servers or to move from a single server to a cluster. –  Peter Schuetze Jan 8 '10 at 16:01
1  
@Peter: That is a different problem than what Boy Mars is experiencing. For your alias problem set the DisableStrictNameChecking registry value as described in the Windows 2003 section of this KB article - support.microsoft.com/kb/281308 –  squillman Jan 8 '10 at 16:27
    
@squillman: Thanks for your quick answer. out of curiosity, I tried to connect to the IP and I can conncet to the share. So it really seems to be something different. (I guess I should do my homework the next time.) –  Peter Schuetze Jan 8 '10 at 16:34
add comment

2 Answers

Do you have multiple NICs in this box? Have a look at this KB about Event ID 8032.

share|improve this answer
    
Thanks for responding, there are 2 NICs in the box, only one is physically connected and active. The other has never been assigned an IP address (assigned a 169.x.x.x address by default). This machine is not a DNS server/master browser. @Peter: I'm glad i'm not the only one with the problem. I do like to use the IP address occasionally and I'm not planning on adding this server to a cluster. I really want to ensure there isn't something a bit more sinister, I don't like to leave problems like this without understanding why they occur. –  BoyMars Jan 11 '10 at 12:03
add comment
up vote 4 down vote accepted

ok it would appear the problem is resolved after uninstalling KB968389 (ref) and then reinstalling again. this has had me stumped for a few months, i would never have guessed it was NTLM related...

to quote:

If you capture network traces while trying to access shared folders, you may see a response of Error, Code =(13) STATUS_INVALID_PARAMETER from the server for the session setup:

192.168.0.2 192.168.0.1 SMB:C; Session Setup Andx, NTLM AUTHENTICATE MESSAGE, Workstation: WRK001

192.168.0.1 192.168.0.2 SMB:R; Session Setup Andx - NT Status: System - Error, Code = (13) STATUS_INVALID_PARAMETER

This error code means that there is an issue with NTLM authentication. The update in KB 968389 introduces a new feature that enhances protection and handling of credentials when authenticating network connections by using Integrated Windows Authentication.

This behavior can occur if the update discussed in KB 968389 did not install properly. To correct the issue, please uninstall the update completely and then reboot the server. After the restart, you should find that the symptoms no longer occur. Reinstall the update from KB 968389 and restart the server again. The issue should not re-occur. You should be able to access all shares successfully locally and remotely.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.