Group Policy: Fundamentals, Security, and the Managed Desktop

Copyright

Copyright © 2015 by John Wiley & Sons, Inc., Indianapolis, Indiana

Published simultaneously in Canada

ISBN: 978-1-119-03558-9

ISBN: 9781119035671 (ebk)

ISBN: 9781119035688 (ebk)

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Web site is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Web site may provide or recommendations it may make. Further, readers should be aware that Internet Web sites listed in this work may have changed or disappeared between when this work was written and when it is read.

For general information on our other products and services or to obtain technical support, please contact our Customer Care Department within the U.S. at (877) 762-2974, outside the U.S. at (317) 572-3993 or fax (317) 572-4002.

Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.

Library of Congress Control Number: 2015946972

TRADEMARKS: Wiley, the Wiley logo, and the Sybex logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.

10 9 8 7 6 5 4 3 2 1

Credits

Senior Acquisitions Editor: Kenyon Brown

Development Editor: Sara Barry

Technical Editor: Alan Burchill

Production Editor: Elizabeth Campbell

Copy Editor: Judy Flynn

Editorial Manager: Mary Beth Wakefield

Production Manager: Kathleen Wisor

Associate Publisher: Jim Minatel

Book Designers: Judy Fung and Bill Gibson

Compositors: Craig Woods and Kate Kaminski, Happenstance Type-O-Rama

Proofreaders: Jenn Bennett, Jen Larsen Word One New York

Indexer: Johnna VanHoose Dinse

Project Coordinator, Cover: Brent Savage

Cover Designer: Wiley

Cover Image: © Mehmet Hilmi Barcin / iStockPhoto

Dedication

For L, A, M, J, B, E, J, and E as we journey through life together.—Jeremy

Acknowledgments

I want to thank Alan Burchill for the second time in taking on the not-so-glamorous job of technical editor. I’m really glad to have you on my team, helping me clean up the little messes I made during the writing process and taking on a heavy responsibility. Note: If there are still any technical problems with the book, blame me, not him. Alan was awesome.

I want to thank Sara Barry for taking my initial chapters and kneading them from a wad of dough into tasty pizza. And to Elizabeth Campbell, who has worked with me through every major project to completion for almost 15 years now. We joke that she’s been making Jeremy sound like Jeremy since 2001. And it’s mostly true. Thank you.

Special thanks to my Sybex and Wiley compatriots: Ken Brown, Mariann Barsolo, Jim Minitel, Mary Beth Wakefield, and everyone else on the Sybex/Wiley team. Once again, your dedication to my book’s success means so much to me. You take everything I create and deal with it so personally, and I really know that. Thank you, very sincerely.

Thanks to Jeff Hicks, PowerShell MVP, who helped me write Appendix A on Group Policy and PowerShell. Jeff, you did a smashing job as usual. Thank you.

Thank you to Microsoft Group Policy team and the Group Policy MVPs who support me directly and indirectly, and help me out whenever they can.

Thank you, Mark Minasi, for being a trusted friend and a great inspiration to me personally and professionally.

A special thanks to my GPanswers.com and PolicyPak Team: You are awesome and it’s great to work with you every day.

Finally, I want to thank you. If you’re holding this book, there’s a good chance you’ve owned a previous edition, or multiple previous editions. Thank you for your trust, and for purchasing and repurchasing each edition of this book I work so hard to bring you each time.

When I meet you, the reader of this book, in person, it makes the hours and hours spent on a project like this vaporize away to a distant memory. Thank you for buying the book, for joining me at my live events and at GPAnswers.com, and for using my PolicyPak software. You all make me the best me I can be. Thanks.

About the Author

Jeremy Moskowitz Group Policy MVP, is the founder of GPanswers.com and PolicyPak Software (PolicyPak.com). He is a nationally recognized authority on Windows Server, Active Directory, Group Policy, and Windows management. He is one of fewer than a dozen Microsoft MVPs in Group Policy. His GPanswers.com is ranked by Computerworld as a Top 20 Resource for Microsoft IT Professionals. Jeremy is a sought-after speaker and trainer at many industry conferences and, in his training workshops, helps thousands of administrators every year do more with Group Policy. Contact Jeremy by visiting www.GPanswers.com or www.PolicyPak.com.

About The Contributors

Jeffery Hicks is an IT veteran with over 25 years of experience, much of it spent as an IT infrastructure consultant specializing in Microsoft server technologies with an emphasis in automation and efficiency. He is a multi-year recipient of the Microsoft MVP Award in Windows PowerShell. He works today as an independent author, trainer, and consultant. He has taught and presented on PowerShell and the benefits of automation to IT pros all over the world. Jeff has written for numerous online sites and print publications, is a contributing editor at Petri.com, a Pluralsight author, and a frequent speaker at technology conferences and user groups. His latest book is PowerShell In Depth: An Administrator's Guide, Second Edition, with Don Jones and Richard Siddaway (Manning Publications, 2013). You can keep up with Jeff on Twitter (http://twitter.com/JeffHicks) and on his blog (http://jdhitsolutions.com/blog).

Alan Burchill works as a manager for Avanade Australia based in Brisbane. He has a normal day job as the lead global Active Directory administrator for a large multinational corporation. Alan has been working with Microsoft technologies for over 17 years and is a regular speaker at Microsoft TechEd and Ignite conferences. He has been a Microsoft Valuable Professional in the area of Group Policy for the past six years. He regularly blogs about Group Policy and other related topics at his website called Group Policy Central at www.grouppolicy.biz. Alan also runs the Brisbane Infrastructure Users Group (www.bigau.org), where he organizes monthly meetings about Microsoft Infrastructure-related topics, and he is the organizer of the annual Infrastructure Saturday event (www.infrastructuresaturday.com), which is a full-day community event about Microsoft Infrastructure Technologies. You can reach him via his website or via Twitter @alanburchill.

