Hello,

Administering classroom computers is an exercise in uniformity. My mandate is to make the end user experience identical in any classroom a professor might teach. The options to standardize settings are two-fold, curate a custom default user profile in Windows, or use Group Policy.

Microsoft introduced Group Policy to Windows 2000 when that product was still in beta. Group Policy allowed administrators to specify and enforce any setting available to them in the policy. As Microsoft progressed in developing Windows, Group Policy followed bringing more options to administrators. Every domain-joined Windows computer and domain users are subject to several group policies without any specific changes being made. Windows Active Directory (AD) domains come with two default Group Policy objects (GPO). Starting with Windows 2000, every “Professional” or “Enterprise” version of Windows which was based on the NT kernel came with a local Group Policy object. Anything that can be set in a registry key, can be set through Group Policy. Windows Server 2008’s version of Group Policy introduced the ability to specifically set preferences for Windows and its users along with the regular policies.

An administrator can completely control Windows desktops and servers through a Group Policy object. Software using MSI installers can be deployed with Group Policy. When set up correctly, Group Policy can be a very handy administrative tool. If it is set incorrectly, Group Policy can be a challenge to troubleshoot and fix. The effects of a GPO are widespread and can apply to every computer or user in the domain or an OU just as easily. A desired change can spread just as quickly as a detrimental mistake through a GPO. Most important of all, a good GPO can end the days of admins having to visit each computer to change settings en masse.

The basics of Group Policy are simple to understand. Any user or computer underneath the scope of the GPO will receive the settings specified. Despite the name, Group Policy does not directly apply to groups, though it is possible to configure it that way with application permissions. Normally, objects being managed by a GPO must live in an object under that GPO whether it is a domain or an OU. There are exceptions to this, but we’ll hold off on that for now. Since a single Active Directory object could theoretically have several GPOs applied at the same time, GPOs have an order in which they are applied.

First, any and all settings from the local GPO are applied to all users and that one computer. Local GPOs only affect the computers on which they’re stored. This is the only way a user or computer not joined to an Active Directory domain will receive settings from Group Policy. Local GPOs are helpful if an AD domain in not in use or available. However, I do not recommend their use in AD domains because their change has to be done at the local level. Then, admins are back to running around. I’d use a local GPO to enforce settings that I know will never ever need to be changed. The number of possible settings that would fall under that description are pretty small. A good example is the GPO setting that enables/disables Windows 10’s sign-in animation. I always disable it. No one likes or appreciates Microsoft’s new animated approach to a first-login progress bar.

Second, is the Active Directory Site. As much as a Site would seem to equate to a physical location, it does not. AD Sites are groupings of domain controllers (DC) either from within the same domain or from multiple domains in the same AD forest. Sites are purely for configuring replication policies. Active Directory replication is automatic within a site (default). Replication across sites is not automatic at all and must be set up manually. I have never needed to use a GPO at the site level outside of a test lab, ever…

Third, is the Active Directory domain. Every AD domain within an AD forest ships with two default GPOs, the “default domain GPO” and the “default domain controllers GPO.” The domain GPO lives at the root of the domain while the DC’s GPO is attached to the domain controller’s OU. They are the only default GPOs Active Directory provides. They’re not the only GPOs possible within Active Directory. Many many more GPOs can be created at the domain level for whatever reasons the administrators decide is best. Settings which are appropriate for every computer and user in the domain, DCs too, are best at this level. Those settings are often not too specific in every example, but can be very helpful in providing a baseline configuration that all computers should have. For example, the Windows Firewall’s setting of “protect all network connections” can be enforced for every computer in the domain, including sub-level OUs. Any required firewall rule exceptions can be defined in that same GPO. Antivirus software or endpoint management client software can be deployed with Group Policy at the domain level. As soon as a new computer joins the domain, it gets the assigned software if the software is not already installed.

Lastly, the Organizational Unit (OU) is the final place a GPO can be applied. All GPOs, no matter where they are applied, have the same settings. At the OU level, configurations can become very specific. This design can level down with OUs having sub-OUs, each with their own GPOs. The settings here are good for one particular group of users or computers can be placed within an OU and administered as necessary. This how I organize my classroom computers in our domain. I have it set that any Windows computer that is placed in the classroom OU can be working as such without any local modification necessary.

