none
Any downside to applying GPOs to different desktop versions of Windows via Security Group instead of OU?

    Question

  • Hello,

    Any downside to applying Baseline GPO settings and a few Preference items via security groups instead of OUs?  For example, all Windows 7 computer objects in SecGroup1, all Windows 8.1 computer objects in SecGroup2, and all Windows 10 computer objects in SecGroup3.  Each of these groups would act as the security filter for the application of a set of Baseline GPO settings for each version of desktop OS as well as apply a few GPP items. We've already specified we don't need to 'delegate control' of permissions for any functions, so we are thinking it be easier to apply GPOs via Security Groups instead of OUs.


    Thanks for your help! SdeDot

    Friday, June 12, 2015 8:42 PM

Answers

  • Hi SdeDot,

    From a technical viewpoint there's no functional difference, however, from a workflow process you'll be creating an extra step to be followed for no gain. It might also make it that one step harder (insofar as people forget things and this isn't a normal paradigm) for someone to spot a policy application issue.

    As an aside, I'm curious as to why you're using separate group policy baselines per operating system to begin with? I can understand a separate one for Windows 10 at the moment as that hasn't RTM'd, but for Windows 8.1 and 7 it's more practical to maintain the one policy while sticking to editing it from Windows 8.1 or Server 2012 R2 machines.

    Anyhow, aside from the extra work mentioned above, I can't think of another downside.

    Cheers,
    Lain

    Saturday, June 13, 2015 2:51 AM
  • > Anyhow, aside from the extra work mentioned above, I can't think of
    > another downside.
     
    As long as the OS installation procedure does NOT add the computer to
    the appropriate groups (and possibly remove it from inappropriate ones),
    for OS filtering I'd almost every time would recommend WMI filtering.
    The evaluation time for OS buildlevel (and possibly processor
    architecture) is minimal...
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Monday, June 15, 2015 10:35 AM

All replies

  • Hi SdeDot,

    From a technical viewpoint there's no functional difference, however, from a workflow process you'll be creating an extra step to be followed for no gain. It might also make it that one step harder (insofar as people forget things and this isn't a normal paradigm) for someone to spot a policy application issue.

    As an aside, I'm curious as to why you're using separate group policy baselines per operating system to begin with? I can understand a separate one for Windows 10 at the moment as that hasn't RTM'd, but for Windows 8.1 and 7 it's more practical to maintain the one policy while sticking to editing it from Windows 8.1 or Server 2012 R2 machines.

    Anyhow, aside from the extra work mentioned above, I can't think of another downside.

    Cheers,
    Lain

    Saturday, June 13, 2015 2:51 AM
  • > Anyhow, aside from the extra work mentioned above, I can't think of
    > another downside.
     
    As long as the OS installation procedure does NOT add the computer to
    the appropriate groups (and possibly remove it from inappropriate ones),
    for OS filtering I'd almost every time would recommend WMI filtering.
    The evaluation time for OS buildlevel (and possibly processor
    architecture) is minimal...
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Monday, June 15, 2015 10:35 AM
  • Thanks for the responses.

    Lain: Different baselines are required due to a few settings required on W7 but not on Windows 8.1.  I dont know off the top of my head what the settings are.

    We will use the Quest Active Roles product to use 'Dynamic Groups' to collect Computer objects based on OS version, etc. to populate a group, then use the group as a Security Filter to apply the Baseline and subsequent Group Policies.


    Thanks for your help! SdeDot

    Tuesday, June 16, 2015 2:24 PM
  • Hi SdeDot,

    As far as the requirement goes, I can't say I've seen a reason for this so I'll simply say fair enough.

    That said, if you have to split policy application by operating system version then WMI filters are a far better approach than shadow groups (so long as you're definitely talking about post Windows 6.x and later, as the performance in the Windows XP era was atrocious).

    Using the Quest tool may well alleviate the administrative burden (though you could just as easily script this yourself and put it in a scheduled task) but the advantage a WMI filter will continue to have over a shadow group is that a WMI filter is processed client side while shadow groups require group expansion to take place on the domain controller.

    My personal preference in such situations is always to place the performance load on the clients as it obviously then becomes a distributed workload. Ultimately though, it's your call.

    Cheers,
    Lain

    Tuesday, June 16, 2015 2:38 PM