Introduction

Windows 10 is here.

Alas, Windows 8 and 8.1, we hardly knew ye.

And Windows 9—we just skipped you entirely and jumped ahead to Windows 10.

For people buying this book for the first time, welcome. For people who have bought previous editions and are returning again (or again and again and again)—thank you for coming back.

Group Policy and Active Directory go hand in hand. If you have Active Directory, you get Group Policy.

If you’re very new to Group Policy, here’s the inside scoop. Group Policy has one goal: to make your administrative life easier. Instead of running around from machine to machine, tweaking a setting here or installing some software there, you’ll have ultimate control from on high.

Like Zeus himself, controlling the many aspects of the mortal world below, you will have the ability, via Group Policy, to dictate specific settings pertaining to how you want your users and computers to operate. You’ll be able to shape your network’s destiny. You’ll have the power. But you need to know how to tap into this power and what can be powered.

In this introduction and throughout the first several chapters, I’ll describe just what Group Policy is all about and give you an idea of its tremendous power. Then, as your skills grow, chapter by chapter, we’ll build on what you’ve already learned and help you do more with Group Policy, troubleshoot it, and implement some of its most powerful features.

For those of you who are already somewhat Group Policy savvy, there is some good and some bad news (which is the same news): From a Group Policy perspective, Windows 10 is not radically different from its Windows 7 or Windows 8 siblings.

Ironically, Group Policy’s innards did get the most recent update between Windows 8 and Windows 8.1, and those carry forward to Windows 10. I’ll explain these when the time comes, so you can understand the behavior changes. Take a look at Table I-1 for how the Windows Group Policy engine evolved when the internal version number changed.

Table I-1: How Windows and Group Policy evolved

Again, Table I-1 shows changes from a Group Policy guts perspective and is not necessarily reflective of what you can do (the actions you can perform) with Group Policy.

Knowing what’s changed within the Group Policy guts is a dual-edged sword. On the one hand, you could say to yourself, Awesome! If I’m already an expert at Windows 7 and Group Policy, there’s not a huge hill to climb! And that would be true. On the other hand, it’s also true that because Windows 8 through 10 didn’t shake things up too much, with regard to Group Policy guts, there’s not a lot of whiz-bang newness to uncover and show off. That being said, the updates in Windows 8.1 (which carry forward to Windows 10) will be covered in Chapter 3.

In a way, I really like the dual-edged sword. I like that there are a variety of new goodies and things you can do with Group Policy for Windows 10, some interesting updates, but not a radical head-spinning change. I like the fact that what is already working in practice doesn’t change that much. I like knowing that the time already invested in getting smarter in Group Policy isn’t for nothing, and you and I won’t have to relearn everything we ever knew all over again.

So, even though the guts haven’t changed all the much, there’s always new stuff you can accomplish with Group Policy as each operating system comes out.

As you likely already know, Group Policy is, at its heart, an on-prem system for management. Isn’t this antithetical to Microsoft’s new battle cry of Mobile first, cloud first?

If you want to read Microsoft’s own perspective on this, see:

http://news.microsoft.com/2014/03/27/satya-nadella-mobile-first-cloud-first-press-briefing/

Shouldn’t Group Policy get a huge overhaul in its underlying technology to align with Mobile first, cloud first?

Perhaps it doesn’t need it. Because Group Policy is, by its very nature, extensible, we can extend Group Policy to the cloud when needed if paired with (at least two) add-ons. Microsoft DirectAccess (beyond the scope of this book, but briefly touched upon in Chapter 3) enables Windows machines to act as if they are always connected on-premise, even though they might be over the Internet at a coffee shop. That being said, DirectAccess only works with the more pricey Enterprise version of the Windows client.

PolicyPak Cloud (demonstrated in Chapter 3 and name dropped throughout the book) can take existing Group Policy directives and get them to the cloud for use on traveling and even non-domain-joined machines. PolicyPak Cloud works with any version of Windows and isn’t limited to the more pricey Enterprise version.

If you’ve done some work already with Group Policy, you might notice that it could be described as various components under one roof; it roughly breaks down as follows:

Group Policy Administrative Templates

Group Policy Security Settings

Group Policy Preferences

Everything else, including third-party extensions

With all that power, and extendibility, Group Policy continues to stay not just relevant but, indeed, central to any Active Directory administrator’s tool belt of required knowledge.

And because Group Policy is extensible, it can keep working in a Mobile first, cloud first world.

Group Policy Defined

If we take a step back and try to analyze the term Group Policy, it’s easy to become confused. When I first heard the term, I didn’t know what to make of it.

I asked myself, "Are we applying ‘policy’ to ‘groups’? Is this some sort of old-school NT 4 System Policy applied to Active Directory groups?"

Turns out, Group Policy as a name isn’t, well, excellent. At cocktail parties, when I tell the person next to me that I teach, write about, and make software to extend Group Policy, they don’t get what Group Policy means.

If I said something like I teach databases, he would cheerfully go back to his scotch and soda and leave me alone. But because I say, I teach Group Policy to smart people looking to get smarter and build software that hooks into Group Policy, he (unfortunately) wants to know more. He’ll say something like What does that mean? I’ve never heard of Group Policy before. And while I love talking about Group Policy with you, my friendly IT geeks, at a cocktail party full of stuffed shirts, I just want to get another canapé.

So, the name Group Policy can be kind of confusing, but it’s also intriguing. Microsoft’s perspective is that the name Group Policy is derived from the fact that you are grouping together policy settings. I don’t really love the name Group Policy—but it’s the name we have, so that’s what it’s called. As Juliet said in Romeo and Juliet (II, ii, 43–44), What’s in a name? That which we call a rose by any other name would smell as sweet.

For me, if I was consulted, I might have named it Windows Policy or Microsoft Policy. But, alas. Group Policy is the name it has.

