'Cannot connect to PTC Name Service. Please ensure that it has been started'

LS,

I'm a newbie to Pro-E and would like to know what this message is and
how I can solve this.

Thanks!

JJ

 

It's a known bug. Go to
http://www.ptc.com/go/timeout/technical_resource.htm and download
nmsd.exe file for your Pro/INTRALINK version. Replace it in files and
then tries to restart your client.

Good luck !

 

Thanx! This I'll try this right now!

Kind regards,

JJ
Ben-TSE schreef:

 

That didn't help. Any suggestions??

 

The following is typical of the responses received for this question on the
PRO/USER Datamgt group on prouser.com/datamgt. This was received in response to a
similar query from Kevin Smith in April of this year, '06:
Thanks to everyone that responded.



****************************************************************************************************

Original question



Folks:



I have been trying to setup access to our one dataserver in Texas from Canada and
am having nothing but problems and PTC can't seem to help.



This is the message I get: Cannot connect to the specified NFS server, 'servername'
Ensure that the file server is running, and that the owner of the file server
process has permissions to read/write to the file vault location(s).



I know that everything is functional as the local users don't have any issues.



We are currently running 3.4 M020.



I have tried various things suggested by PTC as follows:



1. Set value in SQLORA.NET à SQLNET.AUTHENTICATION_SERVICES= (NONE) was NTS - Did
not help

2. Renamed SQLORA.NET to OLDSQLORA so that Intralink did not use it at all. - Did
not help

3. In the Oracle DB changed the fileserver name to the fully qualified name
instead of just nodename. With this change it didn't help me but also when changed
to full name the users at the local site could no longer log in. Once I changed it
back to nodename the local people could log in again.

4. A telnet to the fileserver at port 7777 shows that I am communicating with it.



PTC says that 3.4 is not supported on a WAN but I have other dataservers on the
WAN that I can access without issue and have not had to make any special changes
to make it work.



I have also asked our networking group if there is any port blocking at the sites
and there is none.

*****************************************************************************************************



Solution:



After I added the server into our corporate DNS server everything worked. This is
kind of strange as I have never had to do this before, just putting the server
info into my host file worked in the past.





Here are all the responses I got to my question.



*****************************************************************************************************

*************************************************************************************************************************

When referencing the server in the Intralink client software, use the full network
name, server.mysite.mycompany.com. Many "offsite" systems may not be resolved by
your local DNS server unless you put the full network name.

*************************************************************************************************************************

Are your remote and local clients on windows? How about using the IP instead of
the name of the server? And maybe setting this up thru the hosts file on the
windows side?



Can you ping back and forth from all machines using IPs? Do the remote and local
clients see the Fileserver and Dataserver via the same IP?



These are just some ideas.

*************************************************************************************************************************

We got the same error message yesterday and the solution was to add the domain to
the Advanced TCP/IP Settings DNS tab under "Append these DNS suffixes (in order):"
list.
This was on a Windows 2000 client.

*************************************************************************************************************************

When you telnet to the fileserver do you use the nickname/short name or the fully
qualified name? The fileserver may be specified by the nickname in the Intralink
database. If it is, you may need to change it to the fully qualified host name
(e.g. fileserver.my.company.com). Or, set name resolution on the on your Canadian
system to properly resolve the short host name.

*************************************************************************************************************************

I have dealt with a similar intermittent problem when connected through a frame
relay. The latency of this type of connection can be awful and create problems
for Pro/I. They are also often inconsistent in latency so you have to test over
time. They can be "tuned" though.



Run a tracert command between the sites and see what your latency is. If it is
greater than 100ms, or varies widely with spikes above 100ms, that is likely the
problem.

*************************************************************************************************************************

You have set the dataserver to either its fully qualified domain name or ip
address within the clients trying to see it? Are the clients allowed access from
one site to another? Check those first and it may fix your problem

*************************************************************************************************************************

First I should say that I'm not currently running 3.4. In spite of this fact and
at the risk of being redundant (my guess is someone has already asked you this)
but how is your name service (DNS/DHCP/WINS) handled?

Can you ping the other dataservers over the WAN with a short host name? Long host
name? IP?

What about the 3.4 server (short/long/IPs)?

Do you have a long name specified in your tnsnames.ora file?



Just some things to check or consider, but I recall PTC products having trouble
with client connectivity when the short host name wouldn't resolve correctly. You
could test this quickly by adding an entry to a hosts file on one of the WAN
windows clients (in xp it's in the c:\windows\system32\drivers directory and it's
a hidden system file so you need to change your hosts file). If you want to test
this option, I can provide more detail if need be.

*************************************************************************************************************************

I got the same message trying to connect over a WAN. The problem I ran into was
port blocking. ILINK Client opens a random high port for each new instance
connection to the dataserver. I would verify with your IT that there are no ports
blocked anywhere between the client and the server.

*************************************************************************************************************************

Did you try using fully qualified domain names when you are referring to your
dataserver/fileserver/license server?

*************************************************************************************************************************

I would assume that they are on different domains one being in Canada & the other
in Texas?



Check the DNS settings to make sure the two domains are communicating properly.
You may need to look at the DNS server settings to make sure they are
authenticating properly between each site.

*************************************************************************************************************************

Can you login to the dataserver, but just not transfer data to a workspace?



Once the dataserver "tells" the client which files to get, the file transfer is a
direct negotiation between the fileserver and client. The Oracle authentication
shouldn't be an issue, but the name resolution could be...I assume the clients can
ping the fileserver by the same name that is stored in the DB?



Try using <dataserver_loadpoint>/intralink/bin/pnfs.exe to pinpoint the problem
(pnfs with no args to print usage message).



pnfs FILESERVER_HOST 7777 -Pfschangeme -ping



pnfs FILESERVER_HOST 7777 -Pfschangeme -ver



You can also perform an actual file transfer to confirm that data is flowing.



*************************************************************************************************************************

This may be oversimplified but, ping the server and if that works then use the ip
address, not the server name, in ptcsetup when pointing to the dataserver.

*************************************************************************************************************************

I can not necessarily help with your specific issue, but we have two sites that
access the Intralink 3.3 server at our site with no problems. One site connects
to our headquarters site via a VPN over a cable modem and the headquarters
connects to us via a VPN over a DSL line. The only issues we have are speed
related. Intralink is very slow at the other sites.

Kevin