What is the average time to establish a session in Remote Support?

Hi ​@Tina_K, The log entry you sent is from the Representative Console is shown is not related to the establishment process. As I experienced, there are very few entries on the Access Console side logs, when there is a session initiated.

I have made fresh new logs and in the sra-pin-launch-bgin.log I do not see any delay, everything happens within one second. ← that’s good, so then there is nothing interferes with the client extraction, next step is to check the bomgar-scc / bomgar-pec logs, these contain the connection establishment logs, for these, the PID logging might help, as it logs every thread in a different log file, so it’s easier to analyze. 

Which version are you on, if you can share? In 24.1.1, I know that there was a change made in how clients connect in recent versions where it attempts to download and execute a new client which causes a delay. There is a patch available, that reverts the change, so that it connects in the way they would have previously, but as far as I know it is fixed in later releases.

I think 11 seconds are not that bad by the way, it also depends on where your Primary Node is located, where you are connecting from and where your endpoint is located physically. If everything mentioned before is on the same location, then it’s a little bit slow, but yeah.

You can also do a latency check, which goes through the appliances: Remote Support / Privileged Remote Access - Slowness or latency issue when accessing Jump items 

Hi ​@TZoltan  - this is getting interesting, I am learning a lot. OK, so the console log is not helpful at all… got it. I used the PID logging and yes, it makes analyzing easier!

I found two bigger delays in two of the threads and one 4 second delay says it has trouble with the Proxy detection - maybe this is my problem child?

the other one takes 10 seconds for creating a timer with pointer…?

We are using 25.1.1 right now. The delays did not change between versions.

Yes, the physical location of the client also matters, but these delays appear in daily business with all the clients in the same country / plant. That’s why I am trying to improve stuff ;-)

Hi ​@Tina_K, yes, maybe this is the root cause of your delay. I saw that sometimes it can create a 10s delay also. 

You may check what is the 12180 error code is and how you can manage it.

I know that the Jump Clients do automatic proxy detection, so it may happen that it wants to query the WPAD from the DNS/DHCP.

Hi ​@TZoltan , we are not using a proxy and therefore don’t have WPAD. So there is no possible server to configure (and none is configured). So the big question is why are the jump clients searching for a Proxy / WPAD / PAC URL if there is none… and how to stop them doing this. 

We will add this to our support ticket!

This looks to me like “should not be this way”...

Thank you so much for your help! It is appreciated😄

Hi ​@Tina_K, 

I found this in one of the KBs regarding Proxy detection process:

Proxy detection process:

1. Clients check for previously found instances of known-good connection settings and, if present, use them instead of the proxy detection process that follows.

2. Clients detect and collect HTTP and SOCKS proxy information based on the host operating system:

• On Windows, macOS, and Linux: Firefox proxy config settings are checked using prefs.js for all profiles in the profiles.ini file.
• On Windows: Clients check the Windows system proxy settings (IE and Chrome) via Windows API calls. PAC files are supported.
• On macOS: Clients check OS system proxy settings (PAC files are not supported).
• On Linux: Clients check the HTTP_PROXY (or http_proxy) environment variable.
• On iOS and Android: Clients use system network configuration and skip the proxy detection and direct connection process which follows.

3. Clients simultaneously attempt a connection to each host/port configured on theRS/PRA Box (TCP 443 by default) through each proxy found (if any) as well as directly.

Note: See the Built to Attempt fields on the Status > Information page in the /login interface of the Appliances site.

4. Clients use the SOCKS4a protocol to negotiate a proxy connection if a proxy is found. If authentication is required for the proxy, clients will authenticate using Basic or NTLM credentials in Windows. If these fail, the client will negotiate credentials with the user. Authenticating proxies are not supported on any platforms besides Windows.

5. Clients next ping the appliance to verify that it is a RS/PRA box if a connection is made.

6. Depending on the result of the proxy detection and connection process:

• Clients will terminate all other connection attempts and save the proxy information for re-use if a confirmed RS/PRA appliances Box is connected.
• Clients will return a dialog box stating, The client software was unable to detect a connection to the appliances Box. Please check your network connection and outgoing firewall settings and try again. if no connection can be made. The Client will restart the process if the user presses Retry or uninstall if the user presses Cancel.
• Proxies, load balancers, or other network devices performing packet inspection on RS/PRA traffic can also cause an error stating that the client software was unable to detect a connection to the box.

On why it is happening or how it can be prevented, unfortunately I have no information, probably support can tell you more about this.

I hope your issue resolves if you find solution for this one :)