Group Policy is, in essence, rules that are applied and enforced at multiple levels of Active Directory. Policy settings you dictate must be adhered to by your users and computers. This provides great power and efficiency when manipulating client systems.

Instead of running around from machine to machine, you’re in charge (not your users).

When going through the examples in this book, you will play the various parts of the end user, the OU administrator, the domain administrator, and the enterprise administrator. Your mission is to create and define Group Policy using Active Directory and witness it being automatically enforced. What you say goes! With Group Policy, you can set policies that dictate that users quit messing with their machines. You can dictate what software will be deployed. You can determine how much disk space users can use. You can do pretty much whatever you want—it is up to you. With Group Policy, you hold all the power. That’s the good news.

And this magical power only works on Windows 2000 and later machines. For the sake of completeness, this includes all versions of Windows 2000 and later: workstation and server. Of course, this includes all the modern Windows systems you would use, like Windows 10 and Windows Server 2016.

I’ll likely say this again in multiple places, but I want to get one big ol’ misconception out of the way right here, right in the introduction. The Group Policy infrastructure does not care what mode your domain is in. If you have only one type of Domain Controller or a mixture of Domain Controllers, 100 percent of everything we cover in this book is valid.

Said another way, even if your domain level is the oldest-of-the-old Windows 2000 mixed mode, you’re still pretty much 100 percent covered here. Group Policy is all about the client (the target) operating system and not the Domain Controllers or domain modes.

It is true that wireless settings and BitLocker key storage require schema updates to play nicely with Group Policy. But even then, Group Policy will still work running with the oldest-of-the-old servers.

If the range of control scares you, don’t be afraid! It just means more power to hold over your environment. You’ll quickly learn how to wisely use this newfound power to reign over your subjects, er, users.

Group Policy vs. Group Policy Objects vs. Group Policy Preferences

Before we go headlong into Group Policy theory, let’s get some terminology and vocabulary out of the way:

Group Policy is the concept that, from on high, you can do all this stuff to your client machines.

A policysetting is just one individual setting that you can use to perform some specific action.

Group Policy Objects(GPOs) are the nuts and bolts contained within Active Directory Domain Controllers, and each can contain anywhere from one to a zillion individual policy settings.

The Group Policy Preferences is a newer add-on to the existing set of the original Group Policy settings and abilities many have come to know and love. Group Policy Preferences (sometimes shortened to GPPrefs) don’t act quite the same as their original cousins. We’ll cover the Group Policy Preferences in detail in Chapter 5.

Preference item is a way to describe one Group Policy Preferences directive. It’s like a policy setting, but for the Group Policy Preferences.

It’s my goal that after you work through this book, you’ll be able to jump up on your desk one day and use all the vocabulary at once. Like this: "Hey! Group Policy isn’t applying to our client machines! Perhaps a policy setting is misconfigured. Or, maybe one of our Group Policy Objects has gone belly up! Heck, maybe one of the preference items is misconfigured. I’d better read about what’s going on in Chapter 7, ‘Troubleshooting Group Policy.’"

This terminology can be a little confusing—considering that each term includes the word policy. In this text, however, I’ve tried especially hard to use the correct nomenclature for what I’m describing. If you get confused, just come back here to refresh your brain about the definitions.

Note that there is never a time to use the phrase Group Policies. Those two words together shouldn’t exist. If you’re talking about multiple GPOs or multiple policy settings or policy settings vs. preference items, these are the preferred phrases to use, and never Group Policies.

Where Group Policy Applies

Group Policy can be applied to many machines at once using Active Directory, or it can be applied when you walk up to a specific machine. For the most part, in this book I’ll focus on using Group Policy within an Active Directory environment, where it affects the most machines.

A percentage of the settings explored and discussed in this book are available to member or stand-alone Windows machines—which can either participate (that is, be joined to Active Directory) or not participate (that is, it’s non-domain-joined) in an Active Directory environment.

However, the Folder Redirection settings (discussed in Chapter 10) and the Software Distribution settings (discussed in Chapter 11) are not available to stand-alone machines (that is, computers that are not participating in an Active Directory domain). In some cases, I will pay particular attention to non–Active Directory environments. However, most of the book deals with the more common case; that is, we’ll explore the implications of deploying Group Policy in an Active Directory environment.

The Too Many Operating Systems Problem

If we line up all the operating systems that you (a savvy IT person) might have in your corporate world, we would likely find one or more of the following (presented here in date-release order):

Windows 2000 (Workstation and Server), RTM through SP4

Windows Server 2003, RTM through SP2

Windows XP, RTM through SP3

Windows Vista, RTM through SP2

Windows Server 2008, RTM (known as SP1, actually) through SP2

Windows 7 RTM, through SP1

Windows Server 2008 R2, through SP1

Windows Server 2012, RTM

Windows Server 2012 R2

Windows 8 client, RTM

Windows 8.1 client, RTM

Windows 8.1 Update 1

Windows 10, RTM

Windows Server 2016, RTM

For the love of Pete (whoever Pete is), that’s a lot of potential operating systems. Okay, okay—perhaps you don’t have all of them. You likely don’t have any more Windows 2000 (or maybe you do, tucked in a back room somewhere, quietly processing something or other).

The point, however, is that Group Policy can apply to all of these systems. Under most circumstances, old stuff will work correctly on newer machines. That is, generally, something that could affect, say, an XP machine will also (generally) continue to affect a Windows 10 machine.

With that in mind, here’s an example of what I’m not going to do. I’m not going to show you an example of something in the book, then say something like, and this example is valid for Windows XP, Windows Vista, Windows Server 2008, Windows Server 2008 R2, Windows 7, Windows 8, Windows 8.1, Windows 8.1 Update 1, Windows Server 2012, Windows Server 2012 R2, Windows 10, and Windows Server 2016.

