Losing LAN connections/browse PDC gives Specified network name is no longer available

Hi there

Have a huge issue at a workplace that I have been drafted in to solve that is driving me insane for 3 days. The previous IT guy in charge left some time ago and so the company has had no network/IT support in the meantime, and there are no handovers of any kind. What a great start! I would really love some help on this one; as of issues described as above i haven't fully got to grips with the network setup and so me myself and I have really been thrown in right at the deep end.

The main issues on this 100-150 node LAN is that all clients (Win2k and WinXP) are losing their connection randomly to their shares if an explorer window of that share or an app on that share isn't left open (regardless of leases expiring etc) The WinXP machines can resolve this issue fairly easily by using the Repair network function. The Win2k machines don't have this; a dodgy batch file on some of these machines occasionally does the same thing, but has never worked for me when I've tried. Shared printers which are connected directly to client machines via USB randomly drop away too. One minute they appear Ready, next they appear offline.

The majority of machines I've seen have been given Auto IP addressing on the client and then given a fixed IP address by the DC in the DNS settings. Some of these appear to conflict which is a bit worrying and I have already ensured each machine is now given one unique IP address. (First sign of trouble).

The Win2k machines have been a nightmare. They can always see machines pop up under Entire Network/OurDomainName, regardless of the fact if it is joined to the Domain or not, or whatever workgroup name is given if i drop it out. The client machines are listed in the entire network in sequential fashion, and the DC is also listed (SRV2000 for example).

On this SVR2000 is a share that everyone in the building needs access to. However, the Win2k machines grind to a halt with error "The specified network name is no longer available" . SVR2000 is always visible and only sometimes accessible. In 3 days i have found absolutey no way to predictably replicate the problem - sometimes it will connect and others it will not (usually not - ha) Sometimes it works after restarting, others not. I can find absolutely no pattern - very annoying.

I have tried giving manual addressing on the client, auto-iping, deleting the machine's DNS entries on the DC, giving only the DNS server and auto IP, creating it as a "new" machine and removing it from the domain then rejoining it (which took some doing also - creating a brand new local admin account on that particular machine seemed to do it as opposed to using the exisiting local Administrator account...bizzare). Still the exact same problem.

The setup as far as i can tell is as follows: One PDC running W2kSBS, running AD, WINS and DNS, a seperate W2k3 server running Oracle databases engines only (installed by a 3rd party company), all connected to hub along with a WAP, these are behind firewall pc, then firewall modem, then internet.

From searching forums aplenty most of it would sways towards a DNS/WINS issue. However, for all i know it could be a dodgy switch somewhere. this is a 7 day live network and I want to be more sure where the fault lies before I start making major changes/overnight maintainence. Apparently the dude who set it up wasn't 100% with what he was doing.

Is it wise to remove all the DNS/WINS records and start again from scratch? Is it better to assign the IP addresses on the client machines and not with a DNS/DHCP combo as is now?

This is the largest network I've had to troubleshoot before personally and so it's a toughie. I spoke with the guy who installed the 3rd party w2k3 server and he agreed.

Does anyone have any ideas???


Thanks in advance!
Matt

 

Hi Matthammer and welcome to the forum.

I've moved your thread to the network forum where it should get attention from people who have experience in similar environments to your.

Reading your post two likely types of problems came to my mind:

1. Name resolution caused by incorrect IP set up. I wonder if you have a second DHCP on the network and the resulting conflicts and misconfigurations are causing your strange behaviour (in that sometimes DNS is correctly assigned and sometimes not). You may be able to find the root of the problem by checking each of your servers and making sure that only the ones you want to use have the DHCP server service installed, and that if you use two or more, that they are configured to work together. Otherwise, look round for old servers, print servers and routers that might have DHCP enabled
2. Hardware failure. You could have a hardware failure happening somewhere. It could be an infrastructure device like a hub, or a network card on one of your servers.

I'd suggest the best way forward is to get a packet sniffer on the network. If you are on a tight budget Ethereal is a good start. You can also use the network analyzers built into the latest Windows operating systems. If you want some of the work done for you, a hardware network analyzer is a good investment, but expensive (I like Fluke kit, but you pay for it!).

A packet sniffer will be able to detect two things. A high number of error packets (which is likely to be caused by faulty hardware), and the MAC addresses of your DHCP servers (which will tell you if the DHCP messages are coming from an unexpected source).

