When I set the "force X off" policy to Disabled, why doesn’t it force X on?

A customer was using one of the many "force X off" policies, but instead of using it to force X off, they were trying to use it to force X on by setting the policy to Disabled. For example, there is a "Hide and disable all items on the desktop". The customer was setting this policy to Disabled, expecting it to force all icons visible on the desktop, removing the option on the desktop View menu to hide the icons.

As we discussed some time ago, group policy is for modifying default behavior, and interpreting them requires you to have a degree in philosophy.

In particular, a policy which forces X off has three states:

  • Enabled: X is forced off.
  • Disabled: X is not forced off.
  • Not configured: No opinion. Let another group policy object decide.

Disabling a policy means "Return to default behavior", and the default behavior in many cases is that the user can decide whether they want X or not by selecting the appropriate option. In philosophical terms, "Not forced off" is not the same as "Forced on."

If you want to force X on, then you have to look for a policy that says "Force X on." (And if there isn't one, then forcing X on is not something currently supported by group policy.)

Comments (18)
  1. Antonio Rodríguez says:

    In fact, there is no need for a degree in philosophy. What is needed is the ability to read the labels and apply some basic logic to them. An ability that, sadly, is missing from many people that work with those over-logic machines called "computers".

    Of course, the logic is needed because of the double-negative (we are disabling a setting that hides icons, thus we are enabling it to show icons). If the policy was redacted the other way ("Show and enable all items on the desktop"), it would be easier. Now, when will that time machine be ready?

  2. Skyborne says:

    This reminds me of a time I was trying to disable an optional component of a build, and tried all sorts of false-sounding values like WITH_CONTOSO=0.  It turns out that only "defining the variable" was important, regardless of value, and the correct solution was to set WITHOUT_CONTOSO instead.

  3. Adam Rosenfield says:

    A table would be helpful for this customer.  Since this blog doesn't support any kind of tables in the comments, I'll approximate one:

    1st row: The user wishes to turn X on

    2nd row: The user wishes to turn X off

    1st column: The policy "force X off" is enabled

    2nd column: The policy "force X off" is not enabled

    Each cell entry contains a Y if the user's desired is allowed or N if not allowed

    Row 1: N Y

    Row 2: Y Y

    This customer really wants a policy that results in a column of Y/N, instead of the two currently supported columns of N/Y and Y/Y.  I.e., a "force X on" policy.

  4. Adam: You could just use ASCII to draw a table, like we did in the Old Days.

  5. Joshua says:

    @Chris: Sorry but it's variable width font here.

  6. AndyCadley says:

    The annoying thing about this is that the double negatives are absolutely not required, Group Policy templates are perfectly capable of flipping the Enabled/Disabled values the other way around (i.e. Enabled = 0 and Disabled = 1) if needed in order to make the setting easier to use.

    The way Policies are supposed to work is that Not Configured lets the end user decide and Enabled/Disabled force the setting into a particular state.

    [Not sure whether your "supposed to work" is saying "This is how they are designed to work" or "This is how I would have designed them to work." -Raymond]
  7. Veda says:

    To me this totally makes sense. 6/2=3 2/6!=3. You can't always turn things around. That degree in philosophy is not needed.

    I think the problem is that the customer wanted something that was not there, and *hoped* this would work. Hoping is something else than thinking…

  8. Nico says:


    Clearly we need a Unicode mark that indicates text should be displayed in a monospace font :)

    (Ya know, now that I think about it that's not such a bad idea…)

  9. alegr1 says:

    May the "force X on" be with you!

  10. Joshua says:

    ["supposed to work"]

    "supposed to work" is in idiom meaning "intended to work" (still get requirements writer vs. implementer difference here but not implementer vs. end user). It's even pronounced "suppost to work" in this area, indicating that decomposing it into "supposed" as in "believed" is wrong.

    In which case AndyCadley got it wrong.

    [I've seen "supposed to" (pronounced as "suppost") used in the sense of "If I ruled the world, it would…" so I am never sure. (Related.) -Raymond]
  11. Harry Johnston says:

    Disabling a policy does not always mean reverting to the default behaviour, at least not according to the documentation.

    For example, "Turn off Windows Startup Sound" says: "If this policy setting is enabled, the Windows Startup sound will be turned off for all users.  If this policy setting is disabled, the Windows Startup sound will be turned on for all users.  If this policy setting is not configured, the Windows Startup sound will be turned on for all users by default and customizable in the Sound item of Control Panel."

    IOW, it is documented to behave exactly as your customer expected the unspecified setting to behave. :-)

    [Yup, there are some policies that don't follow the general pattern. Consistency is boring! -Raymond]
  12. Matt says:

    Sounds like the UI for Group Policy is unnecessarily confusing. Would be easier if it was a drop-down option like this:

    Desktop items visibility:

    * Always visible

    * User configurable (default)

    * Always hidden

  13. Bill P. Godfrey says:

    Ⓖⓡⓔⓐⓣ ⓘⓓⓔⓐ Ⓝⓘⓒⓞ

    (Alas, I couldn't find a Unicode block of fixed-width characters without decoration.)

  14. laonianren says:

    @Bill The fullwidth forms are monospaced in IE, as they should be, but not in Firefox.

    I originally posted that in fullwidth text but the blog software rejected it as spam.  Even if it did work universally, you can't use it anyway.

  15. hagenp says:

    <tt>Does this render monospaced?</tt>

  16. AndyCadley says:

    I meant "intended to work", because that's how the Group Policy engine does work. There may be individual settings where the code does something different (and to sysadmin's unexpected) but that's a whole different issue.

    [I don't follow. The group policy engine deploys the policy and calculates the effective policy, but it does not implement the policy. That is done by each individual feature. -Raymond]
  17. AndyCadley says:

    Policies that implement the setting by following the rules you've described break the expected behaviour of Group Policy inheritance. If you don't want a setting to be forced either way, you select Not Configured. Enabled/Disabled override this in the inheritance chain, following the rules of policy priority, to force a setting into a fixed state on/off as appropriate.

    The policies that do work the way you've described are an enormous PITA when it comes to trying to design/debug complex policy hierarchies. Whereas the ones like the one Harry Johnston mentions just work.

    [Enabled = Stop searching – the policy is enabled. Disabled = Stop searching – the policy is not enabled. Not configured = Keep searching. If nobody ever configures the policy, then it is not enabled. This is how, in practice, policies are implemented. -Raymond]
  18. AndyCadley says:

    The group policy engine doesn't "stop searching" though, it follows it's L-SDO inhertitance tree. With various caveats relating to Loopback Policy Processing and Blocked/Enforced policy objects.

    The system works well for policies that follow the underlying design and is incredibly flexible, unfortunately developers who didn't understand the implications and constructed policies that don't play properly with the system design have lead to the situation that "requires you to have a degree in philosophy" to understand.

Comments are closed.

Skip to main content