Group Policy. Jeremy Moskowitz
Читать онлайн книгу.
policy setting that can be configured.
Disabled This setting leads a dual life:
● Disabled usually means that if the same policy setting is enabled at a higher level, reverse its operation. For example, we chose to enable the Prevent Changing Screen Saver policy setting at the site level. If at a lower level (say, the domain or OU level), we chose to disable this policy setting, the Screen Saver option will pop back at the level at which we disabled this policy. You can think of Disabled (usually) as “reverse a policy setting coming from a higher level.”
● Disabled sometimes has a special and, typically, rare use. That is, something might already be hard-coded into the Registry to be “turned on” or work one way, and the only way to turn it off is to select Disabled. One such policy setting is the Shutdown Event Tracker. You disable the policy setting, which turns it off, because in servers, it’s already hard-coded on. In workstations, it’s already hard-coded off. Likewise, if you want to kill the firewall for Windows XP (and later), you need to set Windows Firewall: Protect All Network Connections to Disabled. (You can find that policy setting at Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Network ⇒ Network Connections ⇒ Windows Firewall ⇒ Domain Profile (and also Standard Profile). Again, you set it to Disabled because the firewall’s defaults are hard-coded to on, and by disabling the policy setting, you’re “reverting” the behavior back.
So, think of Not Configured as having neither Allow nor Deny set. Enabled will turn it on, and it will possibly have more functions. Disabled has multiple uses, and be sure to first read the help text for each policy setting. Most times it’s simply directly spelled out what Enabled and Disabled does for that particular setting. Last, test, test, test to make sure that once you’ve manipulated a policy setting, it’s doing precisely what you had in mind.
Final Thoughts
The concepts here are valid regardless of what your domain is running. It doesn’t matter if you have a pure or mixed Active Directory domain with various and sundry Domain Controller types. The point is that to make the best use of Group Policy, you’ll need an Active Directory.
You’ll also need a Windows 10 or Windows Server 2016 management station to do your Group Policy work. Again, we talk more about why you need a Windows 10 management station in Chapters 3 and 6 and elsewhere.
Remember, the GPMC is built into Windows Server 2016, but it’s not installed unless the machine is also a Domain Controller. The GPMC isn’t built into Windows 10 and is only available through the downloadable RSAT tools.
Even though most of the examples of a target computer are Windows 10 in this book, you can usually substitute a Windows 7 or 8 machine as your target and see similar (if not often identical) results.
The more you use and implement GPOs in your environment, the better you’ll become at their basic use while at the same time avoiding pitfalls when it comes to using them. The following tips are scattered throughout the chapter but are repeated and emphasized here for quick reference, to help you along your Group Policy journey:
GPOs don’t “live” at the site, domain, or OU level. GPOs “live” in Active Directory and are represented in the swimming pool of the domain called the Group Policy Objects container. To use a GPO, you need to link a GPO to a level in Active Directory that you want to affect: a site, a domain, or an OU.
GPOs apply locally and also to Active Directory sites, domains, and OUs. There is a local GPO that can be used with or without Active Directory. Everyone on that computer must embrace that local GPO. Then, Active Directory Group Policy Objects apply: site, domain, and then OU. Active Directory GPOs “trump” any local policy settings if set within the Local Group Policy. Active Directory is a hierarchy, and Group Policy takes advantage of that hierarchy.
Avoid using the site level to implement GPOs. Users can roam from site to site by jumping on different computers (or plugging their laptop into another site). When they do, they can be confused by the settings changing around them. Use GPOs linked to the site only to set up special sitewide security settings, such as IPsec or the Internet Explorer Proxy. Use the domain or OU levels when creating GPOs whenever possible.
Implement common settings high in the hierarchy when possible. The higher up in the hierarchy GPOs are implemented, the more users they affect. You want common settings to be created and set one time. It’s not optimal to create many GPOs performing the same functions at other lower levels, which will just clutter your view of Active Directory with the multiple copies of the same policy setting.
Implement unique settings low in the hierarchy. If a specific collection of users is unique, try to round them up into an OU and then apply Group Policy to them. This is much better than applying the settings high in the hierarchy and using Group Policy filtering later.
Use more GPOs at any level to make things easier. When creating a new wish, isolate it by creating a new GPO. This will enable easy revocation by unlinking it should something go awry.
Strike a balance between having too many and too few GPOs. There is a middle ground between having one policy setting within a single GPO and having a bajillion policy settings contained within a single GPO. At the end of your design, the goal is to have meaningfully named GPOs that reflect the “wishes” you want to accomplish. If you should choose to end those wishes, you can easily disable or delete a specific GPO.
As you go on your Group Policy journey… Don’t go at it alone. There are some nice third-party independent resources to help you on your way. I run www.GPanswers.com, which has oodles of resources, downloads, a community forum, downloadable eChapters, video tutorials, links to third-party software, and my in-person and online versions of my hands-on training seminars. Think of it as your secret Group Policy resource.
My pal (and technical editor for this edition of the book) Alan Burchill runs www.grouppolicy.biz and has a wonderful set of step-by-step articles and tips and tricks and such.
My pal (and technical editor for a previous edition) Darren Mar-Elia runs “GPO Guy,” which is part of his software company, SDM Software. Check it out at http://sdmsoftware.com/gpoguy/.
My pal (and technical editor for a previous edition) Jakob Heidelberg has a lot of great articles (mostly on Group Policy topics) at www.heidelbergit.dk/.
Chapter 2
Managing Group Policy with the GPMC and via PowerShell
In Chapter 1, “Group Policy Essentials,” you got to know how and when Group Policy works. We used Active Directory Users and Computers to create and manage users and computers, but we used the Group Policy Management Console (GPMC) to manage Group Policy. We got a little workout with the GPMC when creating new GPOs and linking them to various levels in Active Directory.
And, for just a moment, we went back to the old-school way to delegate control to Frank and the HR-OU-Admins group to link existing GPOs to their Human Resources OU structure.
In this chapter, I’ll cover the remainder of the daily tasks you can perform using the GPMC. As a reminder, the GPMC is for all implementations of Active Directory. That is, you can use the GPMC to manage your Active Directory – whatever the Domain Controllers are that constitute it.
You just need the GPMC loaded up on some machine. Now, in the previous chapter, I put a pretty fine point on it: you want this machine to be one of the latest machines possible, either a Windows 10 or a Windows Server 2016 machine. There are some older editions, but I don’t recommend you use them.
For this edition of the book, I’ve decided to also show the PowerShell equivalent of the GPMC process. In other words, for almost all the things you can do in the GPMC, you could, if you wanted, use PowerShell.
But