My head (and yours) will just explode if I do that and you need to read it each time.

So, here’s what I am going to do. You’ll read my discussion about something, then I’ll say something like, and this example is valid for Windows XP and later. That would mean that the thing I’m about to show you (for example, a policy setting) should work A-OK for XP and later machines (all the way to Windows 10 and also usually for servers, like Windows Server 2016, too). Similarly, if I say, and this is valid for Windows Vista and later, that means you’ll be golden if the target machine is Windows Vista and later (all the way through Windows 10 and Windows Server 2016).

Of course, there are a handful of exceptions: things that only work on one particular operating system in a possibly peculiar way. For instance, there are a handful of Windows Vista–only settings that aren’t valid for Windows 7 and Windows 8. There are Windows 10–specific settings that won’t work on older machines. Again, I’ll strive for clarity regarding the exceptions—but the good news is, those are few and far between.

If you get lost, here’s a quick cheat sheet to help you remember which machines act alike:

Windows 2000 Workstation and Windows Server

Windows Server 2003 and Windows XP

Windows Server 2008 and Windows Vista

Windows 7 and Windows Server 2008 R2

Windows 8 and Windows Server 2012

Windows 8.1 and Windows Server 2012 R2

Windows 10 and Windows Server 2016

Just to be even more specific, Windows 7, Windows 8, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows 10, and Windows Server 2016 are ludicrously close brothers. They look alike, throw the same temper tantrums, and enjoy the same kinds of movies. But they’re not identical. They are, in fact, different, but in most cases, they’re super-duper similar and will react the same way when poked.

For this edition of the book, we decided to make a conscious choice about how to present Group Policy. Most of the walk-throughs, examples, and screen shots in the book will be of Windows 10 and Windows Server 2016.

Since I wrote the last edition of this book, two friends have passed away. Those friends, of course, are Windows XP and Windows Server 2003. It’s impossible to know how much XP is still out there, but my unscientific guess would be that 30 percent of the PCs in the business world are still using XP as I write these words. That’s not a lot, but it’s certainly not a little either.

As far as I’m concerned though, XP and Windows Server 2003 are dead ends. I mean, they really are: Microsoft has stopped supporting them except in extreme circumstances and special handling cases.

But I do want to be super-clear about something: I am also specifically going to note and talk about the differences between the various operating systems. For instance, I’ll definitely be expressing some concepts as originally found in Windows 2000, and also Windows XP and Windows Vista—things that were originally in these operating systems’ behaviors but are absent or changed now.

When explaining Group Policy, I like to explain how Group Policy evolved from Windows 2000 through Windows XP and Vista and now on to Windows 10. I like to talk about the old-school stuff sometimes, because I find it helps explain why Windows does some things today that seem, well, odd or confusing. If I explain the older operating systems, for example, Windows 2000 and Windows XP, it’s actually easier to understand modern Windows. But as far as actual examples go in this book, sayonara XP (and Windows Server 2003). When it’s necessary to get a deeper perspective on details of Windows XP, I might refer you to previous editions of this book.

And now, a quick word about Windows Vista.

Yes, friends. Vista happened.

We also cannot deny the existence of Windows Vista and that it actually came and went without anyone caring at all.

That being said, even though Microsoft didn’t quite get the taste right with regard to Windows Vista, the individual ingredients continue to be the base of our Windows soup going forward. So, that means Windows 7, 8, and 10 are honestly very minor upgrades from Vista.

And pretty much everything that was once valid for Vista is also valid for Windows 7, Windows 8, and Windows 10. Therefore, you’ll see me write a lot about, and this works for Windows Vista and later, or in some places, like table listings, you’ll see Valid for Vista+—meaning that whatever I’m referencing will work on Vista (if you have it), but it will also work on Windows 7, almost always Windows 8, and onward to Windows 10.

A Little about Me, This Book, PolicyPak, and Beyond

Group Policy is a big concept with some big power. This book is intended to help you get a handle on this new power to gain control over your environment and to make your day-to-day administration easier. It’s filled with practical, hands-on examples of Group Policy usage and troubleshooting. It is my hope that you enjoy this book and learn from my experiences so you can successfully deploy Group Policy and manage your desktops to better control your network. I’m honored to have you aboard for the ride, and I hope you get as much out of Group Policy as I do.

I’ve had and continue to have a long history with Group Policy.

I’ve been writing about and speaking about Group Policy in my hands-on workshops for over 10 years.

I’ve been one of about a dozen Group Policy MVPs, as anointed by Microsoft for 12 years.

And, I’ve also founded a company called PolicyPak Software, which extends Group Policy to do more amazing things than what is possible with what is in the box alone. For instance, here are some of the things you can do with the products from PolicyPak:

Manage just about any third-party application using Group Policy (like Java, Flash, Firefox, Lync [now Skype for Business], OpenOffice, and hundreds more).

Craft exactly when and how Group Policy Admin Template template settings will be applied to users or computers.

Keep Group Policy Preferences items working—even when the computer goes offline.

Learn when a machine is in compliance and out of compliance with what you need it to be.

Deploy almost all Group Policy directives over the Internet and on to machines that might never otherwise be able to get Group Policy.

So, I’m going to try to walk a fine line here. With your permission, I am going to, from time to time, describe when something from PolicyPak could enhance a situation or solve a problem that cannot be solved out of the box. I’ll show you real examples of how to solve real problems.

And I’m doing it not to sell you something, but if that happens, that’s okay, too. The point, really, is to demonstrate a problem or situation that might not have any other way out of it. So basically, if I didn’t explain that the PolicyPak possibility to fix a particular problem existed, you wouldn’t know about it and you’d still always be stuck in a rut.

Meanwhile, as you read this book, it’s natural to have questions about Group Policy or managing your desktops. To form a community around Group Policy, I have a popular community forum that can be found at www.GPanswers.com.

