Executing RCT tasks via Config Mgr RUNAS fails

I recently ran into this issue and am having trouble tracking down the cause. From my Win10 workstation, I normally run Config Manager Console using a RUNAS with an elevated access account that has full admin rights to domain workstations. When I run a command from the latest version of RCT 2.5.6334.19976 from the console, such as “refresh machine policy” on a collection, I receive “Access Denied” messages on the majority of the computers.

Executing the same action from the SCCM server, with the same version of Confg Mgr Client and RCT works fine. The only difference being that I am logging into the server with the elevated access account, instead of executing config mgr with the elevated account as “runas”. It appears that the tools are not using the credentials used when executing the Config Mgr Console.

How do i get around this behavior?

Thank you!


Hi Mike,
Could you send the logs from “C:\Users<username>\AppData\Roaming\RecastRCT\Logs” to recast@nowmicro.com? The tools shouldn’t have issues running as a different user account.


While attempting to provide you the logs, I believe I have found the solution. My elevated access account can be described as a ‘2’ account. So normally, all logs associated with running apps under those credentials reside in the C:\Users"2 account"\AppData\Roaming folder. there were no RCT logs in that folder. I found them under my normal access account. This had me examine the way i was executing the Console. I had been executing Config Mgr from a shortcut created using the RUNAS command and the old Config Mgr.msc and NOT the executable linked in the start menu. Changed to the exe and everything working as designed. Mystery solved.

BTW…great work on the tools. This newer version works much faster than the older, powershell based tools.

Also…FYI: I am running tools on SCCM 2016 (1610) running on a 2016 Server on SQL 2016 instance. No compatibility issues on SCCM 2016 that I have found.

Glad to hear you got it working. Thanks for sharing the compatibility information. We do most of our testing against the newest version of current branch these days, so it’s good to hear how the tools are working on other supported versions of ConfigMgr.