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

It's a known bug. Go to

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!

K> It's a known bug. Go to

That didn't help. Any suggestions??

Hey,

I found this TPI report that probably corresponds to your problem. I have seen this error on Intralink 3.4 as well. However, it went away by itself which makes me think it was a temporary port conflict. Here is the report. E-mail me if you want a PDF.

--Start TPI report--

Number 129046 Type TPI Created Date 30-Mar-2005 Last Updated 13-Apr-2005 Title The message "Cannot connect to PTC name service. Please ensure that it is started." appear while starting Pro/Engineer linked to a Workspace. Details Additional Information

Description

----------------- Pro/Engineer will not start when linked to a workspace. It returns the error message : "Cannot connect to PTC name service. Please ensure that it is started." This may happen if the PTCNMSPORT 1239 is already used from other applications.

Alternate Technique

-----------------

Please see Resolution

Resolution

----------------- It is possible to change the value of the PTCNMSPORT by setting up a environment variable with the Name: "PTCNMSPORT" and a value higher than "1239"

If Pro/Engineer Wildfire is used for the linked session with Intralink than the following line have to be removed from the relevant *.psf file in the directory \bin ENV=PTCNMSPORT=1239

Affected ProductsProduct Pro/INTRALINK 3.x Module Pro/E - Pro/I Interaction Reported Release 3.3 Reported Datecode M022 Resolved Release 3.3 Resolved Datecode M022 Affected Client All Windows Affected Server Not Available

--End TPI report--

Hope this helps.

--Adam Joseph Cook, Mechanical Engineer

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

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

2. 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.

1. 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 /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