From our BPA ‘Firewall Configuration’ we are getting the following feedback:
How to disable .Net Remoting?
Note: we changed the ConnectionSettings.txt file from
‘* type=RemotingConnection;polling=0;zip=true’ to ‘* type=GRPCConnection’
We also added this tag to the maintenancesettings as by the docs:
<EnableDotNetRemoting>false</EnableDotNetRemoting>
After adding the ‘via=”https://10.4.2.92/APIGateway”‘ in the redirect rules we started to see the following issue:
The URL does not resolve to a specific page it just redirects the landing page of docs.dataminer.services | DataMiner Docs. However when we look at the FO status everything looks normal:
I quickly fixed that aka-url to the correct page: https://docs.dataminer.services/user-guide/Advanced_Functionality/DataMiner_Systems/BPA_tests/BPA_Check_Cluster_SLNet_Connections.html
Thanks Jordy for fixing that. It looks contradictory in one check it gives an error if you are using .Net remoting and in the other it gives an error if it can’t connect with .Net remoting.
Hey Michiel, an investigation will be needed to look into this. Could you create a task for this and provide more information? A logcollector package with SLNet dump would be useful.
ATM I no longer have access to the failover system for which we tried to solve the BPA items reported (we reverted back to .Net remoting). I’ll check with my colleague who now took ownership of the system to create a task. I do believe this will be the same for any FO system using hostnames.
We had redirect rules as both main and FO agent have different passwords. So we added the ‘via=”https://10.4.2.92/APIGateway”‘, but this also made no difference in the result of the check.