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

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.