I encourage you to visit the website and post your questions to the community forum or peruse the other resources that will be constantly renewed and available for download. For instance, in addition to the forum at www.GPanswers.com, you’ll find these resources:

Full downloadable PowerShell scripts from the PowerShell chapter

Tips and tricks

A third-party Group Policy Solutions Guide, and lots, lots more!

If you want to meet me in person, book me for onsite training, or attend my live public Group Policy courses; my website at www.GPanswers.com has a calendar with upcoming events. I’d love to hear how this book met your needs or helped you out.

Thanks again for being a part of the journey.

Chapter 1

Group Policy Essentials

In this chapter, you’ll get your feet wet with the concept that is Group Policy. You’ll start to understand conceptually what Group Policy is and how it’s created, applied, and modified, and you’ll go through some practical examples to get at the basics.

The best news is that the essentials of Group Policy are the same in all versions of Windows 2000 on. So as I stated in the introduction, if you’ve got Windows XP, Windows 7, Windows 8, Windows 10—whatever—you’re golden.

Learn the basics here, and you’re set up on a great path.

That’s because Group Policy isn’t a server-driven technology. As you’ll learn in depth a little later, the magic of Group Policy happens (mostly) on the client (target) machine. And when we say client, we mean anything that can receive Group Policy directives: Windows 8, Windows XP, or even the server operating systems such as Windows Server 2016 or Windows Server 2008 R2; they’re all clients too.

So, if your Active Directory Domain Controllers are a mixture of Windows Server 2008, Windows Server 2012, and/or Windows Server 2016, nothing much changes. And it doesn’t matter if your domain is in Mixed, Native, or another mode—the Group Policy engine works exactly the same in all of them.

There are occasional odds and ends you get with upgraded domain types. When the domain mode is Windows 2003 or later schema, you’ll get something neat called WMI filters (described in Chapter 4, Advanced Group Policy Processing). Also note that in a Windows 2008 Functional mode domain level or later, the replication of the file-based part of a Group Policy Object (GPO) can be enhanced to use distributed file system (DFS) replication instead of system volume (SYSVOL) replication.

Regardless of what your server architecture is, I encourage you to work through the examples in this chapter.

So, let’s get started and talk about the essentials.

Getting Ready to Use This Book

This book is full of examples. And to help you work through them, I’m going to suggest a sample test lab for you to create. It’s pretty simple really, but in its simplicity we’ll be able to work through dozens of real-world examples to see how things work.

Here are the computers you need to set up and what I suggest you name them (if you want to work through the examples with me in the book):

DC01.corp.com This is your Active Directory Domain Controller. It can be any type of Domain Controller (DC). For this book, I’ll assume you’ve loaded Windows Server 2016 and later on this computer and that you’ll create a test domain called Corp.com.

In real life you would have multiple Domain Controllers in the domain. But here in the test lab, it’ll be okay if you just have one.

I’ll refer to this machine as DC01 in the book. We’ll also use DC01 as a file server and software distribution server and for a lot of other roles we really shouldn’t. That’s so you can work through lots of examples without bringing up lots of servers. Bringing up a modern DC requires the use of Server Manager. Check out the sidebar Bringing Up a Windows Server as a Domain Controller if you need a little guidance.

Win10.corp.com This is some user’s Windows 10 machine and it’s joined to the domain Corp.com. I’ll refer to this machine as WIN10 in the book. Sometimes it’ll be a Sales computer, other times a Marketing computer, and other times a Nursing computer. To use this machine as such, just move the computer account around in Active Directory when the time comes. You’ll see what I mean.

Win10management.corp.com This machine belongs to you—the IT pro who runs the show. You could manage Active Directory from anywhere on your network, but you’re going to do it from here. This is the machine you’ll use to run the tools you need to manage both Active Directory and Group Policy. I’ll refer to this machine as WIN10MANAGEMENT. As the name implies, you’ll run Windows 10 from this machine. Note that you aren’t forced or required to use a Windows 10 machine as your management machine—but you’ll be able to manage it all if you do.

You can see a suggested test lab setup in Figure 1-1.

Note that from time to time I might refer to some machine that isn’t here in the suggested test lab, just to illustrate a point. However, this is the minimum configuration you’ll need to get the most out the book.

To save space in the book, we’re going to assume you’re using a Windows 10 machine as your management machine. You can also use a Windows 8 or 7 management machine as well and be able to work through pretty much everything in the book, barring a few new things that got born in Windows 8.1 and are still present on a Windows 10 management machine. If you’re forced by some draconian corporate edict to use a Windows Vista or Windows XP (or earlier) machine as a management machine, you’ll have to refer to previous editions of the book to get the skinny about using them.

Figure 1-1: Here’s the configuration you’ll need for the test lab in this book. Note that the Domain Controller can be 2000 or above, but Windows Server 2016 is preferred to allow you to work through all the examples in this book.

For working through this book, you can build your test lab with real machines or with virtual hardware. Personally, I use VMware Workstation (a pay tool) for my testing. However, Microsoft’s Hyper-V is a perfectly decent choice as well. Indeed, Hyper-V is now available built into Windows 8 and later. So, you could bring up a whole test lab to learn Windows 10—on your Windows 10 box! What a mindblower! Here’s an (older) overview of Windows 8’s Hyper-V if you care to use it: http://tinyurl.com/3r99nr9. Note there are also other alternatives, such as Parallels Desktop and VMware Fusion (both of which run on a Mac) and Oracle VM VirtualBox.

In short, by using virtual machines, if you don’t have a bunch of extra physical servers and desktops around, you can follow along with all the examples anyway.

I suggest you build your test lab from scratch. Get the original media or download each operating system and spin up a new test lab.

Here is where to find trial downloads for Windows 7, Windows 8.1, Windows 10, and Windows Server 2016:

www.microsoft.com/en-us/evalcenter/evaluate-windows-8-1-enterprise

