The never-ending Command Prompt

The never-ending Command Prompt

Some time ago I showed you the options you have to block the administrative tools like CMD and Regedit. Within the latest Windows 10 Insider Preview 20185 I noticed a new ADMX file

So? it looks like we can finally block the Cmd and Regedit by configuring a CSP, right?

I enrolled a new Window 10 Enterprise VM and updated it to the last insider preview update. After my new VM was configured, I tried to configure this CSP by creating a new device configuration profile like this:




<data id=”DisableRegeditMode”value=”2″/>

But nothing happened…Opening Regedit was still possible. That seems kinda odd. DeviceManagement-Enterprise-Diagnostics event log tells me, the ADMX could not be found. After some digging in the registry, I noticed the ADMX was without the “-“. So I removed the “-“  in the CSP URI

URI: ./user/vendor/MSFT/Policy/Config/ADMX_ShellCommandpromptRegeditTools/DisableRegedit

But again… nothing happened. The event log showed a new warning: “Policy is rejected by licensing”. Okay? I have a nice Windows 10 Enterprise device and I have never seen that error on an enterprise device before, that’s for sure 🙂

I can imagine when you are deploying this Policy on Windows 10 Pro devices, it could be a problem as Windows 10 Pro licensed device doesn’t accept all the settings you can configure in Intune.

I also tried the same with the CMD. I opened the ADMX file to create the correct URI and string.

URI: ./user/vendor/MSFT/Policy/Config/ADMX_ShellCommandpromptRegeditTools/DisableCMD



<data id=”DisableCMDScripts”value=”1″/>

But for the third time, nothing happened. I was still able to open the CMD. And the event log showed the same error: “Rejected by licensing”.

After that, I tested it with another policy (Like Peter Klapwijk did) Admx_CTRLALTDEL Policy.  Within a few minutes, the possibility to open the task manager was gone…   That was working like expected.

It was time for me to involve Peter Klapwijk to check if he gets the same error as I did.  He noticed the exact same thing. He reported it to Microsoft.  

In the meantime, I compared the working Policy with the non-working policy.

This is a working Policy:

This is a non-working policy: (I added a new registry entry. In my opinion that one was missing).

I’m not sure this is the problem, but I think it is weird.

After some time, Peter Klapwijk received an email from Microsoft confirming it’s a Windows bug. And a few days later he received another: “Bug found, fix made”.


Never give up and good luck will find you to block administrative tools soon. But still… Applocker is the best option you have. I hope I can create a new blog soon when there is a new build because with the latest build 200828-1431 is still not working.

Leave a Reply

Your email address will not be published. Required fields are marked *

59  +    =  66