How to troubleshoot "network path not found" and similar issues (4349178)

Sometimes an error like "Network path not found" or "LDAP Server down" or a similar error is logged.
How can such errors be troubleshooted and why do they occur? 

QMM Exch and QMM AD are very complex tools and they deploy agents and components on different computers, often in different domains and organizations.  In this case the mail agents or the directory synchronization agent still need to access the following computers:

QMM console - computer where QMM has been installed, by default this computer is also the licensing machine

ADAM DB - computer where ADAM application has been installed and where the Project is saved.

SQLDB - computer where SQLDB has been installed and where the Exchange Project is saved. From this computer connectivity is established to QMM console and to absolutely all involved Exchange servers.

DSA - Directory Synchronization Agent - could be any computer, but ideally not the same where ADAM is installed.

Having multiple DSA is allowed and recommended so it is important to understand on which computer the error was logged and which computer is not accessible.

Note:  Each source Exchange server and each source and target Public Folder server needs to be able to connect to Exchange servers in opposite domain or org.

Explanation:  Transmission agent need to connect to opposite site and to move data to another server.

1. Perform the basic troubleshooting steps.

- Determine which tool or which component logged the error.
- Connect to this computer.
- Analyze which computer is not accessible.
Ping the computer with NETBIOS name, when it replies with IP then ping the IP using the following syntax:
ping -a 192.168.10.10
It should reply with a FQDN, if not verify why not; if the returned FQDN is incorrect then investigate and correct the issue.  It is a good idea to copy the returned FQDN and ping it as well.
As temporary workaround the local host file can be modified and IP and computer name can be added there.

2. Use on board MS tools when troubleshooting such issues, depending on the failing to connect component one can use the applications listed below, but troubleshooting should not be limited to the usage of these application, those are just examples:

- Start - Run - cmd and use the ping utility (or nbtstat).
- Start - Run - dsa.msc and when ADUC opens connect to domain or to a domain controller (good to troubleshoot LDP connectivity).
- Start - Run - services.msc and connect to another computer (good to troubleshoot RPC connectivity issues).
- Start - Run - regedit - and connect to another computer.
- Manage My Computer and connect to another computer.
- Start - Run - LDP (tool LDP.exe from Support Tools needs to be installed).
- MFCMAPI from Microsoft.
- Windows Explorer.

3. To troubleshoot WMI issues or errors:

- Wmimgmt.msc
Go to Start - Run - and type wmimgmt.msc

When the console opens use the right mouse menu - Connect to another computer - Another computer - and type the name of the server.
After it connects use the right mouse menu again and select Properties, it should display the properties without any errors.

- Wbemtest.exe(Advanced!)

Note:  before continuing, please heed the warning at the link below:  The word Tester in the title of this opening dialog should serve as a "warning" even to GUI gurus.  Wbemtest was not designed for mere mortals or even savvy system admin scripters.  It was designed as a tool for testing the functionality of the WMI COM API.  The result is that: 1) wbemtest enables you to do almost anything with the WMI COM API and 2) the interface is difficult to use even for experts.

Go to Start - Run - and type Wbemtest.exe
The wbemtest.exe tool makes a WMI connect and can query the metabase at the same time.  For more information on the wbemtest.exe tool, please see the following Microsoft article titled Scripting Eye for the GUI Guy | WBEM What? at the following link: http://technet.microsoft.com/en-ca/library/ee692770.aspx