Group Policy Processing Principles

If you're phasing out Windows 2000 in favor of Windows XP, it's likely to be a long time before all your Windows 2000 machines are totally out the door. With that in mind, we'll take a look at how Windows 2000, Windows 2003, and Windows XP process Group Policy. Indeed, to better understand how Windows XP processes its policy, I highly recommend that you understand how Windows 2000 does its thing firstto understand how and why Windows XP's processing is different.

To better understand how GPO processing works, we're going to walk through what happens to two users:

Wally, who only uses a Windows 2000 Professional machine
Xavier, who only uses a Windows XP Professional machine

By using Wally and Xavier as our two sample users (on our two sample computers), we can see precisely when Group Policy applies to themwhen they're using Windows 2000 and Windows XP machines.

Before we go even one step further, let me debunk a popular myth about Group Policy processing. That is, Group Policy is never pushed from the server and forced upon 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.

Note	In Chapter 7, I'll show you a technique that emulates the same effect as if you were performing a push to all your clients. Additionally, on GPanswers.com, in the Third Party Tools section, I have a pointer to a free download that also performs a similar function.

In a nutshell , Group Policy is potentially triggered to apply at four times. Here's a rundown of those times; I'll discuss them in grueling detail in the next sections.

Initial Policy Processing For Windows 2000 and Windows 2003 machines, processing occurs when the computer starts up or when the user logs on. By default, there is no initial policy processing for Windows XP machines.

Background Refresh Policy Processing (Member Servers) For Windows 2000, Windows 2003, and Windows XP member machines, processing occur some time after the user logs on (usually 90 minutes or so). A bit later, you'll see how Windows XP is unique and leverages the background policy processing mechanism to a distinct advantage.

Background Refresh Policy Processing (Domain Controllers) Windows 2000 and Windows 2003 Domain Controllers need love too, and to that end, they receive a background refresh every 5 minutes (after replication has occurred).

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.

Note

You can change the default behavior of certain nonsecurity policy settings so that they are enforced in a manner similar to the way that security settings are automatically enforced. But you have to explicitly turn this feature on, and you have to do so correctly. In the "Security Policy Processing" section, I describe how to do this and give you several examples of why you would want to do so.

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, 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:

Windows 2000 Professional, Windows 2000 member servers, and Windows 2003 member servers all act the same way.
Windows 2000 Domain Controllers and Windows 2003 Domain Controllers act the same way.
Windows XP is a bit peculiar and does some things its own way, but you can make it act like its Windows 2000 cousin.

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 . Windows 2000 and Windows 2003 are capable of what is called initial policy processing. Windows XP is also capable of initial policy processing, but it doesn't work quite the same as its Windows 2000 counterpart .

Windows 2000 Initial Policy Processing

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 (or reboot). When a Windows 2000 or Windows 2003 machine starts up, it states that it is processing security policy. At that time, the workstation logs on to the network by contacting a Domain Controller. The Domain Controller (with DNS information) 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 all goes, you'll see it's a lock-step mechanism: the computer starts up and then processes GPOs in the natural order: site, domain, and each nested OU. The user then logs on, and Group Policy is processed, again in the natural order: site, domain, and each nested OU. This style of GPO processing is called synchronous processing . That is, in order to proceed to the next step in either the startup or logon processes, the previous step must be completed. For example, the GPOs at the OU level of the user are never downloaded before the GPOs at the site level. Likewise, the GPOs at the domain level for the Windows 2000 (and Windows Server 2003) are never downloaded before the site GPOs that affect a computer.

Therefore, the default for Windows 2000 (and Windows Server 2003) for both the computer startup and user logon is that each GPO is processed synchronously. This same process occurs every time a user booting a Windows 2000 (or Windows Server 2003) machine turns on the machine and then logs on.

Windows XP Initial Policy Processing

Xavier walks into his office and turns on his Windows XP Professional machine. For a moment, let's assume this is the first time that this Windows XP Professional 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 Professional machine will act just like Windows 2000 (and Windows 2003). It will look to see which site, domain, and OUs the computer account is in and then applies GPOs synchronously.

Likewise, let's assume this is the first time Xavier is logging in to 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 Windows 2003) 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 on to this particular Windows XP machine before. To understand Windows XP's normal default processing mode, take a deep breath and read on.

