We run sbs 2008, and it's fully patched up.

Every now and again:

1) People have trouble viewing shared drives on it via a unc path but not a mapped path.

2) Opening and saving files causes the programs using them to hang for a few mins. After a while it kicks back into life.

3) When loging on to a comptuer on the network it can wait for ages before progressing to the desktop.

4) Emails don't get sent and then they suddenly do.

5)I get this error in the event log:

The processing of Group Policy failed. Windows attempted to read the file
from a domain controller and was not successful. Group Policy settings may not be 
applied until this event is resolved. This issue may be transient and could be     
caused by one or more of the following: 
a) Name Resolution/Network Connectivity to the current domain controller. 
b) File Replication Service Latency (a file created on another domain controller has  
   not replicated to the current domain controller). 
c) The Distributed File System (DFS) client has been disabled.

These problems come and go every few minutes until the server is rebooted. In the past a reboot would sort it for weeks but now it is happening in the same day.

There are no backups being run, and we have symantec endpoint protection 11 installed on the server but the last auto protect scan was several hours ago according to the stats.

anyone got any ideas what i can do to troubleshoot this?

4 Answers 4


Is this a Dell Server using Broadcom NICS. I assume so, since you mention TOE. Symantec endpoint does not work properly with these adapters, even if you turn TOE off.

I had the same problem on a Dell 2950 Win2008 - writing to the server via a mapped drive was OK (but only just OK), you couldn't browse any shares on the server from an XP client. Retrieving files from the server was virtually impossible - a 1k file copy took around 2 minutes. Remove Symantec - everything working perfectly again 100mb file copy from server to PC took only a few seconds, you vould browse the server shares, connect to a printer, etc.

My solution was to install Bitdefender and ditch the very average Symantec product. System runs perfectly with Bitdefender installed, with TOE enabled.

I think the problem is that Symantec does not install a driver/protocol into the network stack, whereas other vendors such as Bitdefender, Kaspersky, and possibly others do. Therefore when the packets are offloaded to TOE, BD, Kas, etc continue to work perfectly whereas the Lame Dog bounces the stack in and out of TOE rendering the system virtually comatose.

Since Symantec seems to have this architectural defect, I suspect it will never be able to work with any variation of TOE.

  • once the symantec stuff was uninstalled and rebooted. it was ok. Aug 24, 2009 at 10:49

That doesn't sound like a name resolution problem to me, what with all the symptoms you mentioned. It really sounds like poor layer-1 connectivity.

What kinds of other items are you seeing in the event logs on client computers and the server computer? Anything about network interface cards?

If you Ethernet switch has the capability, query the ports of affected client computers and the server computer looking for errors.

  • I can't query the switch it's not that clever! i can remote desktop into the server fine, does that make a difference? Jun 23, 2009 at 13:02
  • Do you have intermittent conectivity with Remote Desktop, too? You might try setting up some continuous PINGs of a large size and leave them run for a bit. I'm just getting a feeling, by your reports above, that you're having creeping infrastructure issues, and that troubleshooting higher in the layer stack is going to waste your time. You might try, from a client computer, a "PING -l 50000 -t <server ip or name>" and let that run for a few minutes. On a normal, uncrowded 10/100 Ethernet switch you shouldn't see anything more than 1% dropped PINGs like that (if any). Jun 23, 2009 at 13:21
  • i ran the ping test for half an hour and none were lost so i guess it's not that. the remote desktop doesn't cut out at all. Jun 23, 2009 at 17:27

I hate SBS, but that's really not relevant, I figured I'd just share it; beyond that;

Have you tried updating your network card drivers? SBS isn't anymore touchy than standard server with NIC cards but I've seen problems like this with old broadcom and intel gigabit adapters, and even with some 100mbit ones as well.

Have you ran DCDIAG and NETDIAG? This can also help you determine these sort of issues even with one server/domain controller

And the biggest, what version is Symantec at? I've had problems with an older update of 11 (MR3) and file shares on 2008. Its a problem with auto-protect malfunctioning and generally occurs on x64 but I've seen it personally on x86 based servers. Here is some more information -> http://www.symantec.com/connect/forums/mr3-locks-server-2008-file-shares

I believe there is a patch for it, but not sure. Most of my file servers are still 2003 because of this issue and I haven't had the time to research it yet.

  • nice try! we're on MR4. I've updated the NIC drives with no effect and turned off TOE. i've ran those tools but can't see the problem. Jul 14, 2009 at 12:10

Wild shot in the dark here but does anyone think this could be a system disk related problem? I highly doubt it is, but it looks like everyone else has mentioned the layer 1 level network infrastructure so I figured I'd skip ahead and see if the hard drive was a factor. Looks like a lot of I/O related problems. I'd look a the network first (of course), and then the NIC and then the hard disks. Are you using SATA/SAS/SCSI? Hardware/Software RAID?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .