After you create or modify a GPO in the domain, the policy’s “wishes” are not immediately dropped on the target machines. In fact, they’re not dropped on the target machines at all; they’re requested by the client computer at various times throughout the day. GPOs are processed at specific times, based on various conditions. You could basically say that GPOs are created from your management machine and plopped on the Domain Controllers for storage. Then those GPOs are simply “pulled” by the client.

It’s likely that you have all sorts of client systems, including Windows 7, Windows 8.1, Windows 10, maybe some Windows XP left behind, and various Windows Servers. So, again, when I say “client system” I mean “the client that receives Group Policy”—even if it’s a server operating system. Each operating system that receives Group Policy instructions processes Group Policy at different times in different ways. With different operating systems requesting different things at different times, the expected behaviors can get confusing quickly.

Additionally, other factors determine when and how a GPO applies. When users dial in over slow links, things can be—and usually are—different. And you can instruct the Group Policy engine (on a specific computer or all computers) to forgo its out-of-the-box processing behaviors for a customized (and often more secure) way to process.

Often, people throw up their hands when the Group Policy engine doesn’t seem to process the dictated GPOs in an expected manner. Group Policy doesn’t just process when it wants to; rather, it adheres to a strict set of processing rules. The goal of this chapter and the next is to answer this question: When does Group Policy apply?

Understanding the processing rules will help you better understand when Group Policy processes GPOs the way it does. Then, in Chapter 7, “Troubleshooting Group Policy,” you’ll get a grip on why and how Group Policy applies. Between these chapters, your goal is to discover how Group Policy can apply under different circumstances and how you can become a better Group Policy troubleshooter.

Group Policy Processing Principles

For you to best understand how modern Windows processes GPOs, I’ll first describe how Windows 2000 does its thing.

“What? That’s lunacy!” I hear you cry. “Here it is, the year 2015,” or later, I suppose, depending on when you’re reading this. “And you, Moskowitz, have the audacity to explain to me how a 15-year-old operating system works? Get modern, Mr. Caveman.” Seriously. I can hear you—right now. It’s like I’m right there.

Anyway, I know it’s weird. But since Windows 2000 came out first, its behavior is critically important—especially because (and here’s the punch line) I think you’ll want to make at least some of your XP (or later) machines act like Windows 2000 by the time you’re done reading this section.

You’ve read that right: I’m guessing you’ll want to make your XP and later machines, like Windows 10 desktops, act like the 15-year-old Windows 2000 operating system.

Trust me. You’ll want to learn how Windows 2000 does its thing first before trying to understand the rest of the family.

Sure, Windows Servers, like Windows Server 2008, Windows Server 2012, and Windows Server 2016, also process GPOs as a Group Policy client. I’ll pepper in that information when necessary. But, as you’re reading along, try to focus on the typical client computer.

To get a feel for how GPO processing works, we’re going to walk through what happens to four users:

• Wally, who uses only a Windows 2000 Professional machine.
• Xavier, who uses only a Windows XP machine.
• Sven, who uses only a Windows 7 machine. Get it? Sven on Seven? I slay myself. But anyway: Sven could also be using a Windows 8 machine—there is no difference in Group Policy processing between a Windows 7 and a Windows 8 machine.
• Ben, who uses a Windows 10 machine. Note that Ben could be using a Windows 8.1 machine, too. Said another way, the Group Policy “engine” got updated with Windows 8.1, but we’ll be using Ben on Windows 10. (“Ben on Ten,” get it?)

By using Wally, Xavier, and Sven, and Ben as our four sample users (on our four sample computers), we can see precisely when Group Policy applies to them based on their machines.

Before we go even one step further, let me debunk a popular myth about Group Policy processing: Group Policy is never pushed from the server and forced on the clients. Rather, the process is quite the opposite. Group Policy occurs when the Group Policy engine on a Windows client requests Group Policy. This happens at various times, but at no time can you magically declare from on high, “All clients! Go forth and accept my latest GPOs!” It doesn’t work like that. Clients request GPOs according to the rules listed in this chapter.

As always, however, there is an exception to the rule, and we will cover that later in this chapter in the section “Manually Forcing Background Policy Processing (Remote GPUpdate),” where we talk about Group Policy Update. Even though this seems like a feature that allows administrators to push out a policy update, it’s still technically just triggering a pull from the server.

In a nutshell, Group Policy is potentially triggered to apply at four times (and one special case we need to cover). Here’s a rundown of those times; I’ll discuss them in grueling detail in the next sections.

1. Initial Policy Processing Initial policy processing is a fancy way of saying “the first cycle” of Group Policy. That first cycle happens for computers at startup time and for users at logon time.
2. Background Refresh Policy Processing (Member Computers) Member machines (that is, non–Domain Controllers) check in with the Domain Controller to see if there are any new or changed Group Policy Objects. This occurs some time after the computer starts up and also for the user after the user logs on (usually at 90-minute intervals or so). A bit later, you’ll see how Windows XP and later (like Windows 10) leverage the background policy processing mechanism to a distinct advantage.
3. Background Refresh Policy Processing (Domain Controllers) Domain Controllers need love, too, and to that end, all Domain Controllers perform a background refresh every five minutes (after replication has occurred).
4. Security Policy Processing For all operating systems, only the security settings within all GPOs are reprocessed and applied every 16 hours regardless of whether they have changed. This safety mechanism prevents unscrupulous local workstation administrators from doing too much harm.

1. Special Case: Moving a User or Computer Object Although all the previous items demonstrate a trigger of when Group Policy applies, one case isn’t trigger specific; however, it’s important to understand a special case of Group Policy processing behavior. You might think that if you move a user or computer around in Active Directory (specifically, from one OU to another), then Group Policy is set to reapply—the system would “know” it’s been moved around in Active Directory. But that doesn’t happen. When you move a user or a computer from one OU to another, background processing may not immediately understand that something was moved. Some time later, the system should detect the change, and background processing should start normally again.

Don’t Get Lost

There are definitely nuances in the processing mechanism among the various operating systems. The good news, if your head starts to swim a bit, is that you can dog-ear this page and highlight this little area for quick reference. If you remember one takeaway from this chapter, it should be that target computers fall into these four behavior types:

1. Behavior Type 1 Windows 2000 Professional workstations, Windows 2000 member servers through Windows Server 2016 member servers
2. Behavior Type 2 Domain Controllers of all sorts: Windows 2000 through Windows Server 2016
3. Behavior Type 3 Windows XP and later, like Windows 7 and 8—though, Windows 8 does have a little trick up its sleeve, as discussed here
4. Behavior Type 4 Windows 8.1 and later, like Windows 8.1 and Windows 10

It’s important to understand the difference between these four behavior types. And once you understand the difference between them, you can decide if you want to take the machines that are in Behavior Types 3 and 4 and make them act like machines that are in Behavior Type 1.

By now, you have likely expunged Windows 2000 systems from your domain. However, I strongly encourage you to read about how all systems are processed.

I recommend this for three reasons:

• The behaviors described in the following sections are all based on the original “baseline” Windows 2000 behavior.
• It’s easier to understand the modern Windows behavior if you understand the original Windows 2000 behavior.
• Later in the chapter I’m going to encourage you to make some of your Windows XP and later machines act like Windows 2000. So, if you don’t understand the Windows 2000 behavior, you won’t know what I’m talking about.

Initial Policy Processing

Recall that each GPO has two halves: a Computer half and a User half. This is important to remember when trying to understand when GPOs are processed. All machines perform what is called initial policy processing. Again, that’s just a way of saying “the first time policy is checked for after a computer is rebooted” and “the first time policy is checked for after a user logs on.”

But Windows XP and later machines don’t exactly perform the same steps as their Windows 2000 counterparts. Let’s check it all out.

Windows 2000 (and All Server Types) Initial Policy Processing

Our sample computer user Wally walks into his office and turns on his Windows 2000 Professional machine. The Computer half of the policy is always processed at the target machines upon startup as his machine reboots. When a Windows 2000 or any Windows Server operating system machine starts up, it states that it is “Processing security policy” or “Applying Computer Settings.” What this should say is “Processing Group Policy” (but it doesn’t).

At that time, the workstation logs onto the network by contacting a Domain Controller. It finds the Domain Controller by looking up DNS records that say, “Hey, here’s the name of a Domain Controller.” The Domain Controller then tells the workstation which site it belongs to, which domain it belongs to, and which OU it is in. The system then downloads and processes the Computer half of Group Policy in that order. When the processing is finished, the “Press Ctrl+Alt+Delete to begin” prompt is revealed, and Wally can log on by pressing Ctrl+Alt+Delete and giving his username and password.

After Wally is validated to Active Directory, the User half of the GPO is downloaded and then processed in the same precise order: site, domain, and then each nested OU.

Wally’s Windows 2000 Desktop is manipulated by the policy settings inside any GPOs targeting Wally’s user or computer account. Wally’s Desktop is displayed only when all the User-side GPOs are processed.

If you look at how all this goes, you’ll see it’s a lock-step mechanism. The computer starts up and then processes GPOs in the natural order: local, site, domain, and each nested OU. The user then logs on, and Group Policy is processed, again in the natural order: local, site, domain, and each nested OU. This style of GPO processing is called synchronous processing. That is, to proceed to the next step in either the startup or logon process, the previous step must be completed. For example, the GPOs at the OU level of the user are never downloaded and applied before the GPOs at the site level. Likewise, the GPOs at the domain level for Windows 2000 (and Windows Server 2003 and Windows Server 2008) are never downloaded before the site GPOs that affect a computer.

Therefore, the default for Windows 2000 (and all server types—up to and including Windows Server 2012 servers), for both the computer startup and the user logon, is that each GPO is processed synchronously. This same process occurs every time.

Again, this synchronous processing style occurs only for Windows 2000 workstations and all server types (by default).

Windows XP and Later Initial Policy Processing

Xavier walks into his office and turns on his Windows XP machine. For a moment, let’s assume this is the first time that this Windows XP machine has started up since joining the domain. Perhaps it just landed on Xavier’s desk after a new desktop rollout of Windows XP. If this is the case, the Windows XP machine will act just like Windows 2000 (as described earlier). It will look to see which site, domain, and OUs the computer account is in and then apply GPOs synchronously. Likewise, let’s assume this is the first time Xavier is logging into this Windows XP machine with his user account, which lives in Active Directory. Again, imagine that this machine just arrived after a desktop rollout. In this case, again, Windows XP will act like Windows 2000 (and synchronously process GPOs based on the site, domain, and OU Xavier is logging on from).

So far, so good. However, Windows XP performs this initial synchronous processing only in this special case described here. That is, either the computer has never started in the domain before or the user has never logged onto this particular Windows XP machine before.

Sven’s experience on Windows 7 will be the same as Xavier’s. That is, if Sven walks into his office and turns on his Windows 7 machine for the first time and logs into the machine for the first time, it will act like Windows 2000 and process GPOs synchronously for both the computer (during startup) and the user (during login).

The same thing occurs on Windows 8 and with Ben on Windows 10: The first time the computer is ever turned on after joining the domain, or first logged in, it acts like Windows 2000.

To understand Windows XP and later’s normal default processing mode, take a deep breath and read on.

Background Refresh Policy Processing

Wally is logged onto Windows 2000 (or any server operating system, like Windows Server 2008 or Windows Server 2012), and Xavier is logged onto Windows XP, and Sven is plugging along on Windows 7, and Ben on Windows 10 is happy as a clam. Things are great—for everyone. As the administrators, we’re happy because Wally, Xavier, Sven, and Ben are all receiving our wishes. They’re happy because, well, they’re just happy, that’s all.

But now we decide to add a new GPO or to modify a policy setting inside an existing GPO. What if something is modified in the Group Policy Management Editor that should affect a user or a computer? Aren’t Wally, Xavier, Sven, and Ben already logged on—happy as clams? Well, a new setting is destined for an already-logged-in user or computer, and the new changes (and only the new changes) are indeed reflected on the user or computer that should receive them. But this delivery doesn’t happen immediately; rather, the changes are delivered according to the background refresh interval (sometimes known as the background processing interval).

The background refresh interval dictates how often changed GPOs in Active Directory are pulled by the client computer. As I implied earlier, there are different background intervals for the different operating systems’ roles (that is, member versus Domain Controller).

When the background refresh interval comes to pass, GPOs are processed asynchronously. That is, if a GPO that affects a user’s OU (or other Active Directory level) is changed, the changes are pulled to the local computer when the clock strikes the processing time. It doesn’t matter if the change happens at any level in Active Directory: OU, domain, or site. When changes are available to users or computers after the user or computer is already logged on, the changes are processed asynchronously. Whichever GPOs at any level have changed, those changes are reflected on the client.

When does this happen? According to the background refresh interval for the operating system (discussed next).

Background Refresh Intervals for Windows Member Servers (Any Operating System)

It stands to reason that when we change an existing GPO (or create a new GPO), we want our users and computers to get the latest and greatest set of instructions and wishes. With that in mind, let’s continue with our example. Remember that Wally is on his Windows 2000 machine, Xavier is on his Windows XP machine, and Sven is on his Windows 7 machine. And Ben is on his Windows 10 machine.

By default, the background refresh interval for Windows 2000 workstations and for all Windows member servers is 90 minutes, with a 0–30-minute positive random differential added to the mix to ensure that no gaggle of PCs will refresh at any one time and clog your network asking for mass GPO downloads from Domain Controllers. Therefore, once a change has been made to a GPO, it could take as little as 90 minutes or as long as 120 minutes for each user or workstation that is already logged onto the network to see that change.

Again, this is known as the background refresh interval. Additionally, the background refresh interval for the Computer half of Group Policy and the User half of Group Policy are on their own independent schedules. That is, the Computer half or the User half might be refreshed before the other half; they’re not necessarily refreshed at the exact same moment because they’re on their own individual timetables. This makes sense: the computer and user didn’t each get Group Policy at the precise moment in time in the first place, did they?

You can change the background refresh interval for the Computer half and/or the User half using Group Policy, as described later in the section cleverly titled “Using Group Policy to Affect Group Policy.”

Background Refresh Intervals for Windows Domain Controllers

Even though Wally, Xavier, Sven, and Ben are not logging onto Domain Controllers, other people might. And because Domain Controllers are a bit special, the processing for Domain Controllers is handled in a special way.

Because Group Policy contains sensitive security settings (for example, Password and Account Policy, Kerberos Policy, Audit Policy), any policy geared for a Domain Controller is refreshed within 5 minutes. This adds a tighter level of security to Domain Controllers. For more information on precisely how the default GPOs work, see Chapter 8, “Implementing Security with Group Policy.

You can change the background interval for Domain Controllers using Group Policy (as described later in the section “Using Group Policy to Affect Group Policy”). However, you shouldn’t mess with the default values here—they work pretty well.

Background Refresh Exemptions and Special Cases

Wally has been logged onto his Windows 2000 machine for four hours. Xavier has been logged onto his Windows XP machine, and both Sven (on Windows 7) and Ben (on Windows 10) have been logged on for the same amount of time. Clearly, the background refresh interval has come and gone—somewhere between two and three times.

If any GPOs had been created or any existing GPOs had changed while Wally, Xavier, Sven, and Ben were logged on, both their user accounts and their computer accounts would have embraced the newest policy settings. However, four policy categories are exceptions and are never processed in the background while users are logged on:

1. Folder Redirection (Explored in Detail in Chapter 10) Folder Redirection’s goal is to anchor specific directories, such as the My Documents folder, to certain network shared folders. This policy is never refreshed during a background refresh. The logic behind this is that if an administrator changes this location while the user is using it (and the system responds), the user’s data could be at risk for corruption. If the administrator changes Folder Redirection via Group Policy, this change affects only the user at the next logon.
2. Software Installation (Explored in Detail in Chapter 11) Software Installation is also exempt from background refresh. You can use Group Policy to deploy software packages, large and small, to your users or to your computers. You can also use Group Policy to revoke already-distributed software packages. Software is neither installed nor revoked to users or computers when the background interval comes to pass. You wouldn’t want users to lose applications right in the middle of use and, hence, lose or corrupt data. These functions occur only at startup for the computer or at logon for the user.
3. Disk Quotas (Explored in Previous Editions of the Book) Disk quotas run on Windows 8.1 and later when the background processing interval comes around. For previous operating systems, such as Windows 7, they are run (changed, really) only at computer startup.
4. Logon, Logoff, Startup, and Shutdown Scripts (Explored in Detail in Chapter 12) Technically, this entry shouldn’t be here. Here’s why: Yes, it’s true that these scripts are run only at the appointed time (at logon, logoff, startup, or shutdown). And, as expected, these scripts are not run again and again when the background processing interval comes around. But, technically, the Client-Side Extension (CSE) that implements scripts does run in the background. If it runs in the background, what is it doing? The Group Policy CSE will update the “values” like location and path changes. This can happen even after the user has already logged on. It’s just that, of course, they won’t run again until the appointed time. So, the important (and often misunderstood) point is that Group Policy itself doesn’t run the scripts. That’s handled by the logon process. The Group Policy part of the magic is always happening—just updating values (like location of the script) if they’re changed within the GPO.
5. Group Policy Preferences’ Drive Maps (Explored in Chapter 5) One of the Group Policy Preferences’ superpowers is the ability to map drives using Group Policy instead of via login scripts.

On Windows 8 and earlier, when Group Policy refreshes, if the user is already logged on, Group Policy Preferences will not touch the existing mapped drives. The user must log out and back on. Sometimes logging off and on twice is required to see that changed drive mapping occur!

On Windows 8.1 and later, when Group Policy refreshes, if the user is already logged on, Group Policy Preferences perform an update.

Windows Background Processing

As I stated in the introduction to this section, Windows XP and later do not process new Group Policy updates in the same way that Windows 2000 and all versions of Windows Server do. Let’s get a grip on how Windows XP and later work.

Now that Xavier has logged onto his Windows XP machine for the first time, Sven has logged onto his Windows 7 machine for the first time, and Ben has logged onto Windows 10 for the first time, their sessions will continue to process GPOs in the background as I just described: every 90 minutes or so if any new GPOs appear or any existing GPOs have changed. Xavier now goes home for the night. He logs off the domain and shuts down his machine. When he comes in the next morning, he will not process GPOs the same way that Wally will on his Windows 2000 machine.

When Xavier (or Sven or Ben) logs on the second time (and all subsequent times) on a Windows XP or later machine, initial policy processing will no longer be performed as described in the section “Initial Policy Processing” earlier in this chapter. From this point forward, at startup or logon, Windows XP and later will not process GPOs synchronously like Windows 2000; rather, GPOs will be processed only in the background.

If you’re scratching your head at this point as to why Windows 2000 is different from Windows XP and later, here’s the short answer: When Windows XP was in development, all the stops were pulled to make the “XPerience” as fast as possible. Both boot times and logon times were indeed faster than ever, but the trade-off came at a price.

By default, Windows XP and later won’t wait for the network to be there in order to check for any updated GPOs. If the network is unavailable or slow, Windows XP and later will simply utilize the last-known downloaded GPOs as the baseline, even if GPOs have changed in Active Directory while the Windows XP or Windows 10 machine was turned off. Said another way, if Windows XP and later machines can’t download anything new (quickly), they just maintain what they have, without any holdups.

While the network card is still warming up and finding the network and the first Domain Controller, the last-used computer GPOs are already just “there.” Then, the “Press Ctrl+Alt+Delete to begin” prompt is presented to the user. While this prompt is presented, and once the network is ready, only then does Windows XP and later download and apply any new computer GPOs.

Assuming the user is now logged on, the Desktop and Start menu appear. Again, the system will not synchronously download the latest site, domain, and OU Group Policy Objects and apply them before displaying the Desktop. Instead, other activity is happening while the latest and greatest Group Policy is being downloaded, so the user might not see the effects right away.

Once the computer has started and the user is logged on, the Group Policy settings from “last time” are already there on the machine. Newly downloaded GPOs (and the policy settings inside) are then processed asynchronously in the background. This net result is a bit of a compromise. The user feels that there is a faster boot time (when the GPO contains computer policy settings) as well as faster logon time (when the GPO contains user policy settings). The most important policy settings, such as updated Security settings and Administrative Templates (Registry updates), are applied soon after logon—and no one is the wiser. Microsoft calls this Group Policy processing behavior Fast Boot (sometimes called Logon Optimization). Yes, it does speed things up a bit, but at a cost.

To keep things simple, we just walked through what would happen for Xavier on his Windows XP machine. However, the exact same behavior would occur for Sven on his Windows 7 machine. There is no difference between Windows 10, Windows 8, Windows 8.1, Windows 7, Windows XP, and Windows Vista in this respect.

Windows XP and Later Fast-Boot Results

Fast Boot affects two major components: Group Policy processing and user-account attribute processing. The (sometimes strange) results occur for users when they have previously logged on. The only one spared the strange behavior is Wally on his Windows 2000 machine, because Windows 2000 doesn’t do this modern “Fast Boot” behavior.

Windows XP and Later Fast Boot Group Policy Processing Details

The immediate downside to the Windows XP and later (including Windows 10) Fast Boot approach is that, potentially, a user could be totally logged on but not quite have all the GPOs processed. Then, once they are working for a little while—pop! A setting takes effect out of the blue. This is because not all GPOs were processed before the user was presented with the Desktop and Start menu. Your network would have to be pretty slow for this scenario to occur, but it’s certainly possible. This is most commonly seen if you do not have Spanning Tree PortFast set to enabled on your network switches. Without it, a 30- to 50-second delay could be seen with the activation of the network port. And considering Windows 8 and Windows 10 boot a lot faster than Windows 7, you may see this behavior more often in your environment. If you’re using Cisco gear, a reference document on this can be found at:

http://tinyurl.com/cisco-spanning

The next major downside takes a bit more to wrap your head around. Some Group Policy (and Profile) features can potentially take Windows XP and later several additional logons or reboots to actually get the changes you want on them. This strange behavior becomes understandable when we take a step back and think about how certain policy categories are processed on Windows 2000. Specifically, we need to direct our attention to Software Distribution and Folder Redirection policy. I mentioned that on Windows 2000 these two types of policy categories (and some others) must be processed in the foreground (or synchronously) to prevent data corruption. That is, if there are Software Distribution or Folder Redirection edicts to embrace, they can happen only during startup or login.

But we have a paradox: if Windows XP and later only process GPOs asynchronously, how are the Software Distribution and Folder Redirection polices handled if they must be handled synchronously?

Windows XP, and later, fake it and tag the machine when a software package is targeted for the user or system. The next time the user logs on (or the computer is rebooted for Computer-side policy), the Group Policy engine sees that the machine is tagged for Software Distribution and switches, just for this one time, back into synchronous mode. The net result: Windows XP and later machines typically require two logons (or reboots) for a user or computer to get a software distribution package.

Again, note that Windows 2000 Professional machines only require one logon (for user settings) or one reboot (for computer settings).

