Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a Windows Server 2008 R2 installation that is acting as a DC. It has been operational without any problems since late August. All of a sudden, UNC share access experiences an issue where no-one (clients or the DC itself) can access the DC's shares. A reboot of the computer resolves the issue for a minimum time 24-hours, at which time UNC fails again. When this occurs, DNS appears to be fine, routing is fine, I can remote in the server by its FCDN, etc. There are no log entries that really indicate that there is a problem until clients and even the DC itself try to refresh Group Policy, which is accessed via a UNC share.

I realize that details are scant, so if you have any troubleshooting information I can go dig up and post, I would appreciate it.

share|improve this question
    
Are there any ACLs between the DC and the clients? –  MDMarra Oct 17 '09 at 0:46
    
Not that I am aware, but the DC itself has a problem accessing its own shared through the domain unc. For example, \\domain.local\sysvol is inaccessible. –  Wayne Hartman Oct 17 '09 at 1:29
    
Can you browse to UNC shares on other servers when this happens? The 24-hour span seems to indicate something like a DHCP/DNS entry expiring, or a service is leaking memory, reaching a point where it eventually crashes. –  mpeterson Oct 17 '09 at 18:14
    
Are you running Symantec Enterprise Security 11 by chance? –  GregD Nov 12 '09 at 2:32
    
does '\\localhost\share' work? –  ITGuy24 Nov 12 '09 at 21:36

9 Answers 9

"Windows Server 2008 network shares may become unresponsive with Symantec Endpoint Protection 11 or Symantec AntiVirus 10.2 client installed and Auto-Protect enabled."

From here.

share|improve this answer
up vote 1 down vote accepted

Have been conducting my own additional research and found this article:

Windows 2008 Server Network Connectivity Problem:

Here was the symptom – Everything would work fine for at least 3 hours, sometimes close to 24 hours. Then everything would start to go screwy. Computers would start to drop off the network like flies. The sysvol share would become inaccessible to anyone on the network (including the server itself.) ... Rebooting the server would make the errors and problems go away for a while, but within a day, the problem would be back. ... This symptom is caused by a flaky network card driver.

I noticed my drivers were the Microsoft installed versions. I also found that my NIC manufacturer had more specific (and recent) versions of the NIC drivers, so I have loaded those. It has been a few days; so far so good. I'm not calling this one solved, so we'll see what the next few days bring...

share|improve this answer

Any updates applied about the time it started having this trouble?

share|improve this answer
    
Last updates were applied at the end of September. –  Wayne Hartman Oct 17 '09 at 3:35

Did you adjust the server clocks for Daylight Savings? You might be off by an hour.

share|improve this answer
    
This was occuring long before the time change. The time is correct. –  Wayne Hartman Nov 12 '09 at 13:03

Please define "no one can access". What is the exact error message/problem....permission denied, shares not visible, server not found, etc?

In your example \\domain.local\sysvol being inaccessible, is DFS in use?

Have you done the previously suggested test of \\127.0.0.1\Share from the server itself?

share|improve this answer
    
'No one can access' means that no clients, nor the server itself, can access UNC shares. There is no error in the logs, save a Group Policy error, saying that it cannot reach the group policy settings stored in the UNC share \\domain.local\sysvol. I have had to do some reboots on the server to do my own troubleshooting, so the error has not yet resurfaced to try the local host share. I would suspect that it would fail because it cannot reach the \\domain.local\sysvol. I will try, however, if/when the problem resurfaces again. –  Wayne Hartman Nov 14 '09 at 1:45
    
In light of what you just said here Wayne - check your AD DNS (advanced view in DNS), I bet that your DC registrations are either missing or wrong. –  pauska Nov 17 '09 at 22:53

This might seem obscure since you can do pretty much everything except SMBFS on the server, but - have you tried moving the server to a different switch port? A confused switch ARP stack can create many weird problems. I've had similar problems before (especially when doing trunking), and my only solution was to hard-reset our switches.

share|improve this answer

The Server service allows shares to be accessible. So you indicated that the server service is up and running and that client and the DC itself cannot connact to the shares.

Do you have a firewall configured? if the clients cannot connect to the shares you could try portqryv2 on the server itself to confirm that the ip ports are open, these ports are 137,138,139, and 445. Is NBT enabled?

Is the DC internet facing?

Also try turning up the logging to find out if there are any errors you're not specifically picking up. It could be that you have a virus which may be causeing a buffer overflow on the TCP stack.

share|improve this answer

Check that following services are up and running on the server:

  1. netlogon
  2. server
  3. computer browser

They should be dealing with sharing...

EDIT:

Try to check also all dependences to Network Discovery, like:
* Function Discovery Resource Publication
* SSDP Discovery
* UPnP Device Host

share|improve this answer
    
I will check this out when the problem occurs again. –  Wayne Hartman Nov 12 '09 at 13:04
    
Those service appear to be working fine. I restarted them for good measure when it exhibited the problem again. No dice. –  Wayne Hartman Nov 12 '09 at 22:17

What does the output of "net share" say when you run it from the cmd.exe?

Are all the shares which should be there actually appearing?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.