Weird share behavior

  • Thread starter Thread starter Dan DeRemer
  • Start date Start date
D

Dan DeRemer

I have a network of 5 domain controllers all running W2k SP4 in Active
Directory with 2k/XP clients. The servers are spec'd similarly since
they are Dells and were purchased in a relatively small timeframe from
each other. The problem I am having is that we run a log on script
that sets up the users mapped drives in accordance to what group they
belong to. These groups are strictly relating to which office these
users are working at. So office 1 would have a share folder on their
server as their Q drive and the other servers are other letters. One
of our offices shares out a folder named "Shared", both the shared
name and the local folder name. Now every so often, the mapped drive
will disconnect and you can't access the share via network places or
by typing in the UNC name. Now if you type in the server's IP as the
UNC name and then the share name (ex. \\1.2.3.4\shared) then you can
reach the share.

Now, when their drive that points to this share (Q:)goes out, I can
unshare it and then reshare it but I have to do it forcibly. I can
unshare it in the sharing properties and it will give me a
confirmation box stating that there are x amount of users accessing x
amount of files and that unsharing will disconnect them. When I click
yes, it goes back to the properties sheet but it is still not
unshared. When I try to click the Stop Sharing button, I get a message
stating "An error occured while trying to delete share Shared. The
shared resource does not exist." I have to then go to the local folder
and rename it to remove sharing. Then I share it back the way it was
and then the users can get back to their network drive (Q:). I'm
stumped and I was wondering if anyone out there has had the same
problem or something similar. Please share any info that could even
slightly help me resolve this problem because it is getting annoying
to have to unshare/reshare this folder 3-5 times a day. Thank you all.

-Dan DeRemer, Administrator
CC&J Law Group
 
The fact that the connection works when you refer to the server by IP vs.
host/netbios name suggests that you have a name resolution problem. Try to
ping the offending server by name and by IP when the problem happens. If by
name fails and by IP succeeds, that's verification. Then you can chase down
the name resolution bug...probably DNS. Is the server name registered at
all with DNS? If not, why not? It prob. doesn't use DHCP, so it prob.
dynamically registers itself with DNS (but only those server listed in its
DNS settings for its NICs). You could add a static registration if the IP
address is static. WINS should be self-configuring, but there are often
problems with name res. on servers with multiple NICs on multiple subnets.
Check its registrations in WINS and delete any that are wrong; don't worry,
if they're legit, they'll reregister.
 
Back
Top