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

Discussion in 'Windows Vista Administration' started by Jason R. Coombs, Oct 31, 2007.

  1. 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

    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.

    Jason R. Coombs
    Jason R. Coombs, Oct 31, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.