XP Slow after implement DFS

Discussion in 'File Systems' started by Dave Mills, Apr 26, 2006.

  1. Dave Mills

    Dave Mills Guest

    I am not sure if this is DFS of not. I do not think DFS is the route cause. But!

    I have set up a DFS namespace - no replication.
    I have used the namespace to map network drives to the same UNC as was being
    done before via the DFS referrals.

    One of the DC I suspect is having problems as I have been getting sudden network
    disconnects for months. This has been happening for Mapped drives and for MMC
    connections via a UNC name. It connect OK again to UNC shares on a retry and in
    the MMC after a short delay. The machine is slated for upgrade to W2003R2 asap
    but is at present W2K SP4.

    My problem is that since I implement the Mapped drives via DFS (on R2) namespace
    the XP SP2 client keep having fits of going very slow for about 15 seconds then
    working for a few minutes then slow again. Most noticeable in Windows Explorer.
    Home drive are failing to connect about 10% of the time. Other symptoms too.

    My question is that given the above would Windows Explorer's DFS client cause
    this repeated slowness if the DC it is using in going nuts. I would expect it to
    be slow in the referral but then the referral to be cached for 30mins. So why
    every 3 to 5 mins. There are about 8 mapped drives - would that explain it.
    Dave Mills, Apr 26, 2006
    1. Advertisements

  2. Hiya Dave,

    It sounds more like an SMB issue than a DFS one - a network trace will give
    us the straight answer in either case. Since the referral is cached as you
    pointed out, we should not try to build another set of PKT for DFS for 1800
    seconds. That leaves SMB-related network issues as the likely cuplrit.

    One the client (once you have netmon or your packet analyzer of choice
    installed, and the 2003 support tools installed) you would want to:

    ipconfig /flushdns
    dfsutil /spcflush
    dfsutil /pktflush
    start capture
    connect to the namespace as would a user, letting the weird bad stuff happen
    stop capture
    examine trace for TCP resets, SMB session setup errors, SMB tree connect
    errors, etc. If you want to share out your trace somewhere or attach it (if
    really small) we can dig a little further.


    Do we have gigabit network drivers on the servers we're connecting to as
    Just to confirm - there's no 2003 SP1 servers operating as targets currently
    that might be affected by KB898060?

    Ned Pyle \(MSFT\), Apr 27, 2006
    1. Advertisements

  3. Dave Mills

    Dave Mills Guest

    Thanks Ned, See comments inline

    I will have a look with Netmon on my workstation. May need a little help with
    interpreting the trace though.

    Mapped drives are to servers WCS (W2K DC), WIZ (R2 Member and DFS Root), SIM
    (W2003 SP1 Member)

    net use r: \\waingels\storage\resources (target = \\wcs\resources)
    net use W: \\waingels\storage\reports (target = \\wcs\reports)
    net use s: \\waingels\storage\photos (target = \\wcs\photos )
    net use G: \\waingels\storage
    folder Sims (target = \\sim\sims )
    folder AdminShared (target = \\sim\adminshared)
    folder ICT_Support (target = \\wiz\ICT_Support)
    folder MSI_Packages (target = \\wiz\MSI_Packages)
    net use p: \\waingels\storage\public (target = \\wcs\public)
    net use N: \\waingels\storage\common (target = \\wcs\common)
    net use T: \\waingels\storage\setup (target = \\wiz\setup)

    net use H: %homeshare%\%username% (Target varies between \\WCS, \\WIZ and
    \\SIM). The H: mapping done during login fails about 10% of the time at random.

    I was wondering if the DFS referrals needed for the above would spread out in
    time and thus the 1800 seconds timeout would happen every 3 to 4 minutes on
    average and potentially hit the WCS (DC) causing the observed symptoms that it
    all hangs at the client especially Windows Explorer until WCS responds. The
    whole thing feels a bit like what happens when you try to open an invalid UNC
    and Explorer stops responding while it does the network lookup and fails.
    Maybe but they are all operating at 100MB. We have a major office relocation due
    in August and all Servers will move then. I plan to go 1GB backbone at that
    All systems are fully patched to latest using WSUS and it is a single subnet -
    no routers only Layer 2 switched. About 500 PCs total. So it looks to me like
    KB898060 is not an issue.
    Dave Mills, Apr 27, 2006
  4. Hi Dave,

    Weirdness. The list re-sorting every 3-4 minutes wouldn't make sense.
    Besides the network trace, you can also (as you test each net use command):

    reboot client
    dfsutil /pktinfo > some_file1.txt
    logoff, logon
    dfsutil /pktinfo > some_file2.txt
    logoff, logon
    dfsutil /pktinfo > some_file3.txt

    All on the same client PC.

    My theory is that while the referral list will stay the same for the next 30
    minutes (same order), there is some network problem between client and
    server that causes it to connect to the next server down on the list (or up
    the list) each time you are reconnecting to those drives. The output files
    above may show us moving the (ACTIVE) entry between servers - this should
    not be happening ordinarily.

    If you have ms06-007 installed on everyone (from WSUS) TCPIP.SYS should not
    be an issue.
    The GB NIC's are a driver-level issue, not a speed issue - they can have big
    UDP fragmentation issues that hork up Kerberos and cause issues like this to
    occur. If your NIC drivers on clients/servers are GB and are more than a
    year old, they'd be suspect.

    Let me know what you find,


    Ned Pyle \(MSFT\), May 2, 2006
    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.