Recently a IT specialist left a client’s company, and they left some time bombs. One of them was blocking command prompt for the end users. Normally this is not a problem, but they set the policy to a bad scope. Even the admins couldn’t use the command prompt. It was not pretty. So, lets take a look at the policy in our own lab.
Block Command Prompt
The blocking command prompt is very simple but can be done wrong. To start create the policy, it’s located at User > Policies > Administrative Templates > System > Prevent access to command prompt. Set the policy to enable and select yes to block script processing.
Scoping
Since this is a user GPO the scope is very important. Scope is based on the location where you link the GPO. So, if you link the gpo at the top of the domain or site level, everything will get it unless, of course, a counter policy is linked at a lower level that is enforced the same way. Here is the scope applied list.
- Local GPOs
- Site-Linked GPOs
- Domain-Linked GPOs
- OU-linked GPOs
- Child OU-linked GPOs
In this case, the user linked the scope at the top of the domain instead of the OUs that need to be applied to. The simple fix was to move the policy link to the sub OUs.