Let's back the train up a little. Some of you know all of this, and may in fact know everything that we discuss in this first chapter. But some will not, and we need to cover our bases. We have already thrown around some terms that are uber important to know and understand as we progress, and there will be more, so let's take a minute to spell out some of the things we are going to be referencing throughout this book:

• Active Directory Domain Services (ADDS): More commonly referred to as simply AD, this is a directory or a listing of all the users and computers that are part of your organization. It's sort of like a really important Rolodex.
• Domain Controller (DC): A server that is running the ADDS role, and therefore stores the information about your organization's directory, is known as a Domain Controller. Most environments have multiple DCs, each of which stores a copy of the directory data because this Active Directory data is so important, you definitely don't want to lose it!
• Active Directory Users and Computers: One of the tools (probably the most common one) that is used to interact with the data that is stored inside AD. Active Directory Users and Computers is a great place to stop for information about, surprise surprise, any user or computer that is joined to your domain.
• Active Directory Sites and Services: Businesses like to grow and make money, and often this means that a company will eventually span multiple geographic locations and network subnets. AD Sites and Services is a tool that helps to organize your physical sites as they pertain to the information stored inside Active Directory.
• Group Policy: Gives centralized management capabilities of both user and computer settings for the machines and user accounts that are part of your Active Directory domain environment.
• Group Policy Object (GPO): These are objects created and stored inside Active Directory that contain the settings that you are applying to users and computers.
• Group Policy Management Console (GPMC): The primary interface that administrators use to interact with Group Policy settings.
• Group Policy Management Editor (GPME): The interface opened when editing a Group Policy Object. GPME is what you use to place settings into GPOs.
• Organizational Unit (OU): Inside Active Directory, you organize your domain hierarchy by placing device and user objects inside containers known as OUs. Each domain object can only be a member of one OU at any given time. This will be important to remember later.

Group Policy is a toolset inside the Microsoft Windows Server operating systems that enables IT administrators to centrally manage many aspects of both their domain user accounts, as well as domain-joined computer accounts. In fact, it can even be used without a domain in the mix, but we'll talk more about that in a few minutes.

Most of the time, Group Policy is used when you need to publish or issue out settings to a wide (or narrow) base of users or client desktop computers within a corporate environment. Group Policy is incredibly useful for these kinds of tasks, and can save IT departments countless man-hours as opposed to putting these same settings into place on all of their computers in a manual fashion. While Group Policy provides desktop administrations with a ton of flexibility and extra free time, it can become even more powerful when you realize that computer accounts inside Active Directory include desktop/laptop computers as well as servers. Most companies have separated roles for Desktop Administrators and Server Administrators, but both can benefit greatly from the powers that are stored inside Group Policy. In today's information-security-focused mindset, where are we most often putting that focus? Certainly, we are somewhat putting that focus on the users and their devices, making sure that those computers aren't influenced in a negative way from outside forces, but I would say that the majority of our network-security provisioning is placed on the server infrastructure side. The servers in your network are the devices that are providing services and storing your data. Keeping that data safe is a big, big deal. Securing your servers is essential in today's world, and there are many ways that Group Policy can be used to enforce that security.

All of this sounds good on paper, but that doesn't mean anything unless you know how to set up, configure, and really use Group Policy. That is the entire purpose of this book. We will be hands-on, as much as possible, as we discuss Group Policy, its management consoles, and the ways that you can use it right now in your network. There will be many step-by-step examples of establishing and distributing common settings that companies are using to secure their environments. We will also cover examples of settings that are not so commonly used, but probably should be. There are many ways to spend money on third-party solutions to have management capabilities of your company devices, but for anyone who really takes some time to dig into Group Policy, I think you will be surprised at how many of those capabilities already exist and are just waiting to be tapped into.

So far, I have mentioned Active Directory about a million times, so based on this section heading, you are probably assuming that we are discussing Active Directory Group Policy. That is correct, but it is also important to note and understand that the AD perspective is not the only way to think about Group Policy settings.

Every Microsoft Windows operating system (starting with Windows XP) has a grouping of configuration settings that is accessed and structured in a similar way. These configuration settings can be used and tweaked to manage and manipulate the workstation or server to your heart's content. This locally-stored conglomeration of settings that exists individually on each machine is known as Local Group Policy, or sometimes simply Local Policy. These local settings could certainly be used on a machine-by-machine basis to administer your entire workforce, but there is nothing centralized about it. You would be talking about massive man-hours to accomplish all of these changes.

