Re: Dropping Shared Connections (only)

Tech-Archive recommends: Fix windows errors by optimizing your registry



"+Bob+" wrote:

On Tue, 12 Aug 2008 08:04:09 -0700, LeftFoot
<LeftFoot@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

If I'm understanding your situation, it sounds as though you've proved that
name resolution is your problem.

I don't know if that's it... I'm no MS networking guru, but when I use
RDC I am using the server's MS network name, not a FQDM or IP...so it
looks like the MS names are still working(?)


Oh, okay. Sorry. I was guilty of making an ASSumtion that you were using the
server's IP address when connecting by RDC. I normally do that to multiple
domains via VPN so only use IP addresses with RDC most of the time.

Oh, and I'm not networking guru of any kind, either. I just plod along
trying to herd the thing along, you know? I sometimes get the feeling that
there are a lot of us on this particular prairie.

All systems member of same workgroup?

Yes

Are the IP addresses of all of these systems fixed, provided by DHCP from some
source like a router or a server (if server, the one with the shares?), or a
mix?

DHCP from a router, although the leases are long and they don't change
(certainly not while working). The server has a fixed IP assigned by
DHCP based on MAC.

So, it also sounds as though they're all on the same subnet. No complications
from that angle.

You are connecting to the server via RDP as an admin or as a TS user?
You have what kinds of accounts on the server / local workstation?

I'm not sure I understand the difference in RDP - you might have to
help me. The account I am connecting to on the server is an admin
there and I am an admin on the Vista client. The accounts match on
username and password. Are you asking a different question?

Yes, I should have stated my real question plainly. I wondered if the TS
connection was being made in admin mode (max. of 2 connections permitted) or
if
the server was running in terminal services mode. I was also wondering if you
had admin privs everywhere. Sounds like you do.


Worst-case scenario, as in you you have no admin rights to fix general
issues / make sure that NetBIOS over TCP/IP is working everywhere,

How to I get through the Vista friendly layer to see the actual
network software configuration? How do I test NetBIOS?

As a first step you can just go into the Advanced properties dialog for IPv4
to
see what NetBIOS setting it is using. From Network and Sharing Center click on
"Manage network connections" in the left pane. Right-click on your network
connection, and choose Properties. Double-click on the IPv4 protocol in the
list. Click on the Advanced button. On the WINS tab, look at the NetBIOS
setting.


you could
just creat your mapped drives using the IP address instead of the server
name.

I can try that and see if it helps.

Please let me know how that works out. But, now that I (think/hope) I am
clearer on your situation, I don't really think name resolution was the
problem after all.

If that's not satisfactory, maybe you could post back with an outline
with more information about the general network environment infrastructure
and your working relationship to it. That might provide enough information
for someone here to give more concrete suggestions.

Network is very simple as described above. Let me know what specific
info you need.

I think I may have almost everything I need to grasp the situation. See
below.


FYI - none of this is a problem with and of the XP or win2000 network
clients. The only oddity I have is that both XP and Vista have had an
issue re-establishing drive connections when returning from a long
term "lock workstation" state. The connections most always drop and
are difficult to re-establish without a reboot.

I'm not quite clear on what you're saying here with respect to whether or not
XP systems are affected. But it appears that a new element of information has
been added. From your first post I had assumed that the failure of the mapped
drive was happening while you were actively using the system, but this info
here has me wondering if this is only happening after the workstation has
been locked or has been sitting idle for a while. If that's the case, you may
need to check the power saving settings of the network interface on the
systems
which have the problem. Later versions of Windows clients have very aggressive
power saving functionality, and the interaction of this zealous green behavior
with some NIC drivers has unfortunate consequences. You might want to go into
the NIC's driver dialog and tell the driver to NEVER, EVER let Windows do
ANYTHING to save power with respect to that NIC. (Unfortunately, there's very
little standardization of the language used by vendors on this matter, so you
may have to do a little research with the manufacturer of the NIC to learn
your best bet for these settings.

Forgive me if I'm going off on a tangent here and this isn't the problem.
.

Quantcast