Microsoft usually also makes prebuilt virtual hard disk (VHD) images for use with Virtual PC and now, more recently, Hyper-V. It’s your choice of course, but I prefer to fresh-build my lab instead of using the preconfigured VHD files.

And that’s what I’ll be doing for my examples in this book. If the URLs I’ve specified change, I’m sure a little Googling, er, Bing-ing will Bing it, er, bring it right up.

Because Group Policy can be so all-encompassing, I highly recommend that you try the examples in a test lab environment first before making changes for real in your production environment.

Bringing Up a Windows Server as a Domain Controller

The DCPROMO.EXE you knew and loved is dead as of Windows Server 2012.

Before continuing, ensure that your server is already named DC01. If it isn’t, rename it and reboot before continuing. Additionally, ensure that DC01 has a static IP address and is configured to use itself as the DNS server.

Now, you’ll need to use the Server Manager’s Add Roles and Features Wizard to add the roles required to make your server a DC. It’s not hard. Here’s a sketch of the steps.

First, fire up Server Manager, which is the leftmost icon when you’re on the server. Next, click Dashboard and select Add roles and features, as seen here.

Then you’ll be at the Add Roles and Features Wizard, as seen here.

Click Next to visit the Installation Type screen and select Role-based or feature-based installation. Then click Next.

At Server Selection, click Select a server from the server pool and select your only machine: DC01.

At Server Roles, select Active Directory Domain Services, as seen here, and say yes when prompted to load the additional items, which must come along for the ride.

At the Features screen, click Next.

At the AD DS screen, click Next.

At the Confirmation screen, select Restart the destination server automatically if required and then click Install.

Next, Active Directory components will be installed on DC01 along with the GPMC. When done, you’ll be able to select Promote this server to a domain controller, as seen here.

At this point it should be pretty familiar. At the Deployment Configuration page, select Add a new forest and type Corp.com as the root domain name. Click Next.

At the Domain Controller Options page, leave the defaults as is. Provide a Directory Services Restore Mode (DSRM) password. I recommend p@ssw0rd. (My suggested password in all my books is p@ssw0rd. That’s a lowercase p, the at sign, an s, an s, a w, a zero, then r, and d.) Click Next to continue.

At the DNS Options page, you might get a warning; click Next.

At the Additional Options page, leave the defaults and click Next.

At the Paths page, leave the defaults as is and click Next.

At the Review Options page, click Next.

At the Prerequisites Check page, make sure there are no showstoppers. Finally, click Install on that same page.

The computer should restart automatically and reboot.

Congrats! You have your first Domain Controller!

Getting Started with Group Policy

Group Policy is a big, big place. And you need a road map. Let’s try to get a firm understanding of what we’re about to be looking at for the next several hundred pages.

Group Policy Entities and Policy Settings

Every Group Policy Object contains two halves: a User half and a Computer half. These two halves are properly called nodes, though sometimes they’re just referred to as either the User half and the Computer half or the User branch and the Computer branch.

A sample Group Policy Object with both the Computer Configuration and User Configuration nodes can be seen in Figure 1-2 (in the upcoming section, Local Group Policy Editor). Don’t worry; I’ll show you how to get there in just a second.

Just to make things a little more complicated, if you’re deploying settings using Active Directory (the most usual case) as opposed to walking up and creating a local GPO as we do later in Figure 1-2, the interface is a wee bit different and shows the Group Policy Preferences node. Hang tight for more on that.

The first level under both the User and the Computer nodes contains Software Settings, Windows Settings, and Administrative Templates. If we dive down into the Administrative Templates of the Computer node, underneath we discover additional levels of Windows Components, System, Network, and Printers. Likewise, if we dive down into the Administrative Templates of the User node, we see some of the same folders plus some additional ones, such as Shared Folders, Desktop, Start Menu, and Taskbar.

In both the User and Computer halves, you’ll see that policy settings are hierarchical, like a directory structure. Similar policy settings are grouped together for easy location. That’s the idea anyway—though, admittedly, sometimes locating the specific policy or configuration you want can prove to be a challenge.

When manipulating policy settings, you can choose to set either computer policy settings or user policy settings (or both!). You’ll see examples of this shortly. (See the section Searching and Commenting Group Policy Objects and Policy Settings in Chapter 2, Managing Group Policy with the GPMC and via Powershell, for tricks on how to minimize the effort of finding the policy setting you want.)

Most policy settings are not found in both nodes. However, there are a few that overlap. In that case, if the computer policy setting is different from the user policy setting, the computer policy setting generally overrides the user policy setting. But, to be sure, check the Explain text associated with the policy setting.

Wait… I Don’t Get It. What Do the User and Computer Nodes Do?

One of the key issues that new Group Policy administrators ask themselves is, What the heck is the difference between the Computer and User nodes?

Imagine that you had a combination store: Dog Treats (for dogs) and Candy Treats (for kids). That’s right; it’s a strange little store with seemingly two types of incompatible foods under the same roof. You wouldn’t feed the kids dog treats (they’d spit them out and ignore the treat), and you wouldn’t feed the kids’ candy to a dog (because the dogs would spit out the sour candy and ignore the treat).

That’s the same thing that happens here. Sure, it looks tempting. There are lots of treats on both sides of the store, but only one type of customer will accept each type of treat.

So, in practical terms, the Computer node (the first part of the policy) contains policy settings that are relevant only for computers. That is, if there’s a GPO that contains Computer-side settings and it hits a computer, these settings will take effect. These Computer-side settings could be items like startup scripts, shutdown scripts, and how the local firewall should be configured. Think of this as every setting relevant to the computer itself—no matter who is logged on at that moment.

