none
Network Share Drives Unaccessible Several Hours After Server Reboot

    Domanda

  • Hi All,

    My LAN has a server running Windows Server 2003 SP2 under file/print/application server roles. Our network was recently migrated to be a part of a large enterprise. After the migration, our network drives intermittently became inaccessible. I noticed the drives would become accessible again after a server reboot (a hard reboot unfortunately since our server literally takes hours to shut down, but that's another issue to address). The drives stay accessible for a few hours and then become inaccessible again.

    I have researched service pack 2 compatibility issues with network adapters on server 2003 (TCP Overstack, RSS, etc...), and performed the suggested actions from this site: http://blogs.technet.com/b/sbs/archive/2007/04/24/common-networking-issues-after-applying-windows-server-2003-sp2-on-sbs.aspx . Unfortunately, the issue was not resolved. The server also tends to freeze up intermittently when attempting to access Logical Disk Manager or Services.msc.

    Interestingly, when the issue occurs, the drives are still being shared out and accessible on the server (we have a SAN attached to the server via iSCSI, the file server shares the drive out to the network). I also attempted to run \\servername\sharedrive in Run, but received an error stating "Unable to access network location." This is a similar error users get when they attempt to re-map the disconnected drives. When the issue occurs, users also have to wait 5 to 10 minutes to log in to their workstations (the screen is black after logging in for 5 to 10 minutes, and then everything loads up).

    Please note that I am able to ping the server and RDP from any workstation on the network. From the server, I am able to ping the gateway. I was also informed by enterprise level administrators that our server is listed in the Print Server OU, which I think may be causing problems, however I am not sure if the server was recently added to that OU or has always been in the OU. I also found the following errors in the event logs: csrss.exe, winsrv was not found; and "A browser has forced an election on network NetBT_Tcpip{insert numbers/letters here} because a master browser was stopped"; but none of these errors occurred around the time of the inaccessibility.

    I look forward to your assistance!

    -Tim

    domenica 29 settembre 2013 08:00

Tutte le risposte

  • Try to resolve the slow shutdown first. Here may be source of your troubles.

    Use performance monitor to check wjat happens on your server and network monitor to check network traffic. More details are needed for problém analysis.

    Also analyze available logs, namely the event logs. I do believe here you will find more relevant information.

    Make sure that thare are no problems on active network devices like network switches and routers.

    Rgds

    Milos

    domenica 29 settembre 2013 09:37
  • Milos,

    What specifically should I be looking for in performance monitor and network monitor? I am very new to Windows Server administration, and unfortunately I have the most knowledge on Windows Server administration out of my entire shop.

    Our event logs don't provide any clues as to what is going on. There are no logged events when the share drives become inaccessible.

    When the issue occurs, I am still able to RDP to the server, so I would think the active network devices are good. Unfortunately, I don't have access to the switch/router software, I can only analyze by the link lights, and those look good.

    Our server is a Dell PowerEdge 2950, the clients are a mix of dell and hp workstations running Windows 7 Enterprise. What other details would you like me to provide?

    Also, thank you for your prompt response, it is much appreciated!

    -Tim

    domenica 29 settembre 2013 21:16
  • It may be a name resolution issue. You can confirm when you can't connect  \\servername\sharedrive try again with  \\ipaddress\sharedrive

     

     

     


    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows]

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    domenica 29 settembre 2013 22:16
  • Dave,

    I have attempted that during my troubleshooting, but it did not work. Earlier we performed the reboot and got drive access for our users, and it has been running strong for the past 3 or 4 hours (usually the drives become inaccessible by now). The main difference between today and other days this issue has occurred is that we had not remotely accessed our server. Would it make sense that this cause an issue?

    domenica 29 settembre 2013 23:52
  • Can we see an unedited ipconfig /all of both domain controller and problem client?

     

     

     


    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows]

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    domenica 29 settembre 2013 23:54
  • Well, I spoke too soon, the drives went back down. Unfortunately, I do not have access to the domain controller, it is the responsibility of a higher level enterprise administrator. What would be points of interest in the ipconfig /all on the server? I do know that it is set up for DHCP and automatic DNS.

    lunedì 30 settembre 2013 00:18
  • Make sure local DNS server has own address as primary and 127.0.0.1 as secondary (assuming only one DNS server) in network connection properties and is not multi-homed. Also put public DNS addresses as forwarders only on local DNS server. Client should have local DNS address ONLY so client can find and logon to domain. Forwarders are so clients can find and resolve internet queries.

     

     

     


    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows]

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    lunedì 30 settembre 2013 00:23
  • From my understanding, we do not have a DNS server in-house, it is somewhere else on the network, and again, something I do not have permissions/access to. From my findings, my server's DNS server IPs are on the same subnet as my workstation's DNS server IPs, but the last octet is not the same between the server and the workstation, there is only one IP that is the same on both, but has a completely different IP address than the other primary and secondary DNS addresses.

    I did notice in our event logs that McLogEvent was in there a couple of times when the drives became inaccessible (Event IDs 257, 5019). I also noticed we were running 78 processes, and McShield process was using a lot of memory. Other processes using a lot of memory were: sqlserver.exe, svchost.exe, system.exe, services.exe, and fcag.exe.

    I have my performace logs, but I am unsure as to how to view them...

    lunedì 30 settembre 2013 00:55
  • The LAN DNS servers could be on a different network. I've no idea on the Mc* events. You may need to ask in the MacAfee forums on those.

     

     

     


    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows]

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    lunedì 30 settembre 2013 01:00
  • We just migrated into a large, global enterprise, and that is about the time we started having the issues. I just can't wrap my mind around it being a DNS issue since the drives are accessible for at least 2 to 3 hours before they go inaccessible.

    After researching, the Mc* events don't really seem to be much of an issue. Another thing to note, is I am unable to access services.msc whenever this issue occurs...

    lunedì 30 settembre 2013 01:33
  • Now I have an even more confusing issue... Some people are able to access the drives, and others aren't. Everyone I have checked is under the same DNS server, same gateway, but different IP subnets. There doesn't seem to be a correlation between subnet and drive accessibility. The only thing I did was unshare the drive, and then reshare it, the effects occurred about 20 minutes afterwards. The only issue, is I am unable to open Microsoft Office files (error says "'Drive:\Pathname\Filename.doc' is currently in use. Try again later."). This is really starting to get strange.

    • Modificato timmc9104 lunedì 30 settembre 2013 03:00
    lunedì 30 settembre 2013 02:22