If you're sitting in front of a Windows computer right now, Local Group Policy can be accessed by clicking Start | Run, typing GPEDIT.MSC, and pressing Enter:

Throughout this book, we will spend much more time in an interface quite like this one so as to explain the text and settings shown here—but for the purposes of explaining Local Group Policy, this Local Group Policy Editor console is the place where you could make administrative changes to the workstation. The changes you make here take effect immediately, so don't poke around too much, or at least read over the descriptions of the settings very well!

Local Group Policy is great and is a wonderful way to test new settings and to poke around and find out what kind of restrictions you can put into place on your workstations, but running the Local Group Policy Editor on every workstation in your environment and configuring all of the same settings sounds like an administrative nightmare. How do we overcome the centralized administration challenge? This is where we up-shift and start talking about Active Directory Group Policy.

Active Directory Group Policy takes all of these local policy settings and makes them available anywhere inside your domain. The interface for editing policies and settings is almost exactly the same as the local policy editor, but an additional layer of technology is introduced by being integrated with Active Directory. Inside AD-based Group Policy, you have the ability to create a policy (or hundreds of different policies) and quite easily choose which users and/or which computers that those policies apply to. In an organization that is making good use of Group Policy, it is very normal to see dozens of different Group Policy Objects (GPOs) that are being assigned to all sorts of different users, computers, or groups of users or computers. AD Group Policy stores its information on your Domain Controller servers, which is an incredibly nice aspect from an IT perspective because it means you don't need additional servers or infrastructure to utilize Group Policy.

For the rest of this book, we will be focusing on using Group Policy within an Active Directory domain environment.

The bulk of interaction between an administrator and Group Policy will be via a Microsoft Management Console (MMC) called the Group Policy Management Console (GPMC). Chapter 2, Group Policy Management Console (GPMC), is all about this console so we won't discuss it too much here, but the primary things to remember are that the GPMC is the place you will visit to both configure settings and filter where you want them to apply, and that you will be able to launch and tap into this console from many different places within your environment.

Here is a quick screenshot of the GPMC for your viewing pleasure:

Another piece of the Group Policy puzzle that is important to understand is the placement and storage of its data. As mentioned, for the remainder of this book, we will be focusing on Active Directory Group Policy. In this setting, the data for Group Policy settings is stored on your Domain Controller server or servers. Small environments may only have one DC, but any SMB or larger will have multiple servers that are hosting this same role. In some cases, an organization may have hundreds of DCs. When multiple DCs are present, the Group Policy settings and data are replicated among all of them, so the failure of one node does not result in the loss of this data. We will dig deeper into the details on what information is stored, and where, in Chapter 8, Group Policy Maintenance.

This really is quite simple: you need to be running a domain. This is almost assuredly already the case for anyone who works for any company that has any servers. The first server in any Microsoft-centric network is almost always a DC, and the act of having a DC implies that you have a domain, and if you have a domain, then you have Group Policy available to you.

If you want your users to receive settings from Group Policy, the user accounts that they use to log into computers need to be domain accounts, and I think it goes without saying that the same is true for computers. If you would like to enforce settings on to computers or servers inside your environment, they must also be domain-joined. A domain is the hub for so many things inside any company network, including Group Policy processing and settings.

While Group Policy hasn't been around since the beginning of time, I also don't think that it is very important to spend too much time hashing out the details of what versions of Windows Server Domain Controllers have Group Policy, or what client-operating systems can take advantage of Group Policy settings. The reason this is not so important these days is because any operating system, both client and server, that Microsoft is still currently supporting does have Group Policy capabilities. In the very near future, we will start losing Microsoft support for Windows 7, and Group Policy has certainly been around for a lot longer than that.

So, the requirements for Group Policy = One Domain Controller.

However, if you want to establish a GPO and put some settings inside it and actually test it, then we'll need another device or user to which we can apply those settings and really test them out—so perhaps a DC plus a workstation.

Any IT administrator who is working within a Microsoft domain environment, or those who are building networks from the ground up can use Group Policy. It benefits everyone involved—the IT administrator as well as the end users. AD and domain administrators will interact with the Group Policy Management Console on a regular basis to establish settings and design the rollout process for those settings to get to their respective users and computers. End users benefit from Group Policy by having preconfigured workstations that they know to be company-appropriate and, most importantly, secure. In fact, in my eyes, the ability to place security settings and requirements on to users and computers is the single biggest reason that every company should be utilizing Group Policy. We will, of course, spend some time securing your devices within this book.

