Troubleshooting a Remote Connection
If you are unable to connect to the remote computer you can troubleshoot the problem by working your way up the network stack. Test each layer until you find the problem.
First, you should do basic network troubleshooting to determine why the server is not visible on the network.
Ping the server from the desktop PC. Open an administrative console and type,
where dc01.acme.local is the fully qualified domain name (FQDN) of the server. If this fails you have a basic network connectivity problem between your desktop and the remote server. Or there is a configuration problem with DNS.
If that fails, ping the numeric Internet Protocol (IP) address of the server,
where 18.104.22.168 is the numeric IP address of the server. To determine the IP address run the console command IPCONFIG on the server.
If the numeric ping works, but the named ping does not work, you probably have a DNS configuration problem.
If the numeric ping fails, you have a physical connection problem (the network cable is unplugged or bad), or the Network Interface Card (NIC) is offline, or the device driver is not installed. If the server is not on the same LAN it could be due to a missing route or a misconfigured router. If you are using a VM, the host virtual network might not be configured correctly. It is also possible that a firewall is blocking the connection.
Verify the NETBIOS Network Name and Address
Test the resolution of the server's NETBIOS network name and address,
NET VIEW \\DC01
NET VIEW \\22.214.171.124
NBTSTAT -a DC01
NBTSTAT -a MyDomain
NBTSTAT -A 126.96.36.199
where DC01 is the unqualified NETBIOS server name, MyDomain is
the unqualified NETBIOS domain name, and 188.8.131.52
is the server's IP address. The capitalization of
-A (name versus IP address) is significant.
If these tests fail it means there was a problem translating the NETBIOS server name (DC01) or domain name (MyDomain) to the IP address of the server (184.108.40.206). The problem might be due to a bad WINS server with missing or incorrect name records. (WINS is the legacy name resolution service.) If your site runs a WINS server you might need to fix the records for the host and domain. It might also be a problem with the Master Browser server.
Problem: NETBIOS Network Name Resolution Across Networks
Microsoft security update MS16-077 (KB3165191) changed NETBIOS network name resolution so that NBTSTAT will no longer work outside of the local subnet.
This means that to test NETBIOS connectivity you must have a working DNS server to resolve the computer name, which can complicate your attempt to troubleshoot network connectivity if your desktop computer is not on the same network (same subnet broadcast domain).
Workaround: To enable NBTSTAT to work outside of the local subnet you will need to add a registry value. Run REGEDIT.EXE. Locate the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters. Add the registry value AllowNBToInternet (REG_DWORD) with the value 1.
You will need to add the registry value AllowNBToInternet on both the local computer and the remote computer in order to test connectivity with NBTSTAT. A reboot is required for the change to take effect.
(For the technical explanation of SMB over NETBIOS versus SMB over TCP/IP see KB204279.)
Mount a File Share
The next step is to attempt to mount a remote file share,
NET USE X: \\DC01\C$ /USER:acme.local\Administrator *
NET USE X: /DELETE
where DC01 is the name of the server and acme.local is the fully qualified name of the domain. If the computer not a member of any domain, substitute DC01 for acme.local.
If the ping worked, but NET USE fails with the error “The network path was not found,” it means there was a problem translating the NETBIOS name (DC01) to the IP address of the server (220.127.116.11). See Verify the NETBIOS Name and Network Address (above).
Note: Microsoft security update MS16-077 blocked NETBIOS SMB from crossing a network boundary. This can prevent you from accessing a file share to test connectivity. See above for the registry workaround.
If the NET USE command fails with the error “Access denied,” you might be using the wrong password, or the Administrator account was renamed or disabled, or Active Directory might not be running. In rare cases you might be connecting to the wrong computer because of a bad DNS or WINS record.
If you continue to have network connectivity problems, check the Event Log for additional clues. Check the Event Log on both the desktop PC and the remote server. Look for error messages related to networking, such as Duplicate IP Address or Network Offline. Also check for errors related to DNS, WINS, or the Master Browser.
If the Event Log indicates that the Master Browser is forcing repeated elections, it might indicate a problem with network broadcasts. This is typically due to a bad IP Network Mask (netmask). For example you might have specified 255.255.255.0, but the correct mask was 255.255.0.0. It might also be due to two servers colliding with the same computer name.
See also Remote Server Management
|U-Move for Active Directory|