Background Refresh Policy Processing

Once Wally is logged on to Windows 2000 (or Windows 2003) and Xavier is logged on to Windows XP, things are greatfor everyone. As the administrator, we're happy because both Wally and Xavier are 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 Object Editor that should affect a user or a computer? Aren't both Wally and Xavier are already logged onhappy as clams? Well, when this happens, 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 vs. 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.

Note	Standard application mechanism still applies; and the precedence order is still reflected: site, domain, OU. In other words, even though a new GPO linked to a site is ready, it isn't necessarily going to trump a GPO linked to the OU.

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

Background Refresh Intervals for Windows 2000/2003 Members

It stands to reason that when we change an existing GPO (or create a new GPO) we would 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 and Xavier is on his Windows XP machine.

By default, the background refresh interval for Windows 2000 workstations and Windows 2000 and Windows 2003 member servers is 90 minutes, with a 030 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 work station that is already logged on to the network to see that change.

Tip

Microsoft documentation isn't consistent in this description. Often, Microsoft documentation will say the offset is 30 minutes (which could be interpreted as positive or negative 30 minutes). Indeed, in the first edition of this book, I incorrectly reported that "fact." However, since then, I have verified with Microsoft that the refresh interval is (and has always been) 90 minutes plus (not minus) 030 minutes.

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 or user half might be refreshed before the other half; they're not necessarily refreshed at the exact 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 this chapter in the section cleverly entitled "Using Group Policy to Affect Group Policy."

Tip

You can manually prevent an individual computer from asking for the background refresh by hacking HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system , adding a DWORD key named DisableBkGndGroupPolicy and giving it a value of 1. You can set individual policy settings to prevent specific areas of Group Policy from being refreshed in the background, such as Internet Explorer Maintenance and Administrative Templates. See the "Using Group Policy to Affect Group Policy" section later in the chapter.

How Does the Group Policy Engine Know What's New or Changed?

The Group Policy engine on Windows 2000 and Windows XP can keep track of what's new or changed via a control mechanism called version numbers . Each GPO has a version number for each half of the GPO, and this is stored in Active Directory. If the version number in Active Directory doesn't change, nothing is downloaded. Since nothing has changed, the Group Policy engine thinks it has all the latest-greatest stuffso why bother to redownload it (which takes time) and reprocess it (which takes more time)?

By default, when a background refresh interval arrives, a time-saving mechanism, "checking the GPO version numbers," is employed to minimize the time needed to get the latest-greatest GPOs. You'll learn more about GPO version numbers in Chapter 4.

To reiterate, when the background refresh interval arrives, only the new or changed GPOs are downloaded and processed.

Background Refresh Intervals for Windows 2000/2003 Domain Controllers

