New Group Policy

[chekmate1984]

Hi all

 

Having started new job recently, looking to re-do the group policy as its currently a mess. One example is zoom is being installed in 4 different locations to same PC via different OU/GPO'S. One aspect is student/staff restrictions. Is there a sample we can use than creating one from scratch? Ideally i dont like tying staff down too much but enough for it to not cause much issues for us

 

Any ideas or is starting from scratch only option ? We are using LTSC widnows 10

 

Thanks

[jthompson]

For me, I like to have GPOs separated out and named according to their function, with a reasonably consistent naming convention. Some examples:

• AppLocker - General
  
• BitLocker - Allow adding of BitLocker protection to removable media
  
• Drive Maps - Staff
  
• Drive Maps - Students
  
• Power - General Defaults
  
• Power - Exam Computers Keep Awake
  
• Software - MuseScore
  
• Students - Windows Lockdown
  
• Web Browsers - Google Chrome - General Computer Settings
  
• Web Browsers - Google Chrome - General User Settings
  
• Web Browsers - Students - Site Notification Settings
  
• Windows - General Computer Settings
  
• Windows Update - WUFB - Fast Rollout
  

 

So you could work through your existing GPOs and duplicate their settings in a new set of more granular GPOs, rather than starting from scratch. Once you've done that, you'll have hopefully ironed out the sort of messy duplication that you're currently plagued with, and you'll have an easier time of knowing what each GPO is actually doing.

[mavhc]

If your OUs are different for staff and student computers you can just attach the Computer GPOs to those OUs only

 

If you're OUs are different for staff and student accounts you can just attach the User GPOs to those OUs only

 

If you want Computer OUs to happen to Pupil accounts you need loopback

 

Are you looking for existing GPOs to start with?

[Rob_D]

If you're reasonably happy with the final result (the actual settings/restrictions applied to the PCs), you could use Group Policy Results to get a summery of the applied settings and use that as your starting point.

[chekmate1984]

Hi

 

Ideally yes existing to start with and ideas how i can sort out this OU mess as shown atatcthed! As i feel its completely a mess and want to simplify it

[mavhc]

Do all those different groups get different software installed, or different settings?

 

Do they need to?

[chekmate1984]

Some GPO is applied at staff computers, then re-applied further down in multiple places, some have specific softwares for depts.

 

I am not sure why Inventry mapped drive is also assigned at top level when only 5 users or so need it!

 

Some OU have printers too. It is mostly softwares - i plan to over come software installs via SCCM in future so these can all come out of GPO

[jthompson]

I'd recommend each piece of software that's being deployed via Group Policy to have its own GPO, that just deploys that bit of software and does nothing else. Same for printer deployments.

 

Mapped drive assignments can make use of item-level targeting, so your Inventry drive, for instance, although applied at a high level, might only be getting applied for members of a particular security group. That's an okay way to do it, assuming that the security group(s) being used are also reasonably manageable.

[psydii]

Do keep an eye out on whether they might also be filtering by security group, and how GPP filtering might be in play for example our drive maps appear very near the top of our OU structure, but are filtered by security group.

 

Personally I've always tried to bundle up GPOs and their settings into the fewest objects as reasonable and apply them at the highest point possible in the OU Structure. To do this we align the computers OU structure with the physical deployment of the devices (rooms/departments) and then split people (Users) into Staff / Students OUs , with students subdivided into the Year of Entry (that would be if they entered at the lowest point in the school).

 

We can then use security groups to filter additional GPO Settings based on department membership or role (for we have security groups for every department role in school) for both the computer and the user.

 

e.g. SchoolName_PrimaryDomainPolicy (that sits in the OU that contains all user and computer ous/objects except DCs which sit apart), Then there might be "All Computers", "All Laptops", "All Desktops" applying on the computer OUs, and "All_Users", "All_Staff", "All_Students" Appling to the users' OUs. Then if we have departmental specific configurations, we link GPOs to the relevant OU. If we have policies that need to change based on the user of the computer (for example a member of staff logging on to an IT Suite computer rather than their normal laptop) we would have a "user" policy filtered for the role/departmental group linked to the "IT Suite" (computer) OU which sets the specific user settings that need to vary from the standard user settings from the Users' OU/GPO and enable loopback in that policy.

 

Or putting the OU structure more visually:

 

domain root \ SchoolName \ Computers \ Desktops \ Rooms

 

domain root \ SchoolName \ Computers \ Laptops \ Trolleys

 

domain root \ SchoolName \ Users \ Staff

Edited May 23, 2023 by psydii

[psydii]

Despite my spiel above (which is true, from a certain point of view), in practice our OU structure looks a lot like that screenshot. I suspect many of those OUs are more for 'documentation' than 'configuration'.

 

...and @%1; is right, one gpo for each piece of software, and one gpo per printer deployment (I think the Print Management MMC generates these like this?), and we've already covered drive mapping can be done from a top level GPO/GPP and make use of item Level Targeting.

Edited May 23, 2023 by psydii

[jthompson]

Do keep an eye out on whether they might also be filtering by security group, and how GPP filtering might be in play for example our drive maps appear very near the top of our OU structure, but are filtered by security group.

 

Personally I've always tried to bundle up GPOs and their settings into the fewest objects as reasonable and apply them at the highest point possible in the OU Structure. To do this we align the computers OU structure with the physical deployment of the devices (rooms/departments) and then split people (Users) into Staff / Students OUs , with students subdivided into the Year of Entry (that would be if they entered at the lowest point in the school).

 

We can then use security groups to filter additional GPO Settings based on department membership or role (for we have security groups for every department role in school) for both the computer and the user.

 

e.g. SchoolName_PrimaryDomainPolicy (that sits in the OU that contains all user and computer ous/objects except DCs which sit apart), Then there might be "All Computers", "All Laptops", "All Desktops" applying on the computer OUs, and "All_Users", "All_Staff", "All_Students" Appling to the users' OUs. Then if we have departmental specific configurations, we link GPOs to the relevant OU. If we have policies that need to change based on the user of the computer (for example a member of staff logging on to an IT Suite computer rather than their normal laptop) we would have a "user" policy filtered for the role/departmental group linked to the "IT Suite" (computer) OU which sets the specific user settings that need to vary from the standard user settings from the Users' OU/GPO and enable loopback in that policy.

 

Or putting the OU structure more visually:

 

domain root \ SchoolName \ Computers \ Desktops \ Rooms

 

domain root \ SchoolName \ Computers \ Laptops \ Trolleys

 

domain root \ SchoolName \ Users \ Staff

 

Similar here, although more aligned with use cases:

 

Computers
- Classrooms
   - 01
   - 02
 - Offices
   - Careers Office
   - Exams Office
 - Staff Laptops

 

The idea of having security groups for each of the user roles in school is a good one. We adopted it a few years ago and it offers loads of flexibility whilst at the same time meaning far less fiddling with GPOs and file provileges whenever personnel changes happen.

[MatthewL]

I would create a baseline policy for computer, server and users of settings that all users need, then baseline staff policy then settings that need applying to these groups can be applied.

 

Then look at your specifics but keep them as minimal as possible as the more policies the longer things will take to login.