It largely depends on not only the network/internet connection to the device, but the device itself.  For example, if the person is on a slower or rural internet, it may take a bit to make that first connection - and even be slow or laggy throughout the session.  Processing power is also a factor.  If you’re trying to remote into an old android tablet or older raspberry pi, the first interaction, let alone continued interaction, may be slow.  Remember that you’re effectively not only streaming a video of the person’s screen, but also sending back actions to their computer at the same time.  While Remote Support isnt exactly the most resource intensive software, it still requires resources.

If the device is a more modern device and on the local network, it should take seconds to make a solid connection.  Off network or in a remote location, it shouldnt take more than 30 seconds to a minute.  Personally speaking, if it took more than 30 seconds (which is a long time in the IT world), then I would have probably figured out another means of support.  If it took 30 seconds for me to see the screen, how long would it take for me to see where I moved my mouse?

Thank you for your reply! 

I am just curious about the establishing time - because after the session is established, everything runs smoothly. No hickups with slow connection etc.

I am trying to connect to completely normal windows notebooks / computers, no low-power devices. And they are all connected to our company network that has very good speed (well, it is very complex and I am sure this slows down the establishing time, but I wanted to know how long this takes in other companies)

Yes, we have establishing times from 10 up to 30 seconds, which is a looong time as you correctly said (remote supporting after that works fast) - a ticket at the BT support is already opened up. But I wanted to know what the “common” time is. 5 seconds until you see the window? 10 seconds? 

I would say on a “normal/modern” network, the load time should be around 5 seconds.  A couple more things come to mind that may help shed some light.  I apologize if this comes off as me suggesting you haven't done your due diligence - that is not my intention.

1. Does the same lag happen if you do an RDP jump instead of a normal jump?
2. Do you see the same lag with using the built-in Windows RDP client? 
3. Are you seeing the same lag when using the web rep console vs the locally installed rep console?
4. If you do a “ping -t [insert IP address]” to the device, do you see a bunch of dropped packets?
5. Do you have any security appliances that do any sort intrusion detection/prevention that would slow down the connection?
6. You mentioned the networking being complex - which most are.  However, it may be worth investigating to make sure there arent any strange configs or physical networking issues.
7. Check DNS.  As we all know, its always DNS.

For us in PRA the connection establishment time can take up from 8s to 30s generally. It depends a lot on the latency and the performance of the device.

What helped us a lot in connection establishment time reducing was to appropriately handle the exceptions for the Endpoint Client in the Endpoint Security Tool.

We are also in contact with support, and from what we saw after the investigation of the logs is that the pull-rdf process is taking much longer than it should be on slow internet connection sites.

You should also check the console how much time does it take until the “In-Session” text appears. This is the time, when the endpoint client is fully operating. Analyzing logs can help a lot to understand which phase is taking much time. I’d recommend to do a PID logging on the Jump Clients so you can see in which phase is taking much time. ← We use PRA (ATLAS), but as far as I know Remote Support mechanism is pretty much similar.

​@LayerZeroIssue Thank you for the checklist!

1. RDP Jump seems to be pretty fast with 5 seconds in comparison - unfortunately, we can not use RDP as default due to company rules.
2. RDP via windows is as fast as RDP Jump. But, well - not useable for our demands.
3. Web and Rep Console have the same delays
4. No packet drops, no delayed pings
5. I think somewhere there lies the issue… I have already seen that virus scan slows the connection down - but when I disable it for testing, my connection still needs 11 seconds to be established. That is 6 seconds too much in comparison. So my search goes on.
6. It is nothing physical, I think it really has to do with complexity / configuration of security things. I just want to know which thing
7. 😆 Well, I think DNS is not the guilty one this time. Just this time!

​@TZoltan Thank you! 8 - 30 seconds is what I see here too, but In RS.

Yes, I am already checking virus scan to make exceptions, but I think some other stuff is messing with the connection, because I can’t get it faster than 11 seconds without virus scan…

The in-session text takes with virus scan on 8 to 12 seconds. After that the delay for “session being put in queue” and after that “session window opens” takes another 5 - 8 seconds.

We also have gathered multiple logs for BT Support which are analyzed for a long time…

With Endpoint security tool you mean only Virus Scan or also something else? Because I am grateful for every hint...

Hi ​@Tina_K,

Yes, I meant the virus scanning under “Endpoint Security”.

Processing logs and get feedback on it always take long for us too.. so I also put effort on trying to understand what is in the logs, not just waiting for a reply.

Generally, I think you should check the sra-pin-launch-bgin.log if you see any delay there. (in our case there was a huge delay in that logs, that’s where exceptions helped)

On the other hand, what I do, is to enable PID logging (Remote Support / Privileged Remote Access - How to turn PID logging on and off for RS and PRA on Windows) on the client, so I see which process / thread is what takes long.

I also saw cases, where proxy couldn’t be contacted, that also put delay on the connection establishment.

So what I can tell you is that start looking in the logs if you can, or wait until the support finishes the analyzing. :)

​@TZoltan I enabled logging and took a look at the logs, they are huge and I see the delay(s), but no dropouts or something like that. So nothing I can really grab and say “THIS is causing an error”.

May I ask what paths you added to your exception list for the virus scan? I found the ones in ProgramData\BeyondTrust and ProgramData\bomgar* and Program Files\BeyondTrust (appears only in an active session) and Program Files\Bomgar

I also added the sra-pin.exe to the file exceptions. This helped a little, but I still have a huge delay of around 14 seconds… better than 20+, but still… ;)

I do my best, but I am no expert on the logs, so I will be patient for the support :)

​@Tina_K do you see the delay in the sra-pin-launch-bgin.log? if yes, then there is something interfering with the extraction / installation of the Endpoint Client, if I am correct. I think those folders should be good, but be careful with folder exceptions!

What can help is to create an exception for the file launch-{some random characters}-bomgar-scc-adhoc-{platform}.exe ← this is the file that is created an launched when a session is initiated to the computer, this extracts the files that are required for the session

​@Tina_K here you can see what processes should be exceptions: Remote Support / Privileged Remote Access - Components name changes

​Hi @TZoltan , 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. 

With exceptions and some other features in endpoint security disabled for testing I get the constant establishing time of 11 seconds - and those I can say have nothing to do with endpoint security. 

I do see that the console is doing a ton of cryptic stuff all the time and to me it looks like it is doing the same stuff over and over again. Yeah, it would be great to know how to read the log correctly… But I found a strange entry - a timeout for the queue. (there are more timeouts...)

On the client side I see that in the bomgar-scc.log there is nothing happening for 2 seconds at the same timestamp.

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 :)