Files / Folders Delay on Network Files

[soveryapt]

Morning All!

 

Right, interesting problem and whilst I search, I just thought I'd see if anyone has any suggestion on here too.

 

When users are saving files / creating folders on the network drives, they don't show up straight away. A quick press of an F5 (or right-click > refresh) will make the folder show, but this can be a bit of a PITA as staff will report files missing, when in actual fact it's this issue.

 

Any possible suggestions?

Ta

Andy T

[Quackers]

We are having this too since with put SP1 for Windows 7 on over the summer.

[soveryapt]

We are having this too since with put SP1 for Windows 7 on over the summer.

 

You know, I hadn't even spotted the correlation there, but I went to SP1 too .. right .. time to start the trawl of the Microsoft TechNet then .. lol ..

[cromertech]

I've had this too. Didn't really think too much of it but it does correlate to the SP1 install. I'll race you for a solution . In any case will the "winner" please post answer for the rest of us?

[SYNACK]

Have you tried using the full DNS name of the server for the UNC \\server.domain.internal\share SP1 and 2008 R2 seem to suck at non fqdn lookups in some situations might be trying using WINS/NetBIOS which seem to take much longer than before.

 

Have noticed simmilar issues with domain DFS roots where it takes a while after logon for \\domain\dfs\share to be resolvable but \\domain.internal\dfs\share seems to be resolvable much earlier.

[Michael]

I think Synack's onto something here as I haven't seen this problem. 2008 R2 SP1 with 7 SP1 clients.

 

Are your shares DFS shares or standard shares?

 

I do agree also that 2008 R2 does definitely favour the FQDN.

[soveryapt]

Mine are all FQDN (\\broadfield.school\shares for instance) .. hmm ..

[Michael]

How many VLANs do you have setup?

[SYNACK]

Have you tried using the full DNS name of the server for the UNC \\server.domain.internal\share SP1 and 2008 R2 seem to suck at non fqdn lookups in some situations might be trying using WINS/NetBIOS which seem to take much longer than before.

 

Have noticed simmilar issues with domain DFS roots where it takes a while after logon for \\domain\dfs\share to be resolvable but \\domain.internal\dfs\share seems to be resolvable much earlier.

 

Additional to this I found that netBIOS is ultra slow under 7 SP1 and tried adding a dns CNAME for the netbios name to DNS so if your domain is domain.internal then you add a cname under it making a domain.domain.local which points back to domain.local. This is hit by the netBIOS lookup first and seems to point it to the right place nice and quick seeming solving the issue.

[Chuckster]

@synack, when creating the new CNAME do you insert the FQDN in the third field or do you leave it blank as it already has the FQDN in the second field?

 

My NetBIOS name is 'NETWORK'. At the moment it is reading network.schoolname.internal as I left the third field blank when creating the CNAME record.

[SYNACK]

@synack, when creating the new CNAME do you insert the FQDN in the third field or do you leave it blank as it already has the FQDN in the second field?

 

My NetBIOS name is 'NETWORK'. At the moment it is reading network.schoolname.internal as I left the third field blank when creating the CNAME record.

 

That should also work as it will just use the record from a level above which is what you want anyway. Can't quite remember the exact layout of the dialogue box but the last one should be the FQDN which as you rightly point out should be automagicly inserted if you just leave it blank anyway.

[SYNACK]

For further refference:

How to configure DFS to use fully qualified domain names in referrals

windows - Long pause when accessing DFS namespace - Server Fault

O

 

Later versions of Windows hate NETBIOS name resolution for DFS.