MSRA Remote Assistance not working for "Offer Remote Assistance Helper"

Question

_{Wednesday, December 18, 2019 3:57 PM}

Hello,

we are facing an issue on Windows 10 1903 devices.

On most of those devices we can't send a "msra /offerra" request as an registered Helper (local group). But if we send it as an registered admin (local group) on the device we can send a request.

Any ideas?

All replies (33)

_{Thursday, December 19, 2019 7:37 AM}

HI
1.can you enter winver in command prompt on both win10 helper's computer and customer's remote pc then look the os version and os version number ?[for example windows 10 enterprise 1809 (os build 17763.316)]
2.are both win10 client computer and remote pc in the same AD domain and in the same network segment?
3."But if we send it as an registered admin (local group) on the device we can send a request."
what do you mean ?do you mean you need to add the it admin account to the local administrator group of customer's remote pc win10?
4.we can use below link method to verify your technet forum account so that you can post picture and website link.
https://social.technet.microsoft.com/Forums/en-US/5c00b9a9-3afe-4ee9-bbf0-34157716b92a/verify-my-account?forum=reportabug

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Thursday, December 19, 2019 9:32 AM}

Hi,

1. Helper: Windows 10 pro 1903 build: 18362.476
   Customer: Windows 10 pro 1903 build: 18362.535

2. Yes they are both in AD and are in the same Network segment

3. If we add the Account of the Helper into the Customers local Administrator group it works. Of course our Domain Admin works everytime but we have other "Helpers" who are not allowed to be local Administrators

Thank you!

_{Friday, December 20, 2019 1:50 AM}

HI
4.after the helper click "help someone who has invited you" ,which next step we select "use an invitation file" or "use easy connect" on helper's computer .

5.are helper account and customer account in the same AD domain ?
is it not your condition that helper account in main domain and the customer account in sub domain?

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Friday, December 20, 2019 7:35 AM}

Hello,

4. We use the /offerra function which is the "Advanced connection option for help desk"

5. Yes they are in the same AD Domain. No that is not our condition. We do use OU's but all the GPO's are the same and it is even the same user. 

Let me explain that: I have an Account (Mustermann) in the AD Domain which is in the AD Group that is listed in the local group as an "Helper" is logged in in Computer A and also in Computer B if he sends a msra /offerra to Computer A (which was installed with Feature Update) from Computer B the request will be denied immediately.

If Mustermann sends a Request (msra /offerra) from Computer A to Computer B (which is a freshly installed system) the request will go through without any error.

Before the Feature Update on Computer A everything worked.

This is my test scenario right now. But we do have computers that were installed the same way as Computer B and are denying the same way as Computer A.

_{Monday, December 23, 2019 2:12 PM}

HI
"If we add the Account of the Helper into the Customers local Administrator group it works. Of course our Domain Admin works everytime but we have other "Helpers" who are not allowed to be local Administrators"

my test environment:helpers' computer win10pro(1909) , customer's computer win10pro(1903)
I have reproduced your issue. i think we can deploy below domain policy for the OU which only contains customer's computers. this policy should not be applied to helpers' computers.after deploying below policy on costomer's computer ,we need to enter gpupdate /force on both DC and customer's computer .

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment 
Deny log on locally   add helper's account or add helpers group
Deny log through remote desktop services add helper's account or add helpers group

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Wednesday, December 25, 2019 8:12 AM}

HI
Is there any progress on your question?

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Friday, December 27, 2019 9:59 AM}

HI

Is there anything to help you?

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Tuesday, December 31, 2019 10:02 AM}

HI

Is there any progress on your question? If there is any reply that helps you, could please you help me mark it as an answer so that other community members could find the helpful reply quickly ? Your contribution is highly appreciated.

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Thursday, January 2, 2020 6:32 AM}

Hello Andy,

Thank you! I am sorry for not answering but I was on vacation.

I tried the solution but it didn't work for me.

Also we do need that also on Helpers Computers. Because some helpers need help from helpers.

Any other ideas?

_{Thursday, January 2, 2020 10:14 AM}

