Vista AD Member - Explorer non-responsive when 445 traffic dropped

I originally posted this as a response to an older message; I'm posting to
its own thread now to encourage a response.

I experience unresponsiveness (also could be seen as slowdown) after joining
my Vista machines to the active directory. I experience it particularly when
I take an
AD-joined laptop and carry it to another location, such as a friend's house
or coffee shop. When I do this, and the provider (e.g. Comcast or T-Mobile,
because I know the problems occur there) blocks port 445 outgoing, the
symptoms will arise. In particular, any function that requires interaction
with Explorer (.exe) will take 30-90 seconds to complete. This includes, for
example, saving a downloaded file using Firefox. Because Firefox integrates
with Explorer to save files (I think to render the icons), when I try to save
a file using firefox in this environment, the download will block for 30-90
seconds before proceeding.

It seems to be that Explorer is blocking to perform some sort of Active
Directory action which requires port 445 (microsoft-ds) on which to
communicate. Explorer resolves a name for the AD action but must wait for
the TCP timeout to occur before returning control to the calling application.

I don't use isolated DNS, so my Active Directory DNS is visible from any
host on the Internet. I can see in other deployments why this symptom would
not arise -- because if the DNS were isolated, the host would not have an AD
server to attempt a connection, and thus would not have to wait for the TCP
timeout.

I would not be feasible for me to put an AD server at every location,
because I have about 2 PCs per location, so it's also difficult for me to
isolate the DNS.

This problem occurs with or without roaming profiles. It occurs on brand
new Vista machines recently joined to the domain. This problem also
exhibited itself to a lesser degree in Windows XP.

One work-around that often works is to establish a VPN connection to one of
the domain controllers. In this way, microsoft-ds traffic can pass
unobstructed, and the problem goes away immediately. Unfortunately, it's
cumbersome to instruct other users to establish a VPN connection to keep
their machine from becoming non-responsive.

This to me is clearly a design flaw or design oversight, or possibly just an
unsupported configuration.

I've applied all Windows Updates as well as kb941649, but the behavior
remains the same.

I would very much appreciate any suggestions for alleviating this problem.
I'm also happy to provide additional details if a Microsoft rep takes
interest in reproducing the problem.

Sincerely,
Jason R. Coombs