none
Remote Assistance (msra.exe) will need 45 seconds to connect from Win10 1809 or 1803 RRS feed

  • Question

  • After upgrading the IT department to Win10 v1803/1809, we noticed that Remote Assistance (MSRA.exe) has a problem.

    Please note: this problem only surfaces on systems that have no internet access!

    Steps to reproduce:

    1 Take two systems (Win10 180x) that are on the same network but have no internet access (either remove the gateway IP or simply take 2 VMs connected to default virtual switch [which is connected to: internal network by default])

    2 on one system, create an invitation file on the command line like this:

    msra.exe /saveasfile %userprofile%\desktop\help.msrcincident 111111

    3 take that file and transport it from your desktop to the other machine (use a share, USB stick, RD-clipboard,...) and open it on the other machine

    Expected behavior, as seen on on any win10 version prior to 1803: you will be asked for the password, which we set to 111111 and you enter it and immediately, you connect

    Observed behavior, as seen on win10 v1803 and 1809: after clicking on the invitation and entering the code, there is a delay of exactly 45 seconds with the status "attempting to connect". Afterwards, everything works.

    Since this is seen on any system, Microsoft will be able to reproduce this in seconds.

    It happens no matter what target operating system the person you want to help is using, as long as the person who would like to offer help is using Win10 v1803 or v1809.

    ---------------

    Please refrain from telling me that there is a newer app "Quick Assist", since we need an app that works offline and QA does not. This is a big nuisance for our support team and we need to get rid of this delay.

    Tuesday, January 8, 2019 2:45 PM

Answers

  • By own research with the friendly help over at experts-exchange.com, the issue is now solved.

    All I had to do is:

    I downloaded all the current certs and lists to a share like this:
    Certutil -syncWithWU \\server\certs\
    Then, at the clients, I set (a REG_SZ value) RootDirURL=file://\\server\certs 
    at HKLM\Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate

    ----no more delays!---

    Still, Microsoft should change the behavior, Eve.

    • Marked as answer by Ronald Schilf Thursday, January 10, 2019 10:48 AM
    Thursday, January 10, 2019 10:48 AM

All replies

  • Hi,

    Thank you for your detail information.

    Please try to restart both systems in Clean Boot, with all 3rd party process disabled, and try the remote assistant again to check the result.

    Perform a clean startup to determine whether background programs are interfering with your game or program:
    https://support.microsoft.com/en-us/help/331796/perform-a-clean-startup-to-determine-whether-background-programs-are-i

    Also, if possible, please disable Windows Firewall temporarily and check the result. 

    If problem persists, please provide me more information, I will try to reproduce such operation on my test environment, and post my test result as soon as possible:
    1. Is it domain or workgroup environment? 
    2. Is it a clean installed system or upgraded system?

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Wednesday, January 9, 2019 6:27 AM
  • Eve, please note that editing your answer will not be reflected by mail notifications. 

    (Your original answer "I will try to reproduce such operation on my test environment, and post my test result as soon as possible" did not ask me to provide details)

    Ok, so let's see:

    Clean boot: no change

    Firewall disabled: no change

    1. it occurs on any system, be it domain joined or not

    2. it is a clean installation with no additional software

    You will be able to reproduce it in 2 minutes.

    I used wireshark and could see that in the meantime, at the target machine, the address

    http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/pinrulesstl.cab?0899494e558a2b7f

    is contacted repeatedly, which of course, does not work without internet. That link holds a certificate revovcation list, if I am not mistaken, so it could be, that msra.exe tries to verify if some certificates are listed on that CRL.

    But why would it? Why would it even use certificates?

    And why did it work with the old versions without?

    And why would it take 45 seconds to determine that that link cannot be retrieved?

    And lastly, what's the point in doing such a check, when after 45 seconds it works without and does not thorw any error?


    Wednesday, January 9, 2019 1:04 PM
  • By own research with the friendly help over at experts-exchange.com, the issue is now solved.

    All I had to do is:

    I downloaded all the current certs and lists to a share like this:
    Certutil -syncWithWU \\server\certs\
    Then, at the clients, I set (a REG_SZ value) RootDirURL=file://\\server\certs 
    at HKLM\Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate

    ----no more delays!---

    Still, Microsoft should change the behavior, Eve.

    • Marked as answer by Ronald Schilf Thursday, January 10, 2019 10:48 AM
    Thursday, January 10, 2019 10:48 AM
  • Hi,

    Thank you for your detail information sharing.

    I will check and confirm it, and report it to product team if necessary. 

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, January 14, 2019 1:05 AM
  • If you want to reproduce it, including my solution, please note that after setting that registry key, you need to reboot the client.
    Monday, January 14, 2019 1:14 PM