HI
Happy New year !Thanks for your reply.
"I tried the solution but it didn't work for me."""If we add the Account of the Helper into the Customers local Administrator group it works""
I add helper account into the Customers local Administrator group on customer's win10 1903 pro.
so it will let helper to use MSRA .But I also configured the below policy deny helper account to remote logon and locally logon customer's computer .now helper still can use msra remote control customer's computer ,but helper account can not remote logon and locally logon customer's computer . 

it's very strange, I had tested successfully in my lab.
we need to find after we set below policy apply on customer's computers ,why below policy can not deny helper account remote/locally logon on customer's computer .
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment 
Deny log on locally   add helper's account or add helpers group
Deny log through remote desktop services add helper's account or add helpers group

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Thursday, January 2, 2020 12:35 PM}

Hi,

Happy New Year.

Now I know what you wanted from me.

I didn't put the "Helper" as "Administrator".

This will work but it is not a good solution for a big company as ours.

I figured out that putting the "Helpers" in the local group "Distributed COM Users" the request also works.

But I am not sure what this group exactly does.

_{Friday, January 3, 2020 3:17 AM}

HI
there is document for your reference.
Distributed COM Users is a new built-in group included with Windows Server 2003 Service Pack 1 to expedite the process of adding users to the DCOM computer restriction settings.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc738214(v=ws.10)?redirectedfrom=MSDN

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Friday, January 3, 2020 9:00 AM}

Hi Andy,
thank you for your feedback.

Unfortunately those two options are not a realy good solution since "Adding the group to not logon locally" is not working for us and "Adding the User to Distributed COM Users" is also not working because the Users in that group can run a "CMD" as Admin. Which is not the best fit for us.

Any fix or informations on the problem from Microsoft? Since you successfully reproduced the issue?

_{Friday, January 3, 2020 1:36 PM}

Hi Andy,

I think I found the Problem:

in DCOMCNFG if you navigate through "Component Services - Computers" and Right Click on "My Computer" and Display the Properties you can edit the "COM Security" and in "Launch and Activation Permissions" if you "Edit Limits..." In there should the "Offer Remote Assistance Helpers" Group have Accesss to "Remote Launch" and "Remote Activation".

Unfortunately I am unable to edit this settings even though I am logged in as "Domain Admin" and have full Admin Rights. Everytime I change settings it will be reset automatically. My Computer that is working does not have those Problems and the group is in there by default. I can edit rights and I can add/delete groups. 

I have double checked my theory by adding the AD Helpergroup to the  "Performance Log Users" and it worked.

Can you confirm my theory and maybe provide a solution?

_{Monday, January 6, 2020 10:54 AM}

HI
after we  enable "configure offer remote assistance" policy and add helper account in it, when customer's computer reboot, there should be "offer remote assistance helpers" group and helper account should in it on customer's win10 1903 pro? like picture.

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Monday, January 6, 2020 12:02 PM}

Hello Andy,

yes the group appears but it is not in the "DCOMCNFG" as a group in "Launch and Activation Permissions".

If we disable the GPO the group also disappears. After enabling it again it reappears (as it should).

Any Idea on the DCOMCNFG?

_{Tuesday, January 7, 2020 3:34 PM}

HI
6.do you mean you can click "edit limits" in launch and activation permissions but you can not change all user permissions like picture ?

7.can you enter gpresult /h c:\dcom.html in command prompt on client computer then search if there is any dcom related policy ?

there is a document for your reference
Windows Component Services Troubleshooting: Unable to edit DCOM security permissions
https://social.technet.microsoft.com/wiki/contents/articles/50926.windows-component-services-troubleshooting-unable-to-edit-dcom-security-permissions.aspx

8."Unfortunately I am unable to edit this settings even though I am logged in as "Domain Admin" and have full Admin Rights."
if we unjoin the test issue win10(1903) from domain to workgroup ,then enter  gpedit.msc to edit local group policy for " offer remote assistance" and add one local account ,will you also not edit it.
when your issue client in workgroup, your issue still exist , please check the symptom in a clean boot (refer to windows 10 steps) environment on win10(1903)if it is possible. Ensure the latest update has been installed to avoid known issue
https://support.microsoft.com/en-us/help/929135/how-to-perform-a-clean-boot-in-windows

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Thursday, January 9, 2020 7:00 AM}