Even though neither Wally nor Xavier is logging on to Domain Controllers, other people might. And because Domain Controllers are a bit special, the processing for Windows 2000 Domain Controllers (and Windows 2003 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 five minutes. This adds a tighter level of security to Domain Controllers. For more information on precisely how the default GPOs work, see Chapter 6.

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

Tip	You'll learn more about affecting Domain Controllers' security in Chapter 6.

Background Refresh Exemptions

Wally has been logged on to his Windows 2000 machine 4 hours, and Xavier has been logged on to his Windows XP machine for the same amount of time. Clearly, the background refresh interval has come and gonesomewhere between two and three times.

If any GPOs had been created or any existing GPOs had changed while Wally and Xavier 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:

Folder Redirection (explored in detail in Chapter 9 ) 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 next logon.

Software Installation (explored in detail in Chapter 10 ) 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.

Tip	There are Third Party tools that hook into Group Policy, which will permit the deployment of software whilethe user is logged on. Check out GPanswers.com in the "Third-Party Tools" section.

Logon, Logoff , Startup, and Shutdown Scripts (explored in detail in Chapter 6 ) These scripts are run only at the appointed time (at logon, logoff, startup, or shutdown). These are not run again and again when the background processing interval comes around. Note that script updates (e.g.: location and path changes) are updated while the user is already logged on. It's just that, of course, they won't run again until the appointed time.
Disk Quotas (explored in detail in Chapter 9 ) These are not run when the background processing interval comes around. They are only run at computer startup.

Windows XP and Background Processing

As I stated in the introduction to this section, Windows XP is the black sheep of the family. Let's see how this works.

Now that Xavier has logged on to his Windows XP Professional machine for the first time, his session 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 logs on the second time (and all consecutive times) to his Windows XP machine, initial policy processing will no longer be performed as described in the "Initial Policy Processing" section earlier in this chapter. From this point forward, at startup or logon, Windows XP 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 and Windows XP are different, here's the short answer. When Windows XP Professional was in development, all the stops were pulled to make the "XPerience" as fast as possible. Both boot times and logon times are indeed now faster than ever, but the tradeoff does come at a price.

By default, Windows XP Professional processes GPOs asynchronouslyboth at computer startup and at user logon. Upon startup, the computer doesn't wait for the network interface to initialize before starting to process computer GPOs. Windows XP uses the last-known down loaded GPOs (held in cache) as its baseline, even if GPOs have changed in Active Directory while the Windows XP machine was turned off.

While the network card is still warming up and finding the network and the first Domain Controller, the previously cached computer GPOs are already being processed! Then, the "Press Ctrl+Alt+Delete to begin" prompt is presented to the user. While this prompt is presented, Windows XP downloads any new computer GPOs. These new computer GPOs are not applied until a bit later.

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. Rather, the system simply processes any cached user GPOs from the last-known GPOs applied in the cache. New GPOs are downloaded, but processing is deferred.

Once the computer has started, the user is logged on, and any cached computer and user GPOs are applied, 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 processing GPOs with computer policy settings) as well as faster logon time (when processing GPOs with user policy settings). The most important policy settings, such as updated Security settings and Administrative Templates (Registry updates), are applied soon after logonand no one is the wiser. Microsoft calls this Windows XP Group Policy processing behavior Fast Boot (sometimes called Windows XP "Logon Optimization"). Yes, it does speed things up a bit, but at a cost.

Windows XP Fast-Boot Results

Windows XP Fast Boot affects two major components : Group Policy processing and user-account attribute processing. The (sometimes strange ) results occur only for Xavier, on his Windows XP Professional machine when he has previously already logged on to it. On his Windows 2000 machine, Wally is spared the following weird behavior.

WINDOWS XP FAST BOOT GROUP POLICY PROCESSING DETAILS

The immediate downside to Windows XP's Fast Boot approach is that, potentially, a user at a Windows XP Professional desktop could be totally logged on but not quite have all the GPOs processed. Then, once they are working for a little whilepop! A setting takes effect out of the blue. This is because not all GPOs were processed before the user was presented with the desk top and Start menu. Your network would have to be pretty slow for this scenario to occur, but it's certainly possible.

The next major downside takes a bit more to wrap your head around. Some Group Policy (and Profile) features can potentially take Windows XP Professional 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 must be processed in the foreground (or synchronously) to prevent data corruption.

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

Windows XP Professional fakes it and tags the machine when a Software Package is targeted for a Windows XP Professional client. The next time the user logs on, 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 Professional typically requires 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, as you'll see in Chapter 9, 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 machines won't get the effects of Basic Folder Redirection for two logons! And Windows XP 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 Redirectionsynchronously for just that one logon.

Note

Again, remember that Fast Boot is automatically disabled the first time any Windows XP machine is started as a member of the domain. It is also disabled the first time any new user logs on to a Windows XP Professional client. In these situations, Windows XP assumes (correctly) that no GPO information is cached and therefore must go out to Active Directory to get the latest GPOs. The net effect is that if settings for either (or both) Folder Redirection policy and Software Distribution policy already exist, the user will not require additional logons or reboots the first time they log on to a Windows XP machine or when the computer is started for the first time after joining the domain.

WINDOWS XP FAST BOOT USER-ACCOUNT ATTRIBUTE PROCESSING DETAILS

Group Policy is only one of two areas affected by Windows XP's Fast Boot. Some Microsoft documentation claims that other parts of the user's information could require several logons or reboots in order to take effect.

The idea is that certain attributes are cached and assumed to be accurate at logon. If, after a background download the information is actually changed, it would only be on the next logon that the change will take effect.

Microsoft says Windows XP takes two logons or reboots to process the following attributes:

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

Now, to be 100% honest, I have not observed this behavior. In my testing, the above attributes take exactly one logoff or reboot to processregardless if Fast Boot is enabled or not.