Folder Redirection is a wonderful tool. It has two modes: Basic Folder Redirection (which applies to everyone in the OU) and Advanced Folder Redirection (which checks which security groups the user is in). Windows XP and later machines won’t get the effects of Basic Folder Redirection for two logons! And Windows XP and later machines won’t get the effects of Advanced Folder Redirection for a whopping three logons. The first logon tags the system for a Folder Redirection change, the second logon figures out the user’s security group membership, and the third logon actually performs the new Folder Redirection—synchronously for just that one logon.

We cover Folder Redirection in Chapter 10, “The Managed Desktop, Part 1: Redirected Folders, Offline Files, and the Synchronization Manager.”

Automatically Killing Fast Boot with Special User Account Attributes

Group Policy is only one of two areas affected by the Windows XP and later Fast Boot mechanism. If you change certain key user attributes, you could find that they are not updated until (you guessed it!) two logons. Those key attributes are as follows:

• Roaming profile path (discussed in Chapter 9)
• The home directory
• Old-style logon scripts

But once they are set (and detected), Fast Boot is officially, automatically killed by the system. From that point forward, since Fast Boot is turned off, if you change those values again, it should take only one logon for you to see.

Read more about this topic here: http://support.microsoft.com/kb/305293.

Manually Turning Off Windows XP and Later Fast Boot

In previous editions of the book, I recommended that you simply turn off Fast Boot for all operating systems and be done with it. The thrust of my idea was that if you kept Fast Boot on, your machines would be a wee bit faster, but all machines would have decreased consistency.

That also means if you turned off Fast Boot (and went back to the Windows 2000 behavior), you’d be going a wee bit slower but gaining increased consistency.

My updated recommendation is as follows:

• Keep Fast Boot on (the default) for machines that are roaming, traveling, laptop-y, or tablet-y. (Yes, I just made up those two words.)
• Turn Fast Boot off (explained later) for any machines that are desktops, hardwired, or VDI machines.

Why is this my new recommendation?

If you want the long story of why this is my recommendation, I’d like to point you toward a speech I gave at TechEd 2014 entitled “Group Policy: Tips, Tricks and Notes from the Field.” At last check the replay of the talk can be found at:

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/WIN-B328#fbid=

The summary of the recommendation, however, can be broken down into two easy thoughts:

1. For Laptop-y and Tablet-y Machines Group Policy can be slowed down over slow links. Therefore, if you have laptop-y or tablet-y machines, they might use a slow link, and you’ll want to ensure that their experience is as fast as possible, even if that means that they don’t get the latest Group Policy settings right away during a reconnect.
2. For Hardwired Machines (Typically Desktops and VDI) They won’t be using slow links. So for these machines, go for consistency in how Group Policy applies, even if it takes an extra moment or two during the logon process. It might be a smidgen slower to log on, but honestly, under most conditions you and your users likely wouldn't notice the difference, and you’ll be thankful for the consistency.

To take my suggestions, you’ll likely need to split machines into different OUs: one OU for traveling machines and one for hardwired machines.

On the OU containing traveling machines, do nothing. Fast Boot is the default, and already on.

On the OU containing the hardwired machines, you will need to create a Group Policy Object that contains a policy setting to revert the behavior of Windows XP and later machines back to the older, more consistent behavior. Enable the policy setting named Always wait for the network at computer startup and logon. This policy can be found in Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Logon. The name of this policy setting is a bit confusing. It would have been better, in my opinion, to name it Make Client Machines Process GPOs Like Windows 2000. But they didn’t.

Remember, to force Windows XP and later machines to receive this computer policy (or any computer policy), the computer account must be within the site, domain, or OU where you set the policy.

Last, don't give the name of the policy setting Always wait for the network at computer startup and logon too much contemplation, even though it's confusing. It does not mean that the machine will just "hang" there until it sees the network during startup and logon. Its job is only to make Windows XP and later machines process policy in the older, more consistent style.

Manually Starting Background Policy Processing (One at a Time)

You get a phone call from the person who handles the firewalls and proxy servers at your company. He tells you that he’s added an additional proxy server for your users to use when going out to the Internet. Excitedly, you add a new GPO that affects Xavier’s, Sven’s, and Ben’s user objects so they can use the new proxy server. But you’re impatient.

You know that when you make this setting, it’s going to take between 90 and 120 minutes to kick in. And you don’t want to tell Sven (and your other users) to log off and log back on to get the policy—they wouldn’t like that much.

In cases like these, you might want to bypass the normal wait time before background policy processing kicks in. The good news is that you can run a simple command that tells the client to skip the normal background processing interval and request an update of new or changed GPOs from the server right now. Again, only new GPOs or GPOs that have changed on the server in some way will actually come down and be reflected on your client machines.

But, because you’re impatient, you want to see Sven on his Windows 7 machine start using that new proxy server setting that you plunked into that GPO right away. So you physically trot out to his machine and enter the gpupdate command to manually refresh the GPOs.

Note that the gpupdate command can refresh either the User or the Computer half of a GPO, or both. The syntax is gpupdate /Target:Computer, /Target:User, or (again) just gpupdate by itself to trigger both.

Running gpupdate while Sven and Ben are logged on gives those users the new settings in the GPO you just set. This is, of course, provided the Domain Controller that Sven and Ben are using has the replicated GPO information.

Additionally, gpupdate can figure out if newly changed items require a logoff or reboot to be active. For instance, we know that Software Distribution and Folder Redirection settings are processed only at future logon times (and not in the background). Therefore, specifying gpupdate with a /Logoff switch will figure out if a policy has changed such that a logoff is required and then automatically log you off. If the updated GPO does not require a logoff, the GPO settings are applied and the currently logged-on user remains logged on.

Similarly, Software Distribution settings will also require a reboot before the software will be available. Therefore, specifying gpupdate with a /boot switch will figure out if a policy has something that requires a reboot and automatically reboot the computer. If the updated GPO does not require a reboot, the GPO settings are applied, and the user remains logged on.

The /logoff and /boot switches are optional.

One switch has a lot of mystery around it: the /force switch. The /force switch basically says, “Redownload all Group Policy settings from all GPOs, even if nothing has changed.” Remember, the Group Policy engine on the client already knows which GPOs it’s already downloaded. For more information on this, see the earlier sidebar “How Does the Group Policy Engine Know What’s New or Changed?” and also the details in Chapter 7.

So, the /force switch is often not needed in gpupdate, because gpupdate could be run without switches and be equally effective.

So, why run the /force switch with gpupdate at all?

A key case when you would need the /force switch would be, say, if someone with local admin rights did a no-no, like change a value that only the protected SYSTEM should get to. For example, say a local administrator deleted a Registry key, which restricted access to the Control Panel or changed how big a log file should be. Now, remember: regular, standard users cannot do this. But local administrators can.

In those cases, running a gpupdate by itself wouldn’t fix the problem. Only a gpupdate /force will “re–bring down” the settings—even if the version numbers have not changed.

So, to be clear, in 99 percent of the cases, you shouldn’t need to add /force to gpupdate.

That being said, I have seen plenty of times where gpupdate /force is like a “brain reboot” for Group Policy. There is some magical quality about /force that does sometimes jump-start you out of a problem, and—hey now—things seem to work the way you expect.

Manually Forcing Background Policy Processing (Remote GPUpdate)

Sometimes, you make a change and you want that change to go out NOW! NOW! NOW! This can happen if you, oops, forgot to perform some critical change or just want to see a gaggle of computers embrace your changes.

When you use the GPMC from Windows 8 or later (preferably Windows 10), you will, indeed, be able to do this very quickly.

Before I show you exactly how to do it, though, let’s go over the theory of what is about to happen. First, you cannot stand on your desk and shout at a bunch of users to download their settings NOW! NOW! NOW! It doesn’t work like that. Instead, you point at a bunch of computers and tell them to download their settings now, and the users who are on those computers also download their settings automatically at the same time. It’s a fine distinction, but an important one. So, to recap, you can only select a place (OUs, really), which contains computers, and the settings for the computer as well as the user’s settings (for the users on those computers) will also be refreshed.

But there’s another small theory point here. The refresh is the equivalent of a gpupdate /force. This means a full “re-application” of all the policy settings will come down. Again, see the previous section for a little more detail on this topic.

So, without further ado, let’s see exactly how to get our computers to embrace our changes NOW! NOW! NOW! Okay, that’s that last time I’m saying that. I’m not really a shouter.

As I stated, the trick is to find the location with the computers that users are already using. The GPMC limits this trick only to OUs and won’t let you perform a remote Group Policy Update upon the whole domain or at a site.

Additionally, this magic only works for Windows 7 and later as target machines. Group Policy on Windows XP machines cannot be remotely updated using the GPMC.

To test this out, I suggest you log on to your Win10 machine as Frank Rizzo. At this point in our story, Frank should be getting a GPO called “Hide Mouse Pointers Option/Restore Screen Saver Option.” You should see that the option to manipulate mouse pointers is prevented. (On the Desktop, right click Personalization ⇒ Themes ⇒ Mouse pointer settings.) You should see the Pointers tab within the Mouse Properties applet is removed (though other tabs, like Pointer Options and Buttons remain).

So let’s set ourselves up for a quick test to force update a GPO to our target computers. For a quick test within the GPMC right-click on the “Hide Mouse Pointers Option/Restore Screen Saver Option” Group Policy Object and uncheck Link Enabled. This will stop the Group Policy Object from affecting the OU that contains Frank.

Don’t do this—but at this point, if Frank were to log off and log back on, this change would take effect. But instead, we want to run the Remote Group Policy Update. Do this by finding the Human Resources Computers OU, then right-clicking over it and selecting Group Policy Update, as seen in Figure 3-1.

When you do this, you’ll get a dialog box like the one in Figure 3-2.

If you make a mistake and select an OU containing only User objects, the Remote Group Policy Update will politely explain the problem, as seen in Figure 3-3.

Note that the Remote Group Policy Update will show you the number of computers that are about to be refreshed. This is great so you don’t inadvertently refresh 200,000 computers when you meant to refresh 20.

The next thing that happens is very disappointing. In short, as seen in Figure 3-4, by default this will always fail.

“Why does this fail?” I hear you cry. Because, by default, on these machines, the Windows Firewall is preventing remote access by you—that is, unless, you followed along in Chapter 2, “Managing Group Policy with the GPMC and via PowerShell” specifically in the sidebar “Understanding Windows Firewall Settings (and Dealing with Group Policy Results).” In that sidebar, I showed you how to poke just the right holes in the Windows Firewall to allow remote administration, like what we’re trying to do here.

Alternatively, you could also use the Starter GPO we talked about in the previous chapter, specifically the section “Should You Use Microsoft's Pre-created Starter GPOs?”Both methods do ostensibly the same thing but take somewhat different routes to perform the work.

Regardless, once you’ve poked the hole through the firewall, you’re ready to go. At this point, rerunning remote Group Policy Update should succeed, as shown in Figure 3-5.

But wait! Just because it succeeded doesn’t mean it will refresh instantly. Indeed, there is a maximum 10-minute wait time between the time you say “Go” and the time the computers say “Done.”

Within 10 minutes, in Figure 3-6, you can see what the user sees while Group Policy applies. As far as I know, there is no way to make this “silent.” Users on Windows 7 and later see the same dialog box pop up. And, Windows XP users see—nothing, as, again, remote Group Policy Update will not apply to Windows XP machines.

The reason for both the 10-minute delay and the dialog box is that the Remote Group Policy Update actually doesn’t perform the update itself. The Remote Group Policy Update does something pretty sneaky: it tells the target computer to add a Scheduled Task to run its own gpupdate /force. For more information on what’s going on under the hood, check out the sidebar “Under the Hood with Remote Group Policy Processing.”