Hello Andy,

unfortunately I am unable to unjoin my test computer.

Could you reproduce the issue I am explaining to you? Since you said you have the same issues with /offerra?

The article you are referring to is not going to help since this setting is not located as adcom config it is the preference of the computer!

There is also now DCOM related GPO! If there were any related GPO's to DCOM we would have this issue on all PC's.

_{Monday, January 13, 2020 7:43 AM}

HI

10.Could you reproduce the issue I am explaining to you? Since you said you have the same issues with /offerra?
I am sorry ,after i try to troubleshoot another user's case and restore checkpoint on win10(1903) ,i can not reproduce your issue now.

11"Before the Feature Update on Computer A everything worked."
are you make sure feature update cause your issue ?
after upgrading from win10(1809)  to win10(1903) (feature update)on computer A then cause your issue ?
if you can sure it is update issue ,please Ensure the latest update has been installed to avoid known issue on both customer's computer and helper's computer then run below command in command prompt(open as admin) on issue win10(1903) computers.
sfc scannow
dism /online /cleanup-image /scanhealth   
dism /online /cleanup-image /restorehealth 

12."There is also now DCOM related GPO! If there were any related GPO's to DCOM we would have this issue on all PC's".
do you mean there is a dcom related local policy applied on issue win10(1903) ?
do you mean there is only one win10(1903) have this issue ?

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Tuesday, January 14, 2020 1:10 PM}

Hello Andy,

thanks for the feedback.

As far as I am aware it could be the issue after the feature Update but we do have computers with 1903 that are freshly installed and have the same issue. We have also freshly installed 1903 that do not have this issue.

I have run every command you suggested. None worked. Neither SFC scannow found any issues nor /scanhealth found any inconviniences on the system. The system has every Windows Update installed.

12. I am sorry. I meant "NO". We do not have any GPO that interferes with DCOM.
We have this issue on at least 20 devices that I know. But there could be more with this issue.

Anymore ideas?

_{Monday, January 20, 2020 10:12 AM}

HI
13.“We have also freshly installed 1903 that do not have this issue.”are both issue win10 and normal win10 added in AD domain ?

14.when the normal win10 and issue win10 in the same OU and we can log on the same account then do below steps to capture process monitor log.
(we must find normal win10(1903) whose "offer remote assistance helpers" is in the "DCOMCNFG" as a group in "Launch and Activation Permissions").

0)we can select "show analytic and debug log" and enable applications and services logs\microsoft\windows\remoteassistance tracing first like below picture 1

1) download and install process monitor v3.5 on both normal win10 and issue win10

2)Open the process monitor, press “Ctrl+E” to “suspend” it, “Ctrl+X” to clear present process information. 3)Press “Ctrl+E” to start the process monitor again.

4)enter gpupdate /force in command prompt on both normal and issue win10 then we see below picture2 then Press “Ctrl+E” to “Suspend” it again then save the present log(Ctrl+S).  save all event as normalwin10.pml and issuewin10.pml

5)compare what's difference between normalwin10.pml and issuewin10.pml about "offer remote assistance helpers" process like picture 3 i add testd

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\RAUnsolicit\printer\testd

6)we can check if there are more log about this issue in below location .

client win10 event viewer\windows logs\

application

security

system

applications and services logs\microsoft\windows\remoteassistance

admin

operational

tracing

14 we need to compare what's difference between normal win10 and issue win10 about ole registry key permission and its content like "machineaccessrestriction" and "machinelaunchrestriction" like below picture 4

Best Regards
Andy YOU
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Tuesday, January 21, 2020 11:12 AM}

Hello Andy,

following happens:

When I run pocmon I see these differences:

Working:

Not working:

Regedit:

Working:

Not Working:

Permission is the same but after running the GPUPDATE /force The keys "MachineLaunchRestriction" and "MachineAccessRestriction" will be renamed to: "MachineLaunchRestrictionOld" and "MachineAccessRestrictionOld". I have tried and delete the Registry Entries and create them again but they still will be just renamed to "Old".

