I've encountered a performance problem with the Windows 7 SMB client connecting to a third-party SMB server that does not support the \srvsvc named pipe. With Windows XP, saving a new XLS file (with Excel 2003) through a UNC path to the server works normally. However, Windows 7 appears to get hung up on the fact that the SMB server doesn't support the \srvsvc pipe, and goes into some strange retry loop for an unspecified amount of time before the file finally saves to the share. Here is a link to some Wireshark captures I've taken of the 'normal' behavior on my XP machine and the delays I see from the Windows 7 machine: http://docs.google.com/leaf?id=0B_QEFXuvDOmmODBkYTdhMjYtNjJiYy00MWRhLWFhODAtOWUzYWJiZjhmMWZk&hl=en Any input on what can be done to make the Windows 7 client behave more like the Windows XP client would be appreciated.

Hi, Based on my research, I would like to suggest the following: 1. Check if the issue also occurs when you access the third-party SMB server or copy some files to it. 2. Adjust the security setting on the Windows 7 computer: 1) Click the Start Button, type "gpedit.msc" (without quotation marks) and click OK. 2) In the "Group Policy" window, double click on "Windows Settings" under "Computer Configuration". 3) Double click on "Security Settings"-> "Local Policies"-> "Security Options" 4) In the right panel, double click on the "Network Security: LAN Manager authentication level", please select "Send LM & NTLM Responses". 5) Click Apply and OK. Considering this issue is related to the third-party SMB server, please also contact the support of the third-party SMB server for help. Hope this helps. Thanks. Nicholas Li - MSFT

The Windows 7 security policy is already set to "Send LM & NTLM Responses" and the machine has been rebooted since making the change. The Windows 7 client still displays the same behavior. I have been in contact with the support for the third-party server, and that is how I was directed to the client side. I understand your reluctance to get involved with an issue involving a third-party server, but I can assure you that the traces I linked in my original post show the Windows client causing the delay. The server side is promptly returning an error to the client on its attempt to open the \srvsvc pipe, and the client is showing delays in resuming SMB requests ranging from a couple seconds to over 10 seconds. I either need the rationale for the delay on the client side, a client setting to change to make the delay go away, or something concrete to take back to the server vendor to point out the problem.

We're having the exact same problem. I've applied all the IBM recommended changes and nothing has made a difference. Our server is a System i 9406-520. IBM Netserver support group ran a trace on one of the problem PCs. Here is the response I received from IBM. NetServer development has reviewed the trace and found that this is a case of the Windows client spending a lot of time trying to access /srvsvc. Windows attempts to open a named pipe (\srvsvc) that NetServer does not support. NetServer returns a normal OPERATION_NOT_SUPPORTED error, It appears that the Windows side is doing some sort of delayed retry of an operation after NetServer returns to error on the connection to \srvsvc NetServer development has also tried doing some changes in their code so that they return an access denied or file not found error, hoping that Windows 7 would handle it differently, but results did not change. Here's what I can find about srvsvc. This all came from a Google search and not from a Microsoft site, so it is word of mouth only. Srvsvc (C:\WinNT\system32\srvsvc.dll) is part of SMB (Server Message Block) and CIFS(Common Internet File System) protocols used by windows. One online source says it is a 'file system driver' and that it supplies connections that are requested by redirectors on the client side and gives them access to the resources they request. It sounds like it passes both requests and data. From several traces we've seen, it appears the XP client accepts the failure to connect to \srvsvc and falls back to some classic LANMAN flows to get the information it wants, whereas the Windows 7 machine does not. It is valid for a file server to reject the \srvsvc call as is done by NetServer and ultimately Microsoft's code, which is issuing that call, needs to better handle the failure. I would be happy to work with someone from Microsoft to try to gain insight into this problem. I agree - Microsoft needs to come up with a solution to this problem. Our XP and W2K PCs work fine. Windows 7 has a major problem.