Yet, Microsoft maintains that under certain circumstances (with Fast Boot enabled) the above will hold true. So, if the user is using Windows XP, and any of these properties is changed in Active Directory, it could take two logons for these changes to actually take effect.

Turning off Windows XP Fast Boot

If you want your Windows XP Professional users to log on a teeny-weeny bit faster, by all means, leave the default of Fast Boot on. If you're doing some no-nos in Group Policy, (namely setting up cross-domain Group Policy links or processing a lot of site-based GPOs), leaving Fast Boot on will, in fact, serve its purpose and likely make each and every startup and logon a wee bit faster.

My recommendation, however, is to get all your machinesWindows XP and Windows 2000 Professionalto act the same. That is, I suggest that you force your Windows XP Professional machines to act like Windows 2000 Professional machines and perform synchronous policy processing during their startup and logon. To do this, you need to set a Group Policy that contains a setting to revert Windows XP machines to the old behavior. It might be a smidgen slower to log on, but no slower than your Windows 2000 machines already experience.

This will make your Windows XP machines perform initial policy processing at startup and logonjust like your Windows 2000 machines. That is, the computer will start up, locate all GPOs, and then process thembefore displaying the "Press Ctrl+Alt+Delete to begin" prompt. Once the user is logged on, all GPOs are processed before the desktop is displayed.

Troubleshooting Group Policy is now a heck of a lot more predictable because you're not trying to guess when Software Distribution, Folder Redirection, or even the errant Administrative Template setting is going to be processed. Since your Windows 2000 machines already act this way (and you can't make Windows 2000 Fast Boot like Windows XP), it probably would be a good enterprise supportability practice to have all machines in your environment act as similarly as possibleeven if they are different operating systems.

To revert Windows XP Professional to the Windows 2000 synchronous behavior, for Initial Policy Processing, create and link a GPO (preferably at the domain level) to simply enable the policy setting named Always wait for the network at computer startup and logon . This policy can be found in the Computer Configuration ˜ Administrative Templates ˜ System ˜ Logon branch of Group Policy. The name of this policy setting is a bit confusing. It would have been better, in my opinion, to name it Make Windows XP Act Like Windows 2000 . But it isn't.

Tip

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. It really only makes XP machines act like Windows 2000.

Remember, to force Windows XP machines to receive this computer policy (or any computer policy), the computer account must be within the site, domain, or OU at which you set the policy. If you set this policy at the domain level, you're guaranteed that all Windows XP machines in your domain will get the policy.

Note

By performing this at the domain level, all your machinesWindows XP, Windows 2000, and Windows 2003will receive the message. But remember that policy settings meant for Windows XP won't apply on Windows 2000 machines. And it's a moot point for Windows 2003 machines anyway, as you'll see in the next section.

Forcing Background Policy Processing

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 Wally and Xavier's user objects so they can use the new proxy server via Internet Explorer Maintenance Settings. 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 Wally or Xavier to log off and log back on to get the policythey 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 in some way on the server will actually come down and be reflected on your client machines.

Initiating a Manual Background Refresh for Windows 2000

The command-line tool used to encourage your Windows 2000 machines to kick off a manual background refresh is SECEDIT.SECEDIT can request the refresh of GPOs (and the settings therein) from the User Configuration node, the Computer Configuration node, or both, but you'll need to run the command once for each half.

As I've mentioned, there is no way from up on high to say, "Go forth and refresh, all ye users or computers affected by this recent change in policy!" To utilize SECEDIT , you must physically be present at the Windows 2000 machine and execute the command. Otherwise, you must simply wait for the background refresh interval to kick in.

Note	You can independently change the background refresh interval of both the user and computer. See the "Using Group Policy to Affect Group Policy" section later in this chapter.

But, because you're impatient, you want to see Wally on his Windows 2000 machine start using that new proxy server setting that you plunked into that GPO right away. So you physically trot out to his machine, log on with administrator-level authority, and enter the following commands to manually refresh the GPOs.

For Windows 2000, follow these steps to request a refresh of GPOs from the User Configuration node:

Choose Start ˜ Run to open the Run dialog box, and in the Open box, enter cmd to open the command-line window.
At the prompt, type secedit /refreshpolicy user_policy .

