"); gbWndPopupLinks.document.close(); if (!s_bNS3 && gbWndTemp != null) { gbWndTemp.close(); }else { gbWndPopupLinks.focus(); } return true; } return false; } onload = BSSCOnLoad; document.onclick = BSSCOnClick; onunload = BSSCOnUnload; onerror = BSSCOnError; function reDo() { if (innerWidth != origWidth || innerHeight != origHeight) location.reload(); } if ((parseInt(navigator.appVersion) >= 4) && (navigator.appName == "Netscape")) { origWidth = innerWidth; origHeight = innerHeight; onresize = reDo; } //-->

Issue 3 - Name Resolution

The workstation must be able to resolve the fully qualified server name, which is found in the license file, to an IP address.

Name resolution is performed by services such as Domain Name Services (DNS), WINS, or an LMHOSTS file. Some kind of name resolution must be in place, or the RunTime will not be able to communicate with the server.

Note that your Internet provider's DNS likely will not have name entries for most of the computers on your local network. You should set up a local DNS to handle resolution of local names, and ensure that your computers will use the local DNS before the Internet provider's DNS.


Determine the exact fully qualified server name in use by NPLSecure. This is shown in the NPLSecure error dialog, the NPLSecure monitor, and in the rtiwin.ini file in the 'installation' section, under the key 'LastNTServerName'.

Compare the name shown in error dialogs on the workstation to the value reported on the server (by Semcount or in the rtiwin.ini file). If the server name being looked for by the client does not match, NPLSecure will fail, and COM takes a few minutes to detect that it can't find the server. (If the server name has changed, authorization should be recalled and re-installed, and if the license file had been copied to the workstations, it should be recopied.)

Ping: From a command prompt, execute 'ping servername' from the workstation to ensure the workstation can see the server. Be sure to use the entire fully qualified server name reported by NPLSecure. (Example: NPLSecure reports the server name as "Win2k.local.test". The command must be "ping Win2k.local.test". "ping Win2k", even if it works, doesn't prove that name resolution is adequate.) Pinging servername assures that the server name can be resolved to a legal IP address. If you get a timeout, there's something wrong - see your network administrator.

IPCONFIG: Use IPCONFIG /ALL from a command prompt to query relevant information about the IP configuration on both the server and the client. Many times this will help diagnose problems with name resolution.

Semcount: If the RunTime starts, but there is some question about what security method it is using, "Semcount" can also be used on the workstations. It is not normally installed there, so it would have to be copied from the server or installed via the "Custom" installation type.

When using DNS, make sure your server and client are using the local DNS as the preferred DNS, and that the local DNS has name entries for both the server and the client. Also check the gateway and routing configuration; if the server and client are on different segments of the local network, they need to know how to find a route to the other segment in order to talk to each other.

Example 3.A

Windows 2000 server: Installed 5.10, the RunTime runs and Semcount reports all the correct values.

Windows 2000 workstation: Installed the client software, set NIAKWA_RUNTIME to the installed RunTime directory. Tried to run the RunTime and got,

"Error code 14
Not found"

Steps taken

1) Ping the value in the error message in a DOS Window.

C:> ping ServerName.DomainName.DNSServerName

Ping failed.

2) Checked the value for the DNS servers in TCP/IP properties. There were two values. The Preferred DNS server was their Internet provider. The Alternate DNS server was the local server.


Changed the two values so the Internet provider was the Alternate DNS server and the Preferred DNS server was the local server. The RunTime started and ran correctly.