All settings from all assigned GPOs will apply to a user or computer in the order of local, site, domain and OU. In the event of a conflict in settings between GPOs, whether from GPOs at different levels or from the same level, the setting from the GPO applied last wins. There are, of course, exceptions to this rule, but we’ll deal with that later.

What will be the best way to approach a GPO to configure your end user’s computers is determined by figuring out what should be controlled and how to provide that configuration. Some settings can be configured and built into the operating system image. This is a fine option, but it lacks versatility. Suppose the configured setting’s requirement changes or the determined setting was incorrect. To remedy this, a new image must be created and those computers already-deployed with the previous image will need to be fixed. The same setting deployed with a GPO would just need the proper adjustment in the GPO. No new image needed. No visiting end user computers or concocting exotic repair scripts.

The latest work I have done with Windows 10 shows that an image without a pre-configured custom default user profile has the quickest login time for new users. In a classroom environment, fast logins are very important. End user profiles are not kept on classroom computers for reasons of privacy. Every time someone logs into one of my classroom computers, they are doing so for the first time whether they have done so in the past or not. A login time of 90 seconds can be tedious for a 45 minute class. The recipe to ensure fast logins is to not modify the default user profile. Let the Windows default profile (2-5 MB in size) be what everyone gets. How then are the settings end users need provided to them? Group Policy. I use Group Policy to control the behavior of the Windows 10 operating system, Microsoft Office 2016, Mozilla Firefox, Google Chrome, and Adobe Acrobat Reader DC. Everything from what the user sees on the login screen to the default file type associations are set by a GPO.

The next steps are to compile a list of all the desired configuration settings and then map them to their respective GPO settings. If a GPO setting does not already exist for the changes trying to be made, see if a GPO template is available, or use Group Policy to distribute a registry edit which will change the desired setting. Group Policy is extensible. Each time Microsoft releases a new build of Windows, new GPO templates come with it. Third party software vendors such as Adobe and Google graciously make GPO template files available for their products. By default, Group Policy will only cover the Windows operating system. To manage Microsoft Office or any other product, the proper GPO templates have to be added to a Group Policy Central Store, which is configured on a DC, manually, by administrators.

Given how easy it is to change settings for Windows through Group Policy, a small mistake has the potential to become a large problem quickly. I practice due diligence in this respect and test every desired GPO change in a dedicated test environment before it is implemented on the production network. No exceptions… If you’re new to Group Policy and have little to no understanding of it, leave it alone until a rudimentary understanding is held. There are ample resources for learning Group Policy online. Try all GPO-related ideas in a test environment. Make sure the test environment is a representation of the production network. The closer the resemblance between the test network and the production network, the more accurate test results will become. There should be as little room as possible for surprises from a GPO setting implemented on the production network that was implemented successfully during testing.

Once a concise list of the settings needed to give the end user the desired environment is compiled, implementing in a test environment is the next step. Depending on the starting point, the settings can be few or they can be extensive. To make GPO management simpler and to not reproduce identical settings in other GPOs elsewhere, I create my GPOs to do one or two specific things. A giant, all-encompassing GPO, which sets everything desired, is compact but not always the best idea. A GPO with dozens of configured settings is difficult to troubleshoot. Several changes will need to be made/unmade to that large GPO to see which one in particular might be the problem. On the other hand, a GPO dedicated to configuring Microsoft Office, Mozilla Firefox, firewall settings, Remote Desktop settings can be applied/unapplied wherever needed and tested much easier. Testing one change at a time is more productive than testing several at the same time and hoping they all work. In the event that a GPO has to be unlinked from its assigned OU, only those settings are removed. All other working settings remain applied from other GPOs. Maybe after a period of successful implementation with no instances of GPO-induced problems, all settings could be rolled into one “known good settings GPO” and applied.

In the next part, I’ll detail the exact settings I use to provide my users with the desktop experience they need to teach their classes without technology getting in the way.

Thank you