Troubleshoot intermittent problem accessing network drives and other resources

We have a simple Windows 2003 network, using SBS 2003 as the domain controller, with a couple of other servers running Windows server 2003. The clients are Windows XP, and most users have three network drives – two mapped to shares on the SBS 2003 server, and another mapped to a share on a standard 2003 server. These network drives are mapped using a logon script.

Recently we have had problems with a couple of clients, where the network drives linked to the shares on the SBS 2003 DC are being disconnected. Approx. twice a week. Sometimes, these drives simply reconnect without any action. Or sometimes the user has to logon/on to reconnect. But today, even after rebooting the client, I couldn't reconnect the drives to the DC. Then a few hours later all was ok.

After the machine was rebooted, and I tried to remap the network drive on the DC, I can see all the shares on the DC. But when I select the share, and try to map the drive, the screen hangs for a few minutes, and then the access to the DC becomes unavailable and I get “unknown path” and similar messages, and I can no longer browse the shares.

It is as though the connection is so unresponsive that the client considers that the DC is not available. Another problem is that these clients are in a branch office connected via a LAN extension. So, the latency of the connection between the client and DC is quite high – about 12ms. Although there are lots of clients in this branch office which work perfectly well – if a bit sluggish. Is there some TCP/IP setting I should be looking at?

Also there is no problem browsing or connecting to the shares on the other servers, or other clients in the network.

This only happens on two clients, out of about 30. However, these two clients are shared machines. Also, I suspect that sometimes users find the machine logged on as someone else, and just power it off/on to get access.

I would guess that I might get things fixed by removing and adding the client to the domain. But, I’d like to stop these problems happening again. So, I’d like to find out exactly where the connectivity problem is.

There are no obvious messages in the event logs of either the client or the server. Except that the client complains that it can’t get the group policy from the DC, which makes sense if it can’t connect.

The other change was a few months ago we installed Symantec End Point anti-virus. But, this is the same for all clients, and most work fine.

Any pointers would be appreciated
Who is Participating?
Hypercat (Deb)Connect With a Mentor Commented:
Since this problem is only affecting 2 workstations, the most likely cause is, as you mentioned, the computer accounts on the network.  When a computers trust with the domain controller on a network is corrupted in some way, the symptoms you described are common. And unjoining and rejoining a computer to the domain is a pretty simply series of steps in terms of troubleshooting these problems. So, here's what I suggest:

1.  Unjoin one of the workstations from the domain.
2.  On the SBS server, go into AD Users and Computers and DELETE the computer account manually from there.
3.  Reboot the workstation and log on as a local administrator.
4.  Rejoin the computer to the domain from the workstation side.

Once you've done it on one of the workstations, you can test by comparing the behavior of this workstation against the behavior of the other one.  If the rejoined workstation seems to have a stable connection to the server after following those steps, then you can simply do the same for the other workstation.

As far as having these problems happen again, this is something that is not that uncommon on older workstations, especially those that may have been abused a little (i.e., force rebooted by turning the machine off instead of a normal restart). There's not really anything you can pinpoint that causes the deterioration as far as I've ever been able to determine; it's just in the nature of the beast.
DJOBKAuthor Commented:
Thanks for the advice hypercat. I'm going to visit the branch office tomorrow and try this out.

Apart from comparing the performance of the two clients (once one has been fixed) is there any other evidence I can look for to confirm that this is a problem with the trust between the DC and the client? For example, shouldn’t I see something in the security event log, or something similar?

It's the possibility of re-occurrence that really bothers me. Staff come in early, at about 7.30am, to prepare reports for the daily management meeting at 9am. So, if the clients which run the application to generate the reports are out of action, the whole business day gets delayed. If I can't get a robust solution, I'll need to ask the IT staff to work shifts.

Would there be any advantage is setting up a common logon for these shared clients? So, we didn’t have multiple users sharing these clients?  I’m not that keen on staff sharing an account. But, that would be better than having these problems.

Also, do you think Windows 7 might be more reliable than Windows XP?

Or, what about if I force a logoff overnight so that the client is ready for the user first thing in the morning?
Hypercat (Deb)Commented:
>>Apart from comparing the performance of the two clients (once one has been fixed) is there any other evidence I can look for to confirm that this is a problem with the trust between the DC and the client? For example, shouldn’t I see something in the security event log, or something similar?

Unfortunately, it's very infrequent that you'll see something as straightforward as an event log error in these cases. The good thing is that if redoing the computer's domain account fixes the problem, it's likely to stay fixed for a very long time. You shouldn't have to worry about a recurrence in the near future, as this is something that doesn't really happen all that often.  If it doesn, then the likelihood is that there's something else going on, like hardware issues, that is causing this to happen.

I agree with you that having users share a logon ID is generally not a good idea.  However, a lot depends on what these users are doing.  If they have pretty restricted access to the network and only perform a few functions, then there's less exposure and fewer potential issues with users sharing a login ID. Usually the biggest problem with these arrangements is that users have different access needs, email accounts, etc., which really can't be accommodated with a common logon.

Your idea about forcing a logoff overnight has merit - if there's a period of time when the computers are idle, that would be a good time to restrict access and force the logoff to try to avoid these problems.

I definitely feel that Windows 7 is more reliable than XP in these areas - I used to have similar problems to yours occasionally in the XP days, but I have to say since most of my clients have upgraded to Vista or Windows 7 I haven't seen this happen even once that I can recall.
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

DJOBKAuthor Commented:
When I arrived on site, it turn out that only one client had a problem with network connections. The other had a hardware problem.

Unfortunately the machine with the network problem was working fine. However, I still removed it from the domain and added them again.  It had a sticker on it with the instructions "If the PC is frozen, unplug the power cord, replace it and restart". So, it's had a hard life. I decided to create a common login, with limited access, to minimise the need for early starters to force a reboot.

The last two days have been fine, and I'll be upgrading this machine to Windows 7 within the next few months. So, hopefully they will behave until then....fingers crossed.

Thanks for all your advice
DJOBKAuthor Commented:
It was an intermittant problem and only time will tell is the solution works long term
Hypercat (Deb)Commented:
You're welcome - good to know you're going to be rid of this in a few months, I'm sure.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.