client: 2 * w2k sp4 (in domain)server: 1 * w2k sp4 (in same domain)problem:1. client logged in workgroup can NOT map to server by \\hostnamein START-RUN (system error 53 occurred, network patch could not be found.)2. client logged in workgroup can map to server by \\serverip in START-RUN (being asked to input username/pwd)3. 2 clients got the problem almost at same time.something have to say:1. no change on client and server. problem happens suddenly (it was ok 2 hours ago, but just appears...)2. server shared folder has everyone read permission (it's a subfolder like \\hostname\subfolder1\...\subfolderN), the test was only trying to access \\hostnamejust for simplification)3. client enable NetBIOS over TCP/IP4. all related services are all up and running on client/server (workstation, server servicesetc.)5. name resolution has no problem (local hosts file has the ip/hostname match, and ping test validated)6. port 445 is blocked between client and server7. sniffer capturing saying, 139 port initiated from client to server and get the error:SMBSession Setup AndX Response, NTLMSSP_CHALLENGE, NTLMSSP_CHALLENGE, Error: STATUS_MORE_PROCESSING_REQUIREDSMBSession Setup AndX Request, NTLMSSP_AUTH, User: %clienthostname%\%clientlocalaccount%Error: Status_Logon_FailureError: Bad userid8. during the troubleshooting period, another host C (in same domain, logged in domain account)has problem connecting to \\hostname either but was ok to connect to \\serverip, there is no failed authentication on destination server, no sniffer data supported so far.need expert help on more diagnostics.I could be very sure that it's not the name resolution or client/server service problem.but some question still confused me:1. if NetBIOS over TCP/IP is enabled on client. when client is initiating connection to either \\hostnameor \\serverip, both 445 and 139 port should be tried to connect to server, right? because 445 is by defaul blocked, but 139 should be through. and why we get the "network patch could not be found" error when trying \\hostname 2. for the sniffer data with "BAD userid". i'm still trying to figure out whether it was an attempt to a hostname or serverip. but anyway, it seems local account in w2k client has the problem to connect to a w2k server. it supposes that there is a pop-up window to ask for username and pwd. where is it?waiting for your comment. thanks:)

anybody can help?another thing i just want to confirm is...when the client is trying \\hostname mapping, suppose it's connecting to server's IPC$. in the test above, \\serverip can work (there is a pop-up window out for asking username/pwd)but \\hostname can not...what's the difference by connecting to IPC$ by server name and IP? it confused me....

hi there, based on your post you have implemented direct hosting feature, i would like to know is there a need to implement this feature ?what happens if you enable 445 and try access the shares.Would like to get few more tests done a) what is the behavior from windows xp to windows 2000 file server ?b) are you able to access shares using FQDN ?c) what is the behavior when you join the users to the domain ?the netmon / sniffer tracei am able to see the below packets. Error: Status_Logon_FailureError: Bad useridwhen implementing direct hosting though there is no VC ( virtual circuit ) established, the redirector sends a negotiate request using datagram .i would like to explain the authentication more in detail. Message authentication occurs during protocol negotiation and during user validation process, this gets applied to every message authentication and to every SMB packet passed. upon receipt the server will validate the message authentication , this behaviro is controlled using enablesecuritysignature", you could toggle this feature to check if the problem is resolve.dthe above feature is also called as SMB signing.sainath Attending Microsoft Teched 2009

hi there, based on your post you have implemented direct hosting feature, i would like to know is there a need to implement this feature ?what happens if you enable 445 and try access the shares.Would like to get few more tests done a) what is the behavior from windows xp to windows 2000 file server ?b) are you able to access shares using FQDN ?c) what is the behavior when you join the users to the domain ?the netmon / sniffer tracei am able to see the below packets. Error: Status_Logon_FailureError: Bad useridwhen implementing direct hosting though there is no VC ( virtual circuit ) established, the redirector sends a negotiate request using datagram .i would like to explain the authentication more in detail. Message authentication occurs during protocol negotiation and during user validation process, this gets applied to every message authentication and to every SMB packet passed. upon receipt the server will validate the message authentication , this behaviro is controlled using enablesecuritysignature", you could toggle this feature to check if the problem is resolve.dthe above feature is also called as SMB signing. sainath Attending Microsoft Teched 2009 Hi,the authentication we see from sniffer package is from a \\serverip SMB request (with 139 port request)while when trying \\hostname, only 445 port is sent out of the initiator.NetBIOS over TCP/IP is enabled, hosts file has the server ip/hostname entry. that is my best interest that why they comes to different result......do you have any idea on this phenomenon?

