Configuration Manager Remote Control not connecting: permissions, firewall and logs

Configuration Manager Remote Control (the SCCM remote tools that helpdesks still use every day) needs four things to line up: the feature enabled on the client, a firewall that lets the viewer in, role-based permissions in the console and the technician on the client's permitted viewers list. When one is missing, the viewer just fails or reports access denied. In this post I'll check each layer in order and show what a working session looks like.

Symptoms#

• The Remote Control viewer can't connect to the device, or connects and then fails before the session starts.
• The viewer reports Access denied, for example for one technician while a colleague can connect to the same device.
• A port test from the technician's computer to the client fails:

PS> Test-NetConnection pc042.contoso.com -Port 2701
WARNING: TCP connect to (10.20.30.42 : 2701) failed
TcpTestSucceeded : False

• Remote control works in the office but never for devices that are only on the internet.

Why it happens#

Session behavior adds a few more rules: with Allow Remote Control of an unattended computer off, only signed-in, unlocked devices can be controlled; with Prompt user for Remote Control permission on, the user must accept; and Access level allowed can be No Access, View Only or Full Control.

How to fix it#

1. Rule out remote connections#

If the device talks to the site only through a CMG or over the internet, Configuration Manager Remote Control won't work by design. Use Remote Help instead, as described in Remote Help in Intune: setup and troubleshooting; for tenant-attached devices, Microsoft also documents remote tools in the Intune admin center.

2. Check the client settings that apply#

Open Administration › Client Settings, then the default or custom device settings deployed to the device's collection, and select Remote Tools:

• Enable Remote Control on clients: configured, with the firewall exception profiles the device actually uses (Domain, Private or Public). If you don't configure the firewall settings, remote control might not work.
• Access level allowed: Full Control if technicians need to take over, not No Access.
• Grant Remote Control permission to local Administrators group: decide deliberately; don't rely on admin rights by accident.
• Permitted viewers of Remote Control and Remote Assistance: Set Viewers lists the users or groups allowed to connect.

Clients pick up changed settings at their next policy retrieval. If a device still behaves the old way, see Configuration Manager client not receiving policy.

3. Confirm the client side#

On the device, check that the remote control service runs and that the permitted viewers arrived:

Get-Service CmRcService
Get-LocalGroupMember -Group 'ConfigMgr Remote Control Users'
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetConnectionProfile | Select-Object Name, NetworkCategory

If the group doesn't contain your permitted viewers, the client hasn't applied the current remote tools settings. If the device's network category (for example Private on a VPN) isn't one of the firewall exception profiles you selected, Windows Firewall blocks the viewer. Then read CmRcService.log in C:\Windows\CCM\Logs for the attempt.

4. Test the network path from the viewer#

Resolve-DnsName pc042.contoso.com
Test-NetConnection pc042.contoso.com -Port 2701

TcpTestSucceeded : True means the port is open. If it's False, check host firewalls and any network firewall between helpdesk and client subnets. Also check the IP address: admins report that stale DNS records send the viewer to a different computer, which then refuses the connection. Compare the result with the IP address on the device itself.

5. Fix permissions#

• In Administration › Security › Administrative Users, give the technician the Remote Tools Operator role (or a custom role with the three collection permissions), scoped to collections that contain the device.
• Add the technician's group to the permitted viewers list. After a group membership change, the technician must sign out and back in so their Kerberos ticket includes the new group.
• Admins also report that users who are only in a nested group of the listed group get access denied; if you see that, list that group directly.

6. Read the viewer log#

The viewer writes CMRcViewer.log to %temp% on the technician's computer. Compare its timestamps with CmRcService.log on the client: if the client log shows no attempt, the problem is network or name resolution; if it shows the attempt and a refusal, it's permissions or session settings.

Verify the fix#

1. From the console, right-click the device and choose Start › Remote Control, or start the viewer and enter the device name.
2. If prompting is on, the user sees the permission request and accepts it.
3. The session opens with the access level you set, and the session bar or taskbar icon appears on the client if you enabled them.
4. CmRcService.log records the session from the technician's account, with no errors.

Prevent it next time#

• Use one AD group for permitted viewers and the same group for the Remote Tools Operator role, so access is managed in one place.
• Include the remote control firewall profiles in your client settings baseline, and include Private when VPN connections use that profile.
• Keep DNS scavenging healthy so names point at the right devices.
• Plan Remote Help for devices that never come back to the office.

References#

• Prerequisites for remote control in Configuration Manager
• Configuring remote control in Configuration Manager
• About client settings in Configuration Manager (Remote tools)