The most important tool we'll use for creating and viewing Group Policy Object is called the Group Policy Management Console or GPMC. You can find this in the Tools menu of Server Manager or by running gpmc.msc from the command line. You can see that the layer of GPMC is similar to other management tools that we've used in Active Directory. On the left, we see the structure of Active Directory. GPMC had several containers to it's GUI. These are AD containers I'll use. There are management interfaces that only show up in GPMC. The Group Policy Objects container will hold all of the GPOs that are defined in the domain. The WMI filters container is used to define powerful targeting roles for your GPOs. These filters use properties of Windows Management Instrumentation or WMI. Objects to decide whether or not a GPO should apply to a specific computer. Group Policy results is a troubleshooting tool that's used to figure out what Group Policies apply to computer and user in your network. You would use this tool to check on Group Policies that are already applied to a computer or user. On the flip side, Group Policy modeling is used to predict which Group Policies will apply to a computer or user in your network. You use this tool if you wanted to test a change to your GPOs, OUs, or WMI filters before making real changes in your Active Directory. Remember that the users and computer containers are not Organizational Units. Group Policy Objects can only be linked to domain sites and OUs. If computer and user objects are in the default containers, they can only be targeted with GPOs that are linked to domains and sites. It's a good practice to organize your user and computer accounts in OUs so they can be targeted with a more specific Group Policies. Now, let's get started with Group Policy Objects not in GPMC, and take a quick look at a GPO that already exist. In a brand new Active Directory domain, there'll be two GPOs that are automatically created; the Default Domain Controller Policy and the Default Domain Policy. The Default Domain Policy is, as you might guess, a default GPO that's linked to the domain. It applies to all of the computers and users in the domain. The Default Domain Controller Policy is linked to the Domain Controllers OU, and applies, you guess that, to the domain controllers. What we're looking at here is a settings report for the Default Domain Policy. This GPO is designed to enforce policy decisions that we want to make for the entire domain. For example, the minimum password length policy prevents users from setting passwords that are too short. The audit account logon events policy says that the computer should create a Windows event for each successful and failed logon attempt. There are thousands of settings that can be controlled with GPO. It can take some research to find the right setting to change in a Group Policy Object to make a change that you want. Group Policy has been around through several versions of Windows, and sometimes things aren't exactly where do you expect to find them. Don't despair. There are lots of documentation online about Group Policies and where to find specific settings. Pro tip. Some thing that you might find super useful are the Group Policy settings reference that Microsoft releases with each new version of Windows. This reference is a spreadsheet that details a GPO Policies and preferences that are available and where to find them. Next, let's try changing one of the settings in our Default Domain Policy. Before we get started, I'm going to make a backup at the GPO. I'll right-click on the "Policy" and choose Backup. I've created a GPO backup folder on my desktop. But in a real environment, we'd want to create a network folder that's locked down to only allow Domain Administrators to access it. I can add a description here too to help me remember why I made the backup, then I complete the backup wizard and I'm done. Now, I know that if I make a mistake, I can restore the policy from backup. I'll right-click on the "Policy" again. But this time I'm choosing Edit. This will open up the Default Domain Policy into the Group Policy Management Editor. You can see over in the left-hand pane that the GPO is divided into two sections; computer configuration and user configuration. Each of these is divided into policies and preferences. Inside this tree of policies and preferences is every individual GPO setting that GPMC knows about. Whether it's been configured or not. Every GPO has access to the same settings that every other GPOs access to. There aren't special GPOs. Even so, it's a good practice to make different GPOs that each address a specific category of need. For example, you might have a GPO that handles all of the settings for a specific group of users, or one that handles security policies for the whole domain. With specific GPOs, for specific solutions, you can link your GPOs to only the computer or users that need that policy. Since you're working with the entire universe of Group Policy in every GPO, it can be very difficult to tell from the Editor what settings are actually configured in this GPO. Refer back to the settings report in GPMC for that information. It looks different. But you might notice that the settings report is laid out in the same hierarchal fashion as the GPO Editor. I can see that the account lockout threshold is configured to zero invalid logon attempts. Let's take a look at that policy and the GPO Editor. I'm going to use a settings report as a roadmap to finding that policy in the Editor. Let me show you how. I'm going to go ahead and right-click "Default Domain Policy, " hit "Edit," and then I'll have this to the side, so we can look at our roadmap. As you can see, computer configuration. I click "Computer Configuration," then click "Policies," Click "Windows Settings," I going to click "Security Settings," and then "Account Policies" because we're interested in the lockout policy. You can see that there are three policies under account lockout policy. The policy column tells us the name of the policy and the policy setting tells us the current configuration of the policy. If a policy is not defined, then this GPO won't make any changes to that setting on the computers that it's applied to. The policy name is pretty easy to understand, but I'm not sure that I understand all of the consequences of changing those values. If I double-click on any of these policies, it will open up the properties dialogue for that policy. Oh, what's this? There's an Explain tab here. Awesome. The Explain tab will tell us what the policy configures. It may also tell us what to expect if the policy is not defined and what the default value of the policy is if it's enabled but not customized. Looking at the explanation of the account lockout threshold policy, I see that by having it set to zero, accounts will never be disabled for failed login attempts. That's not what I want in my domain, so I'm going to change this value. Oh, interesting. It looks like this policy has some dependencies on other policies. I'm going to accept these defaults and now I'll see that all three of these policies in the account lockout policy had been configured. How do we save these changes? As soon as you hit "Apply" or "Okay" in a group policy management editor dialog, the change is made in the GPO immediately, almost right away, computers can receive the update and start applying it. That might not be what you wanted. When you need to make changes to a production group policy, you should test them first. For example, I was playing around with a default domain policy which is linked to the whole domain. I've just immediately made it so all user accounts will be locked if they enter their password incorrectly once. Whoops, where's the Undo button? Guess what? There isn't one. Don't worry. This is why we made a backup before starting to work on this policy. Let's restore the policy from backup and undo this catastrophe waiting to happen. Back in the group policy management console, I'm going to right-click on Default Domain Policy in the Group Policy Objects and then select Restore from Backup. This wizard remembers the last place that I backed up a GPO and assumes that's where I want to restore from. So intuitive. Now, it lists each of the GPO backups that are in the folder that we choose. The name of the policy and the time that it was backed up are listed here along with any descriptions that we provided when we did the backup. If I click on View Settings, it will launch my web browser with the settings report of the backup. Cool. I need to get this policy restored so my users don't get locked out of their accounts. The summary dialog shows me what I'm about to do. Let's go there. This all looks right so I'm going to click "Finish" and make sure that my policy has been restored. Perfect. My backup has been restored and my mistake has been undone. As you've seen in this example, before making changes to a GPO, you should always back it up. But what's another way I could have prevented this mistake? That's right. I could have tested my changes. There are lots of ways to do this. Some organizations will have established best practices for testing GPO changes in their environment. If that's the case, then you should follow those standards. You might need to follow a change management process too, in order to notify others in the organization about the changes that you are about to make. What I'm going to show you is just one way of adding some safety to GPO changes. Let's say I have a GPO code, example policy, like a name. I want to make changes to example policy, but I want to test the changes first to make sure that I don't break production machines. First, I set up a testing OU that contains test machines or user accounts. If example policy is usually linked at example.com finance, then computers, then I can create example.com finance computers test and put testing machines in the test OU. This lets the test machines keep all of the existing production GPOs, but gives me a place to link a test GPO that'll override production. Let me go and show you how I do that. I click "Example", click "New", click "OU" and type in finance, and click "Okay". I look for another OU for my computers. Then underneath that, I'm going to go ahead and make a test OU, so I can test my GPO and hit "Okay". Next, I make a copy of the GPO that I want to change and call it something like test example policy. Let me show you how I do that. This is one policy that I have. I'm going to hit "Copy", go to my Group Policy Objects, hit "Paste". Now, let's say we use default permission for the GPOs because we want to make a copy of course, and hit "Okay". You can see it's called Copy of Master. I'm going to rename this to Test Example Policy, Enter. Now, I can make the changes that I want to test in Test Example Policy and link it to my test OU. Let me show you how I link that. I'm going to go into my OU Finance, Computers, then right-click Test. Now, I say link an existing GPO, which is going to be my Test Example Policy right here, and then hit "Okay". After I've confirmed that my changes were the way that I expected, I can make a backup of the test policy then input the backup of Test Example Policy to the production example policy. This makes some extra work for me since I'm a systems administrator, but I also benefit from added safety and peace of mind. By testing my changes on a copy of the GPO on test machines, I make it much harder to accidentally break production machines. Your organization might be using advanced group policy management or AGPM, which is a set of add-on tools from Microsoft that give you some added revision control abilities in GPMC. If you do use AGPM in your organization, you should follow best practices for GPO version control using AGPM.