The User node (the second part of the policy) contains policy settings that are relevant only for users. Again, if there’s a GPO that contains User-side settings and it hits a user, these settings will take effect for that user. These User-side items make sense only on a per-user basis, like logon scripts, logoff scripts, availability of the Control Panel, and lots more. Think of this as every setting relevant to the currently logged-on user—and these settings will follow the user to every machine they pop on to.

Feeding users dog treats, er, Computer-side settings doesn’t work. Same thing with feeding computers User-side settings. When a GPO hits user objects with Computer policy settings or computer objects with User policy settings, it simply will not do anything. You’ll just sit there and scratch your head and wonder why it doesn’t work. But it’s not that it’s not working; this is how it’s designed.

Computer settings are for computer objects, and User settings are for user objects. If this is bad news for you, there are two ways to get out of the problem. One way is an in-the-box advanced technique called loopback processing that can help you out. Look for more information on loopback processing in Chapter 4. The other way is via a third-party tool called PolicyPak, which (among other things) can permit computers to embrace User-side settings. More on this in Chapter 6, "Managing Applications and Settings Using Group Policy.

Active Directory and Local Group Policy

Group Policy is a twofold idea. First, without an Active Directory, there’s one and only one Group Policy available.

Officially, this policy directly on the workstation is called a local policy, but it still resides under the umbrella of the concept of Group Policy. Later, once Active Directory is available, the nonlocal (or, as they’re sometimes called, domain-based or Active Directory–based) Group Policy Objects come into play, as you’ll see later. Let’s get started and explore both options.

Then, here’s the weird thing: after I’ve fully described Active Directory’s Group Policy, we’re going to take a second visit back to Local Group Policy. That’s because with Windows Vista and later, there’s a special superpower I want to show you, but I only want to explain it after we’ve explored the first two concepts. So, in summary, here’s the short-term road map:

Local Group Policy for Windows XP and later

Active Directory Group Policy for all operating systems

Multiple Local Group Policy (MLGPO) for Windows Vista and later

Trust me; it’s easier to learn it this way, even though we’re taking two passes at one concept.

While you’re plunking around inside the Group Policy editor (also known as the Group Policy Management Editor, or Group Policy Object Editor), you’ll see lots of policy settings that are geared toward a particular operating system. Some are only for specific operating systems, and others are more general. If you happen to apply a policy setting to a system that isn’t listed, the policy setting is simply ignored. For instance, policy settings described as working Only for Windows 8 machines will not typically work on Windows XP machines. All policy settings have a Supported on field that should be consulted to know which operating systems can embrace which policy setting. Many of them will say something like At least Windows XP to let you know they’re valid for, say, XP and on.

Understanding Local Group Policy

Before we officially dive into what is specifically contained inside this magic of Group Policy or how Group Policy is applied when Active Directory is involved, you might be curious to see exactly what your interaction with Local Group Policy might look like.

Local Group Policy is best used when Active Directory isn’t available, say either in a Novell NetWare environment or when you have a gaggle of machines that simply aren’t connected to a domain.

Local Group Policy Editor

The most expeditious way to edit the Local Group Policy on a machine is to click Start ⇒ Run and type in GPEDIT.MSC. This pops up the Local Computer Policy Editor.

You are now exploring the Local Group Policy of this workstation. Local Group Policy is unique to each specific machine. To see how a Local Group Policy applies, drill down through the User Configuration ⇒ Administrative Templates ⇒ System ⇒ Ctrl+Alt+Del options and select Remove Lock Computer, as shown in Figure 1-2. As seen in the figure, the default for all policy settings is Not Configured. To make this policy setting perform its magic, choose the Enabled radio button and click OK.

When you do, within a few seconds you should see that if you press Ctrl+Alt+Del, the Lock Computer option is unavailable.

To revert the change, simply reselect Remove Lock Computer and select Not Configured. This reverts the change.

You can think of Local Group Policy as a way to perform decentralized administration. A bit later, when we explore Group Policy with Active Directory, we’ll saunter into centralized administration.

This Local Group Policy affects everyone who logs onto this machine—including normal users and administrators. Be careful when making settings here; you can temporarily lock yourself out of some useful functions.

If you’re thinking to yourself, Yep, I’ve done that, then stay tuned. After the next section is complete, we’ll return to Local Group Policy and discuss the idea of Multiple Local Group Policy Objects, which can help ensure that you escape from this very jam.

Before we leave Local Group Policy (for now), remember something that I stated in the introduction. That is, many of the settings we’ll explore in this book are available to workstations or servers that aren’t joined to an Active Directory domain. Just poke around here in Local Group Policy to get a feel for what you can and cannot do without Active Directory. However, many functions, like Folder Redirection settings (discussed in Chapter 10, Implementing a Managed Desktop, Part 1: Redirected Folders, Offline Files, and the Synchronization Manager), the Software Distribution settings (discussed in Chapter 11, The Managed Desktop, Part 2: Software Deployment via Group Policy), and others require Active Directory present to embrace these Group Policy directives.

You can point to other computers’ local policies by using the syntax gpedit.msc /gpcomputer:targetmachine or gpedit.msc /gpcomputer:targetmachine.domain.com; the machine name must be in quotes.

Figure 1-2: You can edit the Local Group Policy using the Local Group Policy Editor (GPEDIT.MSC).

Active Directory–Based Group Policy

To use Group Policy in the most meaningful way, you’ll need an Active Directory environment. An Active Directory environment needn’t be anything particularly fancy; indeed, it could consist of a single Domain Controller and perhaps just one Windows 10 workstation joined to the domain.

But Active Directory can also grow extensively from that original solitary server. You can think of an Active Directory network as having four constituent and distinct levels that relate to Group Policy:

The local computer

The site

The domain

The organizational unit (OU)

The rules of Active Directory state the following:

Every server and workstation must be a member of one (and only one) domain and be located in one (and only one) site.

Every user must be a member of one (and only one) domain and may also be located within one OU (and only one OU).