To make use of Group Policy, you don't really have to understand how it works under the hood. You configure GPOs, which contain settings, and then you instruct Active Directory on who or what those GPOs need to apply to. Then, when those computers and users are connected to the corporate network, and therefore connected to Active Directory, they will automatically receive those GPO settings and put them into place on the computers. In other words, Group Policy processes those settings automatically.

What is very important to understand about Group Policy processing is the hierarchy that it follows. As with most Microsoft technologies, Group Policy processing follows a tree-scheme, where the application of settings flow down branches of a tree. There are four levels—also known as tiers or branches—in which Group Policy processing happens.

The four unique levels of hierarchy for Group Policy processing are called Local, Site, Domain, and OU. Let's spend a few minutes going through each one so that you can understand how they are different, and also how they fit together.

We already discussed Local Group Policy and using gpedit.msc to reference these settings. This is the Local Policy of a computer, and any settings that are plugged into Local Policy will process first when Windows starts. These settings affect the entire computer—it doesn't matter which users are logged in. It is very rare that companies would make use of Local Policy to push any settings, because it means that you would be manually touching each workstation to put these settings into place. That's not very time-friendly. What is most important to understand about Local Policy is that your settings that are plugged in at the local policy level may not always be in effect. Since Local Policy is first to apply, it means that any levels of the Active Directory Group Policy that we are about to cover in a minute will take priority over Local Policy. In other words, your computer might put your Local Policy settings into place, but milliseconds later during the boot process, those settings could be overwritten by AD policy settings.

Something that is sort of outside the scope of this book, but is relevant here, is Active Directory Sites and Services. Inside any Active Directory environment, your DCs will automatically have this tool installed, called AD Sites and Services. The purpose here is to define your physical locations of the network, sites, if you will. The many small businesses have only a single site, and often they never have to even open this tool. Makes sense, as everything is always connected to the same site. However, as soon as you grow your business and expand to a second location, the network typically gets much more complex, and you now have IP subnets that are different between the two sites. Active Directory Sites are defined by what IP address space, or subnet, a computer is currently residing in. When your computer checks in with AD, it is automatically known what site you are part of based on the IP address of your computer.

Here is a quick picture of Active Directory Sites and Services, so you can see the layout and also see that the different sites are defined by which IP addressing spaces they contain:

Once your environment is large enough and you have defined your Sites inside this tool, you have now enabled Group Policy to be able to issue settings to computers (and users) based on the site that they reside in. Users follow the computers in this scenario. If a computer account is logging in and Group Policy recognizes it to be in the GrandRapids site, it will apply all GPO settings that are flagged for GrandRapids. The same is true of any users that log into that computer; since the computer is currently sitting in GrandRapids, any user-based policies that are filtered for GrandRapids will also apply.

Some policies and settings are going to be things that you want to apply to all of the machines or users in the entire domain, and the appropriate place for those settings are domain-level GPOs. It's important to point out that the GPOs themselves are not different as we talk about all of these different policy levels—a GPO is a GPO. The level at which the GPO is linked is what we are talking about when we discuss these hierarchical levels. So far, we haven't discussed GPO links, and that is because we will spend a lot of time discussing links and linking when we start to cover the bases on filtering these GPO settings, in upcoming chapters. For now, we simply need to understand that some GPOs will contain settings that need to apply to everything in the domain, and these GPOs will be linked at the domain level.

In the following screenshot, the Default Domain Policy has been linked at the top level, or root, of the domain:

When you link a policy at the top of the domain, that GPO will filter down to each user account and device account that is present inside the domain to where it is linked, theoretically applying to all workstations, servers, and users. I say theoretically because there are a couple of reasons why a domain-level GPO might not actually apply to everything inside the domain. One of those reasons would be that the GPO was filtered to only apply to certain machines or groups (we will discuss this much more in chapter 4, Advanced Filtering of Group Policy Objects). Another reason is that some locations inside Active Directory may have inherency blocking enabled, which would stop GPOs from applying to any objects contained inside those locations. These locations that I am talking about are called OUs, and they are our next level of GPO processing.

