msra.exe (remote assistance) refuses to connect - for non-admins

Last week one of our admins in a remote location came across an odd issue. They were not able to send a remote assistance request (msra.exe /offerra <pcname>) to an employee that needed some help. They tried other computers and everything was working. They tried it again with a different account that has admin permissions on the target (first) machine and that worked too.

Our helpdesk checked all the permissions but was not able to find any faults. A coworker of mine checked everything again but also was not able to find any configuration issues. Everything looked like it was supposed to.

So I fired up two test machines, added a test account to the "remote assistance users" AD group that is added to the local "Offer Remote Assistance Helpers" group through GPO, and tried to establish a remote assistance session between the two test machine - which worked just as expected.

Next I called the user the other admin could not establish a RA session with and tried it with my test account myself - which actually failed.

The error I got was the following, which looks like the regular issue you get when the user is not a member of the local "Offer Remote Assistance Helpers" group:

After verifying that the test account was indeed a member of that group I added the test account to the local administrator group and tried it again - and it worked just fine.

After verifying again that all the GPOs were applied correctly I checked the eventlog on the target machine but did not find any errors or warnings related to this issue in the "Application" and "System" logs under "Windows Logs". Then I took a look at the "Admin" and "Operational" logs under "Applications and Services Logs\Microsoft\Windows\RemoteAssistance\" but did not find anything there either.

So I checked the eventlog on the source machine and while I did not find anything in the "Application" and "System" logs the "Admin" log under "Applications and Services Logs\Microsoft\Windows\RemoteAssistance" had an error entry for me.

Event ID: 9

There was a problem interacting with COM object 833E4010-AFF7-4AC3-AAC2-9F24C1457BCE. An outdated version might be installed, or the component might not be installed at all.

The German version of that error message reads as follows:

Bei der Interaktion mit COM-Objekt 833E4010-AFF7-4AC3-AAC2-9F24C1457BCE ist ein Problem aufgetreten. Möglicherweise wurde eine veraltete Version installiert, oder die Komponente wurde noch nicht installiert. 

The "Operational" log did not show any errors at first glance ... until I took a closer look at the entries.

What I saw where "Info" log entries that actually reported errors. Especially two of them raised some eyebrows as I had never seen them before:

Event ID: 41

(English) Diagnosis Repro Attempt resulted in a failure

(German) Fehler beim Reproduzieren der Diagnose. 

Event ID: 44

(English) Remote Assistance troubleshooting has confirmed the problem: Remote Assistance Easy Connect isn't available

(German) Das Problem "Easy Connect für die Remoteunterstützung ist nicht verfügbar." wurde von der Problembehandlung der Remoteunterstützung bestätigt.

After some searching on the internet I came across a thread on the Microsoft TechNet community where they were discussing a similar - if not the same - issue I was dealing with. After filtering out the usual comments I came across one that was referencing the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole" and the two values "MachineAccessRestriction" and "MachineLaunchRestriction" which had in their case mysteriously been renamed to "MachineAccessRestrictionOld" and "MachineLaunchRestrictionOld" respectively.

I checked the one affected machine and my test machine and almost as expected my test machine had the correct key while the affect machine had the "<x>Old" keys. Renaming one of the keys on my test machine to "<x>Old" automatically renamed the second key too. After removing my test account from the local administrator group on my test machine again I tried to establish a remote assistance session only to be greeted by the same error message I was getting from the employee's machine earlier. Success! I was now able to reproduce the issue without pestering the user anymore.

So I tried renaming the registry values back to what they were originally named, removing the "Old" part ... except that was not possible. They were always reverted back to "<x>Old".

In an attempt to circumvent whatever Windows was doing in the background there I exported the registry key and all its values, edited the resulting .reg file to only contain the "MachineAccessRestriction" and "MachineLaunchRestriction" values (with the "Old" suffix removed), deleted the two values from the registry and imported the modified .reg file.

After verifying that the values were not getting automatically renamed to "<x>Old" anymore I tried to establish a remote assistance session again and was not disappointed - it was working again.

After doing the same on the employee's machine and testing it I informed the other admin that the machine was fixed and that he could do his job again.

But now comes the hard part ... figuring out what caused this issue and whether this was an isolated issue or not.

Searching around the internet (now that we know what to search for) revealed that this issue exists since at least June 2019 on Windows 10 1809 - but we are now in August 2020 and are running Windows 10 1909. So over a year and two major feature upgrades later we are still seeing an issue like that? Great ...

While I was waiting to hear back from Microsoft about how to fix this issue I was collecting data on how many machines in our domain were actually affected by this, using a simple Powershell startup script. And after three weeks of taking inventory I had found around 40 machines out of over 4000 active Windows machines on our network. So just shy of 1% of our machines were affected by this. Too small a number that the cause of this issue could be anything stemming from a configuration error, since all our machines run basically the same configuration. So it must be a bug or some weird edge case of sorts.

The approach described above (exporting the broken keys, renaming them in the .reg file, importing them again) worked on some of the 40+ affected machine but not on others. On some machines I had to do the import first and then delete the "<x>Old" entries. On others the newly imported entries would instantly get deleted or instantly renamed to "<x>Old" again. No idea why ...

In the end I kind of gave up on fixing most of the affected machines because it only affects so few clients and also only users without admin privileges who try to establish a Remote Assistance session. In addition to that Microsoft also informed me (on 16.09.2020) that the (Windows) Product Group is investigating the issue and will release a KB to fix the issue. Though they were not able to give me an ETA on this.

[1] https://www.reddit.com/r/SysAdminBlogs/comments/j18uov/msraexe_remote_assistance_refuses_to_connect_for

[2] https://twitter.com/BeingSysAdmin/status/1310819839456538624