One of the most baffling questions people have when they start to dig into Group Policy is, If a user can only be a member of one OU, how do I apply multiple Group Policy Object directives to one user? I know it seems almost impossible based on the constraints listed, but I promise I’ll explain exactly how to do that in Chapter 2 in the section Filtering the Scope of Group Policy Objects with Security.

Full Windows vs. Windows RT and What It Means for Group Policy

Windows has two big flavors: full Windows and Windows RT.

Windows RT is the tablet edition that runs on ARM-based devices. Microsoft is not permitting Windows RT machines to join Active Directory. Therefore, there is no way to get Active Directory–based Group Policy on Windows RT. However, Windows RT will support Local Group Policy.

In this book we’re not going to be spending much time on Windows RT, because most of what we’ll do, we’ll do within the domain—and Windows RT machines are left out of the fun.

Windows RT has some non–Group Policy management capability so that administrators can control basic security settings. For more information about this feature, visit

http://tinyurl.com/6ufn565

Sadly, Windows RT has been out a few years (with the birth of Windows 8) and there still isn’t any way to manage these devices using Group Policy. If there ever comes a time that Windows RT machines can join the domain and get Active Directory Group Policy, I’ll write about it at www.GPanswers.com. But don’t hold your breath, as all indications suggest Windows RT will likely be depreciated and Microsoft will only be updating Windows RT to keep the lights on.

Group Policy and Active Directory

As you saw, when Group Policy is created at the local level, everyone who uses that machine is affected by those wishes. But once you step up and use Active Directory, you can have nearly limitless Group Policy Objects (GPOs)—with the ability to selectively decide which users and which computers will get which wishes (try saying that five times quickly). The GPO is the vessel that stores these wishes for delivery.

Actually, you can have only 999 GPOs applied and affecting a user or a computer before the system gives up and won’t apply any more.

You’ll create GPOs using the Group Policy Management Console, or GPMC for short. The GPMC can be added to a Windows Server 2016 computer or Domain Controller (see the section Using a Windows Server 2016 Machine as Your Management Station). The GPMC can also be added to a Windows 7, Windows 8, Windows 8.1, or Windows 10 machine via an extra download and install called RSAT. RSAT stands for Remote Server Administration Tools, and after installing it, you’ll find tools like Active Directory Users and Computers as well as the GPMC, which we’ll use right around the bend.

When we create a GPO that can be used in Active Directory, two things happen: we create some brand-new entries within Active Directory, and we automatically create some brand-new files within our Domain Controllers. Collectively, these items make one GPO.

You can think of Active Directory as having three major levels:

Site

Domain

OU

Additionally, since OUs can be nested within each other, Active Directory has a nearly limitless capacity for where we can tuck stuff away.

In fact, it’s best to think of this design as a three-tier hierarchy: site, domain, and each nested OU. When wishes, er, policy settings, are set at a higher level in Active Directory, they automatically flow down throughout the remaining levels.

So, to be precise:

If a GPO is set at the site level, the policy settings contained within affect those accounts within the geography of the site. Sure, their user account could be in one domain and their computer account could be in another domain. And of course, it’s likely that those accounts are in an OU. But the account is affected only by the policy settings here because the account is in a specific site. And logically, when a computer starts up in a new site, the User object will also get its site-based Group Policy from the same place. This is based on the IP subnet the user is a part of and is configured using Active Directory Sites and Services.

If a GPO is set at the domain level, it affects those users and computers within the domain and all OUs and all other OUs beneath it.

If a GPO is set at the OU level, it affects those users or computers within the OU and all other OUs beneath it (usually just called child or sub-OUs).

By default, when a policy is set at one level, the levels below inherit the settings from the levels above it. You can have cumulative wishes that keep piling on.

You might wonder what happens if two policy settings conflict. Perhaps one policy is set at the domain level and another policy is set at the OU level, which reverses the edict in the domain. The result is simple: policy settings further down the food chain take precedence. For instance, if a policy setting conflicts at the domain and OU levels, the OU level wins. Likewise, domain-level settings override any policy settings that conflict with previously set site-specific policy settings. This might seem counterintuitive at first, so bear with me for a minute.

Take a look at the following illustration to get a view of the order of precedence.

The golden rule with Group Policy is truly, Last writer wins. Another way to say it is, If any GPOs conflict, the settings contained in the last-written GPO win.

However, don’t forget about any Local Group Policy that might have been set on a specific workstation. Regardless, once that local policy is determined, only then do policy settings within Active Directory (the site, domain, and OU) apply. So, sometimes people refer to the four levels of Group Policy: local workstation, site, domain, and OU. Nonetheless, GPOs set within Active Directory always trump the Local Group Policy should there be any conflict.

If this behavior is undesirable for lower Active Directory levels, all the settings from higher Active Directory levels can be blocked with the Block Inheritance attribute on a given OU. Additionally, if a higher-level administrator wants to guarantee that a setting is inherited down the food chain, they can apply the Enforced attribute via the GPMC interface. (Panic not! Chapter 2 explores both Block Inheritance and Enforced attributes in detail.)

Note that you cannot Block Inheritance between Local GPOs and Active Directory GPOs. But it is true that anything you set within Active Directory to inverse a Local GPO setting is always honored. Said another way, Active Directory edicts trump local edicts. You can, however, literally turn off Local Group Policy Objects from processing. In Windows Vista and later, there is a policy setting found in Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Group Policy entitled Turn off Local Group Policy Object processing, which, when set to Enabled, will prevent Local Group Policy Objects from affecting the machine.

Don’t sweat it if your head is spinning a little now from the Group Policy application theory. I’ll go through specific hands-on examples to illustrate each of these behaviors so that you understand exactly how this works.

Linking Group Policy Objects

Another technical concept that needs a bit of description here is the linking of GPOs. When a GPO appears to be created at the site, domain, or OU level via the GUI