OUs are containing folders for computer and user accounts that are joined to your domain. OUs themselves are managed and manipulated by using the Active Directory Users and Computers tool, and this is the way domain administrators commonly keep all of their objects organized. In a simple environment, you may have an OU for Users and another OU for Computers. Getting a little more advanced may bring you separate OUs for Accounting, Finance, Human Resources, and so on. Taking full advantage of OUs will result in multiple OUs contained within larger-scope OUs. For example, you may have an OU for Accounting user accounts, and a separate OU for Accounting computer accounts. Or you could even create separate OUs for desktop computers versus laptop computers. Maybe one for tablets, one (or many) for your servers... the list goes on and on. If you wanted to get really crazy, you could create a different OU for every single one of your computers! (Please don't do this, as the admin who takes your job after you retire will loathe you because of it.)

Nesting OUs is a very common practice as well. Just like creating folders inside of other folders by using File Explorer, you can use AD Users and Computers to create OUs inside other OUs. This is important for making a clean structure to contain all of your domain objects, but it is also important to the Group Policy processing... er... process.

When you ask any administrator who has worked with Group Policy before, "Where does that GPO apply?" they will almost certainly start thinking in terms of "What OUs does this GPO apply to?" Applying Group Policy at the OU level is our default mentality when working with GPOs, because it is by far the most common tier to which settings are applied. Linking GPOs to particular OUs gives us extreme flexibility in handing different settings to different groups of people or machines. In contrast to the domain-level GPO shown earlier, here is a screenshot of a GPO that is being linked to only one OU (Human Resources). Even though many other OUs exist and contain objects, the settings inside the Firewall Settings GPO will only be applied to those machines that are sitting inside the Human Resources OU:

Now that you know the four tiers of Group Policy processing, let's bring it back to the reason why this is even important. Certainly, you could start creating GPOs and handing out settings willy-nilly without knowing any of this, right? Yes, and you might get away with it for a long time as well, but eventually you'll have to troubleshoot a GPO or figure out where a particular setting is coming from, or perhaps why a setting is not showing up or not working. That is when this information comes into play.

It's also super helpful to know all of this when taking a new job at a new organization where you were not the original creator of the Group Policy infrastructure.

The four types of policy processing are listed in a particular order for a reason. This is the order that the workflow follows when Group Policy does its thing. When a computer boots, it processes the Group Policy settings in this order:

• Local Policy
• Site-level policies
• Domain-level policies
• OU-level policies

The machine flows through these policies from top to bottom, which is a good way to think about it, because when you are looking inside GPMC keeping a top-to-bottom mindset will also help you understand which policies are getting applied first. The settings contained within these policies are applied cumulatively, so they absolutely do have the capability to step on one anothers' toes. If you have conflicting policy settings among two tiers of GPOs, one of them is going to win and one is going to lose. Looking at this list will help you to determine which settings will exist at the end of a GPO processing cycle.

Looking at the processing order list brings to mind a few examples that may be helpful to round out your understanding on this topic:

• Since Local Policy goes first, anything inside any Active Directory Policy has the potential to nullify or change that local policy setting.
• Site-level policies received by a computer will change based on what physical location they are plugged into, so it is important to keep in mind that these settings can be fluid.
• If there is a domain-level policy setting that contradicts a site-level policy setting, the domain-level policy applies last, and therefore wins the day. That setting will be the one that ends up on the client workstation.
• If an OU-level policy applies that conflicts with a site-level or domain-level policy, the OU-linked policy will win every single time.

OUs have even more to consider, because you could easily have multiple GPOs linked to the same OU that could conflict with each other. In this case, one of them is going to win, and in my experience it isn't always the same GPO. This can be a little confusing for sure, so it is critical that you plan the filtering of your GPOs appropriately when creating them.

The capability to have OUs nested inside other OUs also brings some complication to this scenario. Remember the general rule is that Group Policy processes from the top down, so GPOs that are linked to a nested OU will most likely outweigh GPOs that are linked at a higher-level OU.

When a machine receives a GPO setting from a tier that is above the OU where it is sitting, it is known as inheriting that GPO. The term inheriting will be important when we later discuss inherency blocking and the reasons why you may want to do that. Here is an example based on previous screenshots. Computers inside the Human Resources OU will be receiving the settings from inside the Firewall Settings GPO, because it is linked directly to that OU. Computers inside the Human Resources OU may also be receiving settings from the Default Domain Policy, which is being applied at the domain level, and in this case those computers would be "inheriting" those settings from the Default Domain Policy.

Words are great, but getting your hands dirty and jumping into something is the best way to learn. If you don't have an Active Directory environment available to you right now, and if you have never configured a DC before, there is only one place to start—the beginning. Let's walk through a quick and simple lab build-out that will give you everything you need to start testing and working with Group Policy. We will utilize this lab environment throughout the book to showcase the features and settings that we are going to discuss.

For this exercise, we will be building two systems, and I will preface this with the expectation that you have either two pieces of hardware, or a virtualized environment of some sort upon which you will build these two systems. The virtualized environment could be a Windows Server running Hyper-V or VMware, or it could even be a Windows 10 Professional or Enterprise laptop. These specific versions of the operating systems include the ability to add the Hyper-V role to Windows 10, which will give you a fully-capable hypervisor platform that runs right on your laptop, with the ability to spin up two virtual machines that we can use for our lab, as long as your laptop has enough CPU and memory resources to run two VMs at a time.

As you already know, we need a Domain Controller server to be the host for everything that is stored inside our domain, including the Group Policy settings. For this purpose, I have installed Windows Server 2016 Standard. I won't walk through the installation of the operating system itself, but when we start the process it will be on a very fresh installation that has not yet been configured in any way.

Having a DC fulfills our requirements for being able to use Group Policy, but for practical purposes, we also need a system that we can throw settings at to make sure that our policies are doing what we want them to do. For this, I am installing Windows 10 Enterprise onto a client computer that will be plugged into the same network as our Windows Server 2016 Domain Controller.

If you have the resources available, you could also spin up some additional DCs and join them together to increase the resiliency of your domain, and you could also create some additional testing devices. Perhaps you want to test some settings on Windows 10, but you also have some Windows 7 and Windows 8 clients in your network. Or maybe you have a bunch of Windows Server 2012 R2 servers and you want to test applying settings to those servers from Group Policy. Create as many client or server systems as you want to test with, plug them into the same network, and take the same procedures on those devices that we will be taking on our Windows 10 client in order to increase your testing capabilities.

These are step-by-step instructions to create the first DC in a lab environment, or even an environment which you intend to turn into a production network:

1. Install the Windows Server 2016 operating system onto your server, whether virtual or physical. You can run a DC as a Server Core, but if this is your first Windows Server into an environment, I strongly recommend you choose the option for Desktop Experience. Only this option will give you a full point-and-click graphical interface for interacting with your server. The default Windows Server 2016 Standard option is for implementing Server Core, which would generally only be used by more experienced administrators:

2. Once inside the operating system, configure a static IP address. While it is possible to change the IP address of a DC if you really need to, it is common practice to consider an IP address on a DC to be a permanent fixture, because changing it down the road could result in problems. So, choose your IP wisely. Since basically everyone installs both the Active Directory Domain Services and the DNS roles at the same time on all of their DCs, we will assume that should be the case for you as well and as such, you want to also insert this DC's own IP address as the primary DNS address inside the NIC properties, as shown. Alternatively, you could input 127.0.0.1 as the Preferred DNS server, that would work just as well:

3. Give this server a permanent hostname. You can accomplish this by right-clicking on the Start flag, then choosing to open System properties. Then click Change settings under the Computer name section, and press the Change... button:

4. Input the name of your DC. This name will not be able to be changed later, so make sure you pick a good one. DC1 always works well for a test lab:

5. After changing the hostname, you will be asked to Restart the server. Go ahead and do that now. Once it reboots, you should now be sitting on the desktop, looking at the Server Manager tool (it opens automatically).
6. Near the middle of Server Manager, click on Add roles and features.
7. Click Next three times. You should now be at the Select server roles screen. This screen is a list of all the Roles that are available to install on to your Windows Server.

8. Check the box for Active Directory Domain Services. When you select this box, you will be asked whether you want to Add features that are required for Active Directory Domain Services? Make sure to press the Add Features button to agree to add these features:

9. Back at the Select server roles screen, make sure to also check the box next to DNS Server, to make sure those components are installed as well. DCs are almost always DNS servers.

10. Click Next and you'll find yourself on the Select features screen. You don't have to do anything here, but you'll notice that there is already a checkbox next to Group Policy Management. This is your indication that when this role finishes installing, you will have the Group Policy toolset available to you on this new server:

11. Click Next three more times, and then click the Install button. This will kick off the installation process for Active Directory services on this server:

12. When the role installation is complete, you will notice a yellow exclamation mark near the top of Server Manager. Go ahead and click on that, and it will tell you that additional configuration is required for Active Directory Domain Services. Click on the link that says Promote this server to a domain controller.

13. Since this is the first DC in our environment, choose the option for Add a new forest and then type a name for your domain:

14. This name is even more important than the hostname of your DC, because the name of your domain will be integrated into everything and will be around for a very long time!
15. On the Domain Controller Options screen, specify a Directory Services Restore Mode password and click Next. When setting up a brand-new domain, the rest of the settings that default on this page are generally the ones that you want to stick with:

16. Unless you have a specific need to change one of the remaining settings, you can simply click Next through all the remaining screens of this wizard.

17. There will be a few expected warnings on the Prerequisites Check screen, and these are normal. Go ahead and click Install. When finished, the server will reboot automatically. You now have a fully functional domain hosted on this new DC, and you are ready to start playing around with Group Policy!

Now that we have a DC up and running, we need a device upon which we will apply settings to start testing Group Policy. For this lab, I am going to start with a Windows 10 client computer. You could implement additional devices for testing by following these instructions, whether working with Windows 10 or just about any other Windows operating system, the procedure is going to be the same:

1. Install Windows 10 Enterprise on to a computer. In my case, this is another virtual machine that I am plugging into the same network so that it can communicate with DC1.
2. Assign an IP address to this client. As of this moment, my lab does not contain a DHCP server, and so my client computer will not automatically receive an IP address. Instead of building a DHCP, I am going to simply assign another static IP address to my Windows 10 computer's NIC, as we did with DC1. Since DC1 is hosting DNS for my new domain, I will specify DC1's IP address as the Preferred DNS server on my client computer:

3. Define a hostname for this new device. The process has changed a little bit in the newest versions of Windows 10. As we did on the DC1 server, start by right-clicking on the Start flag, and choosing System. Once inside the System properties, scroll down until you see the button that says Rename this PC, and click on that button.

4. Enter the new name; I am going to call this machine LAPTOP1:

5. Restart when prompted.

6. We need to join LAPTOP1 to our domain for it to really communicate with DC1 and be able to pull its Group Policy information (as well as everything else from Active Directory). Microsoft has done some revamping of the settings screens in the newest versions of Windows 10, as they migrate settings from the old Control Panel over to the new Settings interface. This makes the domain-join task a little bit more confusing than it used to be. You will find that you cannot join a Windows 10 computer to the domain from the Rename this PC screen inside the Settings menu. Thankfully, the fix for this is quite simple. If you open the old Control Panel-based System properties, you can still rename and join the domain, just as you have been able to do in the past. Let's walk through that together, because getting into the old Control Panel is not very straightforward.
7. Click on the Start button, and type Control Panel. You will see it appear in the search results. Then simply press Enter.
8. Inside the legacy Control Panel, click on System and Security, and then click on System. This will get you into the old System properties screen, where you can then click on the Change settings link to change the name of the computer, or to join it to a domain, which is what we are going to do:

9. Click the Change... button.

10. Select the radio button for Domain, and then type the name of your domain. If you remember from a few pages ago, I called mine mydomain.local:

11. You will be prompted to enter a username and password of a domain user account that has permissions to join this computer to the domain. Enter those credentials, and press OK. You will now be asked to restart the computer again, and LAPTOP1 is now fully joined to my domain:

We now have a Domain Controller server and a Windows 10 workstation that are fully prepared to communicate with each other. Very soon, we will begin using DC1 to create some Group Policy settings, and then jump over to LAPTOP1 to take a look and see whether our settings were applied without even having to touch that workstation.

There are certain critical pieces of information for any job that are simply "need to know." When discussing Active Directory Group Policy administration, this chapter is that essential material. Remember, not everyone who handles Group Policy has the advantage of having been the original instigator of the domain at their companies. In fact, I would say the vast majority of IT administrators have come into their roles within an organization long after Active Directory, and therefore Group Policy was already established. In this sense, understanding the basic core capabilities of Group Policy and its behavior could turn out to be completely necessary as you jump into an environment that is already established and running in production, but is completely new to you. You are now equipped to start working with Group Policy, and even able to set it up from scratch in the future, should the need ever arise.

In Chapter 2, Group Policy Management Console (GPMC), we will take a closer look at the GPMC, the primary tool you will be interfacing with to create, modify, and control Group Policy.