Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
1  
Definately worth stopping and asking if the complex logic is really required before adding a whole lot of complexity that you will need to work with/around going forward. –  JamesRyan Feb 18 at 14:48
    
Actually, for us, Scripts are easier to manage than GPOs. We all have a programming background and anything you can version and diff in TortoiseSVN is nicer for us. –  msemack Feb 18 at 16:14
    
Sounds like you are setting yourselves up for a fall, but it's your choice. –  JamesRyan Feb 18 at 17:48
    
Not really seeing the problem. We use startup scripts anyway. This would just be pulling some of the policy items out of the GPO and into the script. –  msemack Feb 18 at 18:37
1  
Just how complex can said logic be? Although not too efficient, WMI filtering can get you a long way –  Mathias R. Jessen Feb 18 at 19:58

2 Answers 2

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.