The never-ending Command Prompt

Last Updated on February 24, 2022 by rudyooms

This blog will be about some new ADMX backed policies for MDM. After trying them out I ran into some weird behavior.

I will divide this blog into multiple parts

  1. Introduction
  2. Configuring the CSP
  3. Troubleshooting
  4. Bug Fixed


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

Looking at the picture above it looks like we can finally block the Cmd and Regedit by configuring a CSP, right? That’s nice, really nice. Let’s try them out shall we?

2. Configuring the CSP

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″/>

3. Troubleshooting

But after configuring and after the policy arrived at the device nothing happened…Opening Regedit was still possible. That seems kinda odd. I opened the eventlog to check out the DeviceManagement-Enterprise-Diagnostics event log. Looking at the events it showed me some errors, one of them was this one: 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: “MDM Policymanager: 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 me again the same error: “Rejected by licensing”.

After again receiving that same error, 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.

4. Bug Fixed

After some time, Peter Klapwijk received an email from Microsoft confirming it was a Windows bug. And a few days later he received another: “Bug found, fix made”. So it should be fixed in a future release.


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 the latest build 200828-1431 is still not working.

2 thoughts on “The never-ending Command Prompt

  1. Hi there, I was just wondering if this issue was ever resolved? I’m looking to apply this restriction to a group of users, and wondering if this is possible.

    1. I guess that blog definitely needs some updating 🙂

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

      But never tested it anymore.. lets find out if its fixed!

Leave a Reply

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

2  +    =  10