Do you have “Offer Remote Assistance” working on your existing Windows 7 deployment? Are you doing in place upgrades to Windows 10 on those machines?

If so, you may run into a difficult to troubleshoot error when trying to offer unsolicited remote assistance using a non-administrator group.

The user offering to connect is a member of our domain RemoteAssist group, as configured in Group Policy under “Computer Configuration-> Policies-> Administrative Templates-> System/Remote Assistance” Helpers. This group is magically added to the local group called “Offer Remote Assistance Helpers” by the group policy behind the scenes.

On a Windows 7 workstation or a clean installed Windows 10 workstation, that is all that is needed to make it work. On an in-place upgraded workstation, you get the error above.

Testing Remote Assistance with a local administrator account on the destination workstation worked, so I knew we had a permissions issue, not a firewall problem. Where to begin? I started with local User Rights assignment, thinking it might be there. But, it wasn’t. (There were a couple of differences between a clean Windows 10 install and an upgrade, but they did not impact this.)

Next step was to get out WireShark, since I had no idea where it was failing. That led me to a DCE/RPC error of “nca_s_fault_access_denied”.

So, we have a DCOM issue somewhere. But where? After some searching, I opened up the Component Services mmc on a clean image and found that the “Offer Remote Assistance Helpers” local group had Remote Launch and Remote Activation permissions in the Launch and Activation Permissions section of the COM Security tab. This didn’t exist on the upgraded workstations. Bingo, there’s our missing permission.

Clean install of Windows 10

In place upgrade Windows 10

How to fix it? There appear to be some PowerShell ways to manage the permissions in Component Services. There’s also a Group Policy way to edit them as well. But, that’s a forced setting, I’d prefer a softer, Group Policy Preferences way.

In the end, we “fixed” it by adding our domain RemoteAssist group to the local “Distributed COM Users” group via GPP, which has the permissions it needs already.