none
Windows XP clients can't connect to Windows 2008 Server

    Question

  • Greetings one and all.

    I have a situation here at work that is getting quite annoying.  In a nutshell, for the past 2 days at roughly 9:30am, all my Windows XP clients loose the ability to connect to one (and only one) of my Server 2008 shares.  Here is the background.

    The server is a part of a stand-alone DFS cluster with no replication between the endpoints (not my design).  The server in question (we'll call it 040) is nearly identical to the other endpoint servers: Server 2008 R2, 8 gig of memory, 2 x CPU, running on VMware, No A/V installed.  The only difference between the servers is the size of the storage LUNS that they are attached to.  In this case (server 040), it is attached to 3 x 2Tb LUNS that are subsequently chained together (RAID-0) into a single 6T Volume.  It also has a single 80 gig OS volume and a 450 gig Shadow Copies volume.  All the servers were deployed from the exact same template and customization spec.  The VMware tools are installed and are version matched to the ESXi server (ESXi 5.0).

    The problem is that for the past 2 days at roughly 9:30am, the actual server itself becomes unavailable to only my XP clients - the Win7 clients can access without any problems.  When the problem is occurring, any attempt to access the server(\\040) from XP locks up explorer for a good minute or so and then finally returns a not accessible error.

    040 is a very busy server, the share it is holding is storing many many many engineering projects and CAD files.  It is in constant use.  It is rare for the CPU utilization to drop below 30% at all during the day (except maybe during lunch time); the CPU utilization generally hovers around 50%~60%.  There are probably 200-300 users constantly hitting this server.  Some of the software packages that are hitting this server: SolidWorks, UG/NX and Catia.

    A fix that has been tried is a Fixit I found on Microsoft that changed the packet size for Netbios packets (that didn't work).  so far, the only way to fix the problem when it hits is to reboot the 040 server.  Another fix that we tried that didn't work was to clear the packet cache and the MupMapping on the DFS root server (called 020). 

    When the problem occurs, the XP machines cannot access the 040 server file share at all - either through DFS or by direct access.  Ping by name still works as expected from the XP machines, returning the correct IP address and getting echo replies as one would expect.

    The server is on a static IP address and has the default NetBios setting enabled (NetBIOS over TCP when IP is static).  None of the other DFS endpoint servers are exhibiting this problem - then again, none of the other servers are seeing this sort of network/processor load.

    Does anyone here have any ideas on else to check or try to resolve this problem?

    Thanks!

    Ron

    Friday, June 21, 2013 4:42 PM

Answers

  • Ron,

    I understand, however we need to do some monitoring of this sort to understand what triggers the issue. Rebooting daily @ midnight to avoid the issue would not be a permanent case.

    Take some machines out for monitoring or schedule or manually run the tools on those few machines to monitor the issue @ that time.


    Regards, AnikG

    Wednesday, June 26, 2013 10:11 AM

All replies

  • Hi

    I does not think it's a packet size error, as it work, and for sudden it stop working.

    When the bug appear can you test to ping by the IP and the name ? I want to isolate if it's a lanman error or a DNS/WINS/ name resolution error that occur.

    If nothing work for the ping, please check the switch setup too.

    Thanks


    MCP | MCTS 70-236: Exchange Server 2007, Configuring
    Microsoft Translator Widget - French moderator (Technet Wiki)

    Twitter - @yagmoth555 ()
    Blog: http://www.jabea.net | http://blogs.technet.com/b/wikininjas/

    Saturday, June 22, 2013 2:48 AM
    Moderator
  • Yagmoth555:

    I guess I wasn't that clear: When the problem is occurring, ping by name and ping by IP address both work as expected.  It is not a DNS issue.


    Ron

    Monday, June 24, 2013 10:32 AM
  • Hi Ron,

    It doesn't look to do anything with the network configuration.

    There is something either on the server itself, or the XP machines (as you don't see issue on the Win7's) that is triggered at the (same) time you mentioned - kind of backup job or antivirus scan (daily update or scan) or file scanning job - by which the access to the server from Win XP machines gets locked up. Hereby, the behavior must be observer from the server and a couple of XP machines. You can set a perfmon counter on both - the server and the XP machines - for disk, memory and process to run with minimum interval say 3/4 seconds and analyze them to get info out of it.

    If you've any network monitor utility over your infrastructure, that might tell if any heavy traffic is caused over all XP machines to that server.

    As with ping, also check "telnet" to the server on port number 445.



    Regards, AnikG

    Monday, June 24, 2013 11:22 AM
  • Anik:

    I cannot test it as when the problem is occurring, I have about 50 engineers who are no longer able to work.  Management frowns on that sort of thing.  I also have a band-aid in place - I have a scheduled task running on the server every day at 3:00am to reboot the server.  This prevents the problem from happening.

    Ron

    Monday, June 24, 2013 1:33 PM
  • If the ping work and not the share then a service on your server might be faulty.

    AV blocking the access ? A remote computer scanning the server share ? etc..

    Please desactivate the AV to rule that out, and be sure your client AV does not scan network share.


    MCP | MCTS 70-236: Exchange Server 2007, Configuring
    Microsoft Translator Widget - French moderator (Technet Wiki)

    Twitter - @yagmoth555 ()
    Blog: http://www.jabea.net | http://blogs.technet.com/b/wikininjas/

    Wednesday, June 26, 2013 2:50 AM
    Moderator
  • Ron,

    I understand, however we need to do some monitoring of this sort to understand what triggers the issue. Rebooting daily @ midnight to avoid the issue would not be a permanent case.

    Take some machines out for monitoring or schedule or manually run the tools on those few machines to monitor the issue @ that time.


    Regards, AnikG

    Wednesday, June 26, 2013 10:11 AM