One totally off the wall thought, how's the virus/malware/spyware scanning set up on each end - maybe someone is doing an on access scan while another client isn't, causing the different response times when opening up network connections and looking at those file systems/directories?
This may be totally unrelated, but I did some searching as we had some slow response issues a while ago and it ended up being some differences between NTLM versions in 2000, 2003, NT, Vista, XP, etc. We had to modify some of the parms. Anyway, these links are just some reads about this stuff and may give you some insight as to the trace you should see and traffic flow when trying to do a dfs browse, etc... W2k Startup and logon traffic Analysis http://technet.microsoft.com/en-us/library/bb742590.aspx Use of CNAME records for availability in DFS / Offline Files Integration http://blogs.technet.com/thenetworker/default.aspx File Session Traffic http://technet.microsoft.com/en-us/library/cc749905.aspx Anyway some good reading fo ryou... Don K ________________________________ From: Russ <[email protected]> To: NT System Admin Issues <[email protected]> Sent: Friday, July 10, 2009 12:32:37 PM Subject: RE: Slow DFS connections for windows xp users (and windows 2003) I meant this to go to the list, but replied back to someone directly by mistake...If anyone has any ideas, I'd love to hear about it! I actually have found that what I posted earlier doesn't really seem to have anything to do with anything. (It does happen just when you are browsing SMB, so it appears to be unrelated). However, I did get a capture where I had an established connection to a share using the DFS namespace (and just to clarify, I only have one DFS root server in this case, and I am browsing a share that only has one DFS target -- we are not replicating at this time) I started my capture, and then double-clicked on a folder -- I just got an hour glass, and then approximately 10 seconds later, the folder opened up. There were no packets in or out to either the target or the DFS root outside of the ICMP packets I was continuously sending during this time. The first packet captured was a "Tree disconnect request" to the DFS root from my machine, followed immediately by a "Tree Disconnect response" from the DFS root. So it looks like my machine was waiting for something during that period?? I don't know . .. at this point we are reluctant to roll DFS namespace further because of this weird slowness issue... Thanks, Russ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
