I'm having an issue on Windows 7 x64, whereby users who do have permissions from SCCM Console to connect are unable to, unless they are Administrators of the remote machine. After some testing, I think it could be to do with UAC, which we have enabled. Here are our UAC settings in GPO: User Account Control Policy Setting User Account Control: Admin Approval Mode for the Built-in Administrator account Enabled User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop Disabled User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode Prompt for credentials User Account Control: Behavior of the elevation prompt for standard users Automatically deny elevation requests User Account Control: Detect application installations and prompt for elevation Enabled User Account Control: Only elevate UIAccess applications that are installed in secure locations Enabled User Account Control: Run all administrators in Admin Approval Mode Enabled User Account Control: Switch to the secure desktop when prompting for elevation Enabled User Account Control: Virtualize file and registry write failures to per-user locations Enabled

I dont think that the UAC settings you show would necessary require you to be Administrators of the remote machine simply to connect via Remote Tools (but UAC may affect what happens when you do successfully connect). One know issue that is specific to x64 versions of Windows 7 is that the "ConfigMgr Remote Control Users" group may not always have the required Read and Execute rights to C:Windows\SysWOW64\CCM\clicomp\RemCtrl\RCLaunch.exe. There is a fuller description at http://blogs.technet.com/b/configurationmgr/archive/2011/04/14/configmgr-2007-quick-fix-remote-tools-fail-with-access-denied.aspx .

I dont think thats the issue, as the machine CAN be remoted, just not by certain users. Coincidentally, the users do appear in the ConfigMgr Remote Control Users group locally on machines. I do see the connection in Windows Security Logs, I see: 1. An account was successfully logged on 2. A new process has been created (RCServer.exe), with TokenElevationTypeDefault (1) 3. An account was successfully logged on 4. An account was logged off, Logon Type 3, This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer. This all happens in the space of a few milliseconds...

It may not be the issue but the fact that the machine can be remote controlled by some users (in your case Administrators) would be expected as the Administrators would have full control (and of course Read and Execute permissions) already. The only reason to explicitly grant permissions would be for the non-administrator users who currently cannot connect. The article linked above does not state this explicitly but logically the workaround described would only be necessary where you wanted to remote control using an account that was not an Administrator on the remote machine.

with UAC, you may be inherently causing issues or conflicts with the DCOM remote launch service as well.

with UAC, you may be inherently causing issues or conflicts with the DCOM remote launch service as well.