Security Background Refresh Processing

As I’ve stated, all Group Policy clients process GPOs when the background refresh interval comes to pass—but only those GPOs that were new or changed since the last time the client requested them.

Wally is on a Windows 2000 machine, and he’s been logged on for four hours. Likewise, Xavier has been logged onto his Windows XP machine for four hours, and Sven has been logged onto his Windows 7 machine for four hours. Ben on Windows 10, also four hours.

Imagine for a second that there was a GPO in Active Directory named “Prevent Access to the Control Panel” and it contained a policy setting inside it to do just that. The client would certainly do so according to the initial policy processing rules and/or the background refresh processing rules.

Assuming that the underlying GPO doesn’t get any policy settings modified or any new policy settings or that the GPO itself doesn’t get removed, the client already knows to accept this edict. The client just accepts that things haven’t changed and, hence, keeps on truckin’. Only a change inside the GPO will trigger the client to realize that new instructions are available, and the client will execute that new edict during its background policy processing.

Now, let’s assume that we anoint Wally, Xavier, Sven, and Ben as local administrators of their Windows 2000, Windows XP, Windows 7, and Windows 10 machines, respectively. Since Wally, Xavier, Sven, and Ben are now local administrators, they have total control to go around the Group Policy engine processes and make their own changes. These changes could nullify a policy you’ve previously set with a GPO and allow them to access and change features on the system that shouldn’t be changed. In this case, there are certainly going to be situations in which the GPOs on the Domain Controllers don’t change, but certain parts of the workstation should remain locked down anyway.

Of course, the right answer is to only give people you absolutely trust access to local Administrator accounts. You should never give regular users Administrator accounts if you can possibly help it.

But, with that being said, let’s examine two potential exploits of the Group Policy engine if a local administrator does choose to do so:

1. Group Policy Exploit Example #1: Going Around an Administrative Template Consider the calc.exe program we are forced to run every time someone uses a computer in Human Resources. We created a GPO named “Auto-Launch calc.exe” and enabled the policy setting named Run these programs at user logon within it. We linked the GPO to the Human Resources Computers OU. Our edict affected all users on our computers (including our administrators) so that calc.exe ran for everyone (because the GPO was linked to an OU containing the computer). Imagine, then, that someone with local administrative privileges (such as Wally) on the workstation changes the portion of the Registry that is affected, as shown in Figure 3-7.

1. After the local administrator changes the setting, calc.exe simply won’t run. (Again, only local administrators can make this change. Mere mortals do not have access to this portion of the Registry.) We’re now at risk; a local administrator did the dirty work, and now all users on this workstation are officially going around our policy. Ninety minutes or so later, the background refresh interval strikes, and the client computer requests the background refresh from the GPOs in Active Directory. You might think that this should once again lock down the “Auto-Launch calc.exe” ability. But it doesn’t. This ability won’t get relocked down on reboot, either. Why? Because the Windows client thinks everything is status quo. Because nothing has changed in the underlying GPO in Active Directory that is telling the client its instruction set changed.
2. In this example, the Group Policy processing engine on the client thinks it has already asked for (and received) the latest version of the policy; the Group Policy processing engine doesn’t know about the nefarious Registry change the local w

   o

   rkstation administrator performed behind its back. Windows clients are not protected from this sort of attack by default. However, the protection can be made stronger. (See the section “Mandatory Reapplication for Nonsecurity Policy” later in this chapter.) Okay, this example exploit is fairly harmless, but it could be more or less damaging depending on precisely which policy settings we are forcing on our clients (as seen in this next example).
3. Group Policy Exploit Example #2: Going Around a Security Policy Setting Imagine we created a GPO with settings that locked down the MYSECUREDIR directory with specific file ACLs. For this example, imagine we set the MYSECUREDIR directory so that only the Domain Administrators have access. Then, behind our backs, Sven, now a local administrator, changes these file ACLs to allow everyone full control of these sensitive files. Uh-oh, now we could have a real problem on our hands.

Windows offers protection to handle cleanup for exploits of these two types. Remember, though, in both cases, we’re assuming these users are running with Administrative rights—a real no-no. If users are simply standard users, then this “problem” would never really be a problem at all.

Let’s see how Windows tries to compensate for these circumstances.

In the first example, we went around the Run these programs at user logon policy setting by forcefully modifying the Registry. Running calc.exe for every user on a particular computer isn’t considered a security setting. So, by default there is no protection for Exploit #1 (note the emphasis on “by default”). But before you start panicking, let’s examine Exploit #2, which attempts to go around a security policy we set.

Background Security Refresh Processing

The Group Policy engine tries to clean up after examples such as Exploit #2 by asking for a special background refresh—just for the security policy settings. This is called the background security refresh and is valid for every version of Windows.

Every 16 hours, a Group Policy client asks Active Directory for all the GPOs that contain “security stuff” (not just the ones that have changed). And, all that security stuff inside those GPOs is reapplied. This ensures that if a security setting has changed on the client (behind the Group Policy engine’s back), it’s automatically patched up within 16 hours.

To reiterate, background security refresh helps secure stuff on the client only every 16 hours and only if the setting is security related. So, within a maximum of 16 hours, the windows epair directory would have the intended permissions rethrust upon it. Okay, great. But in Exploit #1, our evil administrator went around the Run these programs at user logon policy setting. And the background security refresh would not have enforced our intended will upon the system. Running calc.exe is not considered a security policy setting. “How do we secure those exploits?” I hear you cry. “Read on,” I reply. (Hey, that rhymed.)

Mandatory Reapplication for Nonsecurity Policy

Your network is humming along. You’ve established the GPOs in your organization, and you’ve let them sit unchanged for several months. Wally logs on. Wally logs off. So does Xavier. And Sven. And Ben. They each reboot their machines a bunch. But imagine for a moment that the GPOs in Active Directory haven’t changed in months.

When your users or computers perform initial Group Policy processing or background policy processing, a whole lot of nothing happens. If GPOs haven’t changed in months, there’s nothing for the clients to do. Since the engine has already processed the latest version of what’s in Active Directory, what more could it possibly need?

True, every 16 hours the security-related policy settings are guaranteed to be refreshed by the background security refresh. But what about Exploit #1 in which Wally (who was anointed as a local workstation administrator) went around the Run these programs at user logon policy setting by hacking his local Registry?

Well, running calc.exe isn’t a security policy. But it still could be thought of as a security hole you need to fill (if you were running something really important every time a user logged in). With a little magic, you can force the nonsecurity sections of Group Policy to automatically close their own security holes. You can make the nonsecurity sections of Group Policy enforce their settings, even if the GPOs on the servers haven’t changed. This will fix exploits that aren’t specifically security related. You’ll learn how to do this a bit later in the section “Affecting the Computer Settings of Group Policy.”

The general idea is that once the nonsecurity sections of Group Policy are told to mandatorily reapply, they will do so whenever an initial policy processing or background refresh processing happens.

You can choose to (optionally) mandatorily reapply the following areas of Group Policy, along with the initial processing and background refresh:

• Registry (Administrative Templates)
• Internet Explorer Maintenance
• IP Security
• EFS Recovery Policy
• Wireless Policy
• Disk Quota
• Scripts (by scripts I mean the notification of changes to scripts, not the actual rerunning of scripts after the appointed time)
• Security
• Folder Redirection
• Software Installation
• Wired Policy

As you’ll see in the section “Affecting the Computer Settings of Group Policy,” you can use the GUI to select other areas of Group Policy to enforce along with the background refresh.

To recap, if the GPO in Active Directory has actually changed, you don’t have to worry about whether it will be automatically applied. Rather, mandatory reapplication is an extra safety measure that you can choose to place on your client systems so your will is always downloaded and re-embraced, not only if an existing GPO has changed or a new GPO has appeared. And you can specify Group Policy sections that you wish to do this for.

Special Case: Moving a User or a Computer Object

When you move a user or a computer within Active Directory, Group Policy may not immediately apply as you think it should. For instance, if you move a computer from the Human Resources Computers OU to another OU, that computer may still pull GPOs from the Human Resources Computers OU for a while longer. This is because the computer may get confused about where the accounts it’s supposed to work with are currently residing.

The userenv process syncs with Active Directory every so often to determine if a user or a computer has been moved.

This happens, at most, about every 30 minutes or so.

Once resynced, background processing continues as it normally would—only this time the user and computer GPOs are pulled from the new destination. If you move a user or a computer, remember that Group Policy processing continues to pull from the old location until it realizes the switch.

And don’t forget that replication takes a while within your site and, also, potentially between Active Directory sites.

Altogether, the maximum wait time after a move to get GPOs pulled from a new location is as follows:

• 30 minutes (the maximum Active Directory synchronization time) and
• 90 minutes (the maximum Group Policy default background refresh rate) and
• 30 minutes (the maximum Group Policy default background refresh rate offset)

So that’s a grand total maximum of 150 minutes. It could and usually does happen faster than that, but it can’t take any longer. This behavior is important to understand if you move an entire OU (perhaps with many computers) underneath another OU!

Windows 7 and later has a special trick up its sleeves. If you know the computer or user account has been moved (and, hence, would get different Group Policy settings), you can just run gpupdate /force, which double-checks where both the user and computer account live in Active Directory. Once the location is found, it applies GPOs specifically for that new location.

In my testing with Windows 7 and later, this does seem to work “pretty well.” But, my suggestion is that if you move a user around, to be 100 percent sure, you should then log off and log back on. If you move a computer around, you should then reboot the machine. Only then are you really sure to get the latest settings.

Windows 8, 8.1, and 10 Group Policy: Subtle Differences

Okay, I’ve waited until now to discuss (and actually re-discuss) a handful of very, very small and possibly inconsequential secrets about how the Group Policy processing engine for Windows 8 and later is ever-so-slightly different from that of Windows past. The changes happened at Windows 8 and again at Windows 8.1 and continue onward to Windows 10. Said another way, Windows 8 had some changes. Then Windows 8.1 had some more changes, and those changes continued through to Windows 10. But Windows 10 itself really didn’t have any additional changes.

Secret 1: The Windows Group Policy Service Turns On and Off (Windows 8 and Later)

To save battery life, most Windows 8 and later services will automatically turn off when not needed. When it comes to Group Policy, here’s specifically how this works.

When the computer turns on and requests Group Policy, the Group Policy Service starts up, gets Group Policy and then…waits. It waits 10 minutes for any additional requests for Group Policy. Now, usually during those 10 minutes the user logs on. So the service stays on, processes the User side of Group Policy, then waits another 10 minutes. If nothing happens in 10 minutes, the service goes to sleep. Should you manually run gpupdate or perform a remote Group Policy Refresh, the service takes a second (or three) to start up, performs the request, and then waits for 10 minutes. And the cycle continues. Therefore, if you keep running gpupdate over and over again within 10 minutes, the “countdown” to put the service to sleep restarts every time the Group Policy engine has to do something. Eventually, however, the Group Policy service sleeps until it’s next needed.

Microsoft calls this behavior Always On, Always Connected (AOAC). I have no idea why—it’s not a very descriptive name for this “Sleep when not needed” process.

This behavior is set by default on all Windows 8 and later clients, including Windows RT. This does mean that the service will take some time to start up before it performs the Group Policy update request if it’s asleep. You can revert the behavior back to the “non-sleepy” way by using the Group Policy setting Turn off Group Policy Client Service AOAC optimization, which is explored in the section “Using Group Policy to Affect Group Policy” a little later.

This behavior is off by default on Windows Servers. This means that the service never sleeps on Windows Server 2012 and later and is always on.

Secret 2: Windows RT Cannot Get Active Directory–Based Group Policy (Windows 8 and Later)

We talked about this in Chapter 1, so I guess it isn’t a secret. But it’s still unclear and bears repeating.

In short, Windows RT computers cannot be domain joined and therefore cannot get Active Directory–based Group Policy.

You can, however, run GPEDIT.MSC on Windows RT machines and manually flip the switches of various items.

There doesn’t appear to be any way to update a Windows RT machine’s Group Policy using some kind of central management. If it ever happens, stay tuned on GPanswers.com for more information as the subject emerges.

Secret 3: If You Use Windows Hiberboot, You (Basically) Lose Computer Processing at Startup (Windows 8 and Later)

Windows 8 and later has a feature called Hiberboot. Hiberboot enables a low-power and quick restart of a system. The user sees the command as “Shut down” in the GUI—except it’s not really shut down at all. It’s more like “super suspend.”

Then, when the system is powered back on and “rebooted,” it looks and feels super fast. But it’s not a real full power off and full restart reboot. You can read more about Hiberboot and see a video here:

http://blogs.msdn.com/b/b8/archive/2011/09/08/delivering-fast-boot-times-in-windows-8.aspx

So, with regard to Group Policy, here’s the deal. When you start the computer up from Hiberboot, Group Policy doesn’t process the Computer side. That’s because the computer was, technically, on already, just in a low-power state. At some point in the computer’s distant past, it was completely powered off. And only at that initial completely powered-down point did it get the Computer-side GPOs at startup.

Then, when the user logs in, User-side policy processes as normal after logon. All normal User-side processing works as previously described. And if you’ve changed Group Policy processing to synchronous mode, then the Group Policy engine will cheerfully perform in synchronous mode, too.

Then, up to 90 minutes after the computer is started, the background refresh interval will kick in for Windows Computer side and process any changed items on the Computer side.

However, there is a big catch here: Remember that some directives cannot process when the computer is already started up—notably, computer-based Group Policy Software Deployment. So, if you’re expecting to see your software on the next “reboot,” you won’t see it, because you’re not fully rebooting at all. Instead, the computer would need to be powered off and back on with a “Restart” and not a “Shutdown” (which really, again, isn’t a shutdown at all).

If you want to always have full shutdowns, which will enable computer processing every time the computer starts, you will need to disable hibernation, which in turn prevents Hiberboots from occurring.

Secret 4: Group Policy Preferences Drive Maps and Disk Quotas Run in the Background (Windows 8.1 and Later)

Windows 8.1 and later have eliminated the need to log off (for Group Policy Preferences Drive Maps) or to reboot (for Disk Quotas).

If you make a Group Policy Preferences Drive Maps change or a Disk Quota change, you’ll see those changes take effect in the background, or when you run gpupdate.

There’s a side benefit here, too. Before Windows 8.1, if you used Group Policy Preferences Drive Maps, every other login would be triggered for a foreground update, and every other login would be triggered for a background update.

I call this the “Tick / Tock” problem with Group Policy Preferences Drive Maps. I demonstrated this in my TechEd 2014 talk, again found at:

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/WIN-B328#fbid=

You can jump to the 35- and 46-minute minute marks to see the demo.

So instead of one login being fast-ish and another being slower-ish, when Group Policy Preferences Drive Maps is used, it just becomes more consistent.

That’s a big win.

Secret 5: Better Logging from Windows 8.1 and Later

Windows 8.1 and later has added better logging. I’ll talk more about Group Policy event logging in Chapter 7. But, starting in Windows 8.1, Group Policy got a handful of new Event IDs that can help you understand and troubleshoot when things go wrong.

In Chapter 7, I provide a list of Event IDs for the Group Policy engine should you want them.

Secret 6: Group Policy Caching (Windows 8.1 and Later)

Windows 8.1 introduced a very unusual feature called Group Policy Caching. The goal of Group Policy Caching is a noble one, but it appears to have missed its mark.

The goal is to minimize over-the-network chatter when two things are true:

• When the link is slow.
• When Group Policy is told to perform a foreground policy process.

Those conditions are rarely ever occurring with Windows 8.1 and later, because Microsoft reduced the Group Policy items that require a foreground process to only Folder Redirection and Group Policy Software Installation. And even then, those items need to be new or changed in the Group Policy Object to trigger a foreground process.

Therefore, the Group Policy cache is rarely, if ever, actually used.

In fact, there’s a side effect of the Group Policy cache. If you are on someone’s client machine and just run gpupdate, because the Group Policy cache is trying to store these GPOs for later possible use, it takes a lot longer to actually finish a manual gpupdate because of the extra network traffic and disk writes to perform the work. But, again, you would only see this delay if you manually ran gpupdate, and it doesn’t affect login time.

My pal Darren Mar-Elia has two blog entries on Group Policy Caching, which are worth a read, if only to see how he breaks down the feature and, like me, decides that this feature misses its mark. Here are the two URLs for extra reading:

http://sdmsoftware.com/group-policy-blog/group-policy/understanding-group-policy-caching-in-windows-8-1/

http://sdmsoftware.com/group-policy-blog/windows-8-1/clarifying-group-policy-caching-in-windows-8-1/

So, in the end analysis, I think unless the Group Policy cache is updated to support some other use cases, it’s not super valuable. And if your machines are always connected and hardwired, there’s zero reason to keep the cache working at all. In these cases you can turn off the Group Policy cache with the Configure Group Policy Caching policy setting and set it to Disabled as seen in Figure 3-8. It is located in the Computer Configuration ⇒ Administrative Templates ⇒ System ⇒ Group Policy section.

Note there is also a policy setting named Enable Group Policy Caching for Servers, which I wouldn’t recommend enabling.

Secret 7: When Many GPOs Are Involved, Using Windows 8.1 and Later Could Just “Be Faster”

Starting with Windows 8.1 and later, Microsoft optimized the client when multiple GPOs are requested. If there are a lot of GPOs, the amount of “chatter” has been reduced.

Additionally, if there are slow links involved (see the next section) the downloading of the GPOs can just be a lot faster and more optimized than when Windows 7 was doing it.

Therefore, if you have a lot of GPOs and put a Windows 7 and a Windows 10 machine side by side, it’s likely the Windows 10 machine will beat the Windows 7 machine.

There’s nothing to configure here; it’s all internal starting with Windows 8.1 and continuing onward.

Secret 8: Processing of Logon Scripts Is Delayed 5 Minutes (Windows 8.1 and Later)

Starting with Windows 8.1 and continuing onward, Microsoft decided to delay the processing of login scripts when deployed using Group Policy.

If you think about it, this is a good idea.

When the user is logging on, all this stuff is trying to happen at once:

• Talking over the network.
• Setting up or downloading a profile.
• Explorer is trying to run.
• The Run and Runonce items are trying to fire off.
• Possibly other login actions are trying to fire off as well.

With all this activity that is definitely going to happen anyway, do you really want the additional network chatter and hard drive utilization all at the same exact time as this other stuff?

Said another way, the slowest thing in your computer is your hard drive. If all these items are firing off at the same time (including the login script, if there is one), then it’s just going to be a contentious battle for the disk.

So, instead, Microsoft has decided to keep the logon script out of the melee between all the stuff that has to happen and the login script.

The login script is now, by default, delayed 5 minutes, but this delay is configurable to any number you like. This is configurable in the Configure Login Script Delay policy setting. You could set it to disabled, or enabled, 0 (zero), which would make the behavior revert back to the old style.

For me, I think you should be able to get out of the dirty business of login scripts altogether. And if you can’t, I think it’s reasonable to have some kind of delay on it.

That being said, if you’ve rolled out Solid State Disks (SSDs) to your computers or otherwise find that a login script doesn’t add delays, then feel free to turn this feature off by setting the Computer Configuration ⇒ Administrative Templates ⇒ System ⇒ Group Policy ⇒ Configure Login Script Delay policy setting to zero as seen in Figure 3-9.

Policy Application via Remote Access, Slow Links, and after Hibernation

You will certainly have situations in which users take their Windows machines on the road and access your Active Directory and servers remotely via dial-up or VPN.

We’re going to be talking about Windows Vista and later here. If you want to learn how Windows XP handles slow network connections, you’ll have to go to a previous edition of the book.

When and How Does Windows Check for Slow Links?

Windows Vista and later can detect link speed using a Windows component called Network Location Awareness (NLA).

NLA is pretty simple, and there’s nothing you need to configure. NLA for Windows Vista and later (like Windows 10) has two jobs:

1. NLA checks to see if the link is slow. This test doesn’t use ICMP, so if router administrators have turned off ICMP, the calculation will still work. (See the next section, “What Is Processed over a Slow Network Connection?” for why you should care about what is processed over a slow network connection.)
2. NLA calls out to the universe every so often and asks, “Is there a Domain Controller available NOW?” If the answer is “No!” then Group Policy cannot be updated. Pretty simple. However, if the answer is “Yes!” updated Group Policy could, theoretically, be processed, right?

This might be useful when a user has been working at the beach, disconnected for several days, then finally dials up or comes into the office. However, before doing anything, the Group Policy engine kicks in and asks one more question: “Did I miss the last background refresh interval?” (For instance, if the computer was hibernated, and therefore turned off, for three days).

If the answer is “Yes,” then the Group Policy engine immediately performs (what amounts to) a gpupdate (no /force) to refresh Group Policy since the last time the user and computer made contact.

Why is the Group Policy engine so specific about finding out whether it missed the last background refresh interval? The Group Policy engine asks this question because NLA could have determined that the computer was ever-so-briefly off the network—and then back on again. And if that’s the case, there was nothing to miss, so nothing is updated. You wouldn’t want it to trigger every time it went off and back on the network. That would be a veritable flurry of Group Policy updating! In other words, the Group Policy engine ensures that Windows was off the network for a good amount of time before asking for a refresh.

Again, Windows Vista and later all act the same way, including Windows Server 2008 R2 and later. But it’s unlikely you’re going to have Windows Server 2016 on a laptop and VPN in from the beach.

What Is Processed over a Slow Network Connection?

So, if the connection is deemed fast enough, portions of Group Policy are applied.

Surprisingly, even if the connection is deemed “not fast enough,” several sections of Group Policy are still applied. Security settings and Administrative Templates are guaranteed to be downloaded during logon over a slow connection regardless of the speed. And there’s nothing you can do to change that (not that you should want to). Additionally, included in security settings are Software Restriction Policy, EFS (Encrypting File System) Recovery Policy, and IPsec (IP Security) policy. They are also always downloaded over slow links.

Other sections of Group Policy are handled as follows during a slow connection:

1. Folder Redirection Settings By default, these are not downloaded over slow links. (Again, you can change this condition using the information in “Using Group Policy to Affect Group Policy.”)
2. Scripts (Logon, Logoff, Startup, and Shutdown) By default, script updates are not downloaded over slow links. (You can change this condition using the information in “Using Group Policy to Affect Group Policy.”) Scripts themselves should still run, if the client can reach over the network and perform the run.
3. Disk Quota Settings By default, these are not downloaded over slow links. (You can change this condition using the information in “Using Group Policy to Affect Group Policy.”) The currently cached disk quota settings are still enforced.
4. Software Installation and Maintenance By default, these are not downloaded over slow links. More specifically, the offers of newly available software are not shown to users. Users do have the ability to choose whether to pull down the latest versions of applications at their whim. You can torture your dial-in users by changing the behavior of how offers are handled and by permitting the icons of new software to be displayed. They will hate you after you do this, but that is for you and them to work out. See the corresponding setting described later in this chapter in “Using Group Policy to Affect Group Policy.” More information about Group Policy Software Installation can be found in Chapter 11, “The Managed Desktop, Part 2: Software Deployment via Group Policy.”
5. Software Restriction Policy These are guaranteed to download over slow links. You cannot turn off this ability. More information about Software Restriction Policy can be found in Chapter 8.
6. 802.11 Wireless Policy By default, these are not downloaded over slow links. (You can change this condition using the information in “Using Group Policy to Affect Group Policy.”) The currently cached 802.11 policy settings are still enforced.
7. 802.3 Wired Policy (Windows Vista and Later) By default, these are not downloaded over slow links. (You can change this condition using the information in “Using Group Policy to Affect Group Policy.”)
8. Administrative Templates These are guaranteed to download over slow links. You cannot turn off this ability.
9. EFS Recovery Policy These are guaranteed to download over slow links. You cannot turn off this ability. The interface has an option that makes it appear as if you can turn off this ability, but you can’t.
10. IPsec Policy These are guaranteed to download over slow links. You cannot turn off this ability. Again, the interface has an option that makes it appear as if you can turn off this ability, but you can’t.
11. Group Policy Preference Extensions The Group Policy Preference Extensions, which we’ll explore in Chapter 5, “Group Policy Preferences,” will by default all download and process over slow links. Usually, people are concerned about getting Group Policy Preferences Drive Maps over a slow link. And starting with Windows 8.1 and continuing onward, Group Policy Preferences Drive Maps (new ones and changes) should download and process over a slow link. Before Windows 8.1, Group Policy Preferences Drive Maps would not process over a slow link (because Group Policy Preferences Drive Maps would not process in the background).

You can change what is considered fast enough for all these policy categories from 500Kbps to whatever speed you desire (independently for the Computer half and the User half). This is detailed in the section “Using Group Policy to Affect Group Policy.”

Always Get Group Policy (Even on the Road, through the Internet)

So you want Group Policy to apply to your machines, even if they’re not currently physically at your offices or if they rely upon users using a VPN. How can you do that?

There are two ways: One is from Microsoft. The other is (again, I mentioned I would be doing this) from PolicyPak, using PolicyPak Cloud.

Let’s explore the two ways.

Group Policy over the Internet Using Unified Remote Access (Formally Known as DirectAccess)

Microsoft has had two technologies for “seamless network access”—DirectAccess (with Windows Server 2008 R2 and Windows Server 2012) has now been morphed into Unified Remote Access for Windows Server 2012 R2 and Windows Server 2016 and Unified Access Gateway (UAG). UAG is being discontinued for mainstream support in 2015, but Unified Remote Access (aka DirectAccess) lives on.

Here’s the idea of both (they’re built on the same technologies).

In short, both technologies promise a way for laptops to simply “always be on the network”—if they’re really at headquarters or in the coffee shop. Now if that sounds a little scary, there’s supposed to be lots and lots of security involved IN getting these solutions up and going.

But the promise of Unified Remote Access is quite interesting. The promise is that, once your laptops are set up to use Unified Remote Access, your laptops are, well, “always on the network.” And if they’re always on the network, they just always get Group Policy, naturally. I haven’t personally set this up and tested it end to end. I hear generally “good things” from folks who say this works as advertised. It is quite an uphill battle getting all the hardware and software and licenses and such working. But when Unified Remote Access does work, I hear it works great, and Group Policy will magically apply, say, when your users are sipping coffee at Starbucks.

Unified Remote Access has three main problems:

• First, it doesn’t work with all flavors of Windows 7, 8, and 10. It only works with the Enterprise versions of Windows, meaning if you have the Professional (or Pro) versions of Windows, you literally cannot use those systems and magically connect using Unified Remote Access.
• Second, all machines must be domain joined before working with Unified Remote Access.
• Last, based upon what people have told me, my understanding is that it’s quite a bear to set up and keep working reliably.

That said, here are some links to help you if you decide to try out the Unified Remote Access (aka DirectAccess) route:

For DirectAccess on 2012 R2, I would start with:

http://technet.microsoft.com/en-us/library/dn636118.aspx

and:

http://technet.microsoft.com/en-us/library/dn614138.aspx

There’s a multipart article on DirectAccess 2012 with precise how-to for a test lab here: http://tinyurl.com/directaccess-2012. Start with part 1 and continue on. If you’re looking for all the articles in the series, try:

http://blogs.technet.com/b/meamcs/archive/tags/direct+access/

There’s also a more modern book specifically about it found here:

www.packtpub.com/networking-and-servers/windows-server-2012-unified-remote-access-planning-and-deployment

Group Policy over the Internet (using PolicyPak Cloud)

If you want your machines to get Group Policy while your users are on the road or at remote offices, without having to buy or build servers or change any architecture at all, then check out PolicyPak Cloud.

PolicyPak Cloud is a service where you can do the following:

• Create XML “directives” based upon contents of real GPOs.
• Upload those XML directives.
• Have computers join your PolicyPak Cloud.
• Have computers download and process your PolicyPak directives.

In Figure 3-10, you can see four XML directives linked to the “All” group in PolicyPak Cloud.

You can literally take just about any piece of a GPO, and upload it to PolicyPak cloud.

Client computers simply download and process these directives just like real GPOs and process them. Here’s the best part about PolicyPak Cloud:

• There are no servers to buy, build, or install.
• XML directives are created from the contents of real GPOs. Almost all settings within a Group Policy Object can be delivered via PolicyPak Cloud.
• Client machines can be any flavor of Windows (Pro, Professional, or Enterprise).
• Client machines can be domain joined and even non–domain joined. (That’s a big, big deal.)
• Clients can use PolicyPak Cloud over encrypted HTTP or HTTPS—behind proxy servers and other weird network setups.

In this way, PolicyPak Cloud is great for IT pros who need to manage non–domain joined machines and machines that don’t come back to the office very often or use a VPN. It’s also great for Managed Service Providers (MSPs) who want a “one-stop shop” to upload directives and make sure they affect multiple customers at once (based upon customer groupings).

You can see the Quickstart and demos for PolicyPak Cloud on the PolicyPak web page at the following location and then check it out if it seems interesting to you:

www.policypak.com/support-sharing/policypak-cloud-getting-started.html

Also, see Appendix D for a PolicyPak Cloud walk-through.

Using Group Policy to Affect Group Policy

At times, you might want to change the behavior of Group Policy. Amazingly, you actually use Group Policy settings to change the behavior of Group Policy! Several Group Policy settings appear under both the User and Computer nodes; however, you must set the policy settings in each section independently.

Affecting the User Settings of Group Policy

The Group Policy settings that affect the User node appear under User Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Group Policy. Remember that user accounts must be subject to the site, domain, or OU where these GPOs are linked in order to be affected. Most of these policy settings are valid for any Windows machine, although some are explicitly designed and will operate only on Windows XP, Windows Vista, Windows 7, and so on.

The following sections list the policy settings that affect the User side of Group Policy.

Set Group Policy Refresh Interval for Users

This setting changes the default User node background refresh rate of 90 minutes with a 0–30-minute positive randomizer to almost any number of refresh and randomizer minutes you choose. Choose a smaller number for the background refresh to speed up Group Policy on your machines, or choose a larger number to quell the traffic that a Group Policy refresh takes across your network. There is a similar refresh interval for computers, which is on an alternate clock with its own settings. A setting of 0 is equal to seven seconds. Set to 0 only in the test lab.

Configure Group Policy Slow Link Detection

You can change the default definition of fast connectivity for users from 500Kbps to any speed you like. Recall that certain aspects of Group Policy are not applied to machines that are determined to be coming in over slow links. This setting specifies what constitutes a slow link for the User node. There is an identically named policy setting located under the Computer node (explored later in this chapter) that also needs to be set to define what is slow for the Computer node. Preferably set these to the same number. Note that you can set the Group Policy Slow Link Detection policy setting to zero to disable it.

Configure Group Policy Domain Controller Selection

GPOs are written to the PDC emulator by default. When users (generally Domain Administrators or OU administrators) are affected by this setting, they are allowed to create new GPOs on Domain Controllers other than the PDC emulator. See Chapter 7 for more information on this setting and how and why to use it.

Create New Group Policy Object Links Disabled by Default

When users (generally Domain Administrators or OU administrators) are affected by this setting, the GPOs they create will be disabled by default. This ensures that users and computers are not hitting their refresh intervals and downloading half-finished GPOs that you are in the process of creating. Enable the GPOs when finished, and they will download during their next background refresh cycle.

Set Default Name for Group Policy Objects

If a user has been assigned the rights to create GPOs via membership in the Group Policy Creator Owners group and has also been assigned the rights to link GPOs to OUs within Active Directory, the default name created for GPOs is “New Group Policy Object.” You might want all GPOs created at the domain level to have one name, perhaps “AppliesToDomain-GPO,” and all GPOs created at the Human Resources OU level (and all child levels) to have another name, maybe “AppliestoHR-GPO.” Again, in order for this policy to work, the user’s account with the rights to create GPOs must be affected by the policy.

Enforce Show Policies Only

When users (generally Domain Administrators or OU administrators) are affected by this setting, the “Only show policy settings that can be fully managed” setting (explored in Chapter 6, “Managing Applications and Settings Using Group Policy”) is forced to be enabled. This prevents the importation of “bad” Administrative Templates (ADM files), which have the unfortunate side effect of tattooing the Registry until they are explicitly removed. (See Chapter 6 for more information on using all types of ADM templates.) Note, however, that the updated GPMC will always show “bad” ADM templates and, hence, this isn’t needed when using the updated GPMC (the one with RSAT) on your management station.

Turn Off Automatic Update of ADM Files

You’ll learn all about ADM files (and this particular policy setting) in Chapter 6. But, in essence, ADM template files are the underlying “definitions” of what’s possible in Group Policy–land (when you use pre-Vista management machines). When you use Vista (and later) management machines (like Windows 10), a new mechanism called ADMX files is used to define policy settings. Here’s the 10-second “before Chapter 6” crash course. ADM templates start out in life on your local machine running the older GPMC. Then, they’re “pushed up” into the GPO for future reference.

When it comes to ADM template behavior, the default behavior is to check the local machine’s default location—that is, the windowsinf folder—to see if the ADM template (locally) is newer than the one stored inside the GPO. If it’s newer—bingo, the one in the GPO is overwritten.

By default, this check for an update occurs every time you double-click the Administrative Templates section of any GPO as if you were going to modify it. However, if you enable this setting, you’re saying to ignore the normal update process and simply keep on using the ADM template you initially used. In other words, you’re telling the system you’d prefer to keep the initial ADM template regardless of whether a newer one is available. (See Chapter 6 for more info on this topic.)

Determine If Interactive Users Can Generate Resultant Set of Policy Data

Users affected by this setting cannot use gpresult.exe, the Group Policy Modeling, Group Policy Results tasks in the GPMC, or the old-and-crusty RSOP.MSC (which shouldn’t be used anyway).

Enabling this setting locks down a possible entry point into the system. That is, it prevents unauthorized users from determining the current security settings on the box and developing attack strategies.

This policy setting is valid only when applied to Windows XP workstations and Windows 2003 Servers (even though the policy specifies “At least XP and Server 2003”).

In my testing, this setting did not affect Windows Vista and later machines.

Affecting the Computer Settings of Group Policy

The Group Policy settings that affect the Computer node appear under Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Group Policy. Once computers are affected by these policy settings, they change the processing behavior of Group Policy. Remember that the computer accounts must be subject to the site, domain, or OU where these GPOs are linked in order to be affected.

Note that also underneath “Group Policy” is another subcategory called “Logging and Tracing.” We’ll talk about those policy settings in Chapter 5 when we discuss the Group Policy Preferences. Next, we’ll be exploring a lot of settings. If you don’t see all the settings on your machine, it’s likely because you’re using a Windows 10, 8, or 7 management machine and not a Windows Server 2012 or Windows Server 2016 management machine.

If you’re missing some settings, be sure to read the section “The Missing Group Policy Preferences’ Policy Settings” a little later to understand why.

Preference Extension Policy Processing

Actually, this isn’t the name of any specific policy setting. Indeed, you’ll find 21 policy settings that manage each of the Group Policy Preferences items. You’re looking for names like “Drive Maps preference extension policy processing” or “Printers preference extension policy processing” and the like. All of them have the same look and feel should you click on them, similar to what’s seen in Figure 3-11.

Note that when the policy setting is Not Configured, the defaults are set.

Once enabled, each policy setting has four potential options:

1. Allow Processing Across a Slow Network Connection Select this check box to allow this particular Group Policy Preferences category to download when logging on over slow links. This is set on by default. You might want to deselect this check box if you want logins to be faster over VPN so the Group Policy Preferences category isn’t trying to reinstall over a VPN. Group Policy Preferences Printers is a good one to deselect because installing printers over VPN can be really slow.
2. Do Not Apply during Periodic Background Processing If this option is selected, the particular Group Policy Preferences category will not be downloaded or applied during the background refresh. This is not selected by default, meaning that most Group Policy Preferences items will reapply when the user is logged on.
3. Process Even If the Group Policy Objects Have Not Changed If this option is selected, it updates and reapplies the policy settings in this category even if the underlying GPO has not changed. Recall that this type of processing is meant to clean up should a user or an administrator have nefariously gone behind our backs and modified a local setting.
4. Background Priority I’m not exactly sure why this option is available to us as administrators to tweak, because I’ve never seen a reason to use it. In short, this sets up how much processing juice this particular CSE will use. To be on the safe side, I would just leave it as Idle.

   

Turn Off Background Refresh of Group Policy

When this setting is enabled, the affected computer downloads the latest GPOs for both the user and the computer, according to the background refresh interval—but it doesn’t apply them. The GPOs are applied when the user logs off but before the next user logs on. This is helpful in situations in which you want to guarantee that a user’s experience stays the same throughout the session.

Set Group Policy Refresh Interval for Computers

This setting changes the default Computer node background refresh rate of 90 minutes with a 30-minute randomizer to almost any number of refresh and randomizer minutes you choose. Specify a smaller number for the background refresh to speed up Group Policy on your machines, or choose a larger number to quell the traffic a Group Policy refresh causes across your network. A similar refresh interval for the User node is on a completely separate and unrelated timing rate and randomizer. A setting of 0 equals seven seconds. Set to 0 only in the test lab.

Set Group Policy Refresh Interval for Domain Controllers

Recall that Domain Controllers are updated regarding Group Policy changes within five minutes. You can close or widen that gap as you see fit. The closer the gap, the more network chatter. Widen the gap and the security settings will be inconsistent until the interval is hit. A setting of 0 equals seven seconds. Set to 0 only in the test lab.

Configure User Group Policy Loopback Processing Mode

We’ll explore this setting in detail in the next chapter.

Allow Cross-Forest User Policy and Roaming User Profiles

This policy is valid only in cross-forest trust scenarios. I’ll describe how these work and how this policy works in Chapter 4, “Advanced Group Policy Processing,” in the section “Group Policy with Cross-Forest Trusts.”

This policy setting is valid only when applied to Windows XP/SP2 systems and later.

Configure Group Policy Slow Link Detection

You can change the default definition of fast connectivity from 500Kbps to any speed you like. Recall that certain aspects of Group Policy are not applied to those machines that are deemed to be coming in over slow links. Independently, an identically named policy setting that exists under the User node (explored earlier) also needs to be set to define what is slow for the User node. Preferably, set these to the same number.

Turn Off Resultant Set of Policy Logging

As you’ll see in Chapter 7, users on Windows XP can launch the Resultant Set of Policy (RSoP) snap-in by typing RSOP.MSC at the command prompt. Enabling this policy setting doesn’t prevent its launch but, for all intents and purposes, disables its use. This policy setting disables the use for the currently logged-on user (known as the interactive user) as well as anyone trying to get the results using the remote features of the RSoP snap-in.

This policy setting is valid only when applied to Windows XP workstations and Windows 2003 Servers (even though the policy specifies “At least XP and Server 2003”).

In my testing, this setting did not affect Windows Vista and later machines. Your mileage may vary.

Remove Users’ Ability to Invoke Machine Policy Refresh

By default, mere-mortal users can perform their own manual background refreshes using gpupdate. However, you might not want users to perform their own gpupdate. I can think of only one reason to disable this setting: to prevent users from sucking up bandwidth to Domain Controllers by continually running gpupdate. Other than that, I can’t imagine why you would want to prevent them from being able to get the latest GPO settings if they were so inclined. Perhaps one user is performing a denial of service (DoS) attack on your Domain Controllers by continually requesting Group Policy—but even that’s a stretch.

Even if this policy is enabled, local administrators can still force a gpupdate. But, again, gpupdate only works when run locally on the machine needing the update.

This policy setting is valid only when applied to Windows XP and newer and requires a reboot to kick in.

Determine If Interactive Users Can Generate Resultant Set of Policy Data

This policy is similar to the Turn off Resultant Set of Policy logging setting but affects only the user on the console. Enabling this setting might be useful if you don’t want the interactive user to have the ability to generate RSoP data but you still want to allow administrators to get the RSoP remotely.

This policy setting only affects Windows XP (and Windows Server 2003).

Configure Registry Policy Processing

This setting affects how your policy settings in the Administrative Templates subtrees react (and, generally, any other policy that affects the Registry). Once this policy setting is enabled, you have two other options:

1. Do Not Apply during Periodic Background Processing Typically, Administrative Templates settings are refreshed every 90 minutes or so. However, if you enable this setting, you’re telling the client not to ever refresh the Administrative Templates in the GPOs that are meant for it after the logon. You might choose to prevent background refresh for Administrative Templates for two reasons:
   • On Windows XP when the background refresh occurs, the screen may flicker for a second as the system reapplies the changed GPOs (with their policy settings) and instructs Explorer.exe to refresh the Desktop. This could be a slight distraction for the user every 90 minutes or so.
   • You might choose to disable background processing so that users’ experiences with the Desktop and applications stay consistent for the entire length of their logon. Having settings suddenly change while the user is logged on could be confusing.

This issue was resolved since the release of Windows Vista. My advice is to leave this setting alone unless you’re seriously impacted by the background processing affecting your users’ experience.

1. Process Even If the Group Policy Objects Have Not Changed If this setting is selected, the system will update and reapply the policy settings in this category even if the underlying GPO has not changed when the background refresh interval occurs. Recall that this type of processing is meant to clean up should an administrator have nefariously gone behind our backs and modified a local setting.

Configure Internet Explorer Maintenance Policy Processing

Once enabled, this policy setting has three potential options:

1. Allow Processing across a Slow Network Connection Select this check box to allow Internet Explorer Maintenance settings to download when logging on over slow links. Enabling this could cause your users to experience a longer logon time, but they will adhere to your latest Internet Explorer wishes.
2. Do Not Apply during Periodic Background Processing If this option is selected, the latest Internet Explorer settings in Active Directory GPOs will not be downloaded or applied during the background refresh.
3. Process Even If the Group Policy Objects Have Not Changed If this option is selected, it updates and reapplies the policy settings in this category even if the underlying GPO has not changed. Recall that this type of processing is meant to clean up should a user or an administrator have nefariously gone behind our backs and modified a local setting.

Configure Software Installation Policy Processing

Once enabled, this policy setting has two potential options:

1. Allow Processing across a Slow Network Connection As I stated, by default, software deployment offers are not displayed to users connecting over slow links. This is a good thing; allowing users to click the newly available icons to begin the download and installation of new software over a 56K dial-up line can be tortuous. Use this setting to change this behavior.

1. Process Even If the Group Policy Objects Have Not Changed For Software Installation, I cannot find any difference whether this option is selected or not, though Microsoft has implied it might correct some actions should the software become damaged. Since software deployment offers are only displayed upon logon or reboot (otherwise known as foreground policy processing), in my testing this setting seems not to have any effect.

Configure Folder Redirection Policy Processing

Once enabled, this policy setting has two potential options:

1. Allow Processing across a Slow Network Connection Recall that the Folder Redirection policy is changed only at logon time. Chances are you won’t want dialed-in users to experience that new change. Rather, you’ll want to wait until they are on your LAN. If you want to torture your users and allow them to accept the changed policy anyway, use this setting to change this behavior.
2. Process Even If the Group Policy Objects Have Not Changed I cannot find any difference whether this setting is selected or not, though Microsoft has implied it might correct some folder-redirection woes should the username get renamed.

Configure Scripts Policy Processing

This one is a weird one, so stay with me. If you change this setting, you’re not saying, “I want to run scripts over a slow link.”

What you’re saying is, “When I’m over a slow link, I want to accept changes to where I know the scripts are running from.”

That’s a biiiiiig distinction. Here’s the scenario:

• Fred has a GPO that tells him he’s got a logon script that runs from \server15share10 unme.bat.
• Fred cheerfully runs this script, day in and day out—even over a slow link.
• Then, you change the GPO and point Fred’s script to \server81share101 unme2.bat.
• Fred’s computer will not be updated about the knowledge of the change. Fred will continue to try to run the script from the original location. Oops!

So, the idea is that you’ll use this policy setting to change the behavior of the script’s CSE if you want to ensure that Fred will receive the updated location—even over a slow link.

So, once enabled, this policy setting has three potential options:

1. Allow Processing across a Slow Network Connection Recall that, by default, updates to where scripts run are not downloaded over slow networks. Change this option to allow the updates to download over slow links. The actual running of the scripts is a different process; this setting only cares if there is a new or updated reference to a script.
2. Do Not Apply during Periodic Background Processing This option will not allow the newest script instructions to be downloaded.
3. Process Even If the GPOs Have Not Changed This option will allow the newest script instructions to be downloaded even if the GPOs have not changed.

Configure Security Policy Processing

Once enabled, this policy setting has two potential options:

1. Do Not Apply during Periodic Background Processing Recall that the security settings are refreshed on the machines every 16 hours, whether or not they need it. Checking this option will turn off that refresh. I recommend that you leave this as is. However, you might want to consider enabling this setting for servers with high numbers of transactions that require all the processing power they can muster.
2. Process Even If the GPOs Have Not Changed Recall that after 16 hours, this policy category is always refreshed. With this option enabled, the security policies will be reprocessed during every refresh cycle.

Configure IP Security Policy Processing

Once enabled, this policy setting has three potential options:

1. Allow Processing across a Slow Network Connection When selected, this setting (shown in Figure 3-12) does nothing. IP Security settings are always downloaded, regardless of whether the computer is connected over a slow network. So, you might be asking yourself, what happens when you select this check box? Answer: nothing—it’s a bug in the interface. To repeat: IP Security is always processed, regardless of the link speed.

1. Do Not Apply during Periodic Background Processing If this option is selected, the latest IP Security settings in Active Directory GPOs will not be downloaded or applied during the background refresh.
2. Process Even If the Group Policy Objects Have Not Changed If this option is selected, it updates and reapplies the policy settings in this category even if the underlying GPO has not changed. Recall that this type of processing is meant to clean up should a user or an administrator have nefariously gone behind our backs and modified a local setting.

Configure EFS Recovery Policy Processing

Once enabled, this policy setting has three potential options:

1. Allow Processing across a Slow Network Connection When this option is selected, it does nothing.
2. Like IP Security, the EFS recovery settings are always downloaded—even over slow networks. This is the same bug shown earlier in Figure 3-12. To repeat, EFS recovery policy is always processed, regardless of link speed.

1. Do Not Apply during Periodic Background Processing If this option is selected, the latest EFS recovery settings in Active Directory GPOs are not downloaded or applied during the background refresh.
2. Process Even If the Group Policy Objects Have Not Changed If this option is selected, it updates and reapplies the policy settings in this category even if the underlying GPO has not changed. Recall that this type of processing is meant to clean up should a user or an administrator have nefariously gone behind our backs and modified a local setting.

Configure Wireless Policy Processing

If this policy setting is enabled, it has three potential options:

1. Allow Processing across a Slow Network Connection Check this option to allow the latest wireless policy settings to download when the user is logging on over slow links. Enabling this could cause your users to experience a longer logon time.
2. Do Not Apply during Periodic Background Processing If this option is selected, the latest wireless policy settings will not be downloaded or applied during the background refresh.
3. Process Even If the Group Policy Objects Have Not Changed If this option is selected, it updates and reapplies the policy settings in this category even if the underlying GPO has not changed. Recall that this type of processing is meant to clean up should a user or an administrator have nefariously gone behind our backs and modified a local setting.

Configure Wired Policy Processing

This policy setting is valid only when applied to Windows Vista and later. If this policy setting is enabled, it has three potential options:

1. Allow Processing across a Slow Network Connection Check this option to allow the latest wired policy settings to download when the user is logging on over slow links. Enabling this could cause your users to experience a longer logon time.
2. Do Not Apply during Periodic Background Processing If this option is selected, the latest wired policy settings will not be downloaded or applied during the background refresh.
3. Process Even If the Group Policy Objects Have Not Changed If this option is selected, it updates and reapplies the policy settings in this category even if the underlying GPO has not changed. Recall that this type of processing is meant to clean up should a user or an administrator have nefariously gone behind our backs and modified a local setting.

Configure Disk Quota Policy Processing

If this policy setting is enabled, it has three potential options:

1. Allow Processing across a Slow Network Connection Check this option to allow the latest disk quota policy settings to download and apply when the user logs on over slow links. Enabling this could cause your users to experience a longer logon time.
2. Do Not Apply during Periodic Background Processing If this option is selected, the latest disk quota policy settings will not be downloaded or applied during the background refresh.
3. Process Even If the Group Policy Objects Have Not Changed If selected, this option updates and reapplies the policy settings in this category even if the underlying GPO has not changed. Recall that this type of processing is meant to clean up should a user or an administrator have nefariously gone behind our backs and modified a local setting.

Always Use Local ADM Files for Group Policy Object Editor

ADM files are the underlying language that creates policy settings in pre–Windows Vista versions. I’ll talk more about ADM files and how to best use them in Chapter 6. However, for reference, if a computer is affected by this policy setting, the Group Policy Object Editor attempts to show the text within the ADM files from your local %windir%inf directory (usually C:windowsinf). If the ADM file is different inside the GPO than on your local C:windowsinf directory, you could end up seeing different settings and Explain text than what’s inside the GPO.

Indeed, if this policy is enabled, you might now see totally different policy settings than were originally placed in the GPO. However, you might want to enable this policy setting if you know that you will always be using one specific management station. Stay tuned for Chapter 6 to see how to use this function.

Turn Off Local Group Policy Objects Processing

If a Windows Vista or later computer is affected by this policy setting, then whatever is set within the local GPOs is ignored.

This can be useful if a machine is originally used in a workgroup (non–domain joined environment) and then it’s joined to the domain. In that case, you might want to ensure that no user has any lingering policy settings that will specifically affect them. Hence, your desire would be to control everything from Active Directory and not anything from the local level.

Of course, this policy setting only works when being delivered from Active Directory (not when it’s set locally).

This policy setting affects only Windows Vista and later machines (including Windows Server 2008 machines and later).

Specify Startup Policy Processing Wait Time

This policy setting helps with timeouts when processing Group Policy. The policy setting only exists for Windows Vista and later; however, the facility to control these timeouts exists in other operating systems (like Windows XP/SP2 with a Registry hack).

Check out KB article 840669 (found here: http://tinyurl.com/88tbo) if you want to implement this setting for Windows XP/SP2 and earlier machines.

Specify Workplace Connectivity Wait Time for Policy Processing

This value is used if you’re using workplace connectivity (aka DirectAccess).

If so, your computer can be running in the default of Asynchronous processing mode or be switched back to the Windows 2000 behavior of Synchronous processing mode (my suggestion).

If running Asynchronously, then the computer will continue on whether or not it can see your company across the Internet. The downside here is that you might miss the signal for something that could only process in the foreground (like Group Policy Preferences Drive Maps).

If running in Synchronous processing mode, the computer will wait (by default) 60 seconds to see your company across the Internet. After that, it “gives up” and lets the user log on.

If you want to force the waiting to be longer (in the case of Synchronous processing, or even in the case of Asynchronous processing), then set this value. The computer will wait this many seconds before continuing.

Configure Direct Access Connections as a Fast Network Connection

If you are using DirectAccess—see the section “Always Get Group Policy (Even on the Road, through the Internet).” You might want to treat all DirectAccess connections as fast —even if they aren’t.

This seems like a good idea to me, because that way, your users will get the exact same Group Policy experience in the office and out of the office (even if it takes a little bit longer).

This setting only affects Windows 8 and later and Windows Server 2012 and later. If you want to affect a Windows RT machine, you need to specify this setting locally, manually, since Windows RT machines cannot receive Active Directory–based Group Policy.

Allow Asynchronous User Group Policy Processing When Logging On through Remote Desktop Services

Remember: Group Policy will process synchronously for servers of all types and asynchronously for clients (Windows XP and later). By running Group Policy asynchronously, you ensure that logins may run a little bit faster, but at the sacrifice of not always having the latest Group Policy settings at login time.

If you set this policy, you’re making your Windows 2008 (and later) Remote Desktop Services (Terminal Servers) work like client systems do by default.

I wouldn’t set this setting, personally, because I’m a fan of running synchronously, not asynchronously (even if it means things are a teensy-weensy bit slower at login). But that’s just my opinion.

Change Group Policy Processing to Run Asynchronously When a Slow Network Connection Is Detected

This setting tells slow machines to avoid processing any CSE that requires synchronous processing.

I don’t recommend having this setting on. Here’s why:

• If your user isn’t yet logged in and uses the VPN connection, then you’ll be specifically avoiding items that process synchronously like Group Policy Preferences Drive Maps (if you use Windows 7 clients).
• If you are already logged in, then the user makes their VPN connection, then—well, it won’t matter. That’s because if you’re already logged in, you would have missed the opportunity to process items like Group Policy Preferences Drive Maps (on Windows 7), because it can only process them at login time.

In short, don’t bother with this setting. It makes my head hurt just thinking about what will and won’t process. Ow.

Turn Off Group Policy Client Service AOAC Optimization

In the earlier section “Windows 8, 8.1, and 10 Group Policy: Subtle Differences,” I described how the Group Policy service on Windows 8 and later will turn itself off after 10 minutes of idle time.

If you wanted to revert back to the Windows 7 style (which leaves the service always on), you would configure this setting to Enabled.

You might want to do this for Windows 8 and later desktops, since there is very little downside. And you might want to leave this behavior as is (that is, leave this setting Not Configured) for Windows 8 and later laptops to squeeze the extra battery life out of them.

Enable AD/DFS Domain Controller Synchronization during policy refresh

The help text description says it all.

“Enabling this setting will cause the Group Policy Client to connect to the same domain controller for DFS shares as is being used for Active Directory.”

Therefore, when it’s enabled, you are ensuring that the Group Policy client isn’t making another connection to some other DC just to get Group Policy if it’s also using DFS.

Configure Group Policy Caching and Enable Group Policy Caching for Servers

In the earlier section “Windows 8, 8.1 and 10 Group Policy: Subtle Differences” in Secret 6, I explained Group Policy Caching and talked about these two settings.

Configure Logon Script Delay

In the earlier section “Windows 8, 8.1 and 10 Group Policy: Subtle Differences” in Secret 8, I talked about how Windows will delay login script processing and also showed you this policy setting to tweak and configure if you decided.

The Missing Group Policy Preferences Policy Settings

As I stated, you could use a Windows 10 or Windows Server 2016 machine as your management machine and get the same Group Policy features. This is mostly true, except in one big case.

Seriously, this is weird, so stick with me. In Figure 3-13 you can see two screen shots. The left shows the Windows 10 management machine view of the Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Group Policy node. The right shows the same thing, except seen from a Windows Server 2016 management machine.

In fact, the list goes on for so long on the right that I’ve saved space and cut it off.

So, what are these “missing” definitions? These are the settings used to control, manage, and monitor the Group Policy Preferences (basically, what all of Chapter 5 is about.)

You’ll see specific policy definitions to manage and Group Policy Preferences items like Printers Policy Processing, Shortcuts Policy Processing, Start Menu Policy Processing, and all sorts of other Group Policy Preferences–specific settings.

Look closely, and you’ll also see another whole node within the Group Policy node called “Logging and tracing” that’s only available in the definitions on Windows Server 2016.

Okay, so what gives?

We’ll use and understand these settings in Chapter 5 in the “Troubleshooting: Reporting, Logging, and Tracing” section and learn more about where the definitions come from in Chapter 6.

But since you can’t wait that long, here’s the abbreviated version. In short, the “definitions” of what’s possible in Group Policy–land are stored in ADMX files (again, more detail—a lot more detail—in Chapter 6). Turns out, though, that Windows clients and Windows Server don’t ship with the exact same definitions.

Kooky. The “missing” Group Policy settings are only available within the set that exists on Windows Server.

In Chapter 6 we’ll revisit the topic of where policy definitions come from. I’ll show you how to make sure you always have the “latest set” of policy settings, so they’re no mystery—you’ll always have the latest set.

This blog entry spells it all out (in the section “Logging and tracing missing from RSAT”): http://tinyurl.com/kowj66.

Final Thoughts

Group Policy doesn’t just pick and choose when it wants to apply. Rather, a specific set of rules is followed when it comes time to process. Understanding these rules is paramount in helping you prevent potential Group Policy problems.

Here are a few takeaway tips to keep in mind:

1. Remember background refresh policy processing (member computers). For all machine types, regular member computers refresh some time after the user is logged on (usually 90 minutes or so).
2. Remember when GPOs apply and don’t apply. By default, workstations (like Windows 10) will process GPOs only in the background (asynchronously). Some features, such as Software Distribution and Folder Redirection, can take two reboots or logons to take effect. Advanced Folder Redirection can take three logons before you see an effect. This is because these special functions can be processed only in the foreground.
3. Decide when to leave Fast Boot on or turn it off. You can turn off Fast Boot to make Group Policy process more practicably.
4. You can leave Fast Boot on to make Group Policy process faster as the user is logging on.
5. Again, my revised advice is to turn off Fast Boot for well-connected (hardwired) machines and to leave it on for any kind of computer that could roam.
6. Remember background refresh policy processing (Domain Controllers). All Domain Controllers receive a background refresh every five minutes (after replication has occurred).
7. Security policy processing occurs every 16 hours. For all operating systems, just the security settings within all GPOs are reprocessed and applied every 16 hours, regardless of whether security settings have changed. This ensures that all security functions in all GPOs are reprocessed if someone has manually gone around the security on the system.