For Windows 2000, follow these steps to request a refresh of GPOs from the Computer Configuration node:

Choose Start ˜ Run to open the Run dialog box, and in the Open box, enter cmd to open the command-line window.
At the prompt, type secedit /refreshpolicy machine_policy .

See Chapter 6 for additional uses of the SECEDIT command.

Tip	You might want to create a batch file called s. bat or even gpupdate. bat, which run secedit to initiate machine and user policy settings to apply. Then, if you place this batch file on all your workstations, you can perform both in one stroke!

Initiating a Manual Background Refresh for Windows XP and Windows 2003

You now want to initiate a manual refresh for Xavier on his Windows XP machine. Windows XP and Windows 2003 refresh GPOs using a different command called GPUpdate. GPUpdate is similar to SECEDIT in that it can refresh either the user or computer half of a GPO or both. The syntax is GPUpdate /Target:Computer, /Target: User , or just GPUpdate by itself to trigger both.

Running GPUpdate while Xavier is logged on to his Windows XP machine immediately gives him the new settings in the GPO you just set. This is, of course, provided the Domain Controller that Xavier and his Windows XP machine are using has the replicated GPO information.

Additionally, GPUpdate can figure out if newly changed items require a logoff or reboot to be active. Since Windows XP's default behavior is to enable Fast Boot, Software Distribution and Folder Redirection settings are processed only at future logon times. Therefore, specifying GPUpdate with a /Logoff switch will figure out if a policy has changed in Active Directory such that a logoff is required and 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, with Windows XP's Fast Boot enabled, GPOs that have Software Distribution settings will 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.

Tip	For information about how to turn off Windows XP's Fast Boot and make it act like Windows 2000, refer to the "Turning Off Windows XP Fast Boot" section earlier in this chapter.

Security Background Refresh Processing

Even before Microsoft had the big, internal security hurrah, some modicum of security was built into the Group Policy engine. As I've stated, Windows 2000, Windows 2003, and Windows XP clients process GPOs when the background refresh interval comes to passbut 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 4 hours. Likewise, Xavier has been logged on to his Windows XP machine for 4 hours. Imagine for a second that there was a GPO in Active Directory named "Remove Run menu from Start menu" and its function was 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 and Xavier as local administrators of their Windows 2000 and Windows XP machines. Since Wally and Xavier 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 GPO on the domain controllers don't change, but certain parts of the workstation should remain locked down anyway.

Let's examine two potential exploits of the Group Policy engine.

Group Policy Exploit Example #1: Going Around an Administrative Template Consider the Task Scheduler example we looked at in the previous chapters. We created a GPO named "Prohibit new Tasks in Task Scheduler" and put the enabled the policy setting named Prohibit New Task Creation within it. We linked the GPO to the Human Resources Computers OU. Our edit affected all users on our computers (including our administrators) such that the "Add scheduled Task" ability was not accessible in the Task Scheduler within Control Panel. 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.1.

Figure 3.1: simple deletion of the Registry entry will nullify our policy setting.

After the local administrator changes the setting, then "Add Scheduled Task" ability is immediately displayed. (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 "Add Scheduled Tasks" ability. But it doesn't. This ability won't get relocked down upon a 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.

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 workstation administrator performed behind its back. Windows 2000, Windows XP, and Windows 2003 clients are not protected from this sort of attack by default. However, the protection can be made stronger. (See the "Mandatory Reapplication for Non-Security Policy" section later in this chapter.) Okay, this 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).

Group Policy Exploit Example #2: Going Around a Security Policy Setting Via Group Policy, we use the material in Chapter 6 to create a security template (and corresponding security policy) that locks down the \windows\repair directory with specific file ACLs. For this example, imagine we set the \windows\repair directory so that only the Domain Administrators have access. Then, behind our backs, Xavier, now a local administrator, changes these file ACLs to allow everyone full control to these sensitive files. Uh-oh, now we could have a real problem on our hands.

Windows 2000 and Windows XP each offer protection to handle clean-up for exploits of these types. Let's see how that works.

In the first example, we went around the Prohibit New Task Creation policy setting by forcefully modifying the Registry. The Scheduled Tasks section of control panel 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 for Windows 2000, Windows 2003, and Windows XP

