Vista will not connect to closest DFS target

I have come across a problem with DFS that only occurs for Vista clients.
Windows XP and Windows 2003 (acting as a client) do not have this problem.

If the DFS Folder (Link) has multiple Targets, and site-based costing
(Lowest cost) is enabled, then the client is meant to connect to the closest
target based on AD Site costing. However, if the share that is the closest
Target has the Offline Files (caching) option "Files or programs from the
share will not be available offline" set, a Vista client machine will not
connect to this DFS target. Instead it connects to the target at a remote
site. I can replicate this problem at will with the following configuration:

- SiteA contains ServerA (Win2003 R2 with SP2) with a share DFStest. This
share has the Caching setting at the default of "Only the files and programs
that users specify will be available offline".
- SiteB contains ServerB (Win2003 R2 with SP2) with a share DFStest. This
share has the Caching setting changed to "Files or programs from the share
will not be available offline".
- Domain rooted DFS \\domain.local\DFS.
- Folder (Link) within this DFS: test, so the full path is
\\domain.local\DFS\test. This Folder has 2 targets
\\ServerA.domain.local\DFStest and \\ServerB.domain.local\DFStest.
- For ease of visibility, create a file ServerA.txt in \\ServerA\DFStest and
a ServerB.txt in \\ServerB\DFStest.
- Vista client machine in SiteB.

If you use the Vista client machine to connect to \\domain.local\DFS\test,
you would expect it to connect to \\ServerB.domain.local\DFStest and
therefore see the file ServerB.txt, but it does not. Instead it connects to
\\ServerA.domain.local\DFStest and you see the file ServerA.txt.

To verify that it is the setting "Files or programs from the share will not
be available offline" that is causing the problem I browsed away from this
share (click back on domain.local 2 levels above in the tree) and ran
"dfsutil /pktflush" to clear the DFS referrals, change the setting on the
share to "Only the files and programs that users specify will be available
offline", and browse back to \\domain.local\DFS\test again. This time I see
the file ServerB.txt as expected.

I first saw this problem in a client's domain (we are an IT Outsourcing
support provider). I then tried it in our own domain with an existing DFS and
found the same problem. I then replicated the problem in a fresh domain
created in a lab environment.

I read about the problem with Vista and DFS failover when a DFS root server
is unavailable in KB933860, and so have installed Vista SP1 in the hope that
it would also fix my problem, but it does not.

I read about the problem with DFS roots that is documented in KB944505 and
installed this patch on the relevant servers, hoping that it would fix my
problem, but it has not.

To further verify the problem I used Wireshark on a Vista client machine to
do some packet captures of this situation. When the share is set to "Files or
programs from the share will not be available offline", I can see the Trans2
response to GET_DFS_REFERRAL giving the DFS referrals in the expected order
of \ServerB.domain.local\DFStest and then \ServerA.domain.local\DFStest. It
then tries to connect to \\ServerB.domain.local\DFStest with a Tree Connect
AndX Request and gets the Tree Connect AndX Response, but for some reason it
does not use it (rejects it?) and instead makes a Tree Connect AndX Request
for \\ServerA.domain.local\DFStest, receives the Tree Connect AndX Response,
and proceeds to enumerate the files in the ServerA share with a
QUERY_PATH_INFO request.

When I change the ServerB share Caching setting back to "Only the files and
programs that users specify will be available offline" and do another packet
capture, I see it get the same DFS referral, do a Tree Connect AndX Request
and gets the Tree Connect AndX Response for \\ServerB.domain.local\DFStest,
and then instead of rejecting it, it continues on as it should with a
QUERY_PATH_INFO request on ServerB.

Has anyone else seen this problem and found a fix (other than changing the
share to "Only the files and programs that users specify will be available
offline")?

Since this problem is only happening with Vista clients, I think it is a bug
in Vista that will only be fixed with a patch. I have looked for a patch to
fix this problem, but have not found one. Therefore I am hoping that someone
from Microsoft will respond to this post, replicate the problem in their own
lab, and contact the right person to start the ball rolling on generating a
patch.

Thanks
Paul Whitfield