In EventViewer I see following Errors:

On Sending machine:

On Denying machine he is Entering Conditional block at Lines 1611/1614/369/399/402 and 406 of "File:base\diagnosis\ra\dcom\src\gpsettings.cpp"  :

After that the "Errors" appear:

"Hit exception block of code at base\diagnosis\ra\dcom\src\gpsettings.cpp Line 735 in function CRAGroupPolicy::SetMachinePermissions"

"Hit exception block of code at base\diagnosis\ra\dcom\src\gpsettings.cpp Line 1540 in function CRAGroupPolicy::RAHelpersGrantPermission"

"Hit exception block of code at base\diagnosis\ra\dcom\src\gpsettings.cpp Line 1795 in function CRAGroupPolicy::RA_EnableORASupport"

"Hit exception block of code at base\diagnosis\ra\dcom\src\gpsettings.cpp Line 60 in function CRAGroupPolicy::RAGroupPolicyRefresh"

_{Tuesday, January 21, 2020 7:24 PM}

Do you have an AV product installed during your upgrade? We had this issue and I narrowed it down to Domain policy and an AV product clashing during the upgrade that causes the OLD being appended to the OLE keys. If you try an upgrade to the next Windows 10 build without the AV product , you will likely see the OLE keys repaired. In my case its Trend micro, behavioural protection on, and having our RA group policy in place that seems to cause this.

_{Wednesday, January 22, 2020 7:44 AM}

Hello Barry,

uninstalling Trend Micro and upgrading to 1909 is not an option for us at the moment.

Our head of security disapproves with uninstalling trend micro.

Is there any other way of reparing the OLE keys?

SFC /scannow and CHKDSK did not help.

_{Wednesday, January 22, 2020 7:52 PM}

 Hi TK

,

Your findings line up with mine, Check disk and other repair methods do not work, Only a new installation or upgrade generates the proper OLE  keys for remote assistance access. MS does not recommend playing around with those OLE keys in the registry, as it won't get you anywhere. I had a Call open with them, and they tried. Your security department should know its Microsoft's recommendation that 3rd party AV are removed before upgrading. Windows Defender could cover the gap until you Reinstall your 3rd party AV product

Using a MS SCCM Windows 10 upgrade task sequence would be the most efficient way to do this, remove Trend. then reboot, upgrade the computer and then install the TM client back on as soon as its done. Let Defender provide temporary protection, with the Task sequence it would only be in an "unprotected state" for a few seconds. This is not a not an option for me, but maybe it works for you.

Also, if you have Trend Micro support, please open a call with them. The more the merrier.

But Back on topic:

Upgrading 1809 with TM XG 12.0.5383 sp1 to 1903 breaks my OLE keys and remote assistance .

I am currently Testing the newest version of Trend micro client 12.0.5464 and upgrading 1903 to 1909 in hopes, the OLE DCOM keys are not damaged(renamed to OLD). I am also hoping that on a computer where they were damaged in a previous upgrade they will be regenerated. I will share my results after I complete multiple tests.

If you have a chance to test these builds together let me know. I would appreciate it.

Thanks

_{Wednesday, January 22, 2020 11:20 PM}

1) I tested the newest version of Trend micro client 12.0.5464 and upgrading 1903 to 1909.

Result:

This left remote assist as a Non admin not functional. It also appended OLD to the values under HKLM\software\microsoft\OLE Machineaccessrestriction and  the machinelaunchrestriction keys.

_{Thursday, January 23, 2020 3:08 PM}

I also did some testing and I upgraded my freshly installed 1809 VM with Trend Micro Version 12.0.1952 to 1903 and I did not have this issue on that machine.

Even if Microsoft is not recommending changing the "OLE" Key in the registry, I think we need to find a way to alter these keys. Maybe reinstalling them or something else.

_{Thursday, January 23, 2020 3:34 PM}

I have exported the Key: HKLM\Software\Microsoft\OLE 

from a working machine and imported the registry key via "Connect Network Registry" on the not working machine while no one was logged in to the not working computer.

Once the import was "partly" successfull I have deleted the "Old" keys and the "normal" keys stayed.

