Home / server / Questions / 576467
In Process
myron-semack
Asked: 2014-02-19 06:41:28 +0800 CST

OK to modify HKLM\Software\Policies and HKCU\SOFTWARE\Policies on a domain?

  • 772

Background:

I have a domain (2003 Functional Level) with a mix of Windows XP and Windows 7 clients. We have been using Group Policy to manage our workstations.

Now, I am in a situation I need to apply different GPO Policies (not Preferences) based on some complex logic. I might be able to create multiple GPOs and do security/WMI filtering, but it's going to get messy. A script would be a much cleaner approach for us (PowerShell specifically).

What I want to do:

I want to use startup scripts to enable GPO Policies. It seems that my logon scripts could edit the contents of HKEY_LOCAL_MACHINE\SOFTWARE\Policies and HKEY_CURRENT_USER\SOFTWARE\Policies. These registry entries are well documented and setting them is pretty straightforward. I have seen plenty of cases of people doing this online, but I want to make sure this is a sane idea before I do it.

The PCs will still be joined to the domain, and there will still be some GPOs present (Default Domain Policy at the very least). So, conflicts with any existing policies is a possibility. I am expecting the following will happen:

  • If the policy item is "not configured" in a GPO, there is no conflict. The registry value in my the startup script will be written and the policy will take effect.
  • If the policy item is set to Disabled/Enabled in the GPO, it will collide with my script. The script may "win" at startup, but during background refresh it will get overwritten.

So, is my understanding correct? Is this an OK thing to do?

group-policy

2 Answers

  1. Your understanding is correct.

    When your company gets to the size that you need to bring in a dedicated Windows sysadmin they're going to be unhappy that you did this.

    I can't imagine that your logic is so complex that it couldn't be solved by the built-in functionality in Group Policy. Security Group filtering, WMI filtering (which is performance-expensive but flexible), and Item-Level Targeting in Group Policy Preferences all bring a large amount of flexibility to the table. Sticking with stock operating system functionality means that you can get support from Microsoft and qualified third-parties, too. Tell us more about your logic needs, if you are so-inclined.

    From a functionality perspective, you're throwing away a lot. The first few items that c ome to mind include background refresh, site awareness, SYSVOL redundancy, and stock OS management, logging, and reporting tools. I'm sure there are lot more that I'm not thinking of.

    From a maintainability perspective: When you roll your own thing and it breaks you get to keep both pieces. When you leave the company you leave them "high and dry" with what may seem, to you, like something simple and self-documenting but, to the next person, will present some degree of learning curve (especially if your logic is so complex).

    To speak to your comment re: version control - I'd argue that you can "version and diff" Group Policy Object settings fairly easily using the Powershell cmdlet Get-GPOReport, which can output an XML file containing the GPO settings.

    • 6

  2. Your understanding is correct, but when the computer is starting up, you might end up your script changes not working in case of conflict and priority settings (e.g. the GPO which has the startup script runs first, and then there is another GPO that modifies that value)

    GPO modeling provides you with a single view of what configuration is in place. When you take some of the settings out, doing an RSOP on the client will tell you only half the story. If people supporting the workstations are not aware that you are inserting these keys and that's affecting the machines, troubleshooting will be a bit harder.

    • 0