Our InstallShield (IS) 2010 client on Win7 and XP are no longer able to communicate to the licensing server.
The IS clients have not connected in a while therefore it is hard to tell when it "broke".
The licensing server is a Win 2008 server running 11.11.0 FLEXNET
Our license is up to date.
The ports are open and I can telnet to the port that the licensing server (port 27000) is running on.
Ran a wireshark trace, we can see the port connection being established on 27000 but then the windows client abruptly terminates the session.
Windows firewall on client and symantec software has been disabled.
The error from the client is “License Error 96 – InstallShield could not acquire a license because you are not entitled to use this software. You can try to reestablish the connection or exit InstallShield”
Thank You for looking.
Solved it. I ran a wireshark trace and found the following :-
IS Client opens connection to InstallShield License Server Configuration port.
IS client then opens up a second connection to a different port on the server used by Vendor Daemon: mvsn.
Solution:
Log onto the admin tool and valid what ports are listening for the License Server Configuration and Vendor Daemon:mvsn. (might be best to lock down the ports in the admin console otherwise they will be dynamic and change if the services are restarted)
Make sure you can telnet to these ports from the IS client.
Related
Currently hosting a microsoft azure server that has a SCP: Secret laboratory game server on it.
OS: Ubuntu 20.04
After setting up the server and downloading the server files, I can't seem to connect to the server. The port that is needed for the game server is 7777 and I have the port open under NSG with UDP and TCP protocol, but after using multiple port checkers and trying to connect in game, I always got the port closed answer or was given a connection error.
I have tried using the azure's own troubleshooter, but that says the ports are open. Tried different ports like 7778 or 7779. Checked the firewall, but I dont even have it enabled.
I am trying to connect to VS2019 remote debugger installed on virtual machine (Windows Server 2022 version 21H2) hosted in Azure cloud.
Remote debugger is installed correctly and I've checked that TCP port number in options is set to 4024.
Now, when I try to connect from my machine I got an error message
Unable to connect to 'hostname'. The Visual Studio 2019 Remote Debugger (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging.
So the first thing we tried was properly set up firewall and open needed ports. After that it still doesn't work.
I've checked which ports msvsmon.exe process listens on and found out it does not use the preferred port 4024 but rather it listens on some random ports.
netstat -abo -p tcp
TCP 0.0.0.0:20031 hostname:0 LISTENING 9920
[msvsmon.exe]
TCP 0.0.0.0:20035 hostname:0 LISTENING 11148
[msvsmon.exe]
Even when remote debugger window falsely states
1.9.2022 14:25:26 Msvsmon started a new server named 'hostname:4024'. Waiting for new connections.
I've also tried starting msvsmon.exe with /port option. GUI says it used this port but in fact it still listens on some random port.
Any idea, why msvsmon starts server on random port instead of the one set in options?
I am using the "test.udl" to test the connect.
When I use the IP which is from the router, it can connection test is succeeded.
Then I try to use the real IP for testing connect, it got fall.
The router has set as below:
Archer C2>forwarding>Virtual Server:
Service Port=1433,1434,49172
Ip address=192.168.0.100(Permanent)
And I have closed the firewall in windows.
The Sql server configuration manager setting:
TCP IP Properties>IP Address>
IP1:
Active:yes
Enabled:yes
IP Address:119.246.x.x
TCP Dynamic ports:0
TCP port:null(unset)
IP2:
Active:yes
Enabled:yes
IP Address:192.168.0.100
TCP Dynamic ports:0
TCP port:null(unset)
test.udl test information:
Fail test
server name:119.246.x.x\server
Use Windows NT integrated security
result:
Test connection failed because of an error in initializing provider.
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
succeed test
server name:192.168.0.100server
Use Windows NT integrated security
result:
Test connection succeeded.
Does anyone know where i got wrong?
It is a bug.
SYMPTOMS
When you try to connect to a clustered Microsoft SQL Server 2005 or Microsoft SQL Server 2000 named instance by using the "servername\instancename" syntax, you receive the following error message:
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
You may receive this error message when the following conditions are true:
SQL Server 2005 or SQL Server 2000 is installed on a cluster.
You are connecting to a SQL Server named instance by using TCP/IP sockets.
IPSec policy is enabled on the client domain.
IPSec policy is not enabled on the server domain.
CAUSE
This problem occurs during the discovery phase of the connection. The IPSec policy on the client drops packets from the server when the source IP changes.
WORKAROUND
To work around this problem, you have to hardcode the TCP port or the Named Pipe of the SQL Server named instance. To do this, use a connection string that is similar to one of the following:
[oledb]
; Hardcoded TCP OLE DB initstring
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security >Info=False;User ID=clientID;Data Source=tcp:TcpIpAddress,port
[oledb]
; Hardcoded Named Pipes OLE DB initstring
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security >Info=False;User ID=clientID;Data Source=np:\ServerName\pipe\MSSQL$InstanceName\sql\query
*Source taken from https://support.microsoft.com/en-us/kb/888228
Hope it helped
I have solved it. It may cause of the default port is not 1433.
I checked the log file viewer(SQL server Management studio>SQL Server Agent>Error logs>current(archive is also work))
only tick on the sql server check box
find "server is listening on[ 127.0.0.1 xxxx].
In my case it is 9662/9663
I add them all in my router and succeed to connect.
Thank you all above.
I tried to look for solutions and most of them talk about adding HTTP, RDP, HTTPS to security group which I have already done. I have a basic hello world nodeJS application running on Amazon Windows Server 2012. I want to access this application using DNS but it's showing ERR_CONNECTION_TIMED_OUT in my local laptop browser.
Configuration:
I have RDP, HTTPS, HTTP, SSH, Custom TCP Protocol with 9000 port (nodeJS is running on port 9000) for inbound rules and for outbound default "All traffic" rule is present. I have not done any changes in the Windows Server 2012 configuration. WHen I run localhost:9000 in the windows server 2012 then server returns "Hello World" but when I try that on my local machine with DNS : 9000 then it says ERR_CONNECTION_TIMED_OUT
Thanks for everyone's support. Special thanks to Viccari. His suggestion (in the comments below the question) worked. I needed to add the port to the firewall. So basically after adding all the protocols to the security group, I had to add the new port on which the NodeJS is working, to the firewall in the server. Finally its working.
Need help on this!
I'm trying to connect and send a message from my client pc to our host server (Windows Server 2012) via TCP/IP. I configured the DTC connections and also opened the firewall but I still get this error.
Any suggestions on what to configure in order to fix this?
UPDATE: Here is the "View Detail" section: