ARIS 9.6 server is installed on a VM. The VM can be accessed via VPN from home or public network, and directly from office or domain network. However the ARIS client connection works differently as described below
Home/Public Network (connected via VPN)
Connection to the ARIS server using Thin client (web download) works
Connection to the ARIS server using Thick client (local install) works
ARIS UMC and Connect through web browser works
telnet to ARIS server on the port 80 works.
Office/Domain Network (office LAN or wireless)
Connection to the ARIS server using Thin client (web download) works
Connection to the ARIS server using Thick client (local install) doesn’t works. “Error: Unable to connect to ARIS Server. There is no service available for the port you specified”
ARIS UMC and Connect through web browser works
telnet to ARIS server on the port 80 works.
The port and server address mentioned in the connection profile is correct, however the thick client uses the same profile as of thin client. We tried removing the antivirus and firewall (McAfee) software also. The locally installed thick client don't work when users connect their laptop from office network.Is there any network settings which can be done in thick client?
Did you anytime have faced such kind of issue? Any suggestion to solve this would be valuable for us.
Regards,
Amol
0
24.4k
10
by Runé Becker
Posted on Tue, 08/18/2015 - 14:31
Dear Amol,
I vaguely remember that I heard about a similar issue, also only for Architect-based connections. And if I remember correctly, the resolution was a changed network configuration, where GZIP compression had to be enabled.
To exclude a DNS issue, I suggest to test Architect with the IP address instead of the FQDN of the ARIS server.
And use Java Console to check for error messages when the connection failed. In Java Console type "5" to get all details (example below failed to connect to server.domain):
2015-01-01T12:15:16,632 WARNING - unable to determine full qualified name for server.domain
2015-01-01T12:15:16,738 INFO - [server access] could not connect to server: server.domain
We tried using the IP, and from different machines too. Same result. The surprising thing is that thin client works perfectly. Is there a difference in creating a server connection?
No, the connection requires only port 80 for both ARIS clients.
Did you add the company's proxy + port in the connection of the installed ARIS Architect?
Also, are they using SSL certificates? Self-made or officially bought? Self-made might be considered invalid by the embedded JRE of the installed ARIS client.
Next is to check in more detail the log files of abs in folder .\server\bin\work\work_abs_m\base\logs. Increase the details by changing the log level from INFO to DEBUG in file .\server\bin\work\work_abs_m\base\conf\logging.properties. Restart abs.
And check the client's log files in %UserProfile%\ARIS90\log.
We had the same problem after migrating from ARIS 7.1 into 9.6: the thick client showed that error message, but thin client (and UMC, etc.) worked without any issue.
Network security team traced the traffic and found that the problem was the one stated by Rune: we needed to bypass the traffic and enable GZIP compression. The WAN optimization tool was blocking it.
We contacted SAG support, and identified that indeed there was one Riverbed device which was causing the issue. We placed the bypass rules on that device, and that solved the problem.
We hit the same issue recently using ARIS 9.8. I do appreciate if you can provide further details on how did you guys fixed the issue please. It will help other users too.
in case it is Riverbed causing the issue, you could try to switch of compression from the http client used by ARIS.
You should try this first with one installation before rolling this out to all users.
Search for the file "applicationContext.xml", you need to change the flag "compressed" to "false":
<property name="compressed" value="false"/>
You find this file in %userprofile%\<ARIS 9 or 10 >\DownloadClient\<IP adress>\config.
If that works, you need to roll out this change by doing the change on the ABS as well and force the users to download again (they might need to delete their download locally).
