The network path was not found

Resolving the problem

This error might indicate one of several underlying problems:

1. Administration Console for Content Platform Engine has a bad Content Platform Engine server URL. Administration Console for Content Platform Engine calculates the Kerberos SPN by taking the host part of the URL and prefixing it with FNCEWS/, so that, for example, a URL of http://myce01:9080/wsi/FNCEWS40MTOM/ would yield an SPN of FNCEWS/myce01. This should match the SPN previously set up for the server. It will also turn fully qualified domain names like http://myce01.mydom.example.com:9080/wsi/FNCEWS40MTOM/ into an SPN of FNCEWS/myce01@MYDOM.EXAMPLE.COM. These derived SPNs usually work well, but can sometimes have problems. Particularly watch out for URLs that are not DNS names, like http://localhost:9080/wsi/FNCEWS40MTOM/ or similarly ones using IP addresses, like http://123.45.67.89:7001/wsi/FNCEWS40MTOM as these will yield bad SPNs.
2. The SPN is correct, but was never mapped by the setspn utility to the corresponding identity user account, FNCEWS_myce01 in this example. Try running setspn –l FNCEWS_myce01 to list the SPNs that have been mapped to this account. Check for misspellings, such as _ or \ instead of /.
3. The SPN was mapped to more than one identity account. One option to check for this is to use the LDIFDE.EXE utility (part of Microsoft's Windows Server support tools) to dump the account information to a text file by issuing a command like LDIFDE –d dc=mydom,dc=example,dc=com -f mydom.txt. Then open the mydom.txt file with a text editor and search for the SPN string, FNCEWS/myce01 in this example. If duplicates are found, you can remove an extra one by typing something like setspn -d FNCEWS/myce01 FNCEWS_baduser.
4. The SPN is not known in the client's domain. This situation can arise if the client's logged-on user domain and Content Platform Engine Windows domains are either not the same or are not in the same Windows domain forest where the domains implicitly trust each other. See the Cross-realm Kerberos authentication section for a workaround for Windows domains that use external or transitive two-way trusts.
5. The SPN had one of the above problems and was recently fixed. In this case the .NET framework has cached the bad result and the only way to clear this is to reboot the client system. It is a good idea to reboot the client anytime .NET reports a The network path was not found error.