Hello D_Sr, Based on the research, Windows 2000 and later OS support file and printer sharing traffic by using the Server Message Block (SMB) protocol directly hosted on TCP (TCP/UDP port 445). In earlier operating systems, SMB traffic requires the NetBIOS over TCP protocol to work on a TCP/IP transport. NetBIOS over TCP traditionally uses the following ports: nbname 137/UDP nbname 137/TCP nbdatagram 138/UDP nbsession 139/TCP If both the SMB (direct-hosted) and NetBIOS over TCP (NBT interfaces) are enabled on the server, both methods are tried at the same time, and the first to respond is used. This allows Windows to function properly with operating systems that do not support direct hosting of SMB traffic. Actually the TCP 445 packet should always go first. This is why Direct Hosting of SMB takes priority under most circumstances. From the symptoms, it is very likely everything works with Direct Hosting of SMB over TCP/IP, but not with the NetBIOS over TCP. Please use the following steps to disable NetBIOS over TCP/IP; this procedure forces all SMB traffic to be direct hosted. 1. Click Start, point to Settings, and then click Network and Dial-up Connection. 2. Right-click Local Area Connection, and then click Properties. 3. Click Internet Protocol (TCP/IP), and then click Properties. 4. Click Advanced. 5. Click the WINS tab, and then click Disable NetBIOS over TCP/IP. For more information, please refer to: Direct hosting of SMB over TCP/IP http://support.microsoft.com/kb/204279 Hope it helps.This posting is provided "AS IS" with no warranties, and confers no rights.

Hi, thanks for your information. yes i believe both SMB and NetBIOS over TCP/IP are going to negotiate with destination at the same time.your method could help me on only SMB.but in my environment, only NetBIOS over TCP/IP is allowed to open. so my question would be still the same, why i can not see any 139 negotiation in the sniffer (note that the 139 traffic showed above is when i was trying to use \\serverip instead of \\hostname)Hello D_Sr, Based on the research, Windows 2000 and later OS support file and printer sharing traffic by using the Server Message Block (SMB) protocol directly hosted on TCP (TCP/UDP port 445). In earlier operating systems, SMB traffic requires the NetBIOS over TCP protocol to work on a TCP/IP transport. NetBIOS over TCP traditionally uses the following ports: nbname 137/UDP nbname 137/TCP nbdatagram 138/UDP nbsession 139/TCP If both the SMB (direct-hosted) and NetBIOS over TCP (NBT interfaces) are enabled on the server, both methods are tried at the same time, and the first to respond is used. This allows Windows to function properly with operating systems that do not support direct hosting of SMB traffic. Actually the TCP 445 packet should always go first. This is why Direct Hosting of SMB takes priority under most circumstances. From the symptoms, it is very likely everything works with Direct Hosting of SMB over TCP/IP, but not with the NetBIOS over TCP. Please use the following steps to disable NetBIOS over TCP/IP; this procedure forces all SMB traffic to be direct hosted. 1. Click Start, point to Settings, and then click Network and Dial-up Connection. 2. Right-click Local Area Connection, and then click Properties. 3. Click Internet Protocol (TCP/IP), and then click Properties. 4. Click Advanced. 5. Click the WINS tab, and then click Disable NetBIOS over TCP/IP. For more information, please refer to: Direct hosting of SMB over TCP/IP http://support.microsoft.com/kb/204279 Hope it helps. This posting is provided "AS IS" with no warranties, and confers no rights.