You can resolve errors when the network path was not found.
Symptoms
The network path was not found
Resolving the problem
This error might indicate one of several underlying
problems:
- 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.
- 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 "/".
- 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.
- 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.
- 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.