Centralized policy definitions – Bad idea! … with a remedy.
On several occasion in the past few years (and twice in the past month, probably the result of interest in piloting Windows 10 and/or Office 2016), I noticed a very bad Microsoft idea being implemented in a client’s domain environment: a central policy definitions store is created at
\dns.domain.namesysvoldns.domain.namePoliciesPolicyDefinitions
and is populated with some collection of ADMX/ADML policy definition templates (in both recent cases copied from a Windows 10 machine of unknown vintage).
Doing this prevents *all* machines in the environment from which any policy editing is ever done (my XenApp 6.5 servers being just one example of such) from being able to use their own platform-specific, version-specific and custom policy definitions. For my situation at these clients, any ADMX/ADML collection older or newer than the most current Windows 2008 R2 definitions is bad and/or confusing – I want to see all the policy settings that are applicable to the 2008 R2 XenApp servers, and none that aren’t – and anything other than the Microsoft Office policy definitions for the version installed on XenApp means that I (for example) can’t properly manage Office policies because they are seen by the policy editor as just “Extra Registry settings” that are not explained and cannot be modified. Adding more policy definitions (e.g. for additional Office versions) into the central store is *not* a good solution to this, because it further confuses the situation and doesn’t solve the problem of a different Windows version’s policies being displayed (e.g. there are like millions – okay, hundreds – of new policies defined for Windows 10 and Server 2016 and, while editing policies for Windows 7/8.x or 2008/2012 R2, it would be torture to wade through them and ignore the inapplicable ones if the Windows 10 definitions were the ones placed in the central definitions store).
Bottom line: the central store idea was, at the time it first appeared, one of the worst ones Microsoft ever had, because they initially and for a long time thereafter provided no way for a domain machine to say “no thanks, I’ll use my own definitions”) and should even now probably only ever be used in incredibly uniform environments where every machine in the joint is running the same version of Windows, Office, etc., no machine uses custom or modified policy templates, and all machines are always updated at the same time (in lockstep with the central policy definitions) – yeah, I know of no such environment either! My message to those who might unthinkingly implement a central policy store is “If you’re so in love with your set of policy definitions, put them where you use them without imposing them on everybody else!”.
However, should you run into this situation and can’t talk sense into your client (a shameful consulting fail, by the way J), Microsoft did at some point released a hotfix (An update is available to enable the use of Local ADMX files for Group Policy Editor) which, when installed and the following Registry entry added (set to 1), allows a Windows 7/8.x or 2008/2012 R2 machine to force the continued use of its own local policy definitions during editing, i.e. a “thanks but no thanks” setting:
Key: HKEY_LOCAL_MACHINE\SoftwarePoliciesMicrosoftWindowsGroup PolicyEnableLocalStoreOverride
Type: REG_DWORD
Value: 0 (use PolicyDefinitions on Sysvol if present – Default)
1 (always use local PolicyDefinitions)
You’ll need to reboot after applying this hotfix (which is not delivered through Windows Update).
Thought you’d want to know.