[JCSwengros]

When navigating DFS shares from a terminal server session, windows explorer runs slow and hangs w/o any error messages. this issue appears when using "back" or "up folder" in windows explorer (after 2 or 3 folder changes)
and some times the delay is so bad that when you add a new file or folder it wont appear on your screen until you exit the share and then re-enter the share.

Navigating via \\servername\sharename runs longer than navigating via \\Namespace\Sharename, before hanging up windows explorer (but not much)

I have (2) Win2k3 r2 x64 DC's / File servers running DFS-R
and (2) Win2k3 r2 x64 Terminal servers

this issue does not appear on XP-Pro PC's whether browsing via \\servername\share name or Nameshare\sharename

I would chuck DFS but they want to use it to manage shares between multiple sites
I have tried using traget shares vs folder shares, sharing files off the Terminal servers, removing replication... nothing helps

[]SK[]

Clients are configured to talk to a DNS server on the network? The servers are also pointing to the same DNS? AD Sites and Services is configured correctly with sites and subnets etc?

I think the DFS namespaces are mapped to the user depending on what subnet their computer is on.

[JCSwengros]

A/D is correct, clients are thin clients but I'm testing on the 2 Terminal Servers via RDP. std file shares do not have this issue and navigating to the DFS share via Sername works better but still freezes the screen.
It's got to be something to do w/ DFS. I even turned off replication and it still freezes up windows explorer

[]SK[]

I've used DFS-R at alot of places but never encounted this issue. If you right click on the network drive > properties > DFS when its running slow on a machine can you see if the machine is connecting to the correct local server?

[Marktd]

greetings all,

have just fixed this issue by applying patch from KB925066 after logging a call with MS on Monday.

This has fixed the issue with our Citrix farm of 4 servers, and the staff are happy again. very hard to diagnose as initially we thought it may have been a Citrix / TS issue!

Hope this helps.

Mark