The Group Policy engine tries to clean up after examples such as Exploit #2 by asking for a special background refreshjust for the security policy settings. This is called the background security refresh. Every 16 hours (with a 30-minute offset), a client asks Active Directory for all the security- related GPOs that apply for it (not just the ones that have changed). 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.

Note

You can manually change this security refresh interval in two ways. First, you can editing the local workstation's Registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-OOC04F79F83A}\MaxNoGPOListChangesInterval and add a REG_DWORD signifying the number of minutes to pull down the entire security policy (by default, every 16 hours). You can also use the Security Policy Processing policy, which is described in the "Using Group Policy to Affect Group Policy" section, later in this chapter. For more information, see the Microsoft Knowledge Base article 277543.

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\repair directory would have the intended permissions re- thrust upon it. Okay, great. But in Exploit #1, our evil administrator went around the Prohibit New Task Creation policy setting. And the background security refresh would not have re-enforced our intended will upon the system. The Task Scheduler 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 Non-Security 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. 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 as. But what about Exploit #1 in which Wally (who was anointed as a local workstation administrator) went around the Prohibit New Task Creation policy setting by hacking his local Registry?

Well, the New Task Creation settings aren't a security policy. But it still could be thought of as a security hole you need to fill. With a little magic, you can enforce 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 "Affecting the Computer Settings of Group Policy" section.

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

As you'll see in the "Affecting the Computer Settings of Group Policy" section, you can use the GUI to select other areas of Group Policy to enforce along with the background refresh. But, in three specific cases, selecting to do so will not actually do anything to change how they are processed by default: Software Distribution, Folder Redirection, and Scripts.

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

Note

As you'll see in Chapter 4, a bit more is going on between the client and the server. Underneath the hood, the client keeps track of the GPO version number. If the version number changes in Active Directory, the GPO is flagged as being required for download; it is then redownloaded and applied. If the version number stays the same in Active Directory, the Group Policy isn't redown loaded or applied. Stay tuned for more on GPO version numbers in Chapter 4.

Manually Forcing Clients to Process GPOs (Revisited)

In the "Forcing Background Refresh Processing" section, I talked a bit about what happens if you set up a new GPO (or change an existing one) and get impatient. That is, you want to force your client systems to embrace your new settings.

As I've said, there's no way from on high to shout to your client computers and proclaim: "Accept my latest GPOs, ye mere mortals and puny systems!"

If you want to kick off policy processing at a client, you need to trot on over to it to kick it in the shins. You use SECEDIT on Windows 2000 machines and GPUpdate on Windows XP and Windows 2003 machines. But the actions of these two similar tools are not quite the same, and that's what this section is about.

Windows 2000 SECEDIT with the /enforce Switch

Recall that you must run the Windows 2000 SECEDIT command-line tool on the client that you want to refresh. SECEDIT has an additional switch, /enforce , that ensures that all security-related settings are processed by the Windows 2000 workstationregardless of whether the underlying GPO has changed in Active Directory. Instead of waiting 16 hours, you can rush the hands of time and force the background security refresh processing to strike.

Again, only security-related policy that affects the user or computer will be requested from Active Directory to the Windows 2000 workstation. The commands are either:

 secedit /refreshpolicy machine_policy /enforce

 secedit /refreshpolicy user_policy /enforce

Windows XP and Windows 2003 GPUpdate with the /force Switch

Recall that you must run the Windows 2003 and Windows XP command-line tool GPUpdate on the client that you want to refresh. The /force switch looks similar to the /enforce switch for the Windows 2000 command-line tool SECEDIT , but it's not the sameit's better.

GPUpdate /force ensures that all settings in all GPOs are processed by the Windows XP (or Windows 2003) workstationregardless of whether the underlying GPO has changed in Active Directory. It doesn't just pull down the security-related policyno siree, Bob. GPUpdate /force pulls down all aspects of Group Policy regardless of whether the underlying GPO has changed. In this manner, it's leaps and bounds more powerful than its Windows 2000 counterpart.

The command is typically specified as:

 Gpupdate /force

Other options are available in conjunction with /force , such as the ability to logoff the user or reboot the machine should a foreground policy be required (in the case of, say, Software Distribution).

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 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 Group Policy engine may get confused about where the accounts it's supposed to work with are currently residing.

The Group Policy engine 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 the time it takes to replicate the change, plus a 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!