Gpupdate /force and the Group settings were applied and I was able to change the DCOMCNFG again and I saw that every setting is now as it should.

MSRA is working now.

But how can I deploy this solution to all my affected devices?

_{Thursday, January 23, 2020 9:49 PM}

Congrats, that worked for you. For some reason, I did the same test with importing keys from a good machine with Microsoft and they weren't able to make it work that way, and MS also recommended against it. I believe the reasoning being the DCOM binary value can differ from computer to computer based on security groups that have different permissions on different computers in the Org.

When I attempted to Delete the OLD keys they always came back with a reboot or regedit refresh.

Have you been able to run a report to see if all of your known good computers in your environment have the same binary values for those keys? If the values are all identical  on all your good machines I assume you could use a script to import the registry key into each bad machine with SCCM from a Package or deploy a script through Group policy.

A side note : When you upgrade again to 1909 Windows 10 , the OLE Keys will have OLD appended again. At least that what I am seeing.

If we disable behavioural monitoring and service protection in the Trend micro policy before upgrading the OLE OLD keys are not created and MSRA is not affected.

After reading your Post and seeing the Group policies not applying in your earlier screen shots, You have given me an idea. I will test and get back to you.

_{Friday, January 24, 2020 8:44 AM}

Congrats, that worked for you. For some reason, I did the same test with importing keys from a good machine with Microsoft and they weren't able to make it work that way, and MS also recommended against it. I believe the reasoning being the DCOM binary value can differ from computer to computer based on security groups that have different permissions on different computers in the Org.

Did you imported the keys from a different machine via "Connect Network Registry"  and no one was logged in to the system that it was imported to?

My thinking behind that is that I don't want to have the binary values of the keys restored, I want the permissions to the OLE Key restored, since I couldn't change anything in the DCOMCNFG and the procmon said the same (Only Read access has been granted not full access).

After the OLE Keys imported I was able to change permission in the DCOMCNFG and the changes stayed.

I have to check if this is working on different computers as well. I will give feedback on that.

_{Tuesday, February 18, 2020 11:01 PM}

I have a case opened with Trend micro and they have reproduced the issue. We are waiting to see what happens. I will update when I have news.

_{Thursday, March 19, 2020 3:01 PM}

Bladeni here:

To allow Remote assistance in Enterprise environment example AD these changes must be made in GPO:

Open Group Policy Management

Navigate to Domain under forest, right click and choose create a GPO in this Domain, etc

For practical purposes name it Remote Assistance

Right click Remote Assistance and click edit

Computer Configuration/Administrative Templates/Network/Network Connections/Windows Firewall/Domain Profile

• Windows Firewall: Define inbound program exceptions : Enable

enter these lines into the rule above:

• Windows Firewall: Define inbound port exceptions : Enable

Computer Configuration/Administrative Templates/Network/TCPIP Settings/IPv6 Transition Technologies

• Teredo State :  Enabled 
  Select from the following states: Enterprise Client

Computer Configuration/Administrative Templates/System/Remote Assistance

• Offer Remote Assistance Enabled 
  Permit remote control of this computer: Allow helpers to remotely control the computer
  Helpers:

Domain\IT_HELP-DESK

Domain\JohnDoe

Enter the above under helpers

Domain is the actual domain name; Example Contoso

Replace Domain with your actual domain name example:

Contoso\IT_HELP-DESK
Contoso\JohnDoe

The IT_HELP-DESK is a group that you can create and then add the users you want 

Domain\JohnDoe

JohnDoe is user you want to grant remote assistance

_{Wednesday, May 20, 2020 8:38 AM}

Hello Bladeni,

the solution you provided was already tested (as discussed).

The only Solution for the problem is to export the OLE Key from a working computer and import the key to a not working computer.

But Microsoft is not supporting this solution and this is also no solution for me, since we need to apply this to about 200 computers.

Doing that manually is a lot of work and there is so much that can go wrong. Also if Trend Micro is responsible for this problem after a feature update and they don't fix this, we will run into this error once again after the next feature update.

So right now we are waiting for Trend Micro to fix this problem.

I hope that Barry will update us once the ticket from Trend Micro is closed.