The down side of packet sniffing, is that you need to be able to read the captures, and that needs some knowledge of ethernet and TCP/IP. This is less of an issue with a hardware network analyser. You may have to do some reading to get up to speed. The Ethereal site will have some information, and there are plenty of books about (O'Reilly's Internet Core Protocols: The Definitive Guide gave me a good leg up, and although old, is still relevant)

 

Let me jump in with a slightly different approach than ReggieB's.

. In part, this is "Normal" Windows Networking behavior, and it can be modified. The Server side change: http://support.microsoft.com/?kbid=297684

. The Client side changes:

Start with this KB and Hotfix: http://support.microsoft.com/default.aspx?scid=kb;en-us;283492&Product=winxp

Then apply the client side autodisconnect change:

The LAN autodisconnect parameter is found in the registry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters

. Its function is to disconnect idle sessions after a set number of minutes.
The number of minutes can be set at a command prompt using the Net Config
Server command. For example, to set the autodisconnect value to 30 minutes:

Net Config Server /autodisconnect:30

The valid value range of this REG_DWORD value is -1 to 65535 minutes at the
command line. To disable autodisconnect set it to: -1

You "fixed" the remote server, now "fix" the client to avoid Autodisconnect issues. Use the registry change
and not the command line version for the Client.

.

 

And a good one too. Matt, start with Bill's approach. If that doesn't work then go on to the things I've suggested.

If you are new to managing a 100 plus node network, I would still recommend that you take time to read up on Ethernet and TCP/IP. Managing a large network is not a trivial job and the more you know about the underlying systems the better. However, hopefully the techniques Bill's outlined will sort the current problem and you can fit getting to know your network better into your schedule for the coming months rather than having to work it out on the pointy end of the current problem.

 

Hi guys

Many thanks for your replies Reggie & Bill!! I shall report back when I've given them a go.

Cheers
Matt

 

On the client side it helps to add one additonal setting:

. Click Start, click Run, type regedit and then click OK.
. Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

NOTE: The client side session is automatically disconnected when the idling time lasts more than the duration that is set in KeepConn. For this reason, the session is disconnected according to the less set duration value between AutoDisConnect and KeepConn. To modify the timeout duration in the client side during a UNC connection, specify the arbitrary time in KeepConn from registry value.
Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\lanmanworkstation\parameters
Value: KeepConn
Data type : REG_DWORD
Range : 1 to 65535 (sec)
Default value: 600 sec = 10 mins
Set to its highest value.

 

Hey guys

Back at work now so had a chance to investigate.

The Autodisconnect setting I have read of in trying to solve this problem. I'm not sure it's quite the answer though, because although a disconnection is made to conserve server resources, this connection is not easily re-made as the theory goes. Any machine that leaves our database client software open are always guaranteed to stay on the network for the duration, and most people do leave it open at all times.

The Windows 2000 machines are very hit and hope at forcing back onto the network, although XP machines are much easier by simply using the Repair Network Connection button. Quick thought: do you know of any scripts/batch files/utilities that may perform the exact same tasks as a short term effective quick fix?

I have ran the Etheral packet sniffer in promiscuous mode on an XP workstation and left it going through my lunch break. In the Expert Info dialogue, there are 4784 errors, the majority of which are bad checksums. This concerns me!!

My other concern is I have also noticed a high number of Browser Host Announcements from many workstations. Is this normal behaviour? Also I have noticed 2 of these workstations are issuing Local Master Announcements, then the DC issues one shortly after. And so on. I must hunt these machines down??

Thanks for your help so far
Cheers
Matt

 

I can tell you exactly what the repair does:

For Browser Elections:

Control the persistence of the logons to any network share:

On all machines, type once:
net use /Peristent:No (Turns of the default state of Persistence)

For the .cmd file you can point at as the target of a New Desktop Shortcut:

Echo off

net use some_drive_letter: \\server_name\share_name /Persistent:No
some_drive_letter:
cd some_path_to_datebase_program
START /wait some_drive_letter:\some_path_to_database_program\datebase_program_startup
net use some_drive_letter: /Delete
net session \\server_name /Delete

------------------ end of file
This file should allow both Win2k and XP connections every time.

If you are getting a high level of checksum errrors, be sure that the Duplex settings for the network adapters are set to Auto and not manually configured to 10/100/1000.

 

Brilliant - thank you. Will try that!!

Also will post up some capture files from Etheral very shortly of when I tried to access the shares and succeeded, and also failed. I have noticed the server does not respond to SMB connection requests to the Windows 2000 machines when the problem occours.

Thanks again
Matt

 

Hey all

If it helps, here's a link to those packet sniffing logs, of the successful and failed connections to the server. The failed machine was Win2k and the success was from WinXP.

Thanks again!
Matt

 

Bill - sadly again this is not possible because using that server_name\share_name more often than not will throw up the Error #64: "The specified network name is no longer available." ! Once again! This message is haunting me!!

 

You have a browser issue.

Did you make the Master Browser election status change to all PCs?
Did you then reboot them (you must).

The computer that is the Master Browser should be booted first prior to any workstations.

Check the spelling any syntax of the NET USE command:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/net_use.mspx

Check the spelling of the computer name, and the share name.

 

Arghh no I haven't yet! Did you conclude this from the packet sniffer logs per chance or just from the description?

The Net use syntax and spellings were definately correct. The same error occours when mapping via Explorer.

I have also noticed a few DNS issues...(Selected netdiag output run from the DC)

Code:

Testing DNS
          [FATAL]: The DNS registration for 'SBS2000.MyDomainNameHere.local' is incorrect on all DNS servers.
    PASS - All the DNS entries for DC are registered on DNS server '192.168.16.2' and other DCs also have some of the names registered.
    [WARNING] The DNS entries for this DC are not registered correctly on DNS server '212.159.13.49'. Please wait for 30 minutes for DNS server replication.


DNS test . . . . . . . . . . . . . : Failed
      Interface {3F397AD4-9B03-4930-BF71-F43B4650B209}
        DNS Domain: 
        DNS Servers: 192.168.16.2 
        IP Address: 192.168.16.2 
        Expected registration with PDN (primary DNS domain name):
          Hostname: SBS2000.MyDomainNameHere.local.
          Authoritative zone: MyDomainNameHere.local.
          Primary DNS server: SBS2000.MyDomainNameHere.local 192.168.16.2
          Authoritative NS:192.168.16.2 
      Interface {2627E8FF-F31D-48A3-A1F5-4DC1C268F041}
        DNS Domain: 
        DNS Servers: 192.168.16.2 212.159.13.49 
        IP Address: 168.192.192.255 
        Expected registration with PDN (primary DNS domain name):
          Hostname: SBS2000.MyDomainNameHere.local.
          Authoritative zone: MyDomainNameHere.local.
          Primary DNS server: SBS2000.MyDomainNameHere.local 192.168.16.2
          Authoritative NS:192.168.16.2 
      Verify DNS registration:
        Name: SBS2000.MyDomainNameHere.local
        Expected IP: 192.168.16.2 168.192.192.255 
          Server 192.168.16.2: ERROR_NO_MATCH
            Missing IP from DNS: 168.192.192.255 
              [FATAL]: The DNS registration for 'SBS2000.MyDomainNameHere.local' is incorrect on all DNS servers.
Check the DNS registration for DCs entries on DNS server '192.168.16.2'

DC discovery test. . . . . . . . . : Passed

DC list test . . . . . . . . . . . : Passed
    List of DCs in Domain 'JHE':
        SBS2000.MyDomainNameHere.local


Trust relationship test. . . . . . : Skipped

Kerberos test. . . . . . . . . . . : Passed

The 212. DNS server is actually the DNS servers of my ISP. Am I correct in thinking no records to any external networks should be here?

Here's relevant netdiag failures output from a client machine:

Code:

DC list test . . . . . . . . . . . : Failed
    'JHE': No DCs are up.
    List of DCs in Domain 'JHE':
        SBS2000.MyDomainNameHere.local  (this DC is down)


Trust relationship test. . . . . . : Passed
    Test to ensure DomainSid of domain 'JHE' is correct.
    'JHE': No DCs are up (Cannot run test).
    Secure channel for domain 'JHE' is to '\\SBS2000.MyDomainNameHere.local'.
    Since 'SBS2000.MyDomainNameHere.local' is down, it cannot be tested.

Thanks!!
Matt

 

Hey guys

I eventually have solved the **** problem!

My predecessor had set up the IIS Web Server SSL port to operate on port 445.... which is the port Windows uses to perform SMB connections.

I changed this port.

Goddamn it, that took weeks to figure out!!

Cheers for everyone's help!
Matt

 

No wonder it took some effort to track down the problem.

Thank you for posting back the solution and well done!