Access Denied on local computer

Why does Recast give an Access Denied Message when you preform the following steps?

  1. Logon to a computer as local administrator.
  2. Run the CM console elevated (run as administrator)
  3. Accept the UAC prompt
  4. locate and select the computer you are running the CM console on
  5. Preform a HW inventory (either full or delta)

IMO This should not happen as I have run the CM console as an administrator and SCCM client center doesn’t have this same issue. So…

This is a side effect of the client / server architecture when running without a Recast server. When the console is launched, a new process “Right Click Tools Desktop.exe” process is started as the Recast “server” process and stays resident to handle any Recast actions. This process will not close with the console, so if you launched the console as a non-administrator user, then closed and relaunched the console as an administrator, the “Right Click Tools Desktop.exe” process will still be present from the first console launch and will not have administrator permissions. Because the Recast tools detect that the process is already started, it will not try to relaunch the “Right Click Tools Desktop.exe” process, so any actions you run from the elevated admin console will be sent to a non-elevated process. If you kill the “Right Click Tools Desktop.exe” process and relaunch your ConfigMgr console as admin, your Recast tools should have administrator permissions on the local box.

I just uploaded a new version of the 3.0 beta that I believe will fix this. Now the 3.0 version will monitor the ConfigMgr console process and when it closes, the Right Click Tools Desktop.exe process closes, so you shouldn’t get to a scenario where your ConfigMgr console is launched with UAC but the Recast server process is missing UAC. If you want to try out the 3.0 beta, you can download it here:

Thanks Chris that is exactly what I need to know. I hope to download and try the beta over the long Canada Day weekend. :slight_smile:

thanks for the awesome information.

I’m glad it was helpful. With the 4.0 release in 2019 we made significant architectural changes, and this behavior should no longer exist. I’d recommend getting on a 4.x release if you’re still seeing this issue.

1 Like

thanks my issue has been